5 MCPTT Client Configuration

36.579-23GPPMission Critical (MC) services over LTEPart 2: Mission Critical Push To Talk (MCPTT) User Equipment (UE) Protocol conformance specificationRelease 15TS

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

5.1 Configuration / Authentication / User Authorisation / UE Configuration / User Profile / Key Generation

5.1.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) attached to EPS services }

ensure that {

when { the MCPTT User activates an MCPTT application and requests MCPTT initialisation }

then { UE (MCPTT Client) performs MCPTT User Authentication }

}

(2)

with { UE (MCPTT Client) user authenticated }

ensure that {

when { the UE (MCPTT Client) has established a secure HTTP tunnel }

then { UE (MCPTT Client) performs key management authorization and obtains identity management key material }

}

(3)

with { UE (MCPTT Client) has obtained identity management key material }

ensure that {

when { the UE (MCPTT Client) requests user service authorization }

then { UE (MCPTT Client) sends a user authorization request to the MCPTT Server }

}

(4)

with { UE (MCPTT Client) authorized for user services }

ensure that {

when { the UE (MCPTT Client) requests configuration management authorization}

then { UE (MCPTT Client) requests subscription to multiple documents simultaneously and request the retrieval of the MCPTT UE Configuration document, the MCPTT User Profile Configuration Document and the MCPTT Service Configuration Document }

}

(5)

with { UE (MCPTT Client) having obtained user configuration data }

ensure that {

when { the UE (MCPTT Client) requests group management authorization }

then { UE (MCPTT Client) receives the group profile including group traffic keys }

}

(6)

with { UE (MCPTT Client) having obtained all required configuration data }

ensure that {

when { the UE (MCPTT Client) requires to refresh its service settings }

then { UE (MCPTT Client) sends a SIP PUBLISH request }

}

5.1.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TR 24.980 clauses 4.2.1 and 4.3.1, TS 24.482 clause 6.2.1 and Annex A.2.1.2, TS 24.484 clauses 4.2.1, 4.2.2, 6.2.2, 6.3.1.1, 6.3.2.1, 6.3.2.2, 6.3.13.2.1 and 6.3.13.2.2, TS 24.481 clauses 6.2.2.2, 6.2.3, 6.3.3.2.1, 6.3.3.2.2 and 6.3.13.2.1, TS 24.379 clauses 7.2.1, 7.2.1A, 7.2.2 and 7.2.3, TS 33.179 clauses 5.6.1, 6.2, 7.2.3 and Annex D. Unless otherwise stated these are Rel-13 requirements.

[TR 24.980, clause 4.2.1]

The MCPTT UE follows the SIP registration procedures defined in 3GPP TS 24.229 [4]. In addition, when the conditions for performing IMS registration in bullets 2, 3, 4, 5 and 6 in subclause L.3.1.2 of 3GPP TS 24.229 [4] evaluate to true, the MCPTT UE registers with the IMS.

[TR 24.980, clause 4.3.1]

The MCPTT UE follows the procedures defined in 3GPP TS 24.229 [4] and 3GPP TS 33.203 [7] for authentication with IMS Authentication and Key Agreement (IMS-AKA), Sec-Agree and IPSec. The MCPTT UE supports integrity protection.

[TS 24.482, clause 6.2.1]

Upon an indication from the MCPTT client to initiate MCPTT user authentication, the IdM client shall perform the user authentication procedure according to 3GPP TS 33.179 [2] with the following clarifications:

1) shall establish a TLS tunnel to the authorisation endpoint of the IdM server as specified in 3GPP TS 33.179 [2] using the configured URL of the authorisation endpoint of the IdM server as specified in the "/<x>/OnNetwork/AppServerInfo/IDMSAuthEndpoint" leaf node defined in 3GPP TS 24.383 [11] and the clarifications in annex A;

2) shall generate an OIDC Authentication Request message as specified in the OpenID Connect 1.0 [6] and IETF RFC 6749 [5] with the following clarifications:

a) shall generate an HTTP GET request method according to IETF RFC 2616 [4];

b) shall include the configured parameter IdM client id as the client_id parameter specified in 3GPP TS 33.179 [2] in the query component of the authorization endpoint’s URI using the "application/x-www-form-urlencoded" format as specified in W3C.REC-html401-19991224 [7]; and

NOTE 1: The configuration of client_id is specified in 3GPP TS 24.383 [11].

c) shall include the remaining required parameters as specified in 3GPP TS 33.179 [2] in the query component of the authorization endpoint’s URI using the "application/x-www-form-urlencoded" format as specified in W3C.REC-html401-19991224 [7]; and

3) shall send the HTTP GET request method towards the IdM server.

NOTE 2: The OpenID Connect 1.0 [6] specification allows for an alternative mechanism for sending the OIDC Authentication request message using an HTTP POST request method which can be used in place of steps 1, 2, and 3 above.

Upon receipt of an HTTP 200 (OK) response from the IdM server, the IdM client:

1) shall prompt the MCPTT user for their username and password;

NOTE 3: Other types of authentication are supported and are not defined by the OIDC specifications. 3GPP TS 33.179 [2] has defined username and password as a mandatory authentication method to be supported; hence a procedure to realize that method is included here.

2) shall generate an HTTP POST request method containing the MCPTT user’s username and password; and

3) shall send the HTTP POST request method towards the IdM server.

Upon receipt of an OIDC Authentication Response message, the IdM client:

1) shall establish a TLS tunnel to the token endpoint of the IdM server as specified in 3GPP TS 33.179 [2] using the configured URL of the token endpoint of the IdM server as specified in the "/<x>/OnNetwork/AppServerInfo/IDMSTokenEndpoint" leaf node defined in 3GPP TS 24.383 [11] and the clarifications in annex A;

2) shall generate an OIDC Token Request message as specified in OpenID Connect 1.0 [6] and IETF RFC 6749 [5] with the following clarifications:

a) shall generate an HTTP POST request method according to IETF RFC 2616 [4]; and

b) shall include the grant_type parameter set to a value of "authorization_code" and the other required parameters in the entity body of the HTTP POST request method using the using the "application/x-www-form-urlencoded" format as specified in 3GPP TS 33.179 [2]; and

3) shall send the HTTP POST request method towards the IdM server.

Upon receipt of an OIDC Token Response message, the IdM client:

1) shall validate the id_token, access_token and refresh token in the received OIDC Token Response message as specified in the OpenID Connect 1.0 [6] specification; and

2) shall provide the id_token and access_token in the received OIDC Token Response message to the MCPTT client.

NOTE 4: The method in which the IdM client provides the id_token and access_token to the MCPTT client is implementation specific.

[TS 24.482, Annex A.2.1.2]

The HTTP client in the UE shall establish a TCP connection towards the home HTTP proxy FQDN and the home HTTP proxy port, unless the specific TCP connection is to be used for the IdM client to IdM server procedures described in subclause 6.2 and subclause 6.3 in the present document, in which case the HTTP client shall establish a TCP connection towards the IdM server.

The HTTP client in the UE shall establish a TLS tunnel via the TCP connection as specified in 3GPP TS 33.179 [2]. When establishing the TLS tunnel, the HTTP client in the UE shall act as a TLS client and the UE shall perform the TLS tunnel authentication using the TLS authentication method indicated by the TLS tunnel authentication method parameter according to 3GPP TS 33.179 [2]. The UE shall use the configured TLS tunnel authentication X.509 certificate and the configured TLS tunnel authentication pre-shared key when applicable for the used TLS authentication method. In order to prevent man-in-the-middle attacks, the HTTP client in the UE shall check the home HTTP proxy FQDN against the server’s identity as presented in the received server’s certificate message if the TCP connection terminates on the HTTP proxy. The HTTP client in the UE shall not check the portion of dereferenced HTTP URL against the server’s identity as presented in the received server’s certificate message if the TCP connection terminates on the HTTP proxy, but shall do so if the TCP connection terminates on the IdM server.

NOTE: The TLS tunnel can be terminated in the HTTP proxy (rather than in the HTTP server providing the dereferenced HTTP URL).

The HTTP client in the UE shall send and receive all HTTP messages via the TLS tunnel.

If the HTTP client in the UE has an access token of the "bearer" token type as specified in IETF RFC 6750 [14], the HTTP client in the UE shall include an Authorization header field with the "Bearer" authentication scheme as specified in IETF RFC 6750 [14] in HTTP requests.

[TS 33.179 Annex D]

All KMS communications are made via HTTPS. The MCPTT key management client is provisioned via XML content in the KMS’s response. The XML content is designed to be extendable to allow KMS/client providers to add further information in the XML. Where the interface is extended, a different XML namespace should be used (so that may be ignored by non-compatible clients).

It is assumed that transmissions between the KMS and the key management client are secure and that the KMS has authenticated the identity of the key management client.

Additionally, to allow the transmission of key material securely between a secure element within the KMS and a secure element within the key management client, a security extension is defined which allows messages to be signed and key material to be encrypted using a shared Transport Key (TrK).

[TS 33.179 clause 5.6.1]

For key management authorization, the KM client in the UE presents an access token to the KMS over HTTP. The KMS validates the access token and if successful, provides user specific key material back to the UE KM client based on the MCPTT ID of the user. This includes identity based key information used for media and signalling protection.

For user service authorization, the MCPTT client in the UE presents an access token to the MCPTT server over SIP. The MCPTT server validates the access token and if successful, authorizes the user for full MCPTT services and sends an acknowledgement back to the MCPTT client. The MCPTT server then maps and maintains the IMPU to MCPTT ID association. The MCPTT ID to IMPU association shall only be known to the application layer. The SIP message used to convey the access token from the MCPTT client to the MCPTT server may be either a SIP REGISTER or SIP PUBLISH message.

The UE can now perform configuration management authorization and download the user profile. Following the flow described in subclause 10.1.4.2 of 3GPP TS 23.179 [2] "MCPTT user obtains the user profile (UE initiated)", the Configuration Management (CM) client in the UE sends an access token in the user profile query to the Configuration Management server over HTTP. The CM server receives the request and validates the access token, and if valid, the CM server uses the MCPTT ID to obtain the user profile from the MCPTT user database. The CM server then sends the user profile back to the CM client over HTTP.

Upon receiving the user’s profile, the Group Management (GM) client in the UE can now perform group management authorization. The GM client obtains the user’s group membership information from the user’s profile, and following the flow shown in clause 10.1.5.2 of 3GPP TS 23.179 [2] "Retrieve group configurations at the group management client", the Group Management (GM) client in the UE sends an access token in the Get group configuration request to the host GM server of the group membership over HTTP. The GM server validates the access token, and if valid, completes the flow. As part of group management authorization, group key information is provided as per subclause 7.3.2 of the present document.

[TS 33.179 clause 7.2.3]

Case that HTTP proxy is used between the KMC and KMS

0) The key management client establishes a connection to the MCPTT KMS. As with other elements in the Common Services Core, the connection routed via, and secured by, the HTTP Proxy. The message flow below is within this secure connection.

NOTE: Additionally, the connection between the MCPTT KMS and the HTTP Proxy is secured according to clause 8.

1) The key management client makes a request for user key material from the MCPTT KMS. The request contains details of the identity (e.g. the MCPTT ID) requested for key management, and the time for which the key material is required.

2) The KMS provides a response containing key material. The response includes the type of key material, the period of use for the material and any domain-specific parameters required for its use. For public safety use, the key material itself shall be wrapped using a 256-bit transport key (TrK). The TrK is distributed via an out-of-band mechanism along with a 32-bit identifier, TrK-ID.

Case that HTTP proxy is not used between the KMC and KMS

0) The key management client establishes a direct HTTPS connection to the MCPTT KMS. The following message flow is within this secure connection.

1) The key management client makes a request for user key material from the MCPTT KMS. The request contains details of the identity requested for key management, and the time at which the key material is required.

2) The KMS provides a response containing key material. The response includes the type of key material, the period of use for the material and any domain-specific parameters required for its use. Optionally, the key material itself may also be wrapped using a 256-bit transport key (TrK), distributed via an out-of-band mechanism along with a 32-bit identifier (TrK-ID).

[TS 24.484, clause 4.2.1]

Upon start up the MCPTT UE bootstraps the required information (e.g. FQDN or IP address) to locate the configuration management server for configuration of the MCPTT UE initial configuration management object (MO) and the default MCPTT user profile configuration management object (MO).

In order to obtain access to the MCPTT service the MCPTT UE needs to obtain configuration data either online via the network or offline using some external device (e.g. a laptop). As part of the bootstrap process the MCPTT UE needs to discover either:

1. the online configuration management server in the network that configures the MPCTT UE initial configuration MO and the default MCPTT user profile configuration MO, then the MCPTT UE:

a) using the URI of the configuration management server obtained from the MPCTT UE initial configuration MO, obtains:

– the MCPTT UE configuration document;

– the MCPTT user profile configuration document; and

– the MCPTT service configuration document; and

b) using the URI of the group management server obtained from the MPCTT UE initial configuration MO obtain the MCPTT group document; or

[TS 24.484, clause 4.2.2]

The MCPTT UE contacts the identity management server using the HTTPS URI stored in the MCPTT UE initial configuration MO and performs MCPTT User authentication as specified in 3GPP TS 24.382 [6].

The MCPTT UE, using the MCPTT ID obtained during MCPTT user authentication, subscribes to the MCPTT UE configuration document, the MCPTT user profile configuration document and the MCPTT service configuration document using the procedure for subscribing to multiple documents simultaneously using the subscription proxy function specified in subclause 6.3.13.2.2 (i.e., the CMS acts as a Subscription Proxy) and subscribes to the MCPTT group document using the procedure specified in 3GPP TS 24.381 [5]. If these documents have been updated since the current version stored in the MCPTT UE, then the MCPTT UE will receive a SIP NOTIFY request with an XCAP Diff document (see IETF RFC 5875 [11]), in which case the CMC updates its local document copies. Retrieval by the MCPTT UE using the notified HTTPS URI of the MCPTT group document is performed as specified in 3GPP TS 24.381 [5].

