6 Common procedures

29.5823GPPMission Critical Data (MCData) interworking with Land Mobile Radio (LMR) systemsRelease 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 Introduction

This clause describes the IWF procedures for MCData.

6.2 IWF performing the participating role procedures

6.2.1 Void

6.2.2 MCData conversation items

6.2.2.1 IWF generating an SDS Message

In order to generate an SDS message, the IWF performing the participating role:

1) shall generate an SDS SIGNALLING PAYLOAD message as specified in clause 15.1.2;

2) shall generate a DATA PAYLOAD message as specified in clause 15.1.4;

3) shall include in the SIP request, the SDS SIGNALLING PAYLOAD message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in 3GPP TS 24.282 [82] clause E.1; and

4) shall include in the SIP request, the DATA PAYLOAD message in an application/vnd.3gpp.mcdata-payload MIME body as specified in 3GPP TS 24.282 [82] clause E.2.

When generating an SDS SIGNALLING PAYLOAD message as specified in clause 15.1.2, the IWF performing the participating role:

1) shall set the Date and time IE to the current time as specified in 3GPP TS 24.282 [82] clause 15.2.8;

2) if the SDS message starts a new conversation, shall set the Conversation ID IE to a newly generated Conversation ID value as specified in clause 15.2.9;

3) if the SDS message continues an existing unfinished conversation, shall, if available, set the Conversation ID IE to the Conversation ID value of the existing conversation as specified in clause 15.2.9, or shall set the Conversation ID IE to the Conversation ID value "UNKNOWN CONVERSATION" as specified in clause 15.2.9;

4) shall set the Message ID IE to a newly generated Message ID value as specified in clause 15.2.10;

5) if the SDS message is in reply to a previously received SDS message shall include the InReplyTo message ID IE with the Message ID value:

i) set to the Message ID value in the previously received SDS message;

ii) set to the Message ID value "LMR MESSAGE ID"as specified in clause 15.2.10, with the value of octet 16 of the LMR MESSAGE ID set to the value of octet 16 of the Message ID in the previously received SDS message; and

iii) set to the Message ID value "UNKNOWN ORIGINATING MESSAGE ID" as specified in clause 15.2.10;

6) if the SDS message is for user consumption, shall not include an Application ID IE as specified in 3GPP TS 24.282 [82] clause 15.2.7 and shall not include an Extended application ID IE as specified in 3GPP TS 24.282 [82] clause 15.2.24;

7) if the SDS message is intended for an application on the terminating MCData client, shall include:

a) an Application ID IE with a Application ID value representing the intended application as specified in 3GPP TS 24.282 [82] clause 15.2.7; or

b) an Extended application ID IE with an Extended application ID value representing the intended application as specified in 3GPP TS 24.282 [82] clause 15.2.24;

NOTE: The value chosen for the Application ID value is decided by the mission critical organisation.

8) if only a delivery disposition notification is required shall include a SDS disposition request type IE set to "DELIVERY" as specified in 3GPP TS 24.282 [82] clause 15.2.3;

9) if only a read disposition notification is required shall include a SDS disposition request type IE set to "READ" as specified in 3GPP TS 24.282 [82] clause 15.2.3; and

10) if both a delivery and read disposition notification is required shall include a SDS disposition request type IE set to "DELIVERY AND READ" as specified in 3GPP TS 24.282 [82] clause 15.2.3.

When generating a DATA PAYLOAD message for SDS as specified in clause 15.1.4, the IWF performing the participating role:

1) shall set the Number of payloads IE to the number of Payload IEs that need to be encoded, as specified in clause 15.2.12;

2) if end-to-end security is required for a one-to-one communication, shall include the Security parameters and Payload IE with security parameters as described in 3GPP TS 33.180 [78]. Otherwise, if end-to-end security is not required for a one-to-one communication, shall include the Payload IE as specified in clause 15.1.4; and

3) for each Payload IE included:

a) if the payload is text, shall set the Payload content type as "TEXT" as specified in 3GPP TS 24.282 [82] clause 15.2.13;

b) if the payload is binary data, shall set the Payload content type as "BINARY" as specified in 3GPP TS 24.282 [82] clause 15.2.13;

c) if the payload is hyperlinks, shall set the Payload content type as "HYPERLINKS" as specified in 3GPP TS 24.282 [82] clause 15.2.13;

d) if the payload is location, shall set the Payload content type as "LOCATION" as specified in 3GPP TS 24.282 [82] clause 15.2.13;

e) if payload is enhanced status for a group, shall set the Payload content type as "ENHANCED STATUS" as specified in 3GPP TS 24.282 [82] clause 15.2.13;

f) if payload is a native LMR message, shall set the Payload content type as "LMR MESSAGE" as specified in clause 15.2.13; and

g) shall include the data to be sent in the Payload data.

6.2.3 Disposition Notifications

6.2.3.1 Generating an SDS Notification

In order to generate an SDS notification, the IWF performing the participating role:

1) shall generate an SDS NOTIFICATION message as specified in clause 15.1.5; and

2) shall include in the SIP request, the SDS NOTIFICATION message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in 3GPP TS 24.282 [82] clause E.1.

When generating an SDS NOTIFICATION message as specified in clause 15.1.5, the IWF performing the participating role:

1) if sending a delivered notification, shall set the SDS disposition notification type IE as "DELIVERED" as specified in 3GPP TS 24.282 [82] clause 15.2.5;

2) if sending a read notification, shall set the SDS disposition notification type IE as "READ" as specified in clause 3GPP TS 24.282 [82] 15.2.5;

3) if sending a delivered and read notification, shall set the SDS disposition notification type IE as "DELIVERED AND READ" as specified in 3GPP TS 24.282 [82] clause 15.2.5;

4) if the SDS message could not be delivered, shall set the SDS disposition notification type IE as "UNDELIVERED" as specified in 3GPP TS 24.282 [82] clause 15.2.5;

5) if SDS disposition notification was prevented by the LMR system, shall set the SDS disposition notification type IE as "DISPOSITION PREVENTED BY SYSTEM" as specified in 3GPP TS 24.282 [82] clause 15.2.5;

6) shall set the Date and time IE to the current time to as specified in 3GPP TS 24.282 [82] clause 15.2.8;

7) shall set the Conversation ID to the value of the Conversation ID that was received in the SDS message as specified in clause 15.2.9;

8) shall set the Message ID to the value of the Message ID that was received in the SDS message as specified in clause 15.2.10;

9) if the SDS message was destined for the user, shall not include an Application ID IE (as specified in 3GPP TS 24.282 [82] clause 15.2.7) and shall not include an Extended application ID IE (as specified in 3GPP TS 24.282 [82] clause 15.2.24); and

10) if the SDS message was destined for an application, shall include:

a) an Application ID IE set to the value of the Application ID that was included in the SDS message as specified in 3GPP TS 24.282 [82] clause 15.2.3; or

b) an Extended application ID IE set to the value of the Extended application ID that was included in the SDS message as specified in 3GPP TS 24.282 [82] clause 15.2.24.

6.2.4 Sending SIP requests and receiving SIP responses

6.2.4.1 Generating a SIP MESSAGE request towards the controlling MCData function

This clause is referenced from other procedures.

In a SIP MESSAGE request, the IWF performing the participating role:

1) when sending SDS messages or SDS disposition notifications:

a) shall include an Accept-Contact header field containing the g.3gpp.mcdata.sds media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [6];

b) shall include an Accept-Contact header field with the media feature tag g.3gpp.icsi-ref containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [6]; and

c) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" (coded as specified in 3GPP TS 24.229 [4]), in a P-Preferred-Service header field according to IETF RFC 6050 [9] in the SIP MESSAGE request;

2) may include a P-Preferred-Identity header field in the SIP MESSAGE request containing a public user identity as specified in 3GPP TS 24.229 [4]; and

3) shall set the Request-URI to the public service identity of the controlling MCData function.

6.3 Server role procedures

6.3.0 Introduction

The IWF performs the MCData server role when exchanging SDS messages with MCData servers within the MC system. The IWF does not communicate directly with MCData clients. The IWF does not support the FD service. Clause 6.3 describes the IWF operating as a controlling and participating MCData server.

6.3.1 Distinction of requests at the IWF

6.3.1.1 SIP MESSAGE request

The IWF shall perform the role of an MCData server in distinguishing between the following SIP MESSAGE requests for originations and terminations from 3GPP TS 24.282 [82] clause 6.3.1.1 as described below:

– SIP MESSAGE request routed to the IWF performing the terminating participating MCData role with an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" in a P-Asserted-Service header field. Such requests are known as "SIP MESSAGE request for standalone SDS for terminating participating MCData function";

– SIP MESSAGE request routed to IWF performing the MCData server role with an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds", an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" in a P-Asserted-Service header field, and with an application/vnd.3gpp.mcdata-signalling MIME body containing an SDS NOTIFICATION message Such requests are known as "SIP MESSAGE request for SDS disposition notification for MCData server";

– SIP MESSAGE request routed to the IWF performing the controlling MCData role with an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" in a P-Asserted-Service header field. Such requests are known as "SIP MESSAGE request for standalone SDS for controlling MCData function"; and

– SIP MESSAGE requests routed to the IWF performing the terminating participating role as a result of initial filter criteria with the Request-URI set to the public service identity of the IWF performing the participating role and containing a Content-Type header field set to "application/vnd.3gpp.mcdata-info+xml" and includes an XML body containing a <mcdatainfo> root element with a <mcdata-Params> element containing an <anyExt> element with the <request-type> element set to a value of "Interworking Security Data message". Such requests are known as "SIP MESSAGE request for Interworking Security Data message for participating function".

If a SIP MESSAGE request is received at the IWF that is not in accordance with the SIP MESSAGE requests listed above, then the IWF shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response.

6.3.1.2 SIP INVITE request

The IWF shall perform the role of an MCData server in distinguishing between the following SIP INVITE requests for originations and terminations from 3GPP TS 24.282 [82] clause 6.3.1.2 as described below:

– SIP INVITE request routed to the IWF performing the terminating participating MCData role with an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" in a P-Asserted-Service header field and a <request-type> element set to "one-to-one-sds" or "group-sds" contained in an application/vnd.3gpp.mcdata-info+xml MIME body. Such requests are known as "SIP INVITE request for standalone SDS over media plane for terminating participating MCData function";

– SIP INVITE request routed to the IWF performing the controlling MCData role with an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" in a P-Asserted-Service header field and a <request-type> element set to "one-to-one-sds" or "group-sds" contained in an application/vnd.3gpp.mcdata-info+xml MIME body. Such requests are known as "SIP INVITE request for controlling MCData function for standalone SDS over media plane";

– SIP INVITE request routed to the IWF performing the terminating participating MCData role with an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" in a P-Asserted-Service header field and a <request-type> element set to "one-to-one-sds-session" or "group-sds-session" contained in an application/vnd.3gpp.mcdata-info+xml MIME body. Such requests are known as "SIP INVITE request for SDS session for terminating participating MCData function"; and

– SIP INVITE request routed to the IWF performing the controlling MCData role with an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" in a P-Asserted-Service header field and a <request-type> element set to "one-to-one-sds-session" or "group-sds-session" contained in an application/vnd.3gpp.mcdata-info+xml MIME body. Such requests are known as "SIP INVITE request for controlling MCData function for SDS session".

6.3.2 Sending SIP requests and receiving SIP responses

6.3.2.1 Generating a SIP MESSAGE request towards the terminating MCData client

This clause is referenced from other procedures. Refer to 3GPP TS 24.282 [82] clause 6.3.2.1.

6.3.3 Groups homed in the IWF

How information about groups homed in the IWF is stored and retrieved by the IWF is out of scope of the present document. The procedures to perform these actions are supported by the IWF but are not defined.

6.3.4 Void

6.3.5 Affiliation check

The IWF shall determine that the MCData user, with MCData ID, is affiliated to the MCData group, with MCData Group ID, at the MCData client, with MCData client ID, if the elements, as described in clause 8.3.3.2, exist with their expected values, as below:

1) an MCData group information entry with MCData group ID same as the MCData group ID under consideration;

2) in the MCData group information entry found in 1, an MCData user information entry with the MCData ID same as the MCData ID under consideration;

3) in the MCData user information entry found in 2, an MCData client information entry with MCData Client ID same as the MCData client ID under consideration; and

4) in the MCData user information entry found in 2, an expiration time, which has not expired.

NOTE: How the IWF determines which users homed in the IWF are affiliated to the MCData group is out of scope of the present document.

6.4 Handling of MIME bodies in a SIP message

The IWF shall support MIME bodies in SIP requests and SIP responses according to 3GPP TS 24.282 [82] clause 6.4.

6.5 Confidentiality and Integrity Protection of sensitive XML content

6.5.1 General

6.5.1.1 Applicability and exclusions

The procedures in clause 6.5 apply in general to all procedures described in clause 9, clause 12 and clause 13 with the exception that the confidentiality and integrity protection procedures for the registration and service authorisation procedures are described in clause 7.

6.5.1.2 Performing XML content encryption

Whenever the IWF includes XML elements or attributes pertaining to the data specified in clause 4.6 in SIP requests or SIP responses, the IWF shall perform the procedures in clause 6.5.2.3.2, with the exception that when the IWF receives a SIP request with XML elements or attributes in an MIME body that need to be copied from the incoming SIP request to an outgoing SIP request without modification, the IWF shall perform the procedures specified in clause 6.5.2.5.

6.5.1.3 Performing integrity protection on an XML body

The IWF shall perform the procedures in clause 6.5.3.3.2 just prior to sending a SIP request or SIP response.

6.5.2 Confidentiality Protection

6.5.2.2 Keys used in confidentiality protection procedures

Confidentiality protection uses an XPK to encrypt the data which is an SPK as specified in clause 4.5. In the case of an IWF as a server sending or receiving to another server this key will be an SPK. An SPK-ID is used to key the SPK. It is assumed that before the procedures in this clause are called, the SPK/SPK-ID are available on the sender and recipient of the encrypted content as described in 3GPP TS 24.282 [82] clause 4.6.

The procedures in clause 6.5.2.3 and 3GPP TS 24.282 [82] clause 6.5.2.4 are used with an XPK equal to the SPK and a XPK-ID equal to the SPK-ID when the IWF sends confidentiality protected content to an MCData server.

6.5.2.3 Procedures for sending confidentiality protected content

6.5.2.3.2 IWF performing the role of an MCData server

If the IWF performing the role of an MCData server determines locally that it needs to confidentially protect content to an MCData server, then sending confidentially protected content between MCData servers is enabled.

When sending confidentiality protected content, the IWF:

1) shall use the appropriate keying information specified in clause 6.5.2.2;

2) shall perform the procedures in 3GPP TS 24.282 [82] clause 6.5.2.3.3 to confidentiality protect XML elements containing the content described in clause 4.5; and

3) shall perform the procedures in 3GPP TS 24.282 [82] clause 6.5.2.3.4 to confidentiality protect URIs in XML attributes for URIs described in clause 4.5.

If the IWF determines locally that it does not need to confidentiality protect content sent to an MCData server, then sending confidentiality protected content between MCData servers is disabled, and the content is included in XML elements and attributes without encryption.

6.5.2.5 IWF copying received XML content

The following procedure is executed when an IWF receives a SIP request containing XML MIME bodies, where the content needs to be copied from the incoming SIP request to the outgoing SIP request.

The IWF:

1) shall copy the XML elements from the XML MIME body of the incoming SIP request that do not contain a <EncryptedData> XML element, to the same XML body in the outgoing SIP request;

2) for each encrypted XML element in the XML MIME body of the incoming SIP request as determined by 3GPP TS 24.282 [82] clause 6.5.2.4.1:

a) shall use the keying information described in clause 6.5.2.2 to decrypt the content within the XML element by following the procedures specified in 3GPP TS 24.282 [82] clause 6.5.2.4.2, and shall continue with the steps below if the encrypted XML element was successfully decrypted;

b) if confidentiality protection is enabled as specified in clause 6.5.2.3.2, then for each decrypted XML element:

i) shall re-encrypt the content within the XML element using the keying information described in clause 6.5.2.2 and by following the procedures specified in 3GPP TS 24.282 [82] clause 6.5.2.3.3; and

ii) shall include the re-encrypted content into the same XML MIME body of the outgoing SIP request; and

c) if confidentiality protection is disabled as specified in clause 6.5.2.3.2, shall include the decrypted content in the same XML MIME body of the outgoing SIP request; and

3) for each encrypted XML URI attribute in the XML MIME body of the incoming SIP request as determined by 3GPP TS 24.282 [82] clause 6.5.2.4.1:

a) shall use the keying information described in clause 6.5.2.2 to decrypt the URI value of the XML attribute by following the procedures specified in 3GPP TS 24.282 [82] clause 6.5.2.4.3, and shall continue with the steps below if the encrypted XML attribute value was successfully decrypted;

b) if confidentiality protection is enabled as specified in clause 6.5.2.3.2, then for each decrypted XML element:

i) shall re-encrypt the URI value of the XML attribute using the keying information described in clause 6.5.2.2 and by following the procedures specified in 3GPP TS 24.282 [82] clause 6.5.2.3.4; and

ii) shall include the re-encrypted attribute value into the same XML MIME body of the outgoing SIP request; and

c) if confidentiality protection is disabled as specified in clause 6.5.2.3.2, shall include the decrypted value in the same XML MIME body of the outgoing SIP request.

6.5.3 Integrity Protection of XML documents

6.5.3.2 Keys used in integrity protection procedures

Integrity protection uses an XPK to sign the data which is an SPK as specified in clause 4.5. In the case of an IWF as a server sending or receiving to another server this key will be an SPK. An SPK-ID is used to key the SPK. It is assumed that before the procedures in clause 6.5.3.3 and 3GPP TS 24.282 [82] clauses 6.5.3.3.1, 6.5.3.3.3 and 6.5.3.4 are called, the SPK/SPK-ID are available on the sender and recipient of the integrity protected content, as described in clause 4.5.

The procedure in clause 6.5.3.3 and 3GPP TS 24.282 [82] clause 6.5.3.4 shall be used with a XPK equal to the SPK and a XPK-ID equal to the SPK-ID when the IWF sends integrity protected content to an MCData server

6.5.3.3 Sending integrity protected content

6.5.3.3.2 Integrity protection at the IWF

The IWF determines locally whether sending integrity protected content from the IWF to an MCData server is enabled.

When sending integrity protected content, the IWF shall use the appropriate keying information specified in clause 6.5.3.2 and shall perform the procedures in 3GPP TS 24.282 [82] clause 6.5.3.3.3 to integrity protect XML MIME bodies.

NOTE: Each XML MIME body is integrity protected separately.

6.6 Confidentiality and integrity protection of TLV messages

6.6.1 General

Signalling plane provides confidentiality and integrity protection for the MCData data signalling and MCData data messages sent over the signalling plane. Signalling plane security also provides the authentication of MCData data messages.

The signalling plane security is based on 3GPP MCData security solution including key management and end-to-end protection as defined in 3GPP TS 33.180 [78].

Various keys and associated key identifiers protect the MCData data signalling and MCData data messages carried on the signalling plane.

The MCData signalling messages sent and received by an IWF are on-network communications and do not include FD.

The MCData data signalling messages may be:

1. SDS SIGNALLING PAYLOAD;

2. SDS NOTIFICATION; or

3. COMMUNICATION RELEASE.

The MCData data messages may be:

1. DATA PAYLOAD.

In an on-network MCData communication for an MCData group, if protection of MCData data messages is negotiated, the GMK and the GMK-ID of the MCData group protect the MCData data messages sent and received by the IWF acting on behalf of users homed in the IWF.

In an on-network one-to-one MCData communications, if protection of MCData data messages is negotiated, the PCK and the PCK-ID protect the MCData data messages sent and received by the IWF acting on behalf of MCData clients homed in the IWF. The IWF acts as termination point for protection of one-to-one MCData data messages that are sent and received by the IWF acting on behalf of MCData clients homed in the IWF.

The protection of MCData communications between the user homed in the IWF and the IWF acting on behalf of the user homed in the IWF is outside the scope of the present document.

If protection of MCData data signalling messages between the IWF and another MCData function acting in a participating or controlling role is configured, the SPK and the SPK-ID protect the MCData data signalling messages sent and received between the IWF and that MCData function.

The GMK and the GMK-ID are distributed to the IWF acting on behalf of users homed in the IWF using the group document subscription and notification procedure specified in 3GPP TS 24.481 [31].

The PCK and the PCK-ID are generated by the IWF initiating the standalone SDS using signalling control plane.

The SPK and the SPK-ID are configured in the IWF if it is acting as the participating MCData function or if it is acting as the controlling MCData function.

The key material for creating and verifying the authentication signature (SSK, PVT and KPAK) is provisioned to the MCData clients by the KMS as specified in 3GPP TS 33.180 [78].

6.6.2 Derivation of master keys for media and media control

On-network MCData services employing the media plane are not supported by the IWF.

6.6.3 Protection of MCData signalling and MCData messages

6.6.3.1 General

The MCData messages may be encrypted and integrity protected between the IWF and the MCData system. When encryption is applied the media shall be encrypted as specified in 3GPP TS 33.180 [78].

Both unprotected MCData messages and MCData messages that are encypted and/or integrity protected can also be end-to-end encrypted for interworking between an MCData client and the IWF.

NOTE: LMR end to end encryption is independent of 3GPP encryption and is out of scope of the present document.