4 General

24.2823GPPMission Critical Data (MCData) signalling controlProtocol specificationRelease 18TS

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

4.1 MCData overview

The MCData service supports communication between a pair of users (i.e. one-to-one communication) and several users (i.e. group communication), where each user has the ability to:

– share data using Short Data Service (SDS);

– share files using File Distribution (FD) service; and

– exchange Data using IP Connectivity service.

SDS is provided in both, on-network and off-network while FD and IP Connectivity is provided only in on-network in this release of the present document.

The present document provides the signalling control protocol enhancements to support the MCData architectural procedures specified in 3GPP TS 23.282 [2].

For on-network communications, the present document makes use of the existing IMS procedures specified in 3GPP TS 24.229 [5].

The on-network procedures in this document allow an MCData user to:

– send a standalone SDS using signalling control plane;

– send a standalone SDS using media plane;

– initiate a SDS session;

– send a file using HTTP;

– send a file using media plane;

– establish an IP Connectivity session to exchange Data;

– access the MCData message store; and

– use a functional alias to identify the MCData user.

For off-network, the present document utilises the procedures for ProSe direct discovery for Public Safety and the procedures for one-to-one ProSe direct communication for Public Safety and one-to-many ProSe direct communication for Public Safety, as specified in 3GPP TS 24.334 [25], and allows an MCData user to:

– send a standalone SDS using signalling control plane.

ProSe is only supported in EPS.

The MCData procedures provided by the present document refer to:

– the media plane procedures defined in 3GPP TS 24.582 [15];

– the group management procedures defined in 3GPP TS 24.481 [11];

– the identity management procedures defined in 3GPP TS 24.482 [24]; and

– the security procedures defined in 3GPP TS 33.180 [26].

The MCData procedures provided by the present document access the configuration parameters provided by 3GPP TS 24.483 [42] and 3GPP TS 24.484 [12].

The following procedures are provided within this document:

– common procedures are specified in clause 6;

– procedures for registration in the IM CN subsystem and service authorisation are specified in clause 7;

– procedures for affiliation are specified in clause 8;

– procedures for on-network and off-network SDS are specified in clause 9;

– procedures for on-network FD are specified in clause 10;

– procedures for transmission and reception control are specified in clause 11;

– procedures for dispositions and notifications are specified in clause 12;

– procedures for communication release are specified in clause 13;

– procedures for location reporting are specified in clause 17;

– procedure for using MBMS transmission are specified in clause 19;

– procedures for establishing an IP Connectivity session are specified in clause 20;

– procedures for the MCData message store are specified in clause 21; and

– procedures for the use of functional alias are specified in clause 22.

The MCData UE primarily obtains access to the MCData service via E-UTRAN or NG-RAN, using the procedures defined in 3GPP TS 24.301 [43] and 3GPP TS 24.501 [81].

4.2 Identity, URI and address assignments

4.2.1 Public Service identities

In order to support MCData, the following URI and address assignments are assumed:

1) the participating MCData function is configured to be reachable using:

a) the public service identity of the participating MCData function serving the MCData user.

4.2.2 MCData session identity

The MCData session identity is a SIP URI, which identifies the MCData session between:

– the MCData client and the participating MCData function; and

– the participating MCData function and the controlling MCData function.

The MCData session identity shall be a GRUU as defined in IETF RFC 5627 [44] assigned by the MCData server as per 3GPP TS 24.229 [5].

The MCData session identity identifies the MCData session in such a way that e.g.:

– the IM CN subsystem is able to route an initial SIP request to the controlling MCData function.

The controlling MCData function allocates a unique MCData session identity hosted at the controlling MCData function for the MCData session at the time of session establishment.

When protection of sensitive application data is required by the MCData operator, the MCData session identity cannot contain identity information that is classified as sensitive such as the MCData ID or the MCData Group ID, as specified in clause 4.6.

The controlling MCData function sends the MCData session identity towards the MCData client during MCData session establishment by including it in the Contact header field of the final SIP response to a session initiation request.

The participating MCData function allocates a unique MCData session identity hosted at the participating MCData function for the MCData session when it receives a MCData session identity in the Contact header field of a SIP request or a SIP response from the controlling MCData function and includes it in the Contact header field of the SIP request or SIP response sent towards the MCData client. The participating MCData function maintains a mapping of the MCData session identities it sends to the MCData client to the corresponding MCData session identities received from the controlling MCData function.

The MCData client can cache the MCData session identity until a time when it is no longer needed.