[TS 24.484, clause 6.2.2]

The CMC shall send the HTTP request over TLS connection as specified for the HTTP client in the UE in annex A of 3GPP TS 24.382 [6].

[TS 24.484, clause 6.3.1.1]

A CMC shall support subclause 6.1.1 "Document Management" of OMA OMA-TS-XDM_Core-V2_1 [2] and subclause 6.3.13.2.2 for subscribing to configuration management documents.

[TS 24.484, clause 6.3.3.2.1]

In order to retrieve a configuration management document, a GC shall send an HTTP GET request with the Request URI that references the document to be updated to the network according to procedures specified in IETF RFC 4825 [14] "Retrieve a Document".

[TS 24.484, clause 6.3.3.2.2]

In order to retrieve a configuration management document, a CMC shall perform the procedures in subclause 6.3.3.2.1 specified for GC. The CMC shall set the Request-URI of the HTTP GET request to the "CMSXCAPRootURI" configured as per 3GPP TS 24.383 [4] and include the "auid" as per the appropriate application usage in clause 7.

Subclause 7.5 specifies which configuration management documents can be retrieved from the CMS over the CSC-4 reference point.

[TS 24.484, clause 6.3.13.2.1]

This procedure enables the CMC to subscribe to notification of changes of one or more configuration management documents defined in clause 7.

This procedure enables the MCPTT server to subscribe to notification of changes of the MCPTT service configuration document.

[TS 24.484, clause 6.3.13.2.2]

In order to subscribe to Configuration management document, a CMC shall send an initial SIP SUBSCRIBE request to the network according to the UE originating procedures specified in 3GPP TS 24.229 [22] and IETF RFC 5875 [11]. In the initial SIP SUBSCRIBE request, the CMC:

a) …

b) if subscription to multiple documents simultaneously using the subscription proxy function is used:

1) shall include an application/resource-lists+xml MIME body. In the application/resource-lists+xml MIME body, the CMC shall include one <entry> element for each document or element to be subscribed to, such that the "uri" attribute of the <entry> element contains a relative path reference:

A) with the base URI being equal to the "CMSXCAPRootURI" configured in the CMC as per 3GPP TS 24.383 [4]; and

B) with the "auid" parameter set to the appropriate application usage identifying a configuration management document as described in clause 7;

2) shall set the Request-URI to the configured public service identity for performing subscription proxy function of the CMS;

c) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcptt-access-token> element set to the value of the access token received during authentication procedure as described in 3GPP TS 24.382 [6];

d) if identity hiding is required:

1) shall perform the confidentiality protection procedures and integrity protection procedures defined in 3GPP TS 24.379 [9] for MCPTT client on the application/vnd.3gpp.mcptt-info+xml MIME body and on the application/resource-lists+xml MIME body; and

2) shall include an application/mikey MIME body with the CSK as specified in 3GPP TS 24.379 [9];

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

f) shall include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" in the Contact header field.

Upon receiving a SIP NOTIFY request associated with a subscription created as result of the sent initial SIP SUBSCRIBE request:

1) if identity hiding is required, the CMC shall perform the confidentiality protection procedures and integrity protection procedures defined in 3GPP TS 24.379 [9] for MCPTT client; and

2) shall handle the SIP NOTIFY request according to IETF RFC 5875 [11].

[TS 24.481, clauses 6.2.2.2]

In order to address an existing group document defining a group ID known by GC, the GC shall set the Request-URI of an HTTP request to a XCAP URI identifying a group document addressed by a group ID as described in subclause 7.2.10.2, where the group ID is set to the group ID known by GC and where the XCAP root URI is the XCAP root URI configured in the UE.

[TS 24.481, clauses 6.2.3]

The GMC shall send the HTTP request over a TLS connection as specified for the HTTP client in the UE in annex A of 3GPP TS 24.382 [10].

The GMC shall perform the procedures in subclause 6.2.2 specified for GC.

[TS 24.481, clauses 6.3.3.2.1]

In order to retrieve a group document, a GC shall send an HTTP GET request with the Request URI that references the document to be retrieved to the network according to procedures specified in IETF RFC 4825 [22] "Fetch a Document".

[TS 24.481, clauses 6.3.3.2.2]

In order to retrieve a group document, a GMC shall perform the procedures in subclause 6.3.3.2.1 specified for GC.

[TS 24.481, clauses 6.3.13.2.1]

In order to subscribe to notification of changes of:

a) one or more MCPTT group documents of MCPTT groups identified by MCPTT group IDs;

…

a GMC shall send an initial SIP SUBSCRIBE request to the network according to the UE originating procedures specified in 3GPP TS 24.229 [12] and IETF RFC 5875 [13]. In the initial SIP SUBSCRIBE request, the GMC:

a) shall include an application/resource-lists+xml MIME body. In the application/resource-lists+xml MIME body, the GMC shall include one <entry> element for each document or element to be subscribed to, such that the "uri" attribute of the <entry> element:

1) contains a relative path reference:

A) with the base URI being equal to the XCAP root URI configured in the GMC; and

B) identifying a group document addressed by a group ID as described in subclause 7.2.10.2 where the group ID is set to the MCPTT group ID; or

…

b) shall set the Request-URI to the configured public service identity for performing subscription proxy function of the GMS;

d) if identity hiding is required:

1) shall perform the confidentiality protection procedures and integrity protection procedures defined in 3GPP TS 24.379 [5] for MCPTT client on the application/vnd.3gpp.mcptt-info+xml MIME body and on the application/resource-lists+xml MIME body; and

2) shall include an application/mikey MIME body with the CSK as specified in 3GPP TS 24.379 [5];

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

f) shall include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" in the Contact header field.

Upon receiving a SIP NOTIFY request associated with a subscription created as result of the sent initial SIP SUBSCRIBE request:

1) if identity hiding is required, the GMC shall perform the confidentiality protection procedures and integrity protection procedures defined in 3GPP TS 24.379 [5] for MCPTT client; and

2) shall handle the SIP NOTIFY request according to IETF RFC 5875 [13].

[TS 24.379, clause 7.2.1]

When the MCPTT client performs SIP registration the MCPTT client shall perform the registration procedures as specified in 3GPP TS 24.229 [4].

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

1) the g.3gpp.mcptt media feature tag; and

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

…

If the MCPTT client, upon performing SIP registration:

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

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 subclause 6.6.2.3.1 or integrity protection is enabled as specified in subclause 6.6.3.3.1;

then the MCPTT client:

…

2) if confidentiality protection is enabled as specified in subclause 6.6.2.3.1, shall encrypt the received access-token using the client server key (CSK) and shall include in the body of the SIP REGISTER request, an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcptt-access-token> element set to the encrypted access-token, as specified in subclause 6.6.2.3.3;

…

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

[TS 24.379, clause 7.2.1A]

This procedure is only referenced from other procedures.

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

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

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

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 [37], to 4294967295, if the MCPTT user is not removing the MCPTT service settings, otherwise to remove the MCPTT service settings the MCPTT client shall set the Expires header field to zero.

[TS 24.379, clause 7.2.2]

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

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

2) has available an access-token;

then the MCPTT client:

1) shall perform the procedures in subclause 7.2.1A;

…

3) if either confidentiality protection is enabled as specified in subclause 6.6.2.3.1 or integrity protection is enabled as specified in subclause 6.6.3.3.1 shall include an application/mikey MIME body with the CSK as MIKEY-SAKKE I_MESSAGE as specified in 3GPP TS 33.179 [46] in the body of the SIP PUBLISH request;

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

a) the <mcptt-access-token> element set to the received access-token encrypted using the client server key (CSK), as specified in subclause 6.6.2.3.3; and

b) the <mcptt-client-id> element set to the encrypted MCPTT client ID of the originating MCPTT client, as specified in subclause 6.6.2.3.3;

…

6) shall include an application/poc-settings+xml MIME body containing the Answer-Mode Indication setting in the <am-settings> element of the poc-settings event package set to the current answer mode setting ("auto-answer" or "manual-answer") of the MCPTT client according to IETF RFC 4354 [55]; and

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

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

[TS 24.379, clause 7.2.3]

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

1) shall perform the procedures in subclause 7.2.1A;

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

a) the <mcptt-request-uri> element set to the targeted MCPTT ID encrypted using the client server key (CSK), as specified in subclause 6.6.2.3.3; and

b) the <mcptt-client-id> element set to the encrypted MCPTT client ID of the originating MCPTT client, as specified in subclause 6.6.2.3.3;

…

4) shall include an application/poc-settings+xml MIME body containing the Answer-Mode Indication setting in the <am-settings> element of the poc-settings event package set to the current answer mode setting ("auto-answer" or "manual-answer") of the MCPTT client according to IETF RFC 4354 [55]; and

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

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

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

[TS 33.179, clause 6.2]

The support of Transport Layer Security (TLS) on HTTP-1 is mandatory. The profile for TLS implementation and usage shall follow the provisions given in 3GPP TS 33.310 [5], annex E.

If the PSK TLS based authentication mechanism is supported, the HTTP client in the MCPTT UE and the HTTP Proxy shall support the TLS version, PSK ciphersuites and TLS Extensions as specified in the TLS profile given in 3GPP TS 33.310 [5], annex E. The usage of pre-shared key ciphersuites for TLS is specified in the TLS profile given in 3GPP TS 33.310 [5], annex E.

5.1.3 Test description

5.1.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT server).

– For the underlying "transport bearer" over which the SS and the UE will communicate Parameters are set to the default parameters for the basic E-UTRA Single cell network scenarios, as defined in TS 36.508 [24] clause 4.4. The simulated Cell 1 shall belong to PLMN1 (the PLMN specified for MCPTT operation in the MCPTT configuration document).

IUT:

– UE (MCPTT client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10, is inserted.

– The MCPTT Client has been provisioned with the Initial UE Configuration Data as specified in TS 36.579-1 [2], clause 5.5.8.1 allowing for the location of the configuration management server for configuration of the MCPTT UE initial configuration management object (MO) and the default MCPTT user profile configuration management object (MO).

– A single APN (px_MCX_APN, TS 36.579-5 [5]) shall be provided in the Initial UE Configuration Data which the UE shall use to access each and all MCPTT relevant services including the MCPTT SIP-1 reference point, the MC common core services for the HTTP-1 reference point and the MC identity management service for the CSC-1 reference point.

– According to TS 33.180 [94] all HTTP connections are secured by TLS.
The HTTP-1 interface authentication between the HTTP client in the MC UE and the HTTP server endpoint (HTTP proxy, IdM server or KMS) shall be performed by one-way authentication of the HTTP server endpoint based on server certificate as described in TS 33.180 [33] clause 6.1.1.

– The UE User is provided with username/password for user authentication (px_MCX_User_A_username, px_MCX_User_A_password as provided in TS 36.579-5 [5], Table 9.2-1: MCX Client Common PIXIT).

– The UE is provisioned with the names and values of the Transport Key (TrK) and the Integrity Key (InK), since the KMS shall encrypt the key material sent to the client with the TrK and sign the response with the TrK or the InK according to TS 33.180 [94].

Preamble:

– The UE is Switched OFF (state 1) according to TS 36.508 [24].

5.1.3.2 Test procedure sequence

Table 5.1.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The UE is switched-on.	–	–	–	–
–	EXCEPTION: The E-UTRA/EPC related actions which step 1 above will trigger are described in TS 36.579-1 [2], subclause 5.4.2 ‘Generic Test Procedure for MCPTT UE registration” starting with Step 2. The test sequence below shows only the MCPTT relevant messages being exchanged.	–	–	–	–
2	Make the UE user request MCPTT service authorisation/configuration. NOTE: This is expected to be done via a suitable implementation dependent mechanism and may be manually or automatically initiated.	–	–	–	–
3 – 12	Check: Does the UE (MCPTT client) perform the generic procedure for MCPTT user authentication specified in TS 36.579-1 [2] Table 5.3.2.3-1 steps 1 through 10?	–	–	1	P
13 – 16	Check: Does the UE (MCPTT client) perform the generic procedure for MCPTT key management authorization and obtain identity management key material as specified in TS 36.579-1 [2] Table 5.3.2.3-1, steps 11 through 14?	–	–	2	P
–	EXCEPTION: In parallel to the events described in all steps below, the steps in Table 5.1.3.2-2 and Table 5.1.3.2-3 should take place.	–	–	–	–
–	EXCEPTION: Steps 17a1-17b2 describe behaviour that depends on UE implementation; the "lower case letter" identifies a step sequence that take place when one or the other is the case.	–	–	–	–
17a1	Check: Does the UE (MCPTT client) send a SIP REGISTER request for service authorisation?	–>	SIP REGISTER	3	P
17a2	The SS (MCPTT server) sends SIP 200 (OK). NOTE: The user is now authorized for MCPTT service.	<–	SIP 200 (OK)	–	–
17a3	Check: Does the UE (MCPTT client) send a SIP PUBLISH request for update of PoC-settings? NOTE: See NOTE 1 of TS 36.579-1 [2] Table 5.3.2.3-2.	–>	SIP PUBLISH	6	P
17a4	The SS (MCPTT server) sends SIP 200 (OK).	<–	SIP 200 (OK)	–	–
17b1	Check: Does the UE (MCPTT client) send a SIP PUBLISH request for service authorisation and update of PoC-settings? NOTE: See NOTE 1 of TS 36.579-1 [2] Table 5.3.2.3-2.	–>	SIP PUBLISH	3, 6	P
17b2	The SS (MCPTT server) sends SIP 200 (OK).	<–	SIP 200 (OK)	–	–
–	EXCEPTION: SS releases the E-UTRA connection.	–	–	–	–

Table 5.1.3.2-2: Parallel Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Check: Does the UE (MCPTT client) perform the configuration management subscription and notification procedure as described in TS 36.579-1 [2] Table 5.3.2.3-2A?	–	–	4	P

Table 5.1.3.2-3: Parallel Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Check: Does the UE (MCPTT client) perform the group document subscription and notification procedure as described in TS 36.579-1 [2] Table 5.3.2.3-2B?	–	–	5	P

5.1.3.3 Specific message contents

Table 5.1.3.3-1: SIP REGISTER (Step 17a1, Table 5.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.3.2.4-12

Table 5.1.3.3-2: SIP PUBLISH (Step 17a3, Table 5.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.3.2.4-13A

Table 5.1.3.3-3: SIP PUBLISH (Step 17b1, Table 5.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.3.2.4-13

Table 5.1.3.3-4: SIP 200 (OK) (Step 17a2, 17a4, 17b2, Table 5.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.3.2.4-26

5.2 Configuration / Group Creation / Group Regroup Creation / Group Regroup Teardown

5.2.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) attached to EPS services }

ensure that {

when { the MCPTT user requests formation of a new MCPTT group }

then { the UE (MCPTT client) initiates creation of the group by sending a HTTP PUT request }

}

(2)

with { UE (MCPTT Client) having access to at least two MCPTT groups }

ensure that {

when { the MCPTT user requests the groups to be combined }

then { the UE (MCPTT client) initiates creation of the temporary group by sending a HTTP POST request }

}

(3)

with { UE (MCPTT Client) having access to a temporary group }

ensure that {

when { the MCPTT user requests temporary group tear down }

then { the UE (MCPTT client) initiates tear down of the temporary group by sending a HTTP DELETE request }

}

5.2.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.481 clauses 6.3.2.2.1, 6.3.2.2.2, 6.3.14.1, 6.3.14.2, 6.3.15.1 and 6.3.15.2; TS 33.180 clauses 7.3.2. Unless otherwise stated these are Rel-13 requirements.

[TS 24.481 clause 6.3.2.2.1]

In order to create a group document, a GC shall create an XML document of the application usage specified in subclause 7.2.1 and shall send the XML document to the network according to procedures specified in IETF RFC 4825 [22] "Create or Replace a Document". The GC shall set the Request-URI of the HTTP PUT request to an XCAP URI in users’ tree where the XUI is set to a group creation XUI configuration parameter.

[TS 24.481 clause 6.3.2.2.2]

In order to create a group document, a GMC shall perform the procedures in subclause 6.3.2.2.1 specified for GC.

[TS 24.481 clause 6.3.14.1]

This procedure enables a GMC to initiate creation of a temporary MCPTT group by combining MCPTT groups.

[TS 24.481 clause 6.3.14.2]

In order to form a temporary MCPTT group, a GMC shall send a HTTP POST request according to procedures specified in IETF RFC 2616 [21] and subclause 6.2.3. In the HTTP POST request, the GMC:

a) shall set the Request-URI to an XCAP URI:

1) in users tree where the XUI is set to a group creation XUI configuration parameter; and

2) with the document selector identifying the temporary MCPTT group to be created; and

