Content for TS 23.283 Word version: 18.1.0

1… 10… 10.2… 10.2.2… 10.2.3… 10.3… 10.3.3… 10.3.3.7… 10.3.4… 10.3.4.4… 10.3.5… 10.3.5.8… 10.3.6… 10.3.7… 10.3.7.5… 10.3.8… 10.4… 10.4.4… 10.5… 10.5.7… 10.6… 10.6.2… 10.6.2.3… 10.6.3… 10.6.4… 10.7… 10.8… 10.11… 10.11.4… 10.12… 10.14… 10.15…

10.8 MCData short data service 10.8.1 General 10.8.2 Information flows for the short data service 10.8.2.1 General 10.8.2.2 IWF MCData standalone data request 10.8.2.3 IWF MCData data disposition notification 10.8.2.4 IWF MCData group standalone data request (IWF - MCData server) 10.8.2.5 IWF MCData group standalone data request (MCData server - IWF) 10.8.2.6 IWF MCData data disposition notification(s) (MCData server to IWF) 10.8.2.7 IWF MCData group standalone data request (IWF - MCData server) 10.8.2.8 IWF MCData group standalone data request (MCData server - IWF) 10.8.2.9 IWF MCData group standalone data response 10.8.3 Behaviour at the MCData Client 10.8.4 Behaviour at the IWF 10.8.5 Behaviour at the MCData server 10.8.6 MCData user one-to-one SDS request to an LMR user 10.8.6.1 Signalling control plane 10.8.6.2 Media plane 10.8.7 LMR user one-to-one SDS request to an MCData user 10.8.7.1 Signalling control plane 10.8.7.2 Media plane 10.8.8 MCData user group SDS request to an MCData group including LMR users 10.8.8.1 Signalling control plane 10.8.8.2 Media plane 10.8.9 LMR user group SDS request to an MCData group 10.8.9.1 Signalling control plane 10.8.9.2 Media plane 10.9 IWF as a security gateway 10.9.1 Support for transcoding with encrypted speech 10.10 Simultaneous interworked calls (on-network)
...

10.8 MCData short data service p. 145

10.8.1 General p. 145

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.

10.8.2 Information flows for the short data service p. 146

10.8.2.1 General p. 146

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.

10.8.2.2 IWF MCData standalone data request p. 146

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.

Table 10.8.2.2-1: IWF MCData standalone data request

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
Functional alias	O	The associated functional alias of the MCData user sending data.
MCData ID	M	The identity of the MCData user towards which the data is sent
Conversation Identifier (see NOTE 1)	M	Identifies the conversation
Transaction Identifier (see NOTE 1)	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination Type	M	Indicates whether the payload is for application consumption or MCData client consumption
Application identifier (see NOTE 2)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
Payload	M	SDS 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.

10.8.2.3 IWF MCData data disposition notification p. 146

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.

Table 10.8.2.3-1: IWF MCData data disposition notification

Information element	Status	Description
MCData ID	M	The identity of the MCData user towards which the notification is sent
MCData ID	M	The identity of the MCData user sending notification
Conversation Identifier (see NOTE)	M	Identifies the conversation
Disposition association	M	Identity of the original MCData transaction
Disposition	M	Disposition 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.

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

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.

Table 10.8.2.4-1: IWF MCData group standalone data request (IWF - MCData server)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
MCData group ID	M	The MCData group ID to which the data is to be sent
Conversation Identifier (see NOTE 1)	M	Identifies the conversation
Transaction Identifier (see NOTE 1)	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination Type	M	Indicates whether the payload is for application consumption or MCData client consumption
Application identifier (see NOTE 2)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
Payload	M	SDS 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.

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

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.

Table 10.8.2.5-1: IWF MCData group standalone data request (MCData server - IWF)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
MCData group ID	M	The MCData group ID to which the data is to be sent
MCData ID	M	The identity of the MCData user towards which the data is sent
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination Type	M	Indicates whether the payload is for application consumption or MCData client consumption
Application identifier (see NOTE)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
Payload	M	SDS content
NOTE: The application identifier shall be included only if the payload destination type indicates that the payload is for application consumption.

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

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).

Table 10.8.2.6-1: IWF MCData data disposition notification(s) (MCData server - IWF)

Information element	Status	Description
MCData ID	M	The identity of the MCData user towards which the notification is sent
MCData ID	M	The identity of the MCData user sending notification
Conversation Identifier	M	Identifies the conversation
Disposition association	M	Identity of the original MCData transaction
Disposition	M	Disposition which is delivered, read, delivered and read, or disposition prevented by system

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

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.

Table 10.8.2.7-1: IWF MCData group standalone data request (IWF - MCData server)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
MCData group ID	M	The MCData group ID to which the data is to be sent
Conversation Identifier (see NOTE 1)	M	Identifies the conversation
Transaction Identifier (see NOTE 1)	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Transaction type	M	Standalone transaction
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination Type	M	Indicates whether the SDS payload is for application consumption or MCData user consumption
Application identifier (see NOTE 2)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
SDP offer	M	Media 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.

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

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).

Table 10.8.2.8-1: IWF MCData group standalone data request (MCData server - IWF)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
MCData group ID	M	The MCData group ID to which the data is to be sent
MCData ID	M	The identity of the MCData user towards which the data is sent
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Transaction type	M	Standalone transaction
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination Type	M	Indicates whether the SDS payload is for application consumption or MCData user consumption
Application identifier (see NOTE)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
SDP offer	M	Media parameters offered
NOTE: The application identifier shall be included only if the payload destination type indicates that the payload is for application consumption.

10.8.2.9 IWF MCData group standalone data response p. 149

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.

Table 10.8.2.9-1: IWF MCData group standalone data response

Information element	Status	Description
MCData ID	M	The identity of the MCData user receiving data
MCData group ID	M	The MCData group ID to which the data is to be sent
MCData ID	M	The identity of the MCData user sent data
Conversation Identifier (see NOTE)	M	Identifies the conversation
SDP answer	M	Media parameters selected
NOTE: A reserved value of the Information Element shall be defined which indicates that the sender does not support this Information Element.

10.8.3 Behaviour at the MCData Client p. 149

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

10.8.4 Behaviour at the IWF p. 149

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 server p. 149

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 user p. 149

10.8.6.1 Signalling control plane p. 149

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.

10.8.6.2 Media plane p. 150

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.

10.8.7 LMR user one-to-one SDS request to an MCData user p. 150

10.8.7.1 Signalling control plane p. 150

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.

10.8.7.2 Media plane p. 150

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.

10.8.8 MCData user group SDS request to an MCData group including LMR users p. 150

10.8.8.1 Signalling control plane p. 150

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.

10.8.8.2 Media plane p. 150

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.

10.8.9 LMR user group SDS request to an MCData group p. 150

10.8.9.1 Signalling control plane p. 150

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.

10.8.9.2 Media plane p. 151

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.

10.9 IWF as a security gateway p. 151

10.9.1 Support for transcoding with encrypted speech p. 151

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.

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

10.10.1 General p. 151

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.