4.2.3 MCData client ID

MCData client ID is described in clause 4.8 of the present document.

4.3 Pre-established sessions

When establishing a pre-established session, the MCData client negotiates the media parameters, including establishing IP addresses and ports using interactive connectivity establishment (ICE) as specified in IETF RFC 8445 [77] and IETF RFC 8839 [78] with the participating MCData function, prior to using the pre-established session for establishing MCData communication with other MCData users. The procedures for establishing, modifying and releasing a pre-established session are defined in clause 18.

The pre-established session can later be used in MCData communication. This avoids the need to negotiate media parameters (including evaluating ICE candidates) and reserving bearer resources during the MCData communication establishment that results in delayed MCData communication establishment.

4.4 Emergency Alerts

MCData emergency alerts can be initiated or cancelled as described in the procedures of clause 16 which include:

– MCData emergency alert initiation, on-network;

– MCData emergency alert cancellation, on-network;

– MCData emergency alert initiation, off-network; and

– MCData emergency alert cancellation, off-network.

MCData emergency alerts are initiated to a target MCData group, and, if successful and not already affiliated to that group, will result in the initiator being implicitly affiliated to that MCData group.

Key aspects of MCData emergency alerts include:

– MCData emergency alert (MDEA) state: the MCData client maintains the internal MCData emergency alert state (MDEA, see clause G.4.1). The initial setting is "MDEA 1: no-alert".

– MCData private emergency alert (MDPEA) state: the MCData client maintains the internal MCData private emergency alert state (MDPEA, see clause G.4.12). The initial setting is "MDPEA 1: no-alert".

– Authorisations for emergency alerts: MCData users need to be authorised to initiate MCData emergency alerts and additionally need to be authorised to cancel MCData emergency alerts initiated by them or by others. The parameters related to these authorisations are specified in 3GPP TS 24.483 [42] and 3GPP TS 24.484 [12].

4.5 MCData Protocol

Clauses 15 describes the TLV based message formats used in MCData communications. Each message consist of a series of information elements. Annex I of 3GPP TS 24.379 [10] describes the standard format of the messages and the encoding rules for each type of information element.

4.6 Protection of sensitive XML application data

In certain deployments, for example, in the case that the MCData operator uses the underlying SIP core infrastructure from the carrier operator, the MCData operator can prevent certain sensitive application data from being visible in the clear to the SIP layer. The following data are classed as sensitive application data:

– MCData ID;

– MCData group ID;

– user location information;

– alert indicator;

– access token (containing the MCData ID);

– MCData client ID; and

– functional alias.

The above data is transported as XML content in SIP messages. in XML elements or XML attributes.

Data is transported in attributes in the following circumstances in the procedures in the present document:

– an MCData ID, an MCData Group ID, and an MCData client ID in an XML document published in SIP PUBLISH request for affiliation according to IETF RFC 3856 [39];

– an MCData ID or an MCData Group ID in XML document notified in a SIP NOTIFY request for affiliation according to IETF RFC 3856 [39];

– an MCData ID in application/resource-lists+xml document included in a SIP MESSAGE or SIP INVITE request for one-to-one SDS or one-to-one FD, according to IETF RFC 5366 [18];

– an MCData ID and functional alias in an XML document published in SIP PUBLISH request for functional alias management according to IETF RFC 3856 [39]; and

– an MCData ID and functional alias in an XML document notified in a SIP NOTIFY request for functional alias management according to IETF RFC 3856 [39].

3GPP TS 33.180 [26] describes a method to provide confidentiality protection of sensitive application data in elements by using XML encryption (i.e. xmlenc) and in attributes by using an attribute confidentiality protection scheme described in clause 6.6.2.3 of the present document. Integrity protection can also be provided by using XML signatures (i.e. xmlsig).

Protection of the data relies on a shared XML protection key (XPK) used to encrypt and sign data:

– between the MCData client and the MCData server, the XPK is a client-server key (CSK); and

– between MCData servers, the XPK is a signalling protection key (SPK).

The CSK (XPK) and a key-id CSK-ID (XPK-ID) are generated from keying material provided by the key management server. Identity based public key encryption based on MIKEY-SAKKE is used to transport the CSK between SIP end-points. The encrypted CSK is transported from the MCData client to the MCData server when the MCData client performs service authorisation as described in clause 7 and is also used during service authorisation to protect the access token.

The SPK (XPK) and a key-id SPK-ID (XPK-ID) are directly provisioned in the MCData servers.