b) shall include an application/vnd.3gpp.GMOP+xml MIME body containing a GMOP document requesting group regroup creation specified in subclause 7.3.4.3, with a <group> element containing a group document for an MCPTT group. In the group document, the GMC shall include the <on-network-temporary> element according to subclause 7.2. In the <on-network-temporary> element, the GMC shall include <constituent-MCPTT-group-IDs> element according to subclause 7.2. In the <constituent-MCPTT-group-IDs> element, the GMC shall include one <constituent-MCPTT-group-ID> element according to subclause 7.2 for each MCPTT group to be combined.

Upon reception of an HTTP 2xx response to the sent HTTP POST request, the GMC shall consider the temporary MCPTT group formation as successful.

Upon reception of an HTTP 409 (Conflict) response with at least one <alt-value> element in the <uniqueness-failure> error element, the GMC may repeat procedures of the present subclause and identify the temporary MCPTT group being formed with an MCPTT Group ID indicated in an <alt-value> element.

[TS 24.481 clause 6.3.15.1] This procedure enables a GMC to initiate tear down of a temporary MCPTT group.

[TS 24.481 clause 6.3.15.2]

In order to tear down a temporary MCPTT group, the GMC shall send an HTTP DELETE request with Request-URI with an XCAP URI identifying a group document of the temporary MCPTT group according to procedures specified in IETF RFC 4825 [22] "Delete an Element".

[TS 33.180 clause 7.3.2]

The group creation procedure is described in clause 10.2.3 of 3GPP TS 23.280 [36] and applies to the MCPTT scenario of normal group creation by an MC administrator and user regrouping operations by an authorized user/dispatcher. To establish the security context for the group, the GMS follows the procedures in clause 5.7 to create a new GMK and GMK-ID.

The encapsulated GMK and GUK-ID is sent to group members by the GMS within a notification message (step 4 in clause 10.2.3 of 3GPP TS 23.280 [36]). The procedure is equivalent to that described in clause 5.7 of this specification.

[TS 33.180 clause 7.3.3.2]

Group Regroup procedures for the MC system are described in clause 10.2.4.1 of 3GPP TS 23.280 [36]. To create the security context for the temporary group, the GMS follows the procedures in clause 5.7, creating a new GMK and GMK-ID for the temporary group.

An encapsulated GMK and GUK-ID is sent to the temporary group members by the GMS within a notification message (step 5 in clause 10.2.4.1 of 3GPP TS 23.280 [36]). The procedure is equivalent to that described in clause 5.7.

5.2.3 Test description

5.2.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT server)

– E-UTRA related parameters are set to the default parameters for the basic single cell environment, as defined in TS 36.508 [6] clause 4.4.

IUT:

– UE (MCPTT client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10, is inserted.

Preamble:

– The UE has performed the Generic Test Procedure for MCPTT UE registration as specified in TS 36.579-1 [2], subclause 5.4.2.

– The MCPTT User performs the Generic Test Procedure for MCPTT Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.

– UE States at the end of the preamble

– The UE is in E-UTRA Registered, Idle Mode state.

– The MCPTT Client Application has been activated and User has registered-in as the MCPTT User with the Server as active user at the Client.

5.2.3.2 Test procedure sequence

Table 5.2.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Void	–	–	–	–
–	EXCEPTION: The E-UTRA/EPC related actions are described in TS 36.579-1 [2], subclause 5.4.3 ‘Generic Test Procedure for MCPTT CO communication in E-UTRA’. The test sequence below shows only the MCPTT relevant messages being exchanged.	–	–	–	–
2	Make the MCPTT User request the creation of a new group, MCPTT Group B, as specified in TS 36.579-1 [2] Table 5.5.7.4-1. (NOTE 1)	–	–	–	–
3	Check: Does the UE (MCPTT Client) correctly perform Generic Test Procedure for MCX CO Group Creation as described in TS 36.579-1 [2] Table 5.3.26.3-1 to create GROUP B?	–	–	1	P
4-12	Void	–	–	–	–
13	Make the MCPTT User request the creation of a temporary group MCPPT Group T formed from MCPTT Group A and MCPTT Group B. (NOTE 1)	–	–	–	–
14	Check: Does the UE (MCPTT Client) correctly perform Generic Test Procedure for MCX CO Group Creation as described in TS 36.579-1 [2] Table 5.3.27.3-1 to create temporary GROUP T?	–	–	2	P
14A	Check: Does the UE (MCPTT Client) correctly perform Generic Test Procedure for NW initiated notifications regarding temporary group creation as described in TS 36.579-1 [2] Table 5.3.22.3-1 to update the group document of group A and retrieve the GMK for the temporary group	–	–	2	P
15-20	Void	–	–	–	–
21	Make the MCPTT User request tear down of the temporary MCPTT Group T (NOTE 1)	–	–	–	–
22	Check: Does the UE (MCPTT Client) correctly perform Generic Test Procedure for MCX CO Group Tear Down as described in TS 36.579-1 [2] Table 5.3.28.3-1 to delete temporary GROUP Group T?	–	–	3	P
22A	Check: Does the UE (MCPTT Client) correctly perform Generic Test Procedure for NW initiated notifications regarding temporary group tear down as described in TS 36.579-1 [2] Table 5.3.22.3-1 to update the group document and the GKTP document of group A?	–	–	3	P
23-26	Void	–	–	–	–
NOTE 1: This is expected to be done via a suitable implementation dependent mechanism and may be manually or automatically initiated.

5.2.3.3 Specific message contents

Table 5.2.3.3-1..16: Void

Table 5.2.3.3-17: HTTP PUT (step 3 Table 5.2.3.2-1; step 1, TS 36.579-1 [2], Table 5.3.26.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.4.4-1, condition GROUPCREATE

Table 5.2.3.3-18: HTTP POST (step 14 Table 5.2.3.2-1; step 1, TS 36.579-1 [2], Table 5.3.27.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.4.3-1, condition TEMPGROUP

Table 5.2.3.3-19: HTTP 200 (OK) (step 14 Table 5.2.3.2-1; step 2, TS 36.579-1 [2], Table 5.3.27.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.4.6-1, condition TEMPGROUP

Table 5.2.3.3-20: HTTP DELETE (step 22 Table 5.2.3.2-1; step 1, TS 36.579-1 [2], Table 5.3.28.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.4.5-1, condition TEMPGROUP

5.3 Configuration / Group Affiliation / Remote change / De-affiliation / Home MCPTT system

5.3.1 Test Purpose (TP)

(1)

with { MCPTT Client already provisioned with the group information or a pointer to the group information, that the MCPTT Client is allowed to be affiliated }

ensure that {
when { MCPTT User requests for current affiliation status and to subscribe to affiliation status changes for the MCPTT User }

then { UE (MCPTT Client) requests to subscribe to affiliation status changes for the MCPTT User by sending the SS a SIP SUBSCRIBE message and starts informing the MCPTT User of any affiliation status changes for the MCPTT User after the subscription is accepted }

}

(2)

with { MCPTT Client already provisioned with the group information or a pointer to the group information, that the MCPTT Client is allowed to be affiliated }

ensure that {
when { MCPTT User requests to affiliate to an MCPTT group }

then { UE (MCPTT Client) requests to affiliate to an MCPTT group by sending the SS a SIP PUBLISH message }

}

(3)

with { MCPTT Client already provisioned with the group information or a pointer to the group information, that the MCPTT Client is allowed to be affiliated }

ensure that {
when { MCPTT User requests for current affiliation status and to subscribe to affiliation status changes for a target user }

then { UE (MCPTT Client) requests to subscribe to affiliation status changes for the target user by sending the SS a SIP SUBSCRIBE message and starts informing the MCPTT User of any affiliation status changes for the target user after the subscription is accepted }

}

(4)

with { MCPTT client already provisioned with the group information or a pointer to the group information that the MCPTT client is allowed to make affiliation changes for another user }

ensure that {
when { MCPTT User requests that a target user be affiliated to an MCPTT group via mandatory mode }

then { UE (MCPTT Client) requests that a target user be affiliated to an MCPTT group via mandatory mode by sending the SS a SIP PUBLISH message }

}

(5)

with { MCPTT client already provisioned with the group information or a pointer to the group information that the MCPTT client is allowed to make affiliation changes for another user }

ensure that {
when { MCPTT User requests that a target user be de-affiliated to an MCPTT group via mandatory mode }

then { UE (MCPTT Client) requests that a target user be de-affiliated to an MCPTT group via mandatory mode by sending the SS a SIP PUBLISH message }

}

(6)

with { MCPTT client already provisioned with the group information or a pointer to the group information that the MCPTT client is allowed to make affiliation changes for another user }

ensure that {
when { MCPTT User requests that a target user be affiliated to an MCPTT group via negotiated mode }

then { UE (MCPTT Client) requests that a target user be affiliated to an MCPTT group via negotiated mode by sending the SS a SIP MESSAGE message }

}

(7)

with { MCPTT Client already provisioned with the group information or a pointer to the group information, that the MCPTT Client is allowed to be affiliated }

ensure that {
when { MCPTT User requests to de-subscribe to affiliation status changes for a target user }

then { UE (MCPTT Client) requests to de-subscribe to affiliation status changes for a target user by sending the SS a SIP SUBSCRIBE message }

}

(8)

with { MCPTT Client already affiliated with an MCPTT group }

ensure that {
when { MCPTT User requests to de-affiliate from an MCPTT group }

then { UE (MCPTT Client) requests to de-affiliate from an MCPTT group by sending the SS a SIP PUBLISH message }

}

(9)

with { MCPTT Client already provisioned with the group information or a pointer to the group information, that the MCPTT Client is allowed to be affiliated }

ensure that {
when { MCPTT Server requests that the MCPTT User choose to affiliate to an MCPTT group via negotiated mode by sending a SIP MESSAGE message }

then { UE (MCPTT Client) accepts to affiliate to an MCPTT group by sending the SS a SIP PUBLISH message }

}

5.3.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.379, clauses 9.2.1.2, 9.2.1.3, 9.2.1.4, and 9.2.1.5. Unless otherwise stated, these are Rel-13 requirements.

[TS 24.379, clause 9.2.1.2]

In order:

– to indicate that an MCPTT user is interested in one or more MCPTT group(s) at an MCPTT client;

– to indicate that the MCPTT user is no longer interested in one or more MCPTT group(s) at the MCPTT client;

– to refresh indication of an MCPTT user interest in one or more MCPTT group(s) at an MCPTT client due to near expiration of the expiration time of an MCPTT group with the affiliation status set to the "affiliated" state received in a SIP NOTIFY request in subclause 9.2.1.3;

– to send an affiliation status change request in mandatory mode to another MCPTT user; or

– any combination of the above;

the MCPTT client shall generate a SIP PUBLISH request according to 3GPP TS 24.229 [4], IETF RFC 3903 [37], and IETF RFC 3856 [51].

In the SIP PUBLISH request, the MCPTT client:

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

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

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

4) if the targeted MCPTT user is interested in at least one MCPTT group at the targeted MCPTT client, shall set the Expires header field according to IETF RFC 3903 [37], to 4294967295;

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

5) if the targeted MCPTT user is no longer interested in any MCPTT group at the targeted MCPTT client, shall set the Expires header field according to IETF RFC 3903 [37], to zero; and

6) shall include an application/pidf+xml MIME body indicating per-user affiliation information according to subclause 9.3.1. In the MIME body, the MCPTT client:

a) shall include all MCPTT groups where the targeted MCPTT user indicates its interest at the targeted MCPTT client;

b) shall include the MCPTT client ID of the targeted MCPTT client;

c) shall not include the "status" attribute and the "expires" attribute in the <affiliation> element; and

d) shall set the <p-id> child element of the <presence> root element to a globally unique value.

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

[TS 24.379, clause 9.2.1.3]

NOTE 1: The MCPTT UE also uses this procedure to determine which MCPTT groups the MCPTT user successfully affiliated to.

In order to discover MCPTT groups:

1) which the MCPTT user at an MCPTT client is affiliated to; or

2) which another MCPTT user is affiliated to;

the MCPTT client shall generate an initial SIP SUBSCRIBE request according to 3GPP TS 24.229 [4], IETF RFC 3856 [51], and IETF RFC 6665 [27].

In the SIP SUBSCRIBE request, the MCPTT client:

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

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

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

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

5) if the MCPTT client wants to fetch the current state only, shall set the Expires header field according to IETF RFC 6665 [26], to zero; and

6) shall include an Accept header field containing the application/pidf+xml MIME type; and

7) if requesting MCPTT groups where the MCPTT user is affiliated to at the MCPTT client, shall include an application/simple-filter+xml MIME body indicating per client restrictions of presence event package notification information according to subclause 9.3.2.

In order to re-subscribe or de-subscribe, the MCPTT client shall generate an in-dialog SIP SUBSCRIBE request according to 3GPP TS 24.229 [4], IETF RFC 3856 [51], and IETF RFC 6665 [26]. In the SIP SUBSCRIBE request, the MCPTT client:

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

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

2) if the MCPTT client wants to de-subscribe, shall set the Expires header field according to IETF RFC 6665 [26], to zero; and

3) shall include an Accept header field containing the application/pidf+xml MIME type.

Upon receiving a SIP NOTIFY request according to 3GPP TS 24.229 [4], IETF RFC 3856 [51], and IETF RFC 6665 [26], if SIP NOTIFY request contains an application/pidf+xml MIME body indicating per-user affiliation information constructed according to subclause 9.3.1, then the MCPTT client shall determine affiliation status of the MCPTT user for each MCPTT group at the MCPTT client(s) in the MIME body. If the <p-id> child element of the <presence> root element of the application/pidf+xml MIME body of the SIP NOTIFY request is included, the <p-id> element value indicates the SIP PUBLISH request which triggered sending of the SIP NOTIFY request.

[TS 24.379, clause 9.2.1.4]

NOTE: Procedure for sending affiliation status change request in negotiated mode to several target MCPTT users is not supported in this version of the specification.

Upon receiving a request from the MCPTT user to send an affiliation status change request in negotiated mode to a target MCPTT user, the MCPTT client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33]. In the SIP MESSAGE request, the MCPTT client:

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

3) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (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;

4) shall include an application/vnd.3gpp.mcptt-affiliation-command+xml MIME body as specified in Annex F.4; and

5) shall send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [4].

On receiving a SIP 2xx response to the SIP MESSAGE request, the MCPTT client shall indicate to the user that the request has been delivered to an MCPTT client of the target MCPTT user.

[TS 24.379, clause 9.2.1.5]

Upon receiving a SIP MESSAGE request containing:

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

2) an application/vnd.3gpp.mcptt-affiliation-command+xml MIME body with a list of MCPTT groups for affiliation under the <affiliate> element and a list of MCPTT groups for de-affiliation under the <de-affiliate> element;

then the MCPTT client:

1) shall send a 200 (OK) response to the SIP MESSAGE request;

2) shall seek confirmation of the list of MCPTT groups for affiliation and the list of MCPTT groups for de-affiliation, resulting in an accepted list of MCPTT groups for affiliation and an accepted list of MCPTT groups for de-affiliation; and

3) if the user accepts the request:

a) shall perform affiliation for each entry in the accepted list of MCPTT groups for affiliation for which the MCPTT client is not affiliated, as specified in subclause 9.2.1.2; and

b) shall perform de-affiliation for each entry in the accepted list of MCPTT groups for de-affiliation for which the MCPTT client is affiliated, as specified in subclause 9.2.1.2.

5.3.3 Test description

5.3.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT server)

IUT:

– UE (MCPTT client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10 is inserted.

Preamble:

– The UE has performed the Generic Test Procedure for MCPTT UE registration as specified in TS 36.579-1 [2], subclause 5.4.2.

– The MCPTT User performs the Generic Test Procedure for MCPTT Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.

– UE States at the end of the preamble:

– The UE is in E-UTRA Registered, Idle Mode state.

– The MCPTT Client Application has been activated and User has registered-in as the MCPTT User with the Server as active user at the Client.

5.3.3.2 Test procedure sequence

Table 5.3.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Make the MCPTT User send a request to discover which groups the MCPTT User is affiliated to and to subscribe to affiliation status changes for the MCPTT User. (NOTE 1)	–	–	–	–
2-4A	Check: Does the UE (MCPTT Client) correctly perform steps 2 to 5 of the Generic Test Procedure for MCX Subscription and Notification as described in TS 36.579-1 [2] Table 5.3.29.3-1 to subscribe to its own affiliation status changes?	–	–	1	P
4B	Check: Does the UE (MCPTT client) notify the user that the MCPTT User is affiliated with GROUP A? (NOTE 1)	–	–	1	P
4C	Make the MCPTT User send a request to de-affiliate from an MCPTT group, GROUP A. (NOTE 1)	–	–	–	–
4D-4I	Check: Does the UE (MCPTT Client) correctly perform steps 2 to 7 of the Generic Test Procedure for MCX Group Affiliation status change as described in TS 36.579-1 [2] Table 5.3.34.3-1 to de-affiliate with GROUP A?	–	–	8	P
4J	Check: Does the UE (MCPTT client) notify the user that the MCPTT User is no longer affiliated with GROUP A? (NOTE 1)	–	–	1	P
5	Make the MCPTT User send a request to affiliate to an MCPTT group, GROUP A. (NOTE 1)	–	–	–	–
6-9A	Check: Does the UE (MCPTT Client) correctly perform steps 2 to 7 of the Generic Test Procedure for MCX Group Affiliation status change as described in TS 36.579-1 [2] Table 5.3.34.3-1 to affiliate with GROUP A?	–	–	2	P
10	Check: Does the UE (MCPTT client) notify the user that the MCPTT User is now affiliated with GROUP A? (NOTE 1)	–	–	1	P
11	Make the MCPTT User send a request to discover which groups a target user is affiliated to and to subscribe to affiliation status changes for that target user. (NOTE 1)	–	–	–	–
12-13B	Check: Does the UE (MCPTT Client) correctly perform steps 2 to 5 of the Generic Test Procedure for MCX Subscription and Notification as described in TS 36.579-1 [2] Table 5.3.29.3-1 to subscribe to affiliation status changes of a target user?	–	–	3	P
14	Make the MCPTT User send a request to have a target user affiliate to an MCPTT group, GROUP A (mandatory mode). (NOTE 1)	–	–	–	–
15-18A	Check: Does the UE (MCPTT Client) correctly perform steps 2 to 7 of the Generic Test Procedure for MCX Group Affiliation status change as described in TS 36.579-1 [2] Table 5.3.34.3-1 to have the target user affiliate with GROUP A?	–	–	4	P
19	Check: Does the UE (MCPTT client) notify the user that the target user is now affiliated with GROUP A? (NOTE 1)	–	–	3	P
20	Make the MCPTT User send a request to have a target user de-affiliate to an MCPTT group, GROUP A (mandatory mode). (NOTE 1)	–	–	–	–
21-23C	Check: Does the UE (MCPTT Client) correctly perform steps 2 to 7 of the Generic Test Procedure for MCX Group Affiliation status change as described in TS 36.579-1 [2] Table 5.3.34.3-1 to have the target user de-affiliate with GROUP A?	–	–	5	P
24	Check: Does the UE (MCPTT client) notify the user that the target user is now de-affiliated with GROUP A? (NOTE 1)	–	–	3	P
25	Make the MCPTT User send a request to have a target user affiliate to an MCPTT group, GROUP A (negotiated mode). (NOTE 1)	–	–	–	–
26-27	Check: Does the UE (MCPTT Client) correctly perform steps 2 to 3 of Generic Test Procedure for MCX SIP MESSAGE CO as described in TS 36.579-1 [2] Table 5.3.32.3-1 to have a target user affiliate with GROUP A via negotiated mode?	–	–	6	P
28-29A	Steps 4 to 7 of Generic Test Procedure for MCX Group Affiliation status change as described in TS 36.579-1 [2] Table 5.3.34.3-1 are performed informing that the affiliation status of the target user with GROUP A is “affiliating”	–	–	–	–
30	Check: Does the UE (MCPTT client) notify the user that the target user is now affiliated with GROUP A? (NOTE 1)	–	–	3	P
31	Make the MCPTT User send a request to de-subscribe from affiliation status changes of a target user. (NOTE 1)	–	–	–	–
32-33	Check: Does the UE (MCPTT Client) correctly perform Steps 2 to 3 of Generic Test Procedure for MCX Subscription and Notification as described in TS 36.579-1 [2] Table 5.3.29.3-1 to de-subscribe from affiliation status changes for a target user?	–	–	7	P
34	Make the MCPTT User send a request to de-affiliate from an MCPTT group, GROUP A. (NOTE 1)	–	–	–	–
35-37C	Check: Does the UE (MCPTT Client) correctly perform steps 2 to 7 of the Generic Test Procedure for MCX Group Affiliation status change as described in TS 36.579-1 [2] Table 5.3.34.3-1 to de-affiliate with GROUP A?	–	–	8	P
38	Check: Does the UE (MCPTT client) notify the user that the MCPTT User is no longer affiliated with GROUP A? (NOTE 1)	–	–	1	P
39-40	Check: Are the Steps 2 to 3 of Generic Test Procedure for MCX SIP MESSAGE CT as described in TS 36.579-1 [2] Table 5.3.33.3-1 to affiliate the MCPTT User to GROUP A via negotiated mode correctly performed?	–	–	9	P
41	Check: Does the UE (MCPTT client) notify the user that another user is requesting the MCPTT User affiliate to GROUP A? (NOTE 1)	–	–	9	P
42	Make the MCPTT User accept to affiliate to GROUP A. (NOTE 1)	–	–	–	–
43-46A	Check: Does the UE (MCPTT Client) correctly perform steps 2 to 7 of the Generic Test Procedure for MCX Group Affiliation status change as described in TS 36.579-1 [2] Table 5.3.34.3-1 to affiliate with GROUP A?	–	–	9	P
47	Check: Does the UE (MCPTT client) notify the user that the MCPTT User is now affiliated with GROUP A? (NOTE 1)	–	–	1	P
NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

5.3.3.3 Specific message contents

Table 5.3.3.3-1: SIP SUBSCRIBE (step 2, Table 5.3.3.2-1; step 2, TS 36.579-1 [2] Table 5.3.29.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.14-1
Information Element	Value/remark	Comment	Reference	Condition
Expires
delta-seconds	"4294967295"
Message-body
MIME body part		MCPTT-Info
MIME-part-body	MCPTT-Info as described in Table 5.3.3.3-2

Table 5.3.3.3-2: MCPTT-Info in SIP SUBSCRIBE (Table 5.3.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1
Information Element	Value/remark	Comment	Reference	Condition
mcpttinfo
mcptt-Params
mcptt-request-uri	px_MCPTT_ID_User_A

Table 5.3.3.3-3: SIP SUBSCRIBE (step 12, Table 5.3.3.2-1; step 2, TS 36.579-1 [2] Table 5.3.29.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.14-1
Information Element	Value/remark	Comment	Reference	Condition
Expires
delta-seconds	"4294967295"
Message-body
MIME body part		MCPTT-Info
MIME-part-body	MCPTT-Info as described in Table 5.3.3.3-4

Table 5.3.3.3-4: MCPTT-Info in SIP SUBSCRIBE (Table 5.3.3.3-3)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1
Information Element	Value/remark	Comment	Reference	Condition
mcpttinfo
mcptt-Params
mcptt-request-uri	px_MCPTT_ID_User_B

Table 5.3.3.3-5: Void

Table 5.3.3.3-6: SIP SUBSCRIBE (step 32, Table 5.3.3.2-1; step 2, TS 36.579-1 [2] Table 5.3.29.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.14-1 condition re-SUBSCRIBE
Information Element	Value/remark	Comment	Reference	Condition
Expires
delta-seconds	"0"
Message-body
MIME body part		MCPTT-Info
MIME-part-body	MCPTT-Info as described in Table 5.3.3.3-7

Table 5.3.3.3-7: MCPTT-Info in SIP SUBSCRIBE (Table 5.3.3.3-6)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1
Information Element	Value/remark	Comment	Reference	Condition
mcpttinfo
mcptt-Params
mcptt-request-uri	px_MCPTT_ID_User_B

Table 5.3.3.3-8..11: Void

Table 5.3.3.3-12: SIP PUBLISH (steps 6, 43, Table 5.3.3.2-1; step 2, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.11-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		MCPTT-Info
MIME-part-body	MCPTT-Info as described in Table 5.3.3.3-13
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-14

Table 5.3.3.3-13: MCPTT-Info in SIP PUBLISH (Table 5.3.3.3-12)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1
Information Element	Value/remark	Comment	Reference	Condition
mcpttinfo
mcptt-Params
mcptt-request-uri	px_MCPTT_ID_User_A

Table 5.3.3.3-14: PIDF in SIP PUBLISH (Table 5.3.3.3-12)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.1-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
..p-id	any allowed value	p-id shall be present acc. to TS 24.379 [9] clause 9.2.2.2.5 and clause 9.2.2.3.5

Table 5.3.3.3-15: SIP PUBLISH (step 15, Table 5.3.3.2-1; step 2, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.11-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		MCPTT-Info
MIME-part-body	MCPTT-Info as described in Table 5.3.3.3-16
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-17

Table 5.3.3.3-16: MCPTT-Info in SIP PUBLISH (Table 5.3.3.3-15)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1
Information Element	Value/remark	Comment	Reference	Condition
mcpttinfo
mcptt-Params
mcptt-request-uri	px_MCPTT_ID_User_B

Table 5.3.3.3-17: PIDF in SIP PUBLISH (Table 5.3.3.3-15)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.1-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
Entity attribute	px_MCPTT_ID_User_B
tuple
Id attribute	px_MCX_Client_B_ID
..p-id	any allowed value	p-id shall be present acc. to TS 24.379 [9] clause 9.2.2.2.5 and clause 9.2.2.3.5

Table 5.3.3.3-18: SIP PUBLISH (step 21, Table 5.3.3.2-1; step 2, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.11-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Expires
delta-seconds	"0"
Message-body
MIME body part		MCPTT-Info
MIME-part-body	MCPTT-Info as described in Table 5.3.3.3-19
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-20

Table 5.3.3.3-19: MCPTT-Info in SIP PUBLISH (Table 5.3.3.3-18)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1
Information Element	Value/remark	Comment	Reference	Condition
mcpttinfo
mcptt-Params
mcptt-request-uri	px_MCPTT_ID_User_B

Table 5.3.3.3-20: PIDF in SIP PUBLISH (Table 5.3.3.3-18)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.1-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
entity attribute	px_MCPTT_ID_User_B
tuple
Id attribute	px_MCX_Client_B_ID
status	not present
..p-id	any allowed value	p-id shall be present acc. to TS 24.379 [9] clause 9.2.2.2.5 and clause 9.2.2.3.5

Table 5.3.3.3-21: SIP PUBLISH (step 4D, 35, Table 5.3.3.2-1; step 2, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.11-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Expires
delta-seconds	"0"
Message-body
MIME body part		MCPTT-Info
MIME-part-body	MCPTT-Info as described in Table 5.3.3.3-22
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-23

Table 5.3.3.3-22: MCPTT-Info in SIP PUBLISH (Table 5.3.3.3-21)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1
Information Element	Value/remark	Comment	Reference	Condition
mcpttinfo
mcptt-Params
mcptt-request-uri	px_MCPTT_ID_User_A

Table 5.3.3.3-23: PIDF in SIP PUBLISH (Table 5.3.3.3-21)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.1-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
tuple
status	not present
..p-id	any allowed value	p-id shall be present acc. to TS 24.379 [9] clause 9.2.2.2.5 and clause 9.2.2.3.5

Table 5.3.3.3-24: SIP NOTIFY (step 4, Table 5.3.3.2-1; step 4, TS 36.579-1 [2] Table 5.3.29.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-25

Table 5.3.3.3-25: PIDF in SIP NOTIFY (Table 5.3.3.3-24)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
tuple
status
affiliation
status	“affiliated”

Table 5.3.3.3-26: SIP NOTIFY (steps 8, 45, Table 5.3.3.2-1; step 4, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-27

Table 5.3.3.3-27: PIDF in SIP NOTIFY (Table 5.3.3.3-26)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
tuple
status
affiliation
status	“affiliating”
..p-id	same value as received in corresponding SIP PUBLISH (step 6, 43)

Table 5.3.3.3-28: SIP NOTIFY (steps 9, 46, Table 5.3.3.2-1; step 6, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-29

Table 5.3.3.3-29: PIDF in SIP NOTIFY (Table 5.3.3.3-28)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
tuple
status
affiliation
status	“affiliated”
..p-id	same value as received in corresponding SIP PUBLISH (step 6, 43)

Table 5.3.3.3-30: SIP NOTIFY (step 17, Table 5.3.3.2-1; step 4, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-31

Table 5.3.3.3-31: PIDF in SIP NOTIFY (Table 5.3.3.3-30)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
entity attribute	px_MCPTT_ID_User_B
tuple
Id attribute	px_MCX_Client_B_ID
status
affiliation
status	“affiliating”
..p-id	same value as received in corresponding SIP PUBLISH (step 15)

Table 5.3.3.3-31A: SIP NOTIFY (step 28, Table 5.3.3.2-1; step 4, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-31B

Table 5.3.3.3-31B: PIDF in SIP NOTIFY (Table 5.3.3.3-31A)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
entity attribute	px_MCPTT_ID_User_B
tuple
Id attribute	px_MCX_Client_B_ID
status
affiliation
status	“affiliating”

Table 5.3.3.3-32: SIP NOTIFY (step 18, Table 5.3.3.2-1; step 6, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-33

Table 5.3.3.3-33: PIDF in SIP NOTIFY (Table 5.3.3.3-32)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence entity
entity attribute	px_MCPTT_ID_User_B
tuple id
Id attribute	px_MCX_Client_B_ID
status
affiliation
status	“affiliated”
..p-id	same value as received in corresponding SIP PUBLISH (step 15)

Table 5.3.3.3-33A: SIP NOTIFY (step 29, Table 5.3.3.2-1; step 6, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-33B

Table 5.3.3.3-33B: PIDF in SIP NOTIFY (Table 5.3.3.3-33A)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
entity attribute	px_MCPTT_ID_User_B
tuple
Id attribute	px_MCX_Client_B_ID
status
affiliation
status	“affiliated”

Table 5.3.3.3-34: SIP NOTIFY (step 23, Table 5.3.3.2-1; step 4, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-35

Table 5.3.3.3-35: PIDF in SIP NOTIFY (Table 5.3.3.3-34)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
entity attribute	px_MCPTT_ID_User_B
tuple
Id attribute	px_MCX_Client_B_ID
status
affiliation
status	“deaffiliating”
..p-id	same value as received in corresponding SIP PUBLISH (step 21)

Table 5.3.3.3-36: SIP NOTIFY (step 37, Table 5.3.3.2-1; step 4, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-37

Table 5.3.3.3-37: PIDF in SIP NOTIFY (Table 5.3.3.3-36)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
tuple
status
affiliation
status	“deaffiliating”
..p-id	same value as received in corresponding SIP PUBLISH (step 35)

Table 5.3.3.3-38: SIP MESSAGE (step 26, Table 5.3.3.2-1; step 2, TS 36.579-1 [2] Table 5.3.32.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.1-1 with condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		MCPTT-Info
MIME-part-body	MCPTT-Info as described in Table 5.3.3.3-39

Table 5.3.3.3-39: MCPTT-Info in SIP MESSAGE (Table 5.3.3.3-38)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1
Information Element	Value/remark	Comment	Reference	Condition
mcpttinfo
mcptt-Params
mcptt-request-uri	px_MCPTT_ID_User_B

Table 5.3.3.3-40: Void

Table 5.3.3.3-41: SIP MESSAGE (step 39, Table 5.3.3.2-1; step 2, TS 36.579-1 [2] Table 5.3.33.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.2-1 with condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		MCPTT-Info
MIME-part-body	MCPTT-Info as described in Table 5.3.3.3-42

Table 5.3.3.3-42: MCPTT-Info in SIP MESSAGE (Table 5.3.3.3-41)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.2-1
Information Element	Value/remark	Comment	Reference	Condition
mcpttinfo
mcptt-Params
mcptt-calling-user-id	not present

Table 5.3.3.3-43: Void

Table 5.3.3.3-44: SIP NOTIFY (step 13A, Table 5.3.3.2-1; step 4, TS 36.579-1 [2] Table 5.3.29.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-45

Table 5.3.3.3-45: PIDF in SIP NOTIFY (Table 5.3.3.3-44)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
tuple
status	not present

Table 5.3.3.3-46: SIP NOTIFY (step 4H, 37B, Table 5.3.3.2-1; step 6, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-46A

Table 5.3.3.3-46A: PIDF in SIP NOTIFY (Table 5.3.3.3-46)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
tuple id
status	not present
..p-id	same value as received in the corresponding SIP PUBLISH (step 4D, 35)

Table 5.3.3.3-46B: SIP NOTIFY (step 23B, Table 5.3.3.2-1; step 6, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-46C

Table 5.3.3.3-46C: PIDF in SIP NOTIFY (Table 5.3.3.3-46B)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
entity attribute	px_MCPTT_ID_User_B
tuple id
Id attribute	px_MCX_Client_B_ID
status	not present
..p-id	same value as received in corresponding SIP PUBLISH (step 21)

Table 5.3.3.3-47: SIP NOTIFY (step 4F, Table 5.3.3.2-1; step 4, TS 36.579-1 [2] Table 5.3.34.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.3.3.3-48

Table 5.3.3.3-48: PIDF in SIP NOTIFY (Table 5.3.3.3-47)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1 condition AFFILIATION
Information Element	Value/remark	Comment	Reference	Condition
presence
tuple
status
affiliation
status	“deaffiliating”
..p-id	same value as received in corresponding SIP PUBLISH (step 4D)

5.4 Configuration / Pre-established Session Establishment / Pre-established Session Modification / Pre-established Session Release

5.4.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorized for MCPTT Service }

ensure that {
when { MCPTT User requests the creation of a pre-established session }

then { UE (MCPTT Client) requests the creation of a pre-establish session by sending a SIP INVITE message }

}

(2)

with { the MCPTT client already having a pre-established session created }

ensure that {
when { MCPTT User requests the modification of a pre-established session }

then { UE (MCPTT Client) requests the modification of a pre-establish session by sending a SIP re-INVITE message or a SIP UPDATE message (depending on UE implementation) }

}

(3)

with { the MCPTT client already having a pre-stablished session created }

ensure that {
when { MCPTT Server requests the modification of a pre-established session by sending either a SIP UPDATE message or a SIP re-INVITE message }

then { UE (MCPTT Client) responds to the pre-established session modification request by sending a SIP 200 (OK) message }

}

(4)

with { the MCPTT client already having a pre-stablished session created }

ensure that {
when { MCPTT User requests the release of a pre-established session }

then { UE (MCPTT Client) requests the release of a pre-establish session by sending a SIP BYE message }

}

(5)

with { the MCPTT client already having a pre-stablished session created }

ensure that {
when { MCPTT Server requests the release of a pre-established session by sending a SIP BYE message }

then { UE (MCPTT Client) responds to the pre-established session release request by sending a SIP 200 (OK) message }

}

5.4.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.379, clauses 8.2.1, 8.3.1.1, 8.3.1.2, 8.4.1.1, 8.4.1.2. Unless otherwise stated, these are Rel-13 requirements.

[TS 24.379, clause 8.2.1]

When the MCPTT client initiates a pre-established session the MCPTT client shall:

1) gather ICE candidates according to IETF RFC 5245 [17]; and

NOTE 1: ICE candidates are only gathered on interfaces that the MCPTT UE uses to obtain MCPTT service.

2) generate an initial SIP INVITE request by following the UE originating session procedures specified in 3GPP TS 24.229 [4], with the clarifications given below.

The MCPTT client:

1) shall set the Request-URI of the SIP INVITE request to the public service identity of the participating MCPTT function serving the MCPTT user;

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

3) shall include the g.3gpp.mcptt media feature tag in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [16];

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

5) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (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 INVITE request;

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

7) shall include the "timer" option tag in the Supported header field;

8) should include the Session-Expires header field according to IETF RFC 4028 [7] and should not include the "refresher" header field. The "refresher" header field parameter shall be set to "uac" if included;

9) shall include an SDP offer according to 3GPP TS 24.229 [4] with the clarifications given in subclause 6.2.1, and include ICE candidates in the SDP offer as per IETF RFC 5245 [17]; and

10) shall send the SIP INVITE request according to 3GPP TS 24.229 [4].

Upon receiving a SIP 2xx response to the SIP INVITE request the MCPTT client:

1) shall interact with the media plane as specified in 3GPP TS 24.380 [5].

NOTE 2: If ICE candidate evaluation results in candidate pairs other than the default candidate pair being selected a further offer answer exchange using the procedures in subclause 8.3 will be needed.

[TS 24.379, clause 8.3.1.1]

When the MCPTT client needs to modify the pre-established session outside of an MCPTT session, the MCPTT client:

1) shall generate a SIP UPDATE request or a SIP re-INVITE request according to 3GPP TS 24.229 [4];

2) shall include an SDP offer according to 3GPP TS 24.229 [4] with the clarifications given in subclause 6.2.1, and include ICE candidates in the SDP offer as per IETF RFC 5245 [17], if required; and

3) shall send the SIP request towards the MCPTT server according to rules and procedures of 3GPP TS 24.229 [4].

On receipt of the SIP 200 (OK) response the MCPTT client:

1) shall interact with media plane as specified in 3GPP TS 24.380 [5], if there is change in media parameters or codecs in the received SDP answer, compared to those in the previously agreed SDP; and

2) shall interact with media plane as specified in 3GPP TS 24.380 [5], if there is a media stream that is currently used in the pre-established session, marked as rejected in the received SDP answer.

NOTE: The MCPTT client keeps resources for previously agreed media stream, media parameters and codecs until it receives a SIP 200 (OK) response.

[TS 24.379, clause 8.3.1.2]

Upon receiving a SIP UPDATE request or a SIP re-INVITE request to modify an existing pre-established session without associated MCPTT session, the MCPTT client:

1) shall validate that the received SDP offer includes at least one media stream for which the media parameters and at least one codec is acceptable by the MCPTT client and if not reject the request with a SIP 488 (Not Acceptable Here) response. Otherwise, continue with the rest of the steps; and

2) shall generate a SIP 200 (OK) response as follows:

a) shall include an SDP answer according to 3GPP TS 24.229 [4] with the clarifications given in subclause 6.2.2, and include ICE candidates in the SDP answer as per IETF RFC 5245 [17]. if required.

[TS 24.379, clause 8.4.1.1]

NOTE: The MCPTT client needs to be prepared to release the pre-established session when receiving a SIP BYE request generated by the SIP core (e.g. due to network release of media plane resources).

When a MCPTT client needs to release a pre-established session as created in subclause 8.2.1, the MCPTT client:

1) shall generate a SIP BYE request according to rules and procedures of 3GPP TS 24.229 [4];

2) shall set the Request-URI of the SIP BYE request to the URI that identifies the pre-established session;

3) shall send the SIP BYE request towards the participating MCPTT function within the SIP dialog of the pre-established session according to rules and procedures of the 3GPP TS 24.229 [4]; and

4) shall, upon receiving a SIP 200 (OK) response to the SIP BYE request interact with the media plane as specified in 3GPP TS 24.380 [5].

[TS 24.379, clause 8.4.1.2]

Upon receiving a SIP BYE request from the participating MCPTT function within a pre-established session the MCPTT client shall check whether there are any MCPTT sessions using the pre-established session, and:

1) if there is an established MCPTT session then the MCPTT client shall remove the MCPTT client from the MCPTT session by performing the procedures for session release for each MCPTT session as specified in 3GPP TS 24.380 [5]; and

2) if there is no MCPTT session using the pre-established session, then the MCPTT client shall:

a) interact with the media plane as specified in 3GPP TS 24.380 [5] for disconnecting the media plane resources towards the participating MCPTT function; and

b) shall generate and send a SIP 200 (OK) response to the SIP BYE request according to rules and procedures of 3GPP TS 24.229 [4].

5.4.3 Test description

5.4.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT server)

IUT:

– UE (MCPTT client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10 is inserted.

Preamble:

– The UE has performed the Generic Test Procedure for MCPTT UE registration as specified in TS 36.579-1 [2], subclause 5.4.2.

– The MCPTT User performs the Generic Test Procedure for MCPTT Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.

– UE States at the end of the preamble

– The UE is in E-UTRA Registered, Idle Mode state.

– The MCPTT Client Application has been activated and User has registered-in as the MCPTT User with the Server as active user at the Client.

5.4.3.2 Test procedure sequence

Table 5.4.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Make the MCPTT User request the creation of a pre-established session without implicit floor control (NOTE 1)	–	–	–	–
2	Check: Does the UE (MCPTT Client) perform Generic Test Procedure for MCPTT pre-established session establishment CO as described in TS 36.579-1 [2] Table 5.3.3.3-1 to create a pre-established session?	–	–	1	–
2A-3A	Void	–	–	–	–
–	EXCEPTION: Steps 4a1-5b1 describe behaviour that depends on the UE implementation. The "lower case letter" identifies a step sequence that takes place if the UE is capable to provide pre-established session modification triggered by the user.	–	–	–	–
4a1	IF pc_MCX_UserinitiatedPreestablishedSessionModification: Make the MCPTT User request to modify the pre-established session by requesting usage of implicit floor control (NOTE 1)	–	–	–	–
4a2	The E-UTRA/EPC signalling according to clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ takes place	–	–	–	–
–	EXCEPTION: Steps 5a1-5b1 describe behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that takes place if the UE uses the SIP UPDATE message or the SIP re-INVITE message to modify an existing pre-established session.	–	–	–	–
5a1	Check: Does the UE (MCPTT Client) send a SIP UPDATE message to modify a pre-established session?	–>	SIP UPDATE	2	P
5a2	The SS responds to the SIP UPDATE message with a SIP 200 (OK) message	<–	SIP 200 (OK)	–	–
5b1	Check: Does the UE (MCPTT Client) perform Step 1-4 of the Generic Test Procedure for MCPTT CO session modification as described in TS 36.579-1 [2] Table 5.3A.6.3-1 to modify the pre-established session?	–	–	2	–
6	Void	–	–	–	–
–	EXCEPTION: Steps 6Aa1 describes behaviour that depends on the UE implementation. The "lower case letter" identifies a step sequence that takes place if the UE is not capable to provide pre-established session modification triggered by the user.	–	–	–	–
6Aa1	IF NOT pc_MCX_UserinitiatedPreestablishedSessionModification: The E-UTRA/EPC signalling according to clause 5.4.4 ‘Generic Test Procedure for MCX CT communication in E-UTRA’ takes place	–	–	–	–
7	The SS sends a SIP UPDATE message to modify the Floor priority of the pre-established session.	<–	SIP UPDATE	–	–
8	Check: Does the UE (MCPTT Client) respond to the SIP UPDATE message with a SIP 200 (OK) message?	–>	SIP 200 (OK)	3	P
9	Check: Is the Generic Test Procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 to modify the Floor priority of the pre-established session correctly performed?	–	–	3	–
10	Void	–	–	–	–
11	Make the MCPTT User request to release the pre-established session (NOTE 1)	–	–	–	–
12	Check: Does the UE (MCPTT Client) perform Generic Test Procedure for MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1 to release the pre-established session?	–	–	4	–
13	Void	–	–	–	–
14	Make the MCPTT User request the creation of a pre-established session (NOTE 1)	–	–	–	–
15	The Generic Test Procedure for MCX pre-established session establishment CO as described in TS 36.579-1 [2] Table 5.3.3.3-1 to create a pre-established session is performed.	–	–	–	–
15A-16A	Void	–	–	–	–
17	Check: Is the Generic Test Procedure for MCX CT call release as described in TS 36.579-1 [2] Table 5.3.12.3-1 to release the pre-established session correctly performed?	–	–	5	–
18	Void	–	–	–	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

5.4.3.3 Specific message contents

Table 5.4.3.3-1: SIP INVITE from the UE (steps 2, 15, Table 5.4.3.2-1;
step 8, TS 36.579-1 [2] Table 5.3.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1
Information Element	Value/remark	Comment	Reference	Condition
Content-Type
media-type	"application/sdp"
Message-body
SDP message	SDP message as described in Table 5.4.3.3-1A

Table 5.4.3.3-1A: SDP in SIP INVITE (Table 5.4.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.1-1, condition INITIAL_SDP_OFFER, PRE_ESTABLISHED_SESSION

Table 5.4.3.3-2: SIP 200 (OK) from the SS (steps 2, Table 5.4.3.2-1;
step 10, TS 36.579-1 [2] Table 5.3.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1
Information Element	Value/remark	Comment	Reference	Condition
Message-body
SDP message	SDP message as described in Table 5.4.3.3-2A

Table 5.4.3.3-2A: SDP in SIP 200 (OK) (Table 5.4.3.3-2)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-1 condition SDP_ANSWER, PRE_ESTABLISHED_SESSION

Table 5.4.3.3-3..5: Void

Table 5.4.3.3-5A: SIP UPDATE from the UE (step 5a1, Table 5.4.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.15.1-1 condition MO_CALL
Information Element	Value/remark	Comment	Reference	Condition
Message-body
SDP Message	SDP Message as described in Table 5.4.3.3-5B

Table 5.4.3.3-5B: SDP in SIP UPDATE (Table 5.4.3.3-5A) or re-INVITE (Table 5.4.3.3-6)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.1-1 condition SDP_OFFER, PRE_ESTABLISHED_SESSION, IMPLICIT_GRANT_REQUESTED

Table 5.4.3.3-6: SIP INVITE from the UE (step 5b1, Table 5.4.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3A.6.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1 condition re-INVITE
Information Element	Value/remark	Comment	Reference	Condition
Contact	Contact header with the same Contact URI and the same mandatory feature parameters as in the INVITE creating the dialog
Content-Type
media-type	"application/sdp"
Message-body
SDP Message	SDP Message as described in Table 5.4.3.3-5B

Table 5.4.3.3-6A: SIP 200 (OK) (step 5a2, 5b1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1 condition INVITE-RSP
Information Element	Value/remark	Comment	Reference	Condition
Contact
addr-spec
user-info and host	tsc_MCX_SessionID_B	The URI that identifies the pre-established session

Table 5.4.3.3-6B: SIP UPDATE from the SS (step 7, Table 5.4.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.15.2-1 condition MO_CALL
Information Element	Value/remark	Comment	Reference	Condition
Message-body
SDP Message	SDP Message as described in Table 5.4.3.3-6D

Table 5.4.3.3-6C: SIP 200 (OK) (step 8)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1 condition INVITE-RSP
Information Element	Value/remark	Comment	Reference	Condition
Contact	Contact header with the same Contact URI and the same mandatory feature parameters as in the INVITE creating the dialog
Content-Type
media-type	"application/sdp"
Message-body
SDP Message	SDP message as described in Table TS 36.579-1 [2] 5.5.3.1.1-1

Table 5.4.3.3-6D: SDP in SIP UPDATE (Table 5.4.3.3-6B)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-1 condition SDP_OFFER. PRE_ESTABLISHED_SESSION
Information Element	Value/remark	Comment	Reference	Condition
Media description [2]		Media description for media control
media attribute		a= line attribute = fmtp
fmtp
format specific parameters
mc_priority	"2"

Table 5.4.3.3-7: SIP INVITE from the SS (step 9, Table 5.4.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3.4.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.2-1 condition re_INVITE
Information Element	Value/remark	Comment	Reference	Condition
Contact	same as in the response for the INVITE creating the dialog
Message-body
SDP Message	SDP Message as described in Table 5.4.3.3-7A

Table 5.4.3.3-7A: SDP in SIP INVITE (Table 5.4.3.3-7)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-1 condition SDP_OFFER, PRE_ESTABLISHED_SESSION
Information Element	Value/remark	Comment	Reference	Condition
Media description [2]		Media description for media control
media attribute		a= line attribute = fmtp
fmtp
format specific parameters
mc_priority	"3"

Table 5.4.3.3-7B: SIP 200 (OK) from the UE (step 9, Table 5.4.3.2-1;
step 4, TS 36.579-1 [2] Table 5.3.4.3-1)

Derivation Path: Table 5.4.3.3-6C

Table 5.4.3.3-8: SIP BYE from the UE (step 12, Table 5.4.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3.10.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.2.1-1
Information Element	Value/remark	Comment	Reference	Condition
Request-Line
Request-URI	tsc_MCX_SessionID_B	The URI that identifies the pre-established session

Table 5.4.3.3-9: SIP BYE from the SS (step 17, Table 5.4.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3.12.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.2.2-1, condition MO_CALL
Information Element	Value/remark	Comment	Reference	Condition
Request-Line
Request-URI	tsc_MCX_SessionID_B	The URI that identifies the pre-established session

5.5 Configuration / Determination of MCPTT Service Settings / Current Active MCPTT Settings / De-subscribe

5.5.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorised for MCPTT Service }

ensure that {
when { MCPTT User requests to verify the currently active MCPTT service settings or to discover MCPTT service settings }

then { UE (MCPTT Client) sends a SIP SUBSCRIBE message to find the MCPTT service settings and responds to the SIP NOTIFY message with a SIP 200 (OK) message }

}

(2)

with { UE (MCPTT Client) having already subscribed to find the MCPTT service settings }

ensure that {
when { MCPTT User requests to re-subscribe for MCPTT service settings }

then { UE (MCPTT Client) sends a SIP SUBSCRIBE message to re-subscribe for the MCPTT service settings and responds to the SIP NOTIFY message with a SIP 200 (OK) message }

}

(3)

with { UE (MCPTT Client) having already subscribed to find the MCPTT service settings }

ensure that {
when { MCPTT User requests to de-subscribe for MCPTT service settings }

then { UE (MCPTT Client) sends a SIP SUBSCRIBE message to de-subscribe for the MCPTT service settings and responds to the SIP NOTIFY message with a SIP 200 (OK) message }

}

5.5.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.379 clause 7.2.4. Unless otherwise stated these are Rel-14 requirements.

[TS 24.281, clause 7.2.4]

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

In the SIP SUBSCRIBE request, the MCPTT client:

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

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

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 MCPTT client wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [26], 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 [24].

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

In order to re-subscribe or de-subscribe, the MCPTT client shall generate an in-dialog SIP SUBSCRIBE request according to 3GPP TS 24.229 [4], IETF RFC 6665 [26], IETF RFC 4354 [55]. In the SIP SUBSCRIBE request, the MCPTT 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 MCPTT client wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [26], 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 [24].

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

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

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

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

5.5.3 Test description

5.5.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT server)

– E-UTRA related parameters are set to the default parameters for the basic single cell environment, as defined in TS 36.508 [20] clause 4.4.

IUT:

– UE (MCPTT Client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10, is inserted.

Preamble:

– The UE has performed the Generic Test Procedure for MCPTT UE registration as specified in TS 36.579-1 [2], subclause 5.4.2.

– The MCPTT User performs the Generic Test Procedure for MCPTT Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.

– UE States at the end of the preamble

– The UE is in E-UTRA Registered, Idle Mode state.

– The MCPTT Client Application has been activated and User has registered-in as the MCPTT User with the Server as active user at the Client.

5.5.3.2 Test procedure sequence

Table 5.5.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Make the MCPTT User request to verify the currently active MCPTT service settings of the UE (MCPTT Client) and to receive later notifications. (NOTE 1)	–	–	–	–
2	Check: Does the UE (MCPTT Client) perform Generic Test Procedure for MCX Subscription and Notification as described in TS 36.579-1 [2] Table 5.3.29.3-1 to request to verify the currently active MCPTT service settings of the UE (MCPTT Client)?	–	–	1	P
3-5	Void	–	–	–	–
6	Make the MCPTT User request to re-subscribe to MCPTT service settings and to receive later notifications. (NOTE 1)	–	–	–	–
7	Check: Does the UE (MCPTT Client) perform Generic Test Procedure for MCX Subscription and Notification as described in TS 36.579-1 [2] Table 5.3.29.3-1 to re-subscribe to MCPTT service settings and to receive later notifications?	–	–	2	P
8-10	Void.	–	–	–	–
11	Make the MCPTT User request to de-subscribe to MCPTT service settings. (NOTE 1)	–	–	–	–
12-14	Check: Does the UE (MCPTT Client) perform Steps 1a1 to 3 of Generic Test Procedure for MCX Subscription and Notification as described in TS 36.579-1 [2] Table 5.3.29.3-1 to de-subscribe to MCPTT service settings?	–	–	3	P
–	EXCEPTION: SS (MCPTT Server) releases the E-UTRA connection.	–	–	–	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI command.

5.5.3.3 Specific message contents

Table 5.5.3.3-1: SIP SUBSCRIBE (step 2, Table 5.5.3.2-1; step 2, TS 36.579-1 [2] Table 5.3.29.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.14-1, condition POC-SETTINGS-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Expires			TS 24.379 [9] clause 7.2.4
value	"4294967295"
Message-body
MIME body part		MCPTT Info
MIME-part-body	MCPTT-Info as described in Table 5.5.3.3-2

Table 5.5.3.3-1A: SIP SUBSCRIBE (step 7, Table 5.5.3.2-1; step 2, TS 36.579-1 [2] Table 5.3.29.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.14-1, condition POC-SETTINGS-EVENT, re_SUBSCRIBE
Information Element	Value/remark	Comment	Reference	Condition
Expires			TS 24.379 [9] clause 7.2.4
value	"4294967295"
Message-body
MIME body part		MCPTT Info
MIME-part-body	MCPTT-Info as described in Table 5.5.3.3-2

Table 5.5.3.3-2: MCPTT-Info in SIP SUBSCRIBE (Table 5.5.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1, condition POC-SETTINGS-EVENT

Table 5.5.3.3-3: SIP 200 (OK) from the SS (steps 2, 7, 13, Table 5.5.3.2-1; step 3, TS 36.579-1 [2] Table 5.3.29.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition SUBSCRIBE-RSP

Table 5.5.3.3-4: SIP NOTIFY from the SS (steps 2, 7, Table 5.5.3.2-1; step 4, TS 36.579-1 [2] Table 5.3.29.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1, condition POC-SETTINGS-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PoC-Settings	RFC 4354 [103]
MIME-part-body	PoC-Settings as described in Table 5.5.3.3-5

Table 5.5.3.3-5: PoC-Settings in SIP NOTIFY (Table 5.5.3.3-4)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.11.2-1, condition AUTOMATIC

Table 5.5.3.3-6: Void

Table 5.5.3.3-7: SIP SUBSCRIBE (step 12, Table 5.5.3.2-1; step 2, TS 36.579-1 [2] Table 5.3.29.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.14-1, condition POC-SETTINGS-EVENT, re_SUBSCRIBE
Information Element	Value/remark	Comment	Reference	Condition
Expires			TS 24.379 [9] clause 7.2.4
value	"0"
Message-body
MIME body part		MCPTT Info
MIME-part-body	MCPTT-Info as described in Table 5.5.3.3-2

5.6 Configuration / Download CSK

5.6.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorised for MCPTT Service }

ensure that {

when { MCPTT Client receives a CSK key download message via a SIP MESSAGE message }

then { UE (MCPTT Client) responds with a SIP 200 (OK) message and replaces the existing CSK and CSK-ID associated with the participating MCPTT function and uses the new CSK information with a SIP INVITE message when prompted to initiate a call and }

}

(2)

with { UE (MCPTT Client) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { the MCPTT User engages in communication with the invited MCPTT User(s) }

then { UE (MCPTT Client) respects the floor control imposed by the MCPTT Server and uses the updated CSK to protect the sent floor control messages }

}

(3)

with { UE (MCPTT Client) having an ongoing On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { MCPTT User requests to terminate the ongoing MCPTT Group Call }

then { UE (MCPTT Client) sends a SIP BYE message and leaves the MCPTT session }

}

5.6.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.379 clause 7.2.5, TS 33.180 clause 9.2.1.4, TS 24.380 clause 13.3.3. Unless otherwise stated these are Rel-15 requirements.

[TS 24.379, clause 7.2.5]

When the MCPTT client receives a SIP MESSAGE request containing:

1) a P-Asserted-Service header field containing the "urn:urn-7:3gpp-service.ims.icsi.mcptt"; 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 MCPTT client:

1) shall follow the security procedures in clause 9.2.1 of 3GPP TS 33.180 [78] 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 [78]. If the initiator URI deviates from the public service identity of the participating MCPTT function serving the MCPTT user, shall reject the SIP MESSAGE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [47], 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.4 and shall not continue with the rest of the steps;

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

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

ii) shall convert the public service identity of participating MCPTT function serving the MCPTT user to a UID as described in 3GPP TS 33.180 [78];

i) shall compare the generated UID with the UID in the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [78]. 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 [47], 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.4 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 [78];

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 [47], 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.4 and shall not continue with the rest of the steps;

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

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

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

[TS 33.180, clause 9.2.1.4]

The MCX Server may decide to update an existing CSK at any time. This may be due to CSK revocation or expiry.

The CSK shall be updated by the MCX Server using the ‘key download’ procedure, defined in clause 5.8. Upon receipt of a CSK via a ‘key download’ procedure, the MC client shall identify the type of key as a CSK via the 4 most significant bits of the CSK-ID. The MC client shall:

– discard any previous CSKs associated with the MC Server FQDN, and

– use the new CSK for uplink signalling with the MC Server.

[TS 24.380 clause 13.3.3]

The MCPTT client:

1. in an on-network group call of an MCPTT group which is not a constituent MCPTT group of a temporary MCPTT group:

A) if protection of media is negotiated and the GMK and the GMK-ID of the MCPTT group were received using the group document subscription and notification procedure specified in 3GPP TS 24.481 [12] for the MCPTT group:

i) shall encrypt sent media according to IETF RFC 3711 [16] and 3GPP TS 33.180 [18] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the GMK and GMK-ID as specified in subclause 13.2; and

ii) shall decrypt received media according to IETF RFC 3711 [16] and 3GPP TS 33.180 [18] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the GMK and GMK-ID as specified in subclause 13.2;

B) if protection of floor control messages sent using unicast is negotiated and the CSK and the CSK-ID were sent to the participating MCPTT function using SIP signalling according to 3GPP TS 24.379 [2]:

i) shall encrypt floor control messages sent using unicast according to IETF RFC 3711 [16] and 3GPP TS 33.180 [18] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the CSK and CSK-ID as specified in subclause 13.2; and

ii) shall decrypt floor control messages received using unicast according to IETF RFC 3711 [16] and 3GPP TS 33.180 [18] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the CSK and CSK-ID as specified in subclause 13.2;

C) if protection of floor control messages sent over the MBMS subchannel from the participating MCPTT function to the served MCPTT clients is required:

i) if a MuSiK and a MuSiK-ID are associated with the on-network group call, shall decrypt floor control messages received over the MBMS subchannel for floor control messages according to IETF RFC 3711 [16] and 3GPP TS 33.180 [14] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the MuSiK and the MuSiK-ID associated with the on-network group call as specified in subclause 13.2; and

ii) if a MuSiK and a MuSiK-ID are not associated with the on-network group call and the MKFC and the MKFC-ID of the MCPTT group were received using the group document subscription and notification procedure specified in 3GPP TS 24.481 [12] for the MCPTT group, shall decrypt floor control messages received over the MBMS subchannel for floor control messages according to IETF RFC 3711 [16] and 3GPP TS 33.180 [18] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the MKFC and MKFC-ID as specified in subclause 13.2; and

NOTE 1: The MCPTT client can receive floor control messages encrypted using SRTP-MK, SRTP-MS and SRTP-MKI generated using the MKFC and MKFC-ID from a participating MCPTT function compliant only to Release 13 of the present document.

D) if protection of media control messages sent using unicast between the participating MCPTT function and the MCPTT client is negotiated and the CSK and the CSK-ID were sent to the participating MCPTT function using SIP signalling according to 3GPP TS 24.379 [2]:

i) shall encrypt media control messages sent using unicast according to IETF RFC 3711 [16] and 3GPP TS 33.180 [18] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the CSK and CSK-ID as specified in subclause 13.2; and

ii) shall decrypt media control messages received using unicast according to IETF RFC 3711 [16] and 3GPP TS 33.180 [18] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the CSK and CSK-ID as specified in subclause 13.2;

5.6.3 Test description

5.6.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT server)

IUT:

– UE (MCPTT client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10 is inserted.

Preamble:

– The UE has performed the Generic Test Procedure for MCPTT UE registration as specified in TS 36.579-1 [2], subclause 5.4.2.

– The MCPTT User performs the Generic Test Procedure for MCPTT Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.

– UE States at the end of the preamble

– The UE is in E-UTRA Registered, Idle Mode state.

– The MCPTT Client Application has been activated and User has registered-in as the MCPTT User with the Server as active user at the Client.

5.6.3.2 Test procedure sequence

Table 5.6.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Check: Is the Generic Test Procedure for MCX SIP MESSAGE CT as described in TS 36.579-1 [2] Table 5.3.33.3-1 requesting to update the existing CSK correctly performed?.	–	–	1	–
2	Void	–	–	–	–
3	Make the MCPTT User request the establishment of an MCPTT on-demand pre-arranged group call using Group A, automatic commencement mode, with implicit floor control. (NOTE 1)	–	–	–	–
4	Check: Does the UE (MCPTT client) perform Generic Test Procedure for MCPTT CO session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.7.3-1 to establish an MCPTT on-demand pre-arranged group call, automatic commencement mode, with implicit floor control according to option b.i of NOTE 1 in TS 36.579.1 [2] Table 5.3.7.3-1, and using the updated CSK to protect the SIP INVITE message and the SIP ACK message?	–	–	1	–
5	Check: Does the UE (MCPTT client) provide floor granted notification to the MCPTT User? (NOTE 1)	–	–	2	–
6	Make the MCPTT User indicate end of talking (e.g. releasing the PTT button). (NOTE 1)	–	–	–	–
7	Check: Does the UE (MCPTT client) perform Generic Test Procedure for MCPTT Floor release – Floor Idle as described in TS 36.579-1 [2] Table 5.3.20.3-1, using the updated CSK to protect the Floor Release message?	–	–	2	–
8	Make the MCPTT User end the on-demand group call. (NOTE 1)	–	–	–	–
9	Check: Does the UE (MCPTT client) perform Generic Test Procedure for MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1 to end the on-demand group call, using the updated CSK to protect the SIP BYE message?	–	–	3	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

5.6.3.3 Specific message contents

Table 5.6.3.3-1: SIP MESSAGE (step 1, Table 5.6.3.2-1; step 2, TS 36.579-1 [2] Table 5.3.33.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.2-1
Information Element	Value/remark	Comment	Reference	Condition
P-Asserted-Service			TS 24.379 [9] clause 7.3.7
Service-ID	"urn:urn-7:3gpp-service.ims.icsi.mcptt"
Content-Type
media-type	"application/mikey"
Message-body
MIKEY message	base64 encoded MIKEY message as described in TS 36.579-1 [2], Table 5.5.9.1-1A	MIKEY message, containing the updated CSK

5.7 Configuration / Subscription to group dynamic data / De-subscribe

5.7.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { MCPTT User requests to subscribe to group dynamic data for group call ongoing information }

then { UE (MCPTT Client) sends a SIP SUBSCRIBE message to subscribe to group dynamic data for group call ongoing information }

}

(2)

with { UE (MCPTT Client) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { UE (MCPTT Client) receives a SIP NOTIFY message indicating the group call ongoing information }

then { UE (MCPTT Client) responds with a SIP 200 (OK) message }

}

(3)

with { UE (MCPTT Client) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { MCPTT User requests to de-subscribe from group dynamic data for group call ongoing information }

then { UE (MCPTT Client) sends a SIP SUBSCRIBE message to de-subscribe from group dynamic data for group call ongoing information }

}

5.7.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.379 clause 9.2.1.6. Unless otherwise stated these are Rel-15 requirements.

[TS 24.379, clause 9.2.1.6]

In order to subscribe to changes in per-group dynamic data, the MCPTT client shall generate an initial SIP SUBSCRIBE request specified in 3GPP TS 24.229 [4], IETF RFC 3856 [51], and IETF RFC 6665 [26].

In the SIP SUBSCRIBE request, the MCPTT client:

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

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

4) if the MCPTT client wants to receive the current status and later notification, shall set the Expires header field specified in IETF RFC 6665 [26], to 4294967295;

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

5) if the MCPTT client wants to fetch the current state only, shall set the Expires header field specified in IETF RFC 6665 [26], to zero;

6) shall include an Accept header field containing the application/pidf+xml MIME type; and

7) shall include an application/simple-filter+xml MIME body indicating per-group restrictions of presence event package notification information specified in clause 9.3.2, indicating the MCPTT group ID.

In order to re-subscribe or de-subscribe, the MCPTT client shall generate an in-dialog SIP SUBSCRIBE request specified in 3GPP TS 24.229 [4], IETF RFC 3856 [51], and IETF RFC 6665 [26]. In the SIP SUBSCRIBE request, the MCPTT client:

1) if the MCPTT client wants to receive the current status and later notification, shall set the Expires header field specified in IETF RFC 6665 [26], to 4294967295;

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

2) if the MCPTT client wants to de-subscribe, shall set the Expires header field specified in IETF RFC 6665 [26], to zero; and

3) shall include an Accept header field containing the application/pidf+xml MIME type.

Upon receiving a SIP NOTIFY request specified in 3GPP TS 24.229 [4], IETF RFC 3856 [51], and IETF RFC 6665 [26], if the SIP NOTIFY request contains an application/pidf+xml MIME body indicating per-group dynamic data information constructed according to clause 9.3.1, then the MCPTT client shall determine per-group dynamic data of the MCPTT group in the MIME body.

5.7.3 Test description

5.7.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT server)

IUT:

– UE (MCPTT client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10 is inserted.

Preamble:

– The UE has performed the Generic Test Procedure for MCPTT UE registration as specified in TS 36.579-1 [2], subclause 5.4.2.

– The MCPTT User performs the Generic Test Procedure for MCPTT Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.

– UE States at the end of the preamble

– The UE is in E-UTRA Registered, Idle Mode state.

– The MCPTT Client Application has been activated and User has registered-in as the MCPTT User with the Server as active user at the Client.

5.7.3.2 Test procedure sequence

Table 5.7.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Make the MCPTT User request the establishment of an MCPTT on-demand pre-arranged group call using Group A, automatic commencement mode, without implicit floor request. (NOTE 1)	–	–	–	–
2	The UE (MCPTT Client) performs Generic Test Procedure for MCPTT CO session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.7.3-1 to establish an MCPTT on-demand pre-arranged group call, automatic commencement mode, applying End-to-end communication security without implicit floor control according to option a of NOTE 1 in TS 36.579.1 [2] Table 5.3.7.3-1.	–	–	–	–
3	Void	–	–	–	–
4	Make the MCPTT User request to subscribe to group dynamic data for group call ongoing information. (NOTE 1)	–	–	–	–
5-8	Check: Does the UE (MCPTT Client) correctly perform steps 2 to 5 of Generic Test Procedure for MCPTT Subscription and Notification as described in TS 36.579-1 [2] Table 5.3.29.3-1 to subscribe to group dynamic data for group call ongoing information?	–	–	1,2	P
9	Make the MCPTT User request to de-subscribe to group dynamic data. (NOTE 1)	–	–	–	–
10-11	Check: Does the UE (MCPTT Client) correctly perform steps 2 to 3 of Generic Test Procedure for MCPTT Subscription and Notification as described in TS 36.579-1 [2] Table 5.3.29.3-1 to subscribe to group dynamic data for group call ongoing information?	–	–	3	P
12-13	Void	–	–	–	–
14	Make the MCPTT User end the on-demand group call. (NOTE 1)	–	–	–	–
15	The UE (MCPTT client) performs Generic Test Procedure for MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1 to end the on-demand group call.	–	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

5.7.3.3 Specific message contents

Table 5.7.3.3-1: SIP SUBSCRIBE from the UE (step 5, Table 5.7.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3.29.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.14-1 with conditions MCPTT, PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Expires			TS 24.379 [9] clause 9.2.1.6
value	"4294967295"
Message-body
MIME body part		MCPTT Info
MIME-part-headers
MIME-part-body	MCPTT-Info as described in Table 5.7.3.3-2
MIME body part		SIMPLE-FILTER
MIME-part-headers
MIME-part-body	SIMPLE-FILTER as described in Table 5.7.3.3-3

Table 5.7.3.3-2: MCPTT-Info in SIP SUBSCRIBE (Table 5.7.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1
Information Element	Value/remark	Comment	Reference	Condition
mcpttinfo
mcptt-Params
mcptt-request-uri	Encrypted <mcptt-request-uri> with mcpttURI set to px_MCPTT_Group_A_ID	Encrypted element as described in TS 36.579-1 [2] Table 5.5.3.2.1-1A

Table 5.7.3.3-3: SIMPLE-FILTER in SIP SUBSCRIBE (Table 5.7.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.6-1, condition PER-GROUP

Table 5.7.3.3-4: SIP NOTIFY from the SS (step 7, Table 5.8.3.2-1;
step 4, TS 36.579-1 [2] Table 5.3.29.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1 with condition PRESENCE-EVENT
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.7.3.3-5

Table 5.7.3.3-5: PIDF in SIP NOTIFY (Table 5.7.3.3-4)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1
Information Element	Value/remark	Comment	Reference	Condition
presence			TS 24.379 [9] clause 9.3.1
entity attribute	Encrypted URI (NOTE 1) with value set to px_MCPTT_Group_A_ID		TS 24.379 [9] clause 9.3.1
tuple			TS 24.379 [9] clause 9.3.1
id attribute	Encrypted URI (NOTE 1) with value set to px_MCPTT_ID_User_A		TS 24.379 [9] clause 9.3.1
status			TS 24.379 [9] clause 9.3.1
affiliation			TS 24.379 [9] clause 9.3.1
group	not present
client	Encrypted URI (NOTE 1) with value set to the mcptt-client-id as provided by the UE at registration		TS 24.379 [9] clause 9.3.1
status	not present
expires	Current time plus one hour		TS 24.379 [9] clause 9.2.2.3.10
tuple			TS 24.379 [9] clause 9.3.1
id attribute	Encrypted URI (NOTE 1) with value set to px_MCPTT_ID_User_B		TS 24.379 [9] clause 9.3.1
status			TS 24.379 [9] clause 9.3.1
affiliation			TS 24.379 [9] clause 9.3.1
group	not present
client	Encrypted URI (NOTE 1) with value set to px_MCPTT_Client_B_ID		TS 24.379 [9] clause 9.3.1
status	not present
expires	Current time plus one hour		TS 24.379 [9] clause 9.2.2.3.10
additionalData			TS 24.379 [9] clause 9.3.1
groupCallOngoing	"true"		TS 24.379 [9] clause 9.3.1
NOTE 1: Encrypted attribute as described in TS 36.579-1 [2], Table 5.5.13.3-1

Table 5.7.3.3-6: SIP SUBSCRIBE from the UE (step 10, Table 5.7.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3.29.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.14-1 with conditions MCPTT, PRESENCE-EVENT, re_SUBSCRIBE
Information Element	Value/remark	Comment	Reference	Condition
Expires			TS 24.379 [9] clause 9.2.1.6
value	"0"
Message-body
MIME body part		MCPTT Info
MIME-part-headers
MIME-part-body	MCPTT-Info as described in Table 5.7.3.3-2
MIME body part		SIMPLE-FILTER
MIME-part-headers
MIME-part-body	SIMPLE-FILTER as described in Table 5.7.3.3-3

5.8 Configuration / Functional Alias / Functional alias status determination / Activate functional alias / Deactivate functional alias

5.8.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorised for MCPTT Service }

ensure that {

when { MCPTT User requests to determine the current status of a functional alias and later notification of status changes of a functional alias }

then { UE (MCPTT Client) sends a SIP SUBSCRIBE message to determine the current status of a functional alias and later notification of status changes of a functional alias and responds to the SIP NOTIFY message with a SIP 200 (OK) message }

}

(2)

with { UE (MCPTT Client) having already subscribed to determine the status of a functional alias }

ensure that {

when { MCPTT User requests to activate a functional alias }

then { UE (MCPTT Client) sends a SIP PUBLISH message to activate a functional alias and responds to the SIP NOTIFY message with a SIP 200 (OK) message }

}

(3)

with { UE (MCPTT Client) having already subscribed to determine the status of a functional alias }

ensure that {

when { MCPTT User requests to deactivate a functional alias }

then { UE (MCPTT Client) sends a SIP PUBLISH message to deactivate a functional alias and responds to the SIP NOTIFY message with a SIP 200 (OK) message }

}

(4)

with { UE (MCPTT Client) having already subscribed to determine the status of a functional alias }

ensure that {

when { MCPTT User requests to de-subscribe from determining the status of a functional alias }

then { UE (MCPTT Client) sends a SIP SUBSCRIBE message to de-subscribe from determining the status of a functional alias and responds to the SIP NOTIFY message with a SIP 200 (OK) message }

}

5.8.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.379 clause 9A.2.1.2, 9A.2.1.3. Unless otherwise stated these are Rel-15 requirements.

[TS 24.379, clause 9A.2.1.2]

In order:

– to indicate that an MCPTT user requests to activate one or more functional aliases;

– to indicate that the MCPTT user requests to deactivate one or more functional aliases;

– to refresh indication of an MCPTT user interest in one or more functional aliases due to near expiration of the expiration time of a functional alias with the status set to the "activated" state received in a SIP NOTIFY request in subclause 9A.2.1.3; or

– any combination of the above;

the MCPTT client shall generate a SIP PUBLISH request according to 3GPP TS 24.229 [4], IETF RFC 3903 [37], and IETF RFC 3856 [51].

In the SIP PUBLISH request, the MCPTT client:

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

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

4) if the MCPTT client requests to activate one or more functional aliases, shall set the Expires header field according to IETF RFC 3903 [37], to 4294967295;

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

5) if the MCPTT client requests to deactivate one or more functional aliases, shall set the Expires header field according to IETF RFC 3903 [37], to zero; and

NOTE 2: Activation and deactivation of functional alias cannot be performed with the same PUBLISH request.

6) shall include an application/pidf+xml MIME body indicating per-user functional alias information according to subclause 9A.3.1. In the MIME body, the MCPTT client:

a) shall include all functional aliases where the MCPTT user requests activation for the MCPTT ID;

b) shall include the MCPTT client ID of the targeted MCPTT client;

c) shall not include the "status" attribute and the "expires" attribute in the <functionalalias> element;

d) if the MCPTT client has received an indication that take over of a functional alias is possible and intends to take over a functional alias, shall include a <take-over> child element set to "true"; and

e) shall set the <p-id-fa> child element of the <presence> root element to a globally unique value.

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

[TS 24.379, clause 9A.2.1.3]

NOTE 1: The MCPTT UE also uses this procedure to determine which functional alias have been successfully activated for the MCPTT ID.

In order to discover functional aliases:

1) which are activated for the MCPTT user; or

2) which another MCPTT user has activated;

the MCPTT client shall generate an initial SIP SUBSCRIBE request according to 3GPP TS 24.229 [4], IETF RFC 3856 [51], and IETF RFC 6665 [26].

In the SIP SUBSCRIBE request, the MCPTT client:

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

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

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

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

5) if the MCPTT client wants to fetch the current state only, shall set the Expires header field according to IETF RFC 6665 [26], to zero;

6) shall include an Events header field set to "presence"; and

7) shall include an Accept header field containing the application/pidf+xml MIME type.

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

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

2) if the MCPTT client wants to de-subscribe, shall set the Expires header field according to IETF RFC 6665 [26], to zero;

3) shall include an Events header field set to "presence"; and

4) shall include an Accept header field containing the application/pidf+xml MIME type.

Upon receiving a SIP NOTIFY request according to 3GPP TS 24.229 [4], IETF RFC 3856 [51], and IETF RFC 6665 [26], if SIP NOTIFY request contains an application/pidf+xml MIME body indicating per-user functional alias information constructed according to subclause 9A.3.1, then the MCPTT client shall determine the status of the MCPTT user for each functional alias in the MIME body. If the <p-id-fa> child element of the <presence> root element of the application/pidf+xml MIME body of the SIP NOTIFY request is included, the <p-id-fa> element value indicates the SIP PUBLISH request which triggered sending of the SIP NOTIFY request.

5.8.3 Test description

5.8.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT server)

– E-UTRA related parameters are set to the default parameters for the basic single cell environment, as defined in TS 36.508 [20] clause 4.4.

IUT:

– UE (MCPTT Client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10, is inserted.

Preamble:

– The UE has performed the Generic Test Procedure for MCPTT UE registration as specified in TS 36.579-1 [2], subclause 5.4.2.

– The MCPTT User performs the Generic Test Procedure for MCPTT Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.

– UE States at the end of the preamble

– The UE is in E-UTRA Registered, Idle Mode state.

– The MCPTT Client Application has been activated and User has registered-in as the MCPTT User with the Server as active user at the Client.

5.8.3.2 Test procedure sequence

Table 5.8.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Check: Does the UE (MCPTT Client) perform Generic Test Procedure for UE initiated MCPTT functional alias status determination and subscription as described in TS 36.579-1 [2] table 5.3.24.3-1 to determine the current status of a functional alias and later notification of status changes of a functional alias? NOTE: The UE (MCPTT Client) sends a SIP SUBSCRIBE message and responds to a SIP NOTIFY message and then the RRC connection is released.	–	–	1	–
2	Check: Does the UE (MCPTT Client) perform Generic Test Procedure for UE initiated MCPTT functional alias status change as described in TS 36.579-1 [2] table 5.3.25.3-1 to change the status of a functional alias to "activated"? NOTE: The UE (MCPTT Client) sends a SIP PUBLISH message and responds to a SIP NOTIFY message and then the RRC connection is released.	–	–	2	–
3	Make the MCPTT User request to change the status of a functional alias to "not activated". (NOTE 1)	–	–	–	–
3A-3E	Check: Does the UE (MCPTT Client) perform Generic Test Procedure for UE initiated MCPTT functional alias status change as described in TS 36.579-1 [2] table 5.3.25.3-1 from step 2a1 onward to change the status of a functional alias to "not activated"? NOTE: The UE (MCPTT Client) sends a SIP PUBLISH message and responds to a SIP NOTIFY message and then the RRC connection is released.	–	–	3	–
4	Make the MCPTT User request to un-subscribe from getting notification of status changes of a functional alias. (NOTE 1)
5-7	Check: Does the UE (MCPTT Client) perform Generic Test Procedure for UE initiated MCPTT functional alias status determination and subscription as described in TS 36.579-1 [2] table 5.3.24.3-1 Steps 2a1 – 4 to de-subscribe from determining the status of a functional alias?	–	–	4	–
–	EXCEPTION: The SS waits 2 seconds before the SS deactivates the dedicated EPS bearer and releases the RRC connection. (NOTE 2)	–	–	–	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI. NOTE 2: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished.

5.8.3.3 Specific message contents

Table 5.8.3.3-1: SIP PUBLISH (step 3B, Table 5.8.3.2-1; step 2, TS 36.579-1 [2] Table 5.3.25.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.3.25.4-1
Information Element	Value/remark	Comment	Reference	Condition
Expires			TS 24.379 [9] clause 9A2.1.2
value	"0"

Table 5.8.3.3-2: SIP NOTIFY (step 3D, Table 5.8.3.2-1; step 4, TS 36.579-1 [2] Table 5.3.25.4-1)

Derivation Path: TS 36.579-1 [2], Table 5.3.25.4-5
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		PIDF
MIME-part-body	PIDF as described in Table 5.8.3.3-3

Table 5.8.3.3-3: PIDF in SIP NOTIFY (Table 5.8.3.3-2)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.5.2-1, condition NOTIFY_FOR_PUBLISH (NOTE 1)

NOTE 1: PIDF contains tuple with empty <status> element (i.e. there are no <functionalAlias> entries at all) and <p-id-fa> element with value as received in the previous SIP PUBLISH.

Table 5.8.3.3-4: SIP SUBSCRIBE (step 6, Table 5.8.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.3.24.4-1
Information Element	Value/remark	Comment	Reference	Condition
Expires			TS 24.379 [9] clause 9A2.1.3
value	"0"