7 Registration and service authorisation

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

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

7.1 General

This clause describes the procedures for SIP registration and MCData service authorization for the MCData client and the MCData service. The MCData UE can use SIP REGISTER or SIP PUBLISH for MCData service settings to perform service authorization for MCData. The decision which method to use is based on implementation and on availability of an access-token received as outcome of the user authentication procedure as described in 3GPP TS 24.482 [24].

If another MC service client (e.g. MCPTT, MCVideo) is operating at the same time on the same MC UE as the MCData client, then the MCData client shares the same SIP registration as the other MC service clients. The SIP REGISTER procedures in this clause are combined with the SIP REGISTER procedures for the other operating MC service clients to create a single SIP REGISTER request. If other MC service clients are already operating when the MCData client registers then a re-registration is performed containing the parameters for the other operating MC services.

Although the access-token can be the same for the MCData service as for other MC services when performing service authorization for MCData along with other MC services using SIP REGISTER multipart MIME bodies for each MC service are included in the SIP REGISTER request. The MCData server can therefore receive multipart MIME bodies in the SIP REGISTER request. Multiple contact addresses (one per MC service client) can be included in a SIP REGISTER request provided they all contain the same IP address and port number (see 3GPP TS 24.229 [5] for further details of including multiple contact addresses in a single SIP REGISTER request).

If the MCData client logs off from the MCData service but other MC service clients are to remain registered the MC UE performs a re-registration as specified in 3GPP TS 24.229 [5] without the supported g.3gpp.mcdata media feature tags and the g.3gpp.icsi-ref media feature tags containing the values of the supported MCData service ICSIs in the Contact header field of the SIP REGISTER request but with the parameters for the remaining operating MC service clients.

7.2 MCData client procedures

7.2.1 SIP REGISTER request for service authorisation

When the MCData client performs SIP registration for service authorisation the MCData client shall perform the registration procedures as specified in 3GPP TS 24.229 [5].

The MCData client shall include the following media feature tags in the Contact header field of the SIP REGISTER request:

1) the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata";

2) if SDS is supported then:

a) the g.3gpp.mcdata.sds media feature tag; and

b) the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds"; and

3) if FD service is supported then:

a) the g.3gpp.mcdata.fd media feature tag; and

b) the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd".

NOTE 1: If the MCData client logs off from the MCData service but the MCData UE remains registered the MCData UE performs a re-registration as specified in 3GPP TS 24.229 [5] without the supported g.3gpp.mcdata media feature tags and the g.3gpp.icsi-ref media feature tag containing the supported MCData service ICSIs in the Contact header field of the SIP REGISTER request.

If the MCData client, upon performing SIP registration:

1) has successfully finished the user authentication procedure as described in 3GPP TS 24.482 [24];

2) has available an access-token;

3) based on implementation decides to use SIP REGISTER for service authorization;

4) confidentiality protection is disabled as specified in clause 6.5.2.3.1; and

5) integrity protection is disabled as specified in clause 6.5.3.3.1;

then the MCData client shall include in the SIP REGISTER request an application/vnd.3gpp.mcdata-info+xml MIME body as defined in Annex D.1 with:

1) the <mcdata-access-token> element set to the value of the access token received during the user authentication procedures; and

2) the <mcdata-client-id> element set to the value of the MCData client ID of the originating MCData client.

NOTE 2: the access-token contains the MCData ID of the user.

If the MCData client, upon performing SIP registration:

1) has successfully finished the user authentication procedure as described in 3GPP TS 24.482 [24];

2) has an available access-token;

3) based on implementation decides to use SIP REGISTER for service authorization; and

4) either confidentiality protection is enabled as specified in clause 6.5.2.3.1 or integrity protection is enabled as specified in clause 6.5.3.3.1;

then the MCData client:

1) shall include an application/mikey MIME body with the CSK as MIKEY-SAKKE I_MESSAGE as specified in 3GPP TS 33.180 [26] in the body of the SIP REGISTER request;

2) if confidentiality protection is enabled as specified in clause 6.5.2.3.1, shall include in the body of the SIP REGISTER request an application/vnd.3gpp.mcdata-info+xml MIME body with the following clarifications:

a) shall encrypt the received access-token using the CSK and include the <mcdata‑access‑token> element set to the encrypted access-token, as specified in clause 6.5.2.3.1; and

b) shall encrypt the MCData client ID of the originating MCData client using the CSK and include the <mcdata‑client‑id> element set to the encrypted MCData client ID;