Configuration in the MCData client and MCData server is used to determine whether one or both of confidentiality protection and integrity protection are required.

The following four examples give a brief overview of the how confidentiality and integrity protection is applied to application data in this specification.

EXAMPLE 1: Pseudo code showing how confidentiality protection is represented in the procedures in the document for sensitive data sent by the originating client.

IF configuration is set for confidentiality protection of sensitive data

THEN

Encrypt data element using the CSK (XPK;

Include in an <EncryptedData> element of the XML MIME body:

(1) the encryption method;

(2) the key-id (XPK-ID);

(3) the cipher data;

Encrypt URIs in attribute using the CSK (XPK) by following clause 6.6.2.3;

ELSE

include application data into XML MIME body in clear text;

ENDIF;

EXAMPLE 2: Pseudo code showing how integrity protection is represented in the procedures in the present document for data sent by the originating client.

IF configuration is set for integrity protection of application data

THEN

Use a method to hash the content;

Generate a signature for the hashed content using the CSK (XPK;

Include within a <Signature> XML element of the XML MIME body:

(1) a cannonicalisation method to be applied to the signed information;

(2) the signature method used for generating the signature;

(3) a reference to the content to be signed;

(4) the hashing method used;

(5) the hashed content;

(6) the key-id (XPK-ID);

(7) the signature value;

ENDIF;

EXAMPLE 3: Pseudo code showing how confidentiality protection is represented in the procedures in the present document at the server side when receiving encrypted content.

IF configuration is set for confidentiality protection of sensitive data

THEN

Check that the XML content contains the <EncryptedData> element;

Check that the XML document contains a URI with the domain name for MC Services confidentiality protection;

Return an error if the <EncryptedData> element or domain name for MC Services confidentiality protection are not found;

Otherwise:

(1) obtain the CSK (XPK) using the CSK-ID (XPK-ID) in the received XML body;

(2) for encrypted data in elements, decrypt the data elements using the CSK;

(3) for encrypted URIs in attributes, decrypt the URIs using the CSK;

ENDIF;

EXAMPLE 4: Pseudo code showing how integrity protection is represented in the procedures in the present document at the server side when receiving signed content.

IF configuration is set for integrity protection of application data

THEN

Check that the XML content contains the <Signature> element;

Return an error if the <Signature> element is not found;

Otherwise:

(1) obtain the CSK (XPK) using the CSK-ID (XPK-ID) in the received XML body;

(2) verify the signature of the content using the CSK;

Return an error if the validation of the signature fails;

IF validation of the signature passes

THEN

decrypt any data found in <EncryptedData> elements;

decrypt any encrypted URIs found in attributes;

ENDIF;

The content can be re-encrypted and signed again using the SPK between MCData servers.

The following examples show the difference between normal and encrypted data content. In this example consider the MCData client initiating a group standalone SDS message using the signalling control plane.

EXAMPLE 5: <mcdata-info> MIME body represented with data elements in the clear:

Content-Type: application/vnd.3gpp.mcdata-info+xml

<?xml version="1.0"?>

<mcdata-info>

<mcdata-Params>

<request-type>group-sds</request-type>

<mcdata-request-uri type="Normal">

<mcdataURI>sip:group123@mcdataoperator1.com></mcdataURI>

</mcdata-request-uri>

</mcdata-Params>

</mcdata-info>

EXAMPLE 6: <mcdata-info> MIME body represented with the <mcdata-request-uri> encrypted:

Content-Type: application/vnd.3gpp.mcdata-info+xml

<?xml version="1.0"?>

<mcdata-info>

<mcdata-Params>

<request-type>group-sds</request-type>

<mcdata-request-uri type="Encrypted">

<EncryptedData xmlns=’http://www.w3.org/2001/04/xmlenc#’

Type=’http://www.w3.org/2001/04/xmlenc#Content’>

<ds:KeyInfo>

<ds:KeyName>base64XpkId</KeyName>

</ds:KeyInfo>

</CipherData>

</EncryptedData>

</mcdata-request-uri>

</mcdata-Params>

</mcdata-info>

EXAMPLE 7: pidf+xml MIME body represented with clear URIs in attributes:

Content-Type: application/pidf+xml

<?xml version="1.0" encoding="UTF-8"?>

</status>

</tuple>

</presence>

EXAMPLE 8: pidf+xml MIME body represented with encrypted URIs in attributes:

Content-Type: application/pidf+xml

<?xml version="1.0" encoding="UTF-8"?>

</status>

</tuple>

</presence>

4.7 Protection of TLV signalling and media content

The protection of TLV signalling and media content is based on 3GPP MCData security solution as defined in 3GPP TS 33.180 [26].

For different security requirements of different information elements of a MCData message, the information elements of MCData messages are bifurcated in the following components:

– MCData Data signalling payload: information elements necessary for identification and management of the MCData messages e.g. conversation identifiers, session identifiers, transaction identifiers, disposition requests, etc. This payload is confidentiality and integrity protected between the MCData Client and the MCData server.

– MCData Data payload: the actual user payload for MCData user or application consumption. This payload is end-to-end confidentiality and integrity protected.

An SDS message can be sent over both, signalling plane and media plane. When an SDS message is sent using signalling plane, the body included in the SIP MESSAGE request, which carries MCData Data signalling payload, is protected between each entity separately if protection is applied. On the other hand the body included in the SIP MESSAGE request which carries the MCData Data payload is end-to-end protected. The procedures for the protection of the SDS messages over the signalling plane are specified in this document. Protection of SDS message over media control plane is specified in 3GPP TS 24.582 [15].

For FD using HTTP and FD using media plane, the MCData Data signalling payload sent over the signalling plane is protected between each entity separately if protection is applied. The procedure for the protection of the file is specified in 3GPP TS 24.582 [15].

The ciphering algorithm indicated in the Key Download procedure by the MCData server shall be used to protect the MCData signalling fields (i.e. MCData signaling parameters, Data signaling payload and end-to-end security parameters).

4.7A Signalling security when using MBMS

Signalling security is established between the participating MCData function and the MCData client.

The protection of MBMS subchannel control messages on the general purpose MBMS subchannels can be done with MSCCKs (each identified by a corresponding MSCCK-ID), distributed during MBMS bearer announcement (see clause 19.2.2). Each general purpose MBMS subchannel is associated with an MSCCK and a corresponding MSCCK‑ID. There can be multiple general purpose MBMS subchannels deployed, each associated with its own MSCCK and corresponding MSCCK-ID. The (MSCCK-ID, MSCCK) pair is provided for each general purpose MBMS subchannel separately.

According to 3GPP TS 33.180 [26] clause 8.2, the MCData Payload Protection Key (DPPK) referenced in clause 6.6 is a Multicast Signalling Keys (MuSiK), (identified by a corresponding (MuSiK-ID)), distributed via MuSiK download messages. The MSCCK and MuSiKs can be distributed independently of each other and in any order and can also be used independently. Signalling supports initial keying, as well as repeated re-keying and un-keying for both MSCCK and MuSiKs.

The MuSiK download message contains an embedded MIME payload which is the MIKEY payload containing the MuSiK and MuSiK-ID, as well as an embedded XML payload potentially containing an explicit list of MCData group ids to which the key applies. Both payloads are protected as described in 3GPP TS 33.180 [26], as they are transferred between the participating MCData function and the MCData client. Within the XML payload, the list of MCData group ids is protected as application sensitive data (see clause 4.8). Within the MIKEY payload, the MuSiK is encrypted using the MCData ID of the served MCData client. The payload is signed using a key associated to the identity of the participating MCData function.

To distribute MuSiK, the participating MCData function uses the I_MESSAGE format from clause 5.2.4 of 3GPP TS 33.180 [26], which includes associated parameters. The participating function sets the Status associated parameter to values defined in clause E.6.9 of 3GPP TS 33.180 [26], namely "Not-revoked" when keying or rekeying and "Revoked" when unkeying, respectively. Upon receipt, the MCData client validates the signature and, if valid, the MCData client first examines the Status attribute and either marks the associated security functions as "not in use" or stores the MuSiK and the MuSiK-ID, and then replies with a success code; otherwise, the MCData client can reply with a failure code. If a success code is not received from the MCData client in response to the MuSiK download message, the participating MCData function starts using only unicast towards the respective MCData client for the listed groups.

The security context is initiated when the MBMS bearer is announced to the MCData clients. The procedure involves the participating MCData function creating an MBMS subchannel control key (MSCCK) and a corresponding key identifier (MSCCK-ID) associated with the MBMS bearer when the MBMS bearer is activated, and then transferring the MSCCK and the MSCCK-ID associated with the MBMS bearer to served MCData clients using SIP signalling. The MSCCK is encrypted using the MCData ID of the served MCData client and domain-specific material provided from the KMS.

The MSCCK and the MSCCK-ID associated with the MBMS bearer are distributed within a MIKEY payload within the SDP describing the general purpose MBMS subchannel of the MBMS bearer. This payload is called a MIKEY-SAKKE I_MESSAGE, as defined in IETF RFC 6509 [55], which ensures the confidentiality, integrity and authenticity of the payload. The encoding of the MIKEY payload in the SDP is described in IETF RFC 4567 [45] using an "a=key-mgmt" attribute. The payload is signed using a key associated to the identity of the participating MCData function. To distribute MSCCK, the participating MCData function uses the I_MESSAGE format from clause 5.2.4 of 3GPP TS 33.180 [26], which includes associated parameters.

The participating function sets the Status associated parameter to values defined in clause E.6.9 of 3GPP TS 33.180 [26], namely "Not-revoked" when keying or rekeying and "Revoked" when unkeying, respectively. Upon receipt, the MCData client validates the signature and, if the signature is found valid and the I_MESSAGE contains a Status attribute, the MCData client first examines the Status attribute and either marks the associated security functions as "not in use" or extracts and stores the encapsulated MSCCK and the corresponding MSCCK-ID. The decrypted key is used as described in 3GPP TS 33.180 [26]. With the MSCCK successfully shared between the participating MCData function and the served UEs, the participating MCData function is able to securely send MBMS subchannel control messages to the MCData clients.

4.8 MCData client ID

The MCData client assigns the MCData client ID when the MCData client is used for the first time. The MCData client generates the MCData client ID as specified in clause 4.2 of IETF RFC 4122 [14].

The MCData client preserves the MCData client ID:

– while the MCData client is SIP registered as specified in 3GPP TS 24.229 [5];

– while the MCData client is not SIP registered as specified in 3GPP TS 24.229 [5] and the UE serving the MCData client is switched on;

– while the UE serving the MCData client is switched off; and

– while the UE serving the MCData client is power-cycled.

NOTE: MCData client ID is not preserved when the UE is reset to factory settings.

4.9 Warning Header Field

4.9.1 General

The MCData server can include a free text string in a SIP response to a SIP request. When the MCData server includes a text string in a response to a SIP MESSAGE or SIP INVITE request the text string is included in a Warning header field as specified in IETF RFC 3261 [4]. The MCData server includes the Warning code set to 399 (miscellaneous warning) and includes the host name set to the host name of the MCData server.

EXAMPLE: Warning: 399 "200 user not authorised to transmit data"

4.9.2 Warning texts

The text string included in a Warning header field consists of an explanatory text preceded by a 3-digit text code, according to the following format in Table 4.9.2-1.

Table 4.9.2-1 ABNF for the Warning text

warn-text =/ DQUOTE mcdata-warn-code SP mcdata-warn-text DQUOTE

mcdata-warn-code = DIGIT DIGIT DIGIT

mcdata-warn-text = *( qdtext | quoted-pair )

Table 4.9.2-2 defines the warning texts that are defined for the Warning header field when a Warning header field is included in a response to a SIP request as specified in clause 4.9.1.

Table 4.9.2-2: Warning texts defined for the Warning header field

Code	Explanatory text		Description
101	service authorisation failed		The service authorisation of the MCData ID against the IMPU failed at the MCData server.
102	too many simultaneous affiliations		The MCData user already has N2 maximum number of simultaneous affiliations.
104	isfocus not assigned		A controlling MCData function has not been assigned to the MCData session.
110	user declined the call invitation		The MCData user declined to accept the call for the file distribuition.
113	group document does not exist		The group document requested from the group management server does not exist.
114	unable to retrieve group document		The group document exists on the group management server but the MCData server was unable to retrieve it.
115	group is disabled		The group has the <disabled> element set to "true" in the group management server.
116	user is not part of the MCData group		The group exists on the group management server, but the requesting user is not part of this group.
120	user is not affiliated to this group		The MCData user is not affiliated to the group.
136	authentication of the MIKEY-SAKKE I_MESSAGE failed		Security context establishment failed.
139	integrity protection check failed		The integrity protection of an XML MIME body failed.
140	unable to decrypt XML content		The XML content cannot be decrypted.
141	user unknown to the participating function		The participating function is unable to associate the public user identity with an MCData ID.
142	unable to determine the controlling function		The participating function is unable to determine the controlling function for the group call or private call.
145	unable to determine called party		The participating function was unable to determine the called party from the information received in the SIP request.
148		group is regrouped	The group hosted by a non-controlling function is part of a temporary group session as the result of the group regroup function.
149		SIP-INFO request pending	The MCData client needs to wait for a SIP-INFO request with specific content, before taking further action.
150		invalid combinations of data received in MIME body	The MCData client included invalid combinations of data in the SIP request.
160		user not authorised to request creation of a regroup	The user is not authorised to request creation of a regroup.
161		user not authorised to request removal of a regroup	The user is not authorised to request removal of a regroup.
162		group call abandoned due to required group members not affiliated	The group call was abandoned as the required number of affiliated group members is not met or some required members are not affiliated.
163		the group identity indicated in the request does not exist	The server determines that the group identity indicates a user or group regroup based on a preconfigured group that does not exist.
165		group ID for regroup already in use	The group ID proposed by the client for the user/group regroup based on a preconfigured group is already in use.
167		call is not allowed on the preconfigured group	Calls are not allowed on this group that is administratively designated for preconfigured group use only.
168		alert is not allowed on the preconfigured group	Alerts are not allowed on this group that is administratively designated for preconfigured group use only.
176		user not authorized to request for binding/unbinding of a functional alias with the MCData group(s) for the MCData user		The function is not allowed to this user.
177		unable to determine target functional alias or group for creating/removing a binding information for the MCData user		The MCData server is unable to determine the targeted functional alias or group for creating/removing an binding information for the MCData user
178		MCData group binding already exists with other functional alias for the MCData user		The requested functional alias binding with MCData group already exist with other functional alias for the MCData user
179		service not authorized with the interconnected system		The MCData service is not authorized between the local and the interconnected system and is rejected in the local system
180		service not authorized by the interconnected system		The MCData service is not authorized between the local and the interconnected system and is rejected by the interconnected system
198	no users are affiliated to this group		No users in the group are affiliated.
199	expected MIME bodies not in the request"		The expected MIME bodies were not received in the SIP request.
200	user not authorised to transmit data		The MCData user is not authorised to transmit data.
201	user not authorised to transmit data on this group identity		The MCData user is not authorised to transmit data on the group identity included in the request.
202	user not authorised for one-to-one MCData communications due to exceeding the maximum amount of data that can be sent in a single request		The MCData user is not authorised for one-to-one MCData communications due to exceeding the maximum amount of data that can be sent in a single request
203	message too large to send over signalling control plane		The MCData client sent data that is greater than the size that can be handled by the signalling control plane.
204	unable to determine targeted user for one-to-one SDS		The MCData server is unable to determine the targeted user for one-to-one SDS.
205	unable to determine targeted user for one-to-one FD		The MCData server is unable to determine the targeted user for one-to-one FD.
206	short data service not allowed for this group		SDS is not allowed on the group indicated in the SDS request.
207	SDS services not supported for this group		SDS services not supported for this group
208	user not authorised for MCData communications on this group identity due to exceeding the maximum amount of data that can be sent in a single request		The MCData user is not authorised for group MCData communications due to exceeding the maximum amount of data that can be sent in a single request.
209	one FD SIGNALLING PAYLOAD or FD HTTP TERMINATION message only must be present in FD request		Only one FD SIGNALLING PAYLOAD or FD HTTP TERMINATION message must be present in FD request
210	Only one File URL must be present in the FD request		Only one File URL must be present in the FD request.
211	payload for an FD request is not FILEURL		The payload in the FD request did not contain a FILEURL
212	file referenced by file URL does not exist		The MCData server was unable to locate the file referenced by the file URL.
213	file distribution not allowed for this group		FD is not allowed on the group indicated in the FD request.
214	FD services not supported for this group		FD services not supported for this group
215	request to transmit is queued by the server		The MCData request was queued by the server for later transmission.
216	unable to correlate the disposition notification		The MCData server was unable to correlate the disposition notification to a MCData message.
217	user not authorised for SDS communications on this group identity due to message size		The size of the message exceeded the maximum data allowed for SDS communications on this group identity
218	user not authorised for one-to-one SDS communications due to message size		The size of the message exceeded the maximum data allowed for one-to-one SDS communications.
219	user not authorised for FD communications on this group identity due to file size		The size of the file exceeded the maximum data allowed for FD communications on this group identity
220	user not authorised for FD communications due to file size		The size of the file exceeded the maximum data allowed for one-to-one FD communications.
221	user not authorised to initiate one-to-one SDS session		The MCData user is not authorised to initiate a one-to-one SDS session.
222	user not authorised to initiate group SDS session on this group identity		The MCData user is not authorised to initiate a SDS session on the group identity included in the request.
223	No Conversation ID or Message ID present		Conversation ID and Message ID required to identify transmission
224	No Transmission available		No transmission identified with given Conversation ID, Message Id and file URL
225		User not authorized to initiate pre-established session	The MCData user is not authorised to initiate a pre-established MCData session.
226		function not allowed due to pre-established session not supported	Pre-established session is not supported by MCData participating function
227		unable to determine targeted user for one-to-one IP Connectivity	The MCData server is unable to determine the targeted user for one-to-one IP Connectivity.
228		maximum number of service authorizations reached	The number of maximum simultaneous service authorizations for the MCData user has been reached.
229		one-to-one MCData communication not authorised to the targeted user	The user is not authorised to initiate one-to-one MCData communication to this targeted user.
230		one-to-one MCData communication not authorised from this originating user	The user is not authorised to receive one-to-one MCData communication from this originating user.
231		user deferred the call invitation	The MCData user deferred the call invitation for the file distribuition.
232		communication is stored for later delivery	The participating MCData function stores the communication for later delivery if the receiving MCData user is not available at the time of data delivery or the network is congested, or the request is deferred by the MCData user. If the communication is for file distribution then the file content is also stored.
233	user not authorised to initiate emergency communication			The user is not authorised to initiate emergency MCData communication.
234	user not authorized to enable or disable the storage of MCData communications into the MCData message store			The function is not allowed to this user.
235	unable to determine target user or group for enabling or disabling the storage of MCData communications into the MCData message store			The MCData server is unable to determine the targeted user or group for enabling or disabling the storage of MCData communications

4.10 MCData emergency groups and emergency group communications

MCData emergency groups and emergency group communications as defined by 3GPP TS 23.282 [2] are supported by the procedures in this specification. There are a number of state variables used to manage MCData emergencies, including:

– MCData emergency (MED) state: in accordance with 3GPP TS 23.282 [2], indicates (see clause G.4.2) that the MCData user is in a life-threatening situation. This MCData client state variable is changed via action by the MCData user of the device or by an authorised MCData user. While the MCData emergency state is set on the client, all communications originated by the client will be MCData emergency communications, assuming the MCData user is authorised for MCData emergency communications.

– in-progress emergency group (IPEG) state: in accordance with 3GPP TS 23.282 [2], this state variable (see clause G.4.3) indicates whether or not there is an MCData emergency group communication ongoing on the specified group. This state is managed by the controlling MCData function. All group communications originated on this MCData group when in an in-progress emergency state are MCData emergency group communications until this state is cancelled, regardless of the originator being (or not) in an MCData emergency state.

– MCData emergency group (MDEG) state: this is an internal state (see clause G.4.4) managed by the MCData client which tracks the in-progress emergency state of the group (see 3GPP TS 23.282 [2]) managed by the controlling MCData function. Ideally, the MCData client would not need to track the in-progress emergency group state, but doing so enables the MCData client to request MCData emergency-level priority earlier than otherwise possible. For example, if the MCData user wishes to join an MCData emergency group communication and is not in MCData emergency state itself, the MCData client should have emergency level priority. If it has knowledge of the in-progress emergency state of the group, it can request priority by including a Resource-Priority header field set to the MCPTT namespace specified in IETF RFC 8101 [67], and appropriate priority level in the SIP INVITE request (or SIP re-INVITE request).

– MCData emergency group communication (MDEGC) state: this is an internal state (see clause G.4.5) corresponding to an ongoing group communication. The state is managed by the MCData client, which in conjunction with the MCData emergency alert state (see clause 4.4), aids in managing the MCData emergency state and related actions.

4.11 MCData imminent peril group communications

MCData imminent peril group communications as defined by 3GPP TS 23.282 [2] are supported by the procedures in this specification. The following MCData imminent peril group communications functionalities are specified in the present document:

– MCData imminent peril group communications origination;

– upgrade of an MCData group communication to an MCData imminent peril group communication;

– upgrade from an MCData imminent peril group communication to an MCData emergency group communication; and

– cancellation of the in-progress imminent peril state of the group.

Key aspects of MCData imminent peril include:

– adjusted EPS bearer priority for all participants when the in-progress imminent peril state of the group is set whether or not they themselves initiated an imminent peril group communication. For unicast bearers this is achieved by using the Resource-Priority header field as specified in IETF RFC 4412 [74] with namespaces defined for use by MCPTT specified in IETF RFC 8101 [67], and for MBMS bearers this is achieved by having the participating MCData function adjust the ARP (priority, PVI, PCI) and executing the Modify MBMS Bearer Procedure per 3GPP TS 29.468 [57];

– restoration of normal EPS bearer priority to the communication when the in-progress imminent peril group state is cancelled; and

– requires the MCData user to be authorised to either originate or cancel an MCData imminent peril group communication.

Relationship to other MCData priority group communication types:

– A normal MCData group communication can be upgraded to an MCData imminent peril group communication;

– An MCData imminent peril group communication can be upgraded to an MCData emergency group communication;

– An MCData imminent peril group communication or an MCData emergency group communication (i.e., their respective "in-progress" states) can be downgraded to a normal MCData group communication, but it is not possible to directly downgrade an MCData emergency group communication to an MCData imminent peril group communication;

– MCData imminent peril functionality is only applicable to MCData group communications, not MCData private communications; and

– MCData imminent peril group communications have no associated alert capabilities such as the MCData emergency alert capability which is associated with MCData emergency group communications.

There are a number of states that are key in managing these aspects of MCData imminent peril group communications, which include:

– MCData imminent peril group (MDIG) state: this is an internal state of the MCData client which in conjunction with the MCData imminent peril group communication state aids the client in managing the use of the Resource-Priority header field and related actions.

– MCData imminent peril group communication (MIGC) state: this is an internal state managed by the MCData client which in conjunction with the MCData imminent peril group state aids the client in managing the use of the Resource-Priority header field and related actions.

– In-progress imminent peril group (IPIG) state: this a state of the MCData group which is managed by the controlling MCData function. While an MCData group is in an in-progress imminent peril group state, all participants in group communications using this group will receive elevated priority.

The above states and their transitions are described in Annex G.

4.12 MCData emergency private communications

MCData emergency private communications refer to emergency one‑to‑one communications. The following MCData emergency private communication functionalities are specified in the present document:

– MCData emergency private communication origination with optional MCData emergency alert initiation;

– upgrade of an MCData private communication to an MCData emergency private; and

– cancellation of the MCData emergency private communication priority.

Key aspects of MCData emergency private communications include:

– adjusted EPS bearer priority for both participants whether or not they are both in an emergency condition (i.e. both have their MCData emergency state set). This is achieved by using the Resource-Priority header field as specified in IETF RFC 4412 [74] with namespaces defined for use by MCPTT specified in IETF RFC 8101 [67];

– the initiator of the MCData emergency private communication can override the other MCData user in the MCData emergency private communication unless that user also has their MCData emergency state set;

– restoration of normal EPS bearer priority to the communication according to system policy (e.g., configured time limit for the emergency priority of an MCData emergency private communication or cancellation of the emergency condition of the private communication);

– requires the MCData user to be authorised to either originate or cancel an MCData emergency private communication;

– requires the targeted MCData user to be authorised to receive an MCData emergency private communication;

– requests to originate MCData emergency private communications may also include an indication of an MCData emergency alert; and

There are a number of states that are key in managing these aspects of MCData emergency private communications, which include:

– MCData private emergency alert (MDPEA) state: this is an internal state of the MCData client which in conjunction with the MCData emergency private communication state aids in managing the MCData emergency state and related actions.

– MCData emergency private communication (MDEPC) state: this is an internal state managed by the MCData client which in conjunction with the MCData emergency alert state aids in managing the MCData emergency state and related actions.

– In-progress emergency private communication (IPEPC) state: indicates whether or not there is an MCData emergency private communication in-progress for the two participants. This state is managed by the controlling MCData function. All private communications originated between these two participants when in an in-progress emergency private communication state are MCData emergency private communications until this state is cancelled, whether or not the originator is in an MCData emergency state.

– MCData emergency private priority (MDEPP) state: this is an internal state managed by the MCData client which tracks the in-progress emergency private communication state of the private communication managed by the controlling MCData function. Ideally, the MCData client would not need to track the in-progress emergency private priority state, but doing so enables the MCData client to request MCData emergency-level priority earlier than otherwise possible. For example, if the MCData user wishes to join an MCData emergency private communication and is not in the MCData emergency state, the MCData client should have emergency level priority. If it has knowledge of the in-progress emergency private priority state of the private communication (i.e., the two participants), it can request priority by including a Resource-Priority header field set to the MCPTT namespace specified in IETF RFC 8101 [67], and appropriate priority level in the SIP INVITE request (or SIP re-INVITE request).

NOTE: The above states and their transitions are described in Annex G.