Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.283  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   10…   10.2…   10.3…   10.3.2   10.3.3…   10.3.4…   10.3.5…   10.3.6…   10.3.7…   10.3.8…   10.4…   10.5…   10.6…   10.6.2…   10.6.3…   10.7…   10.8…   10.11…   10.12…   10.14…   10.15…   10.17…

 

10.8  MCData short data servicep. 146

10.8.1  Generalp. 146

The present document specifies short data service (SDS) interworking between LMR users and MCData clients using one-to-one standalone SDS messages and group standalone SDS messages. The IWF behaves as a peer MCData server to other MCData servers.
When an LMR user attempts to send an LMR message to the MCData service, the IWF converts the LMR message into a request to send an MCData SDS. The method by which the IWF converts the LMR message into a request to send an MCData SDS is outside the scope of the present document.
When the IWF receives a request to send an MCData SDS to an LMR user or a group of LMR users, the IWF converts the request into one or more LMR messages. The method by which the IWF converts the MCData SDS request into an LMR messages is outside the scope of the present document.
Up

10.8.2  Information flows for the short data servicep. 147

10.8.2.1  Generalp. 147

The following subclauses define information flows for MCData SDS on the IWF-2 interface. MCData SDS related information flows on reference points other than IWF-2 are defined in subclause 7.4.2.1 of TS 23.282. In each case, the LMR users behind the IWF are represented by MCData IDs or a MCData group ID as appropriate and so the MCData server shall be capable of routing messages towards identities located behind the IWF.
Up

10.8.2.2  IWF MCData standalone data requestp. 147

Table 10.8.2.2-1 describes the information flow for the MCData standalone data request (in subclauses 7.4.2.2.2 and 7.4.2.3.2 of TS 23.282) sent from the MCData server to the IWF and from the IWF to a MCData server.
Information element Status Description
MCData IDMThe identity of the MCData user sending data
Functional aliasOThe associated functional alias of the MCData user sending data.
MCData IDMThe identity of the MCData user towards which the data is sent
Conversation Identifier
(see NOTE 1)
MIdentifies the conversation
Transaction Identifier
(see NOTE 1)
MIdentifies the MCData transaction
Reply IdentifierOIdentifies the original MCData transaction to which the current transaction is a reply to
Disposition TypeOIndicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination TypeMIndicates whether the payload is for application consumption or MCData client consumption
Application identifier
(see NOTE 2)
OIdentifies the application for which the payload is intended (e.g. text string, port address, URI)
PayloadMSDS content
NOTE 1:
A reserved value of the Information Element shall be defined which indicates that the sender does not support this Information Element.
NOTE 2:
The application identifier shall be included only if the payload destination type indicates that the payload is for application consumption.
Up

10.8.2.3  IWF MCData data disposition notificationp. 147

Table 10.8.2.3-1 describes the information flow for the MCData data disposition notification sent from the IWF to the MCData server and from the MCData server to the IWF.
Information element Status Description
MCData IDMThe identity of the MCData user towards which the notification is sent
MCData IDMThe identity of the MCData user sending notification
Conversation Identifier
(see NOTE)
MIdentifies the conversation
Disposition associationMIdentity of the original MCData transaction
DispositionMDisposition which is delivered, read, delivered and read, or disposition prevented by system
NOTE:
A reserved value of the Information Element shall be defined which indicates that the sender does not support this Information Element.
Up

10.8.2.4  IWF MCData group standalone data request (IWF - MCData server)p. 148

Table 10.8.2.4-1 describes the information flow for the MCData group standalone data request (in subclause 7.4.2.5.2 of TS 23.282) sent from the IWF to the MCData server when the IWF is acting as the initiating MCData client.
Information element Status Description
MCData IDMThe identity of the MCData user sending data
MCData group IDMThe MCData group ID to which the data is to be sent
Conversation Identifier
(see NOTE 1)
MIdentifies the conversation
Transaction Identifier
(see NOTE 1)
MIdentifies the MCData transaction
Reply IdentifierOIdentifies the original MCData transaction to which the current transaction is a reply to
Disposition TypeOIndicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination TypeMIndicates whether the payload is for application consumption or MCData client consumption
Application identifier
(see NOTE 2)
OIdentifies the application for which the payload is intended (e.g. text string, port address, URI)
PayloadMSDS content
NOTE 1:
A reserved value of the Information Element shall be defined which indicates that the sender does not support this Information Element.
NOTE 2:
The application identifier shall be included only if the payload destination type indicates that the SDS message is for application consumption.
Up

10.8.2.5  IWF MCData group standalone data request (MCData server - IWF)p. 148

Table 10.8.2.5-1 describes the information flow for the MCData group standalone data request (in subclause 7.4.2.5.2 of TS 23.282) sent from the MCData server to the IWF when the IWF is acting as proxy for MCData clients.
Information element Status Description
MCData IDMThe identity of the MCData user sending data
MCData group IDMThe MCData group ID to which the data is to be sent
MCData IDMThe identity of the MCData user towards which the data is sent
Conversation IdentifierMIdentifies the conversation
Transaction IdentifierMIdentifies the MCData transaction
Reply IdentifierOIdentifies the original MCData transaction to which the current transaction is a reply to
Disposition TypeOIndicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination TypeMIndicates whether the payload is for application consumption or MCData client consumption
Application identifier
(see NOTE)
OIdentifies the application for which the payload is intended (e.g. text string, port address, URI)
PayloadMSDS content
NOTE:
The application identifier shall be included only if the payload destination type indicates that the payload is for application consumption.
Up