3) if confidentiality protection is disabled as specified in clause 6.5.2.3.1, shall include an application/vnd.3gpp.mcdata-info+xml MIME body as defined in Annex D.1 with:

a) the <mcdata-access-token> element set to the value of the access token received during the user authentication procedures; and

b) the <mcdata-client-id> element set to the value of the MCData client ID of the originating MCData client; and

4) if integrity protection is enabled as specified in clause 6.5.3.3.1, shall use the CSK to integrity protect the application/vnd.3gpp.mcdata-info+xml MIME body by following the procedures in clause 6.6.3.3.3.

7.2.1AA SIP REGISTER request without service authorisation

When the MCData client performs SIP registration without service authorisation the MCData client shall perform the registration procedures as specified in 3GPP TS 24.229 [5].

The MCData client shall include the following media feature tags in the Contact header field of the SIP REGISTER request:

1) the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata";

2) if SDS is supported then:

a) the g.3gpp.mcdata.sds media feature tag; and

b) the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds"; and

3) if FD service is supported then:

a) the g.3gpp.mcdata.fd media feature tag; and

b) the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd".

NOTE: If the MCData client logs off from the MCData service but the MCData UE remains registered the MCData UE performs a re-registration as specified in 3GPP TS 24.229 [5], without the supported g.3gpp.mcdata media feature tags and the g.3gpp.icsi-ref media feature tag containing the supported MCData service ICSIs in the Contact header field of the SIP REGISTER request.

7.2.1A Common SIP PUBLISH procedure

This procedure is only referenced from other procedures.

When populating the SIP PUBLISH request, the MCData client shall:

1) shall set the Request-URI to the public service identity identifying the participating MCData function serving the MCData user;

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

3) shall set the Event header field to the "poc-settings" value; and

4) shall set the Expires header field according to IETF RFC 3903 [34], to 4294967295, if the MCData user is not removing the MCData service settings, otherwise to remove the MCData service settings the MCData client shall set the Expires header field to zero.

NOTE 1: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

NOTE 2: The expiration timer of the MCData client service settings is only applicable for the MCData client service settings from the MCData client that matches the Instance Identifier URN. The expiration timer of MCData user service settings is also updated in the MCData server if expiration timer of MCData client service settings is updated in the MCData server.

NOTE 3: Removing the MCData service settings by setting the Expires header field to zero, logs off the MCData client from the MCData service.

7.2.2 SIP PUBLISH request for service authorisation and MCData service settings

If based on implementation the MCData client decides to use SIP PUBLISH for MCData server settings to also perform service authorization and

1) has successfully finished the user authentication procedure as described in 3GPP TS 24.482 [24]; and

2) has available an access-token;

then the MCData client:

1) shall perform the procedures in clause 7.2.1A;

2) if confidentiality protection is disabled as specified in clause 6.5.2.3.1 and integrity protection is disabled, shall include in the body of the SIP PUBLISH request, an application/vnd.3gpp.mcdata-info+xml MIME body as specified in Annex D.1 with the <mcdata-access-token> element set to the value of the access token received during the user authentication procedures;

3) if either confidentiality protection is enabled as specified in clause 6.5.2.3.1 or integrity protection is enabled as specified in clause 6.5.3.3.1 shall include an application/mikey MIME body with the CSK as MIKEY-SAKKE I_MESSAGE as specified in 3GPP TS 33.180 [26] in the body of the SIP PUBLISH request;

4) if confidentiality protection is enabled as specified in clause 6.5.2.3.1, shall include in the body of the SIP PUBLISH request an application/vnd.3gpp.mcdata-info+xml MIME body with:

a) the <mcdata-access-token> element set to the received access-token encrypted using the CSK, as specified in clause 6.5.2.3.3; and

b) the <mcdata-client-id> element set to the encrypted MCData client ID of the originating MCData client, as specified in clause 6.5.2.3.3;

5) if confidentiality protection is disabled as specified in clause 6.5.2.3.1, shall include in the body of the SIP PUBLISH request, an application/vnd.3gpp.mcdata-info+xml MIME body as specified in Annex D.1 with:

a) the <mcdata-access-token> element set to the value of the access token received during the user authentication procedures in the body of the SIP PUBLISH request; and

b) the <mcdata-client-id> element set to the value of the MCData client ID of the originating MCData client;

