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.
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.
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 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.
|
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 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.
|
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 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.
|
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 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.
|
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 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 |
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 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.
|
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 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.
|
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 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.
|
The MCData client interfaces with the MCData server as specified in
TS 23.282.
The IWF interfaces with the MCData server via the reference points defined in
subclause 7.4 of the present document.
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.
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.
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.
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.
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.
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.
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.
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.
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.