10.8.2.6  IWF MCData data disposition notification(s) (MCData server to IWF)p. 148

Table 10.8.2.6-1 describes the information flow for the MCData data disposition notification(s) sent from the MCData server to the IWF when the IWF is acting as proxy for MCData client(s).
Information element Status Description
MCData IDMThe identity of the MCData user towards which the notification is sent
MCData IDMThe identity of the MCData user sending notification
Conversation IdentifierMIdentifies the conversation
Disposition associationMIdentity of the original MCData transaction
DispositionMDisposition which is delivered, read, delivered and read, or disposition prevented by system
Up

10.8.2.7  IWF MCData group standalone data request (IWF - MCData server)p. 149

Table 10.8.2.7-1 describes the information flow for the MCData group standalone data request (in subclause 7.4.2.6.2 of TS 23.282) sent from the IWF representing the MCData client to the MCData server.
Information element Status Description
MCData IDMThe identity of the MCData user sending data
MCData group IDMThe MCData group ID to which the data is to be sent
Conversation Identifier
(see NOTE 1)
MIdentifies the conversation
Transaction Identifier
(see NOTE 1)
MIdentifies the MCData transaction
Reply IdentifierOIdentifies the original MCData transaction to which the current transaction is a reply to
Transaction typeMStandalone transaction
Disposition TypeOIndicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination TypeMIndicates whether the SDS payload is for application consumption or MCData user consumption
Application identifier
(see NOTE 2)
OIdentifies the application for which the payload is intended (e.g. text string, port address, URI)
SDP offerMMedia parameters offered
NOTE 1:
A reserved value of the Information Element shall be defined which indicates that the sender does not support this Information Element.
NOTE 2:
The application identifier shall be included only if the payload destination type indicates that the SDS message is for application consumption.
Up

10.8.2.8  IWF MCData group standalone data request (MCData server - IWF)p. 149

Table 10.8.2.8-1 describes the information flow for the MCData group standalone data request (in subclause 7.4.2.6.2 of TS 23.282) sent from the MCData server to the IWF acting as proxy for MCData client(s).
Information element Status Description
MCData IDMThe identity of the MCData user sending data
MCData group IDMThe MCData group ID to which the data is to be sent
MCData IDMThe identity of the MCData user towards which the data is sent
Conversation IdentifierMIdentifies the conversation
Transaction IdentifierMIdentifies the MCData transaction
Reply IdentifierOIdentifies the original MCData transaction to which the current transaction is a reply to
Transaction typeMStandalone transaction
Disposition TypeOIndicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination TypeMIndicates whether the SDS payload is for application consumption or MCData user consumption
Application identifier
(see NOTE)
OIdentifies the application for which the payload is intended (e.g. text string, port address, URI)
SDP offerMMedia parameters offered
NOTE:
The application identifier shall be included only if the payload destination type indicates that the payload is for application consumption.
Up

10.8.2.9  IWF MCData group standalone data responsep. 150

Table 10.8.2.9-1 describes the information flow for the MCData group standalone data response (in subclause 7.4.2.6.2 of TS 23.282) sent from the IWF to the MCData server and from the MCData server to the IWF acting as proxy for other MCData clients.
Information element Status Description
MCData IDMThe identity of the MCData user receiving data
MCData group IDMThe MCData group ID to which the data is to be sent
MCData IDMThe identity of the MCData user sent data
Conversation Identifier
(see NOTE)
MIdentifies the conversation
SDP answerMMedia parameters selected
NOTE:
A reserved value of the Information Element shall be defined which indicates that the sender does not support this Information Element.
Up

10.8.3  Behaviour at the MCData Clientp. 150

The MCData client interfaces with the MCData server as specified in TS 23.282.

10.8.4  Behaviour at the IWFp. 150

The IWF interfaces with the MCData server via the reference points defined in subclause 7.4 of the present document.

10.8.5  Behaviour at the MCData serverp. 150

The MCData server behaves as specified in TS 23.282, with the addition that the MCData server shall route SDS messages addressed to MCData IDs and MCData group IDs that lie behind IWFs to the appropriate IWFs.

10.8.6  MCData user one-to-one SDS request to an LMR userp. 150

10.8.6.1  Signalling control planep. 150

The procedure for an MCData user requesting to send a signalling control plane SDS to a single LMR user is as specified in subclause 7.4.2.2 of TS 23.282 for the one-to-one standalone short data service using the signalling control plane, with the exception that MCData client 2 is located behind the IWF. The SDS is addressed to the MCData ID that has been allocated to the LMR user. The IWF behaves as a peer MCData server.
Up

10.8.6.2  Media planep. 151

The procedure for an MCData user requesting to send a media plane SDS to a single LMR user is as specified in subclause 7.4.2.3 of TS 23.282 for the one-to-one standalone short data service using the media plane, with the exception that MCData client 2 is located behind the IWF. The SDS is addressed to the MCData ID that has been allocated to the LMR user. The IWF behaves as a peer MCData server.
Up

10.8.7  LMR user one-to-one SDS request to an MCData userp. 151

10.8.7.1  Signalling control planep. 151

The procedure for an IWF requesting, on behalf of an LMR user, to send a signalling control plane SDS to a single MCData user is as specified in subclause 7.4.2.2 of TS 23.282 for the one-to-one standalone short data service using the signalling control plane, with the exception that MCData client 1 is located behind the IWF. The source address of the SDS is the MCData ID that has been allocated to the LMR user. The IWF behaves as a peer MCData server.
Up

10.8.7.2  Media planep. 151

The procedure for an IWF requesting, on behalf of an LMR user, to send a media plane SDS to a single MCData user is as specified in subclause 7.4.2.3 of TS 23.282 for the one-to-one standalone short data service using the media plane, with the exception that MCData client 1 is located behind the IWF. The source address of the SDS is the MCData ID that has been allocated to the LMR user. The IWF behaves as a peer MCData server.
Up

10.8.8  MCData user group SDS request to an MCData group including LMR usersp. 151

10.8.8.1  Signalling control planep. 151

The procedure for an MCData user requesting to send a signalling control plane SDS to an MCData group that includes one or more LMR users is as specified in subclause 7.4.2.5 of TS 23.282 for the group standalone short data service using the signalling control plane. In the case of implementation involving an IWF the difference is that one or more of the MCData clients 2 to n are located behind IWFs that have affiliated to the MCData group (see subclause 10.1.2 of the present document). The SDS is addressed to the MCData group ID. The IWF behaves as a peer MCData server. The IWF can also respond on behalf on a MCData client located behind the IWF to a disposition request with a disposition of 'disposition prevented by system' for forwarding to the originating MCData client.
Up

10.8.8.2  Media planep. 151

The procedure for an MCData user requesting to send a media plane SDS to an MCData group that includes one or more LMR users is as specified in subclause 7.4.2.6 of TS 23.282 for the group standalone short data service using the media plane. In the case of implementation involving an IWF the difference is that one or more of the MCData clients 2 to n can be located behind IWFs that have affilated to the MCData group (see subclause 10.1.2 of the present document). The SDS is addressed to the MCData group ID. The IWF behaves as a peer MCData server. The IWF can also respond on behalf on a MCData client located behind the IWF to a disposition request with a disposition of 'disposition prevented by system' for forwarding to the originating MCData client.
Up

10.8.9  LMR user group SDS request to an MCData groupp. 151

10.8.9.1  Signalling control planep. 151

The procedure for an IWF requesting, on behalf of an LMR user, to send a signalling control plane SDS to an MCData group is as specified in subclause 7.4.2.5 of TS 23.282 for the group standalone short data service using the signalling control plane, with the exception that MCData client 1 is located behind an IWF and one or more of the MCData clients 2 to n can be behind IWFs that have affiliated to the MCData group (see subclause 10.1.2 of the present document). The SDS is addressed to the MCData group ID. The IWF behaves as a peer MCData server to other MCData servers.
Up

10.8.9.2  Media planep. 152

The procedure for an IWF requesting, on behalf of an LMR user, to send a media plane SDS to an MCData group is as specified in subclause 7.4.2.6 of TS 23.282 for the group standalone short data service using the media plane, with the exception that MCData client 1 is located behind an IWF and one or more of the MCData clients 2 to n can be behind IWFs that have affiliated to the MCData group (see subclause 10.1.2 of the present document). The SDS is addressed to the MCData group ID. The IWF behaves as a peer MCData server to other MCData servers.
Up

10.9  IWF as a security gatewayp. 152

10.9.1  Support for transcoding with encrypted speechp. 152

In some cases when encryption of voice media is required in the MC system, the MCPTT user(s) and the LMR user(s) can use different codecs. In these cases, transcoding is needed and before transcoding can occur, encryption applied to the voice media by the MC system needs to be removed. After transcoding, LMR encryption can be applied (out-of-scope of the present document). An IWF can perform these functions and be deployed as a security gateway between the MCPTT system and the LMR system. When the IWF removes the encryption applied by the MC system, the IWF must perform key management procedures defined in TS 33.180 to obtain the key material for the group.
Up

10.10  Simultaneous interworked calls (on-network)p. 152

10.10.1  Generalp. 152

An IWF representing an LMR user may support simultaneous interworked calls for the same LMR user. The LMR user can become involved in simultaneous interworked calls when the IWF invites, joins or accepts more than one interworked call on behalf of the LMR user, or when the IWF affilates the LMR user to multiple groups. This subclause is based on the subclause for simultaneous session for MCPTT calls in subclause 10.8 of TS 23.379.
How the IWF accomodates simultaneous interworked calls to a single LMR user is outside the scope of the present document.
Up

Up   Top   ToC