6) shall include an application/poc-settings+xml MIME body as defined in 3GPP TS 24.379 [10] containing:

a) the <selected-user-profile-index> element set to the value contained in the "user-profile-index" attribute of the selected MCData user profile as defined in 3GPP TS 24.484 [12]; and

7) if integrity protection is enabled as specified in clause 6.5.3.3.1, shall use the CSK to integrity protect the application/vnd.3gpp.mcdata-info+xml MIME body and application/poc-settings+xml MIME body by following the procedures in clause 6.5.3.3.3.

The MCData client shall send the SIP PUBLISH request according to 3GPP TS 24.229 [5].

7.2.3 Sending SIP PUBLISH for MCData service settings only

To set, update, remove or refresh the MCData service settings, the MCData client shall generate a SIP PUBLISH request according 3GPP TS 24.229 [5], IETF RFC 3903 [34] and IETF RFC 4354 [35]. In the SIP PUBLISH request, the MCData client:

1) shall perform the procedures in clause 7.2.1A;

2) if confidentiality protection is enabled as specified in clause 6.5.2.3.1, shall include in the body of the SIP PUBLISH request, an application/vnd.3gpp.mcdata-info+xml MIME body with:

a) the <mcdata-request-uri> element set to the targeted MCData ID encrypted using the CSK, as specified in clause 6.5.2.3.3; and

b) the <mcdata-client-id> element set to the encrypted MCData client ID of the originating MCData client, as specified in clause 6.5.2.3.3;

3) if confidentiality protection is disabled as specified in clause 6.5.2.3.1, shall include an application/vnd.3gpp.mcdata-info+xml MIME body as specified in Annex D.1 with:

a) the <mcdata-request-uri> set to the cleartext targeted MCData ID; and

b) the <mcdata-client-id> element set to the value of the MCData client ID of the originating MCData client;

4) shall include an application/poc-settings+xml MIME body as defined in 3GPP TS 24.379 [10] containing:

a) the <selected-user-profile-index> element set to the value contained in the "user-profile-index" attribute of the selected MCData user profile as defined in 3GPP TS 24.484 [12]; and

5) if integrity protection is enabled as specified in clause 6.5.3.3.1, shall use the CSK to integrity protect the application/vnd.3gpp.mcdata-info+xml MIME body and application/poc-settings+xml MIME body by following the procedures in clause 6.5.3.3.3.

The MCData client shall send the SIP PUBLISH request according to 3GPP TS 24.229 [5].

On receiving the SIP 200 (OK) response to the SIP PUBLISH request the MCData client may indicate to the MCData User the successful communication of the MCData service settings to the MCData server.

7.2.4 Determination of MCData service settings

In order to discover MCData service settings of another MCData client of the same MCData user or to verify the currently active MCData service settings of this MCData client, the MCData client shall generate an initial SIP SUBSCRIBE request according to 3GPP TS 24.229 [5], IETF RFC 6665 [36], and IETF RFC 4354 [35].

In the SIP SUBSCRIBE request, the MCData client:

1) shall set the Request-URI to the public service identity identifying the originating participating MCData function serving the MCData user;

2) shall include an application/vnd.3gpp.mcdata-info+xml MIME body. In the application/vnd.3gpp.mcdata-info+xml MIME body, the MCData client shall include the <mcdata-request-uri> element set to the MCData ID of the MCData user;

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

4) shall set the Event header field to the ‘poc-settings’ value;

5) shall include an Accept header field containing the "application/poc-settings+xml" MIME type;

6) if the MCData client wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [36], to 4294967295; and

NOTE 1: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

7) if the MCData client wants to fetch the current state only, shall set the Expires header field according to IETF RFC 6665 [36], to zero.

In order to re-subscribe or de-subscribe, the MCData client shall generate an in-dialog SIP SUBSCRIBE request according to 3GPP TS 24.229 [5], IETF RFC 6665 [36], IETF RFC 4354 [35]. In the SIP SUBSCRIBE request, the MCData client:

1) shall set the Event header field to the ‘poc-settings’ value;

2) shall include an Accept header field containing the "application/poc-settings+xml" MIME type;

3) if the MCData client wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [36], to 4294967295; and

NOTE 2: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

4) if the MCData client wants to de-subscribe, shall set the Expires header field according to IETF RFC 6665 [36], to zero.

Upon receiving a SIP NOTIFY request according to 3GPP TS 24.229 [5], IETF RFC 6665 [36] and IETF RFC 4354 [35], that contains an application/poc-settings+xml MIME body the MCData client shall cache:

1) the <am-settings> element of the poc-settings+xml MIME body for each MCData client identified by the "id" attribute according to IETF RFC 4354 [35] as the current Answer-mode indication of that MCData client; and

2) the <selected-user-profile-index> element of the poc-settings+xml MIME body for each MCData client identified by the "id" attribute according to IETF RFC 4354 [35] as the active MCData user profile of that MCData client.

7.2.5 Receiving a CSK key download message

When the MCData client receives a SIP MESSAGE request containing:

1) a P-Asserted-Service header field containing the "urn:urn-7:3gpp-service.ims.icsi.mcdata"; and

2) an application/mikey MIME body;

Then, if the key identifier within the CSB-ID of the MIKEY payload is a CSK-ID (4 most-significant bits have the value ‘2’), the MCData client:

1) shall follow the security procedures in clause 9.2.1 of 3GPP TS 33.180 [26] to extract the CSK. The client:

a) if the initiator field (IDRi) has type ‘URI’ (identity hiding is not used), the client:

i) shall extract the initiator URI from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [26]. If the initiator URI deviates from the public service identity of the participating MCData function serving the MCData user, shall reject the SIP MESSAGE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [45], and include warning text set to "136 authentication of the MIKEY-SAKKE I_MESSAGE failed" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps; and

ii) shall convert the initiator URI to a UID as described in 3GPP TS 33.180 [26];

b) if the initiator field (IDRi) has type ‘UID’ (identity hiding in use), the client:

i) shall convert the public service identity of participating MCData function serving the MCData user to a UID as described in 3GPP TS 33.180 [26]; and

ii) shall compare the generated UID with the UID in the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [26]. If the two initiator UIDs deviate from each other, shall reject the SIP MESSAGE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [45], and include warning text set to "136 authentication of the MIKEY-SAKKE I_MESSAGE failed" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;

c) shall use the UID to validate the signature of the I_MESSAGE as described in 3GPP TS 33.180 [26];

d) if authentication verification of the I_MESSAGE fails, shall reject the SIP MESSAGE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [45], and include warning text set to "136 authentication of the MIKEY-SAKKE I_MESSAGE failed" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;

e) shall extract and decrypt the encapsulated CSK using the participating MCData function’s (KMS provisioned) UID key as described in 3GPP TS 33.180 [26];

f) shall extract and store the algorithm to be used to protect the MCData signalling fields; and

g) shall extract the CSK-ID, from the payload as specified in 3GPP TS 33.180 [26]; and

2) Upon successful extraction, the client shall replace the existing CSK and CSK-ID associated with the participating MCData function, with the extracted CSK and CSK-ID in the ‘key download’ message.

7.3 MCData server procedures

7.3.1 General

The MCData server obtains information that it needs to implement service authorization specific requirements from:

a) any received third-party SIP REGISTER request (e.g. including information contained in the body of the third-party SIP REGISTER request) as specified in 3GPP TS 24.229 [5]. The body will carry the SIP REGISTER request as sent by the MCData client and may contain information needed for service authorization; or

b) any received SIP PUBLISH request for MCData server settings containing the g.3gpp.mcdata.sds media feature tag along with the "require" and "explicit" header field parameters. The body of the SIP PUBLISH request will contain information needed for service authorization.

7.3.1A Confidentiality and Integrity Protection

When the MCData server receives a SIP REGISTER request sent from the MCData client contained within a message/sip MIME body of a received third-party SIP REGISTER request or a SIP PUBLISH request, it first determines whether XML MIME bodies included in the request are integrity protected. If XML MIME bodies are integrity protected the MCData server validates the signature of each of the XML MIME bodies. If the integrity protection check(s) pass or the XML MIME bodies are not integrity protected, the MCData server then determines whether the content in specific XML elements is confidentiality protected. If XML content is confidentiality protected, the MCData server decrypts the protected content.

Upon receiving:

– a SIP REGISTER request containing an application/vnd.3gpp.mcdata-info+xml MIME body within a message/sip MIME body of the SIP REGISTER request sent from the MCData client; or

– a SIP PUBLISH request containing an application/vnd.3gpp.mcdata-info+xml MIME body and an application/poc-settings+xml MIME body;

the MCData server:

1) shall determine if integrity protection has been applied to XML MIME bodies in the SIP request by following the procedures in clause 6.5.3.4.1 for each XML MIME body;

2) if integrity protection has been applied, shall use the keying data described in clause 6.5.3.2 and the procedures described in clause 6.5.3.4.2 to verify the integrity of each of the XML MIME bodies; and

3) if all integrity protection checks succeed, shall continue with the remaining steps of this clause.

Upon receiving:

– a SIP REGISTER request containing an application/vnd.3gpp.mcdata-info+xml MIME body with an <mcdata-access-token> element and an <mcdata-client-id> element within a message/sip MIME body of the SIP REGISTER request sent from the MCData client; or

– a SIP PUBLISH request containing an application/vnd.3gpp.mcdata-info+xml MIME body with an <mcdata-access-token> element and an <mcdata-client-id> element, and an application/poc-settings+xml MIME body;

the MCData server:

1) shall determine if confidentiality protection has been applied to the <mcdata-access-token> element and the <mcdata-client-id> element in the application/vnd.3gpp.mcdata-info+xml MIME body, by following the procedures in clause 6.5.2.4.1;

2) if confidentiality protection has been applied to the <mcdata-access-token> element and <mcdata-client-id> element:

a) shall use the keying information received in the MIKEY-SAKKE I_MESSAGE as specified in 3GPP TS 33.180 [26], along with the procedures described in clause 6.5.2.4.2 to:

i) decrypt the received access token in the <mcdata-access-token> element in the application/vnd.3gpp.mcdata-info+xml MIME body; and

ii) decrypt the received MCData client ID in the <mcdata-client-id> element in the application/vnd.3gpp.mcdata-info+xml MIME body;

b) if the decryption procedure succeeds, shall identify the MCData ID and the MCData client ID from the decrypted values; and

c) if the decryption procedure fails, shall determine that confidentiality protection has not been successful;

3) if confidentiality protection has been applied to only one of the <mcdata-access-token> element or the <mcdata-client-id> element:

a) shall determine that confidentiality protection has not been successful;

4) if confidentiality protection has not been applied:

a) shall identify the MCData ID from <mcdata-access-token> element received in the application/vnd.3gpp.mcdata-info+xml MIME body; and

b) shall identify the MCData client ID from the <mcdata-client-id> element received in the application/vnd.3gpp.mcdata-info+xml MIME body.

Upon receiving a SIP PUBLISH request containing an application/vnd.3gpp.mcdata-info+xml MIME body with an <mcdata-request-uri> element, an <mcdata-client-id> element, and an application/poc-settings+xml MIME body, the MCData server:

1) shall determine if confidentiality protection has been applied to the <mcdata-request-uri> element and the <mcdata-client-id> element in the application/vnd.3gpp.mcdata-info+xml MIME body by following the procedures in clause 6.5.2.4.1;

2) if confidentiality protection has been applied to the <mcdata-request-uri> element and the <mcdata-client-id> element:

a) shall use the keying information described in clause 6.5.2.2 along with the procedures described in clause 6.5.2.4.2 to:

i) decrypt the received encrypted MCData ID in the <mcdata-request-uri> element in the application/vnd.3gpp.mcdata-info+xml MIME body; and

ii) decrypt the received encrypted MCData client ID in the <mcdata-client-id> element in the application/vnd.3gpp.mcdata-info+xml MIME body;

b) if all decryption procedures succeed, shall identify the MCData ID and MCData client ID from the decrypted values; and

c) if the decryption procedure fails, shall determine that confidentiality protection has not been successful;

3) if confidentiality protection has been applied to only one of the <mcdata-request-uri> element or <mcdata-client-id> element:

a) shall determine that confidentiality protection has not been successful;

4) if confidentiality protection has not been applied:

a) shall identify the MCData ID from the contents of the <mcdata-request-uri> element in the application/vnd.3gpp.mcdata-info+xml MIME body; and

b) shall identify the MCData client ID from the <mcdata-client-id> element received in the application/vnd.3gpp.mcdata-info+xml MIME body.

7.3.2 SIP REGISTER request for service authorisation

The MCData server shall support obtaining service authorization specific information from the SIP REGISTER request sent from the MCData client and included in the body of a third-party SIP REGISTER request.

NOTE 1: 3GPP TS 24.229 [5] defines how based on initial filter criteria the SIP REGISTER request sent from the UE is included in the body of the third-party SIP REGISTER request.

Upon receiving a third party SIP REGISTER request with a message/sip MIME body containing the SIP REGISTER request sent from the MCData client containing an application/vnd.3gpp.mcdata-info+xml MIME body with an <mcdata-access-token> element and an <mcdata-client-id> element within a message/sip MIME body of the SIP REGISTER request sent from the MCData client, the MCData server:

1) shall identify the IMS public user identity from the third-party SIP REGISTER request;

2) shall identify the MCData ID from the SIP REGISTER request sent from the MCData client and included in the message/sip MIME body of the third-party SIP REGISTER request by following the procedures in clause 7.3.1A;

2A) shall check if the number of maximum simultaneous authorizations supported for the MCData user is specified in the <user-max-simultaneous-authorizations> element of the <anyExt> element contained in the <OnNetwork> element of the MCData user profile (see the user profile configuration document in 3GPP TS 24.484 [12]) and if present shall check whether it has been reached. If reached, the MCData server shall not continue with the rest of the steps in this clause;

2B) if the <user-max-simultaneous-authorizations> element of the <anyExt> element is not present in the <OnNetwork> element of the MCData user profile (see the user profile configuration document in 3GPP TS 24.484 [12]), shall check if the number of maximum simultaneous authorizations supported for any MCData user as specified in the <max-simultaneous-authorizations> element of the <anyExt> element contained in the <OnNetwork> element of the MCData service configuration document (see the service configuration document in 3GPP TS 24.484 [12]) has been reached. If reached, the MCData server shall not continue with the rest of the steps in this clause;

3) shall perform service authorization for the identified MCData ID as described in 3GPP TS 33.180 [26];

4) if service authorization was successful, shall bind the MCData ID and the MCData client ID to the IMS public user identity;

4a) if service authorization was successful and if the service authorization request was from an MCData user who is previously MCData service authorized on another MCData client (as determined by a comparison of the received MCData client ID with the MCData client ID of existing bindings), keep the current bindings and create a new binding between the MCData ID, the MCData client ID and the IMS public user identity;

NOTE 2: The MCData server will store the binding MCData ID, MCData client ID, IMS public user identity and an identifier addressing the MCData server in an external database.

5) if a Resource-Share header field with the value "supported" is contained in the "message/sip" MIME body of the third-party REGISTER request, shall bind the MCData ID and the MCData client ID to the identity of the MCData UE identified by the "+g.3gpp.registration-token" header field parameter in the Contact header field of the incoming third-party REGISTER request; and

6) if more than one binding exists for the MCData ID, shall include in the SIP 200 (OK) response an application/vnd.3gpp.mcdata-info+xml MIME body as specified in annex D.1 with a <multiple-devices-ind> element set to the value "true".

7.3.3 SIP PUBLISH request for service authorisation and service settings

The MCData server shall support obtaining service authorization specific information from a SIP PUBLISH request for MCData server settings.

Upon receiving a SIP PUBLISH request containing:

1) an Event header field set to the "poc-settings" value;

2) an application/poc-settings+xml MIME body; and

3) an application/vnd.3gpp.mcdata-info+xml MIME body containing an <mcdata-access-token> element and an <mcdata-client-id> element;

the MCData server:

1) shall identify the IMS public user identity from the P-Asserted-Identity header field;

2) shall perform the procedures in clause 7.3.1A;

3) if the procedures in clause 7.3.1A were not successful shall send a SIP 403 (Forbidden) response towards the MCData client with the warning text set to: "140 unable to decrypt XML content " in a Warning header field as specified in clause 4.9, and not continue with the rest of the steps in this clause;

3A) shall check if the number of maximum simultaneous authorizations supported for the MCData user as specified in the <user-max-simultaneous-authorizations> element of the <anyExt> element contained in the <OnNetwork> element of the MCData user profile (see the MCData user profile service configuration document in 3GPP TS 24.484 [12]) has been reached. If reached, the MCData server shall send a SIP 486 (Busy Here) response towards the MCData client with the warning text set to: "228 maximum number of service authorizations reached" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps in this clause;

3B) if the <user-max-simultaneous-authorizations> element of the <anyExt> element is not present in the <OnNetwork> element of the MCData user profile (see the user profile configuration document in 3GPP TS 24.484 [12]), shall check if the number of maximum simultaneous authorizations supported for any MCData user as specified in the <max-simultaneous-authorizations> element of the <anyExt> element contained in the <OnNetwork> element of the MCData service configuration document (see the service configuration document in 3GPP TS 24.484 [12]) has been reached. If reached, the MCData server shall send a SIP 486 (Busy Here) response towards the MCData client with the warning text set to: "228 maximum number of service authorizations reached" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps in this clause;

4) shall perform service authorization for the identified MCData ID as described in 3GPP TS 33.180 [26];

5) if service authorization was successful:

a) shall bind the MCData ID and MCData client ID to the IMS public user identity;

b) if the service authorization request was from an MCData user who is previously MCData service authorized on another MCData client (as determined by a comparison of the received MCData client ID with the MCData client ID of existing bindings), keep the current bindings and create a new binding between the MCData ID, MCData client ID and the IMS public user identity; and

c) if a Resource-Share header field with the value "supported" was included in the "message/sip" MIME body of the third-party REGISTER request, shall bind the MCData ID and MCData client ID to the identity of the MCData UE identified by the "+g.3gpp.registration-token" header field parameter in the Contact header field of the third-party REGISTER request that contained this IMS public user identity;

NOTE 1: The MCData server will store the binding MCData ID, MCData client ID, IMS public user identity and an identifier addressing the MCData server in an external database.

6) if service authorization was not successful, shall send a SIP 403 (Forbidden) response towards the MCData client with the warning text set to: "101 service authorisation failed" in a Warning header field as specified in clause 4.9, and not continue with the rest of the steps in this clause;

7) shall process the SIP PUBLISH request according to rules and procedures of IETF RFC 3903 [34] and if processing of the SIP request was not successful, do not continue with the rest of the steps;

8) shall cache the received MCData service settings until the MCData service settings expiration timer expires;

9) shall send a SIP 200 (OK) response according 3GPP TS 24.229 [5] with:

a) if more than one binding exists for the MCData ID, an application/vnd.3gpp.mcdata-info+xml MIME body as specified in annex D.1 with a <multiple-devices-ind> element set to the value "true";

10) shall download the MCData user profile from the MCData user database as defined in 3GPP TS 29.283 [37] if not already stored at the MCData server and use the <selected-user-profile-index> element of the poc-settings event package if included to identify the active MCData user profile for the MCData client;

NOTE 2: If the <selected-user-profile-index> element of the poc-settings event package is included then only that MCData user profile is needed to be downloaded from the MCData user database.

11) if there is no <selected-user-profile-index> element included in the poc-settings event package then if multiple MCData user profiles are stored at the MCData server or downloaded for the MCData user from the MCData user database, shall determine the pre-selected MCData user profile to be used as the active MCData user profile by identifying the MCData user profile (see the MCData user profile document in 3GPP TS 24.484 [12]) in the collection of MCData user profiles that contains a <Pre-selected-indication> element; and

NOTE 3: If only one MCData user profile is stored at the MCData server or only one MCData user profile is downloaded from the MCData user database, then by default this MCData user profile is the pre-selected MCData user profile.

12) if an <ImplicitAffiliations> element is contained in the <OnNetwork> element of the MCData user profile document with one or more <entry> elements containing an MCData group ID (see the MCData user profile document in 3GPP TS 24.484 [12]) for the served MCData ID, shall perform implicit affiliation as specified in clause 8.3.2.15.

7.3.4 Receiving SIP PUBLISH request for MCData service settings only

Upon receiving a SIP PUBLISH request containing:

1) an Event header field set to the "poc-settings" value;

2) an application/poc-settings+xml MIME body; and

3) an application/vnd.3gpp.mcdata-info+xml MIME body containing an <mcdata-request-uri> element and an <mcdata-client-id> element;

The MCData server:

1) shall identify the IMS public user identity from the P-Asserted-Identity header field;

2) shall perform the procedures in clause 7.3.1A;

3) if the procedures in clause 7.3.1A were not successful, shall send a SIP 403 (Forbidden) response towards the MCData client with the warning text set to: "140 unable to decrypt XML content" in a Warning header field as specified in clause 4.9, and not continue with the rest of the steps in this clause;

4) shall verify that a binding between the IMS public user identity in the Request-URI and the MCData ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml exists at the MCData server;

5) if a binding exists between the IMS public user identity and the MCData ID in the request and the validity period of the binding has not expired shall download the MCData user profile from the MCData user database as defined in 3GPP TS 29.283 [37] if not already stored at the MCData server;

6) if a binding does not exist between the IMS public user identity and the MCData ID in the request or the binding exists, but the validity period of the binding has expired, shall reject the SIP PUBLISH request with a SIP 404 (Not Found) response and not continue with any of the remaining steps;

7) shall process the SIP PUBLISH request according to rules and procedures of IETF RFC 3903 [34] and if processing of the SIP request was not successful, do not continue with the rest of the steps;

8) shall cache the received MCData service settings until the MCData service settings expiration timer expires;

9) shall send a SIP 200 (OK) response according 3GPP TS 24.229 [5];

NOTE 1: If the <selected-user-profile-index> element of the poc-settings event package is included then only that MCData user profile is needed to be downloaded from the MCData user database.

NOTE 2: If only one MCData user profile is stored at the MCData server or only one MCData user profile is downloaded from the MCData user database, then by default this MCData user profile is the pre-selected MCData user profile.

7.3.5 Receiving SIP PUBLISH request with "Expires=0"

Upon receiving a SIP PUBLISH request containing:

1) an Event header field set to the "poc-settings" value; and

2) an Expires header field set to 0;

the MCData server:

1) shall identify the IMS public user identity from the P-Asserted-Identity header field;

2) shall process the SIP PUBLISH request according to rules and procedures of IETF RFC 3903 [34] and if processing of the SIP request was successful, continue with the rest of the steps;

3) shall remove the MCData service settings;

NOTE: Removal of MCData service settings includes removal of all group affiliations.

4) shall remove the binding between the MCData ID and public user identity; and

5) shall send a SIP 200 (OK) response according to 3GPP TS 24.229 [5].

7.3.6 Subscription to and notification of MCData service settings

7.3.6.1 Receiving subscription to MCData service settings

Upon receiving a SIP SUBSCRIBE request such that:

1) Request-URI of the SIP SUBSCRIBE request contains the public service identity identifying the participating MCData function of the served MCData user;

2) the SIP SUBSCRIBE request contains an application/vnd.3gpp.mcdata-info+xml MIME body containing the<mcdata-request-uri> element which identifies an MCData ID served by the MCData server;

3) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata,sds" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7]; and

3) the Event header field of the SIP SUBSCRIBE request contains the ‘poc-settings’ event type.

the MCData server:

1) shall identify the served MCData ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP SUBSCRIBE request;

2) if the Request-URI of the SIP SUBSCRIBE request contains the public service identity identifying the participating MCData function serving the MCData user, shall identify the originating MCData ID from public user identity in the P-Asserted-Identity header field of the SIP SUBSCRIBE request;

3) if the originating MCData ID is different than the served MCData ID, shall send a 403 (Forbidden) response and shall not continue with the rest of the steps; and

4) shall generate a 200 (OK) response to the SIP SUBSCRIBE request according to 3GPP TS 24.229 [5], IETF RFC 6665 [36] and IETF RFC 4354 [35].

For the duration of the subscription, the MCData server shall notify subscriber about changes of the MCData service settings of the subscribed MCData user, as described in clause 7.3.6.2.

7.3.6.2 Sending notification of change of MCData service settings

In order to notify the subscriber about changes of the MCData service settings of the subscribed MCData client of the subscribed MCData user, the MCData server:

1) shall generate an application/poc-settings+xml MIME body as defined in 3GPP TS 24.379 [10] containing:

a) the <selected-user-profile-index> element identifying the active MCData user profile; and

2) send a SIP NOTIFY request according to 3GPP TS 24.229 [5], IETF RFC 6665 [36] and IETF RFC 4354 [35] with the constructed application/poc-settings+xml MIME body.

7.3.7 Sending a CSK key download message

If confidentiality protection is enabled as specified in clause 6.5.2.3.1, and if the participating MCData function received a Client Server Key (CSK) within a SIP REGISTER request for service authorisation or SIP PUBLISH request for service authorisation, the participating MCData function may decide to update the CSK. In this case, the participating MCData function shall perform a key download procedure for the CSK. The participating MCData function:

1) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6];

2) shall set the Request-URI to the URI received in the To header field in the third-party SIP REGISTER request;

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

4) shall include a P-Asserted-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.mcdata";

5) shall include an application/mikey MIME body containing the algorithm to be used to protect the MCData signalling fields, the CSK-ID and the CSK encrypted within a MIKEY message to the MC client as specified in clause 9.2.1 of 3GPP TS 33.180 [26] in the body of the SIP MESSAGE request; and

6) shall send the SIP MESSAGE request towards the MCData client according to 3GPP TS 24.229 [5].