5 MCVideo Client Configuration

36.579-63GPPMission Critical (MC) services over LTEPart 6: Mission Critical Video (MCVideo) User Equipment (UE) Protocol conformance specificationRelease 15TS

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

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

5.1.1 Test Purpose (TP)

(1)

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

ensure that {

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

then { UE (MCVIDEO Client) performs MCVideo User Authentication }

}

(2)

with { UE (MCVIDEO Client) user authenticated }

ensure that {

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

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

}

(3)

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

ensure that {

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

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

}

(4)

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

ensure that {

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

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

}

(5)

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

ensure that {

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

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

}

(6)

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

ensure that {

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

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

}

5.1.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.482 clause 6.2.1 and Annex A.2.1.2, TS 24.484 clauses 4.2.1, 4.2.2.1, 6.2.2, 6.3.1.1, 6.3.2.1, 6.3.2.2, 6.3.3.2.1, 6.3.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.281 clauses 7.2.1, 7.2.1A, 7.2.2 and 7.2.3, TS 33.180 clauses 5.1.3.1, 5.3.3, 6.1.2, and Annex D. The following represents a copy/paste extraction of the requirements relevant to the test purpose; any references within the copy/paste text should be understood within the scope of the core spec they have been copied from. Unless otherwise stated these are Rel-14 requirements.

[TS 24.482, clause 6.2.1]

Upon an indication from the MC service client to initiate MC service user authentication, the IdM client shall perform the user authentication procedure according to 3GPP TS 33.180 [17] with the following clarifications:

1) shall establish a TLS tunnel to the authorisation endpoint of the IdM server as specified in 3GPP TS 33.180 [17] 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.483 [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.180 [17] 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.483 [11].

c) shall include the remaining required parameters as specified in 3GPP TS 33.180 [17] 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 MC service 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.180 [17] 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 MC service 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.180 [17] 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.483 [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.180 [17]; 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 MC service client.

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

The MC UE may repeat the entire procedure in this clause as needed to obtain the necessary authorisation tokens for the MC service clients, depending on the scope parameter in the Authentication Request message as specified in 3GPP TS 33.180 [17].

[TS 24.482, Annex A.2.1.2]

The HTTP client in the UE shall support the client role defined in IETF RFC 2818 [10].

The HTTP client in the UE shall support transport layer security (TLS) as specified in 3GPP TS 33.180 [17].

The HTTP client in the UE is configured with the following parameters:

1) a home HTTP proxy FQDN;

2) a home HTTP proxy port;

3) a TLS tunnel authentication method. The TLS tunnel authentication method parameter is set to one of the following:

a) one-way authentication of the HTTP proxy based on the server certificate;

b) mutual authentication based on certificates; and

c) mutual authentication based on pre-shared key;

as specified in 3GPP TS 33.180 [17];

4) if the TLS tunnel authentication method is the mutual authentication based on certificates:

a) TLS tunnel authentication X.509 certificate; and

5) if the TLS tunnel authentication method is the mutual authentication based on pre-shared key;

a) TLS tunnel authentication pre-shared key.

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 clause 6.2 and 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.180 [17]. 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.180 [17]. 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.180, Annex D.1]

This annex specifies the key management procedures between the KMS and the key management client that allows keys to be provisioned to the key management client based on an identity. It describes the requests and responses for the authorization following provisioning messages:

– KMS Initialize.

– KMS KeyProvision.

– KMS CertCache.

All KMS communications are made via HTTPS. The 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.180, clause 5.1.3.1]

This clause expands on the MCX user service authorization step shown in figure 5.1.1-1 step C.

MCX User Service Authorization is the function that validates whether or not a MCX user has the authority to access certain MCX services. In order to gain access to MCX services, the MCX client in the UE presents an access token (acquired during user authentication as described in clause 5.1.2) to each service of interest (i.e. Key Management, MCX server, Configuration Management, Group Management, etc.). If the access token is valid, then the user is granted the use of that service. Figure 5.1.3.1-1 shows the flow for user authorization which covers key management authorization, MCX user service authorization, configuration management authorization, and group management authorization.

NOTE: All HTTP traffic between the UE and HTTP proxy, and all HTTP traffic between the UE and KMS (if not going through the HTTP proxy) is protected using HTTPS.

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 one or more sets of user specific key material back to the UE KM client based on the MC service ID(s) present in the access token (MCPTT ID, MCVideo ID and/or MCVideo ID). User specific key material includes identity based key information for media and signalling protection. This key management authorisation may be repeated for each KM service the user is authorised to use (MCPTT, MCVideo, MCVideo).

For MCPTT 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.

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

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

The UE can now perform configuration management authorization and download the user profile for the service(s) (MCPTT, MCVideo, MCVideo). Following the flow described in subclause 10.1.4.3 of 3GPP TS 23.280 [36] " MC service user obtains the MC service user profile(s) from the network ", 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 identity from the access token (MCPTT ID, MCVideo ID, MCVideo ID) to obtain the user profile from the MCX user database. The CM server then sends the user profile back to the CM client over HTTP. This configuration management authorisation may be repeated for each CM service the user is authorised to use (MCPTT, MCVideo, MCVideo).

Upon receiving each user 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 profile, and following the flow shown in clause 10.1.5.2 of 3GPP TS 23.280 [36] "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 5.7 of the present document. This group management authorisation may be repeated for each GM service the user is authorised to use (MCPTT, MCVideo, MCVideo).

Figure 5.1.3.1-1: MCX user service authorization

The user authorization procedure in Step C of Figure 5.1.1-1 is further detailed into 5 sub steps that comprise the MCX user service authorization process:

Step C-1: If not already done, establish a secure HTTP tunnel using HTTPS between the MCX UE and MCX proxy server. Subsequent HTTP messaging makes use of this tunnel (with the possible exception of the KMS client to KMS server interface).

Step C-2: The KMS client in the UE presents an access token to the KMS over HTTP. The KMS authorizes the user for key management services based upon the MC service ID(s) provided and replies to the client with identity specific key information. This step may be repeated to authorise the user with additional KM services (MCPTT, MCVideo, MCVideo) as necessary.

Step C-3: The MCX client in the UE presents an access token to the MCX server over SIP as defined in clause 5.1.3.2 of the present document. This step may be repeated to authorise the user with additional MCX services (MCPTT, MCVideo, MCVideo) as necessary.

Step C-4: The CM client in the UE follows the "MCX user obtains the user profile (UE initiated)" flow from clause 10.1.4.3 of 3GPP TS 23.280 [36], presenting an access token in the Get MCX user profile request over HTTP. If the token is valid, then the CM server authorizes the user for configuration management services. Completion of this step results in the CM server providing the user’s profile to the CM client. This step may be repeated as necessary to obtain the user profile for additional services (MCPTT, MCVideo, or MCVideo).

Step C-5: The GM client in the UE follows the "Retrieve group configurations at the group management client" flow as shown in clause 10.1.5.2 of 3GPP TS 23.280 [36], presenting an access token in the Get group configuration request over HTTP. If the token is valid, the GMS authorizes the user for group management services. Completion of this step results in the GMS sending the user’s group policy information and group key information to the GM client. This step may be repeated to authorise the user for additional group services (MCPTT, MCVideo, MCVideo) as necessary.

[TS 33.180, clause 5.3.3]

The procedure for the provision of identity-specific key material when the HTTP proxy is supported between the KMS and the KMS client is described in figure 5.3.3-1. The procedure is the same whether the key management client in the MC UE, an MCX Server or a Group Management Server is making the request.

Figure 5.3.3-1: Provisioning of key material via the HTTP proxy

The procedure in figure 5.3.3-1 is now described step-by-step.

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

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

1) The key management client makes a request for user key material from the KMS. The request contains an access token to authenticate the user as defined in clause 5.1. There are three types of request (as defined in Annex D):

a) KMSInit Request. This request is the first request sent to the KMS to setup the user.

b) KMSKeyProv Request: This request is to obtain new key material from the KMS. The request may contain details of a specific identity (e.g. MCPTT ID) required for key management, and may contain a specific time for which the key material is required.

c) KMSCertCache Request: This request is to obtain external KMS certificates associated with external security domains (managed by another KMS). The request may contain details of the latest version of the cache received by the client.

2) The KMS provides a response based upon the authenticated user and the user’s request. For public safety use, the key material itself shall be encrypted using a 256-bit transport key (TrK). The response may also be signed by the TrK or the InK. The TrK and InK are initially distributed via an out-of-band mechanism along with their 32-bit identifiers, the TrK-ID and InK-ID, respectively. The responses are:

a) KMSInit Response. This response contains domain parameters and optionally, a new TrK and/or a new InK.

b) KMSKeyProv Response: This response provides new key material to the user and optionally, a new TrK.

c) KMSCertCache Response: This response contains new or updated home KMS certificates and/or external KMS certificates required by the user for communications with external security domains.

The procedure for the provisioning of identity-specific key material when the HTTP proxy is not used between the KMS and the KMS client is as described in Figure 5.3.3-2.

Figure 5.3.3-2: Provisioning of key material without a proxy

The procedure in Figure 5.3.3-2 is now described step-by-step:

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

1) The key management client makes a request to the KMS. The same requests can be made as defined above with a proxy.

2) The KMS provides a response based upon the authenticated user and the user’s request. Optionally, the key material itself may also be encrypted using a 256-bit transport key (TrK). The response may also be signed using the TrK or the InK. The TrK and InK are initially distributed via an out-of-band mechanism along with their 32-bit identifiers (TrK-ID and InK-ID respectively).

As a result of this procedure, the key management client has securely obtained key material for use within the MC system.

[TS 24.484, clause 4.2.1]

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

In order to obtain access to MC services the 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 MC UE needs to discover either:

1. the online configuration management server in the network that configures the MCS UE initial configuration MO and the default MCS user profile configuration MO(s), then the MC UE:

a) using the URI of the configuration management server obtained from the MCS UE initial configuration MO, obtains for each MCS that is enabled:

– the appropriateMCS UE configuration document;

– the appropriateMCS user profile configuration document; and

– the appropriateMC service configuration document; and

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

2. the:

a) offline configuration management server on the external device that configures the MC UE with the:

– MCS UE initial configuration MO;

– appropriate MCS UE configuration MO(s);

– appropriate MCS user profile MO(s); and

– appropriate MCS service configuration MO(s); and

b) offline group management server on the external device that configures the MC UE with the MCS group MO.

The mechanism to discover the online or offline configuration management server is dependent on the protocol used to manage and configure the MO and is out of scope of the present document.

[TS 24.484, clause 4.2.2.1]

The format of the MCS UE initial configuration MO downloaded to the MC UE during online configuration is defined in 3GPP TS 24.483 [4].

The format of the MCS group document downloaded to the MC UE during online configuration is defined in 3GPP TS 24.481 [5].

Figure 4.2.2-1 shows the MCPTT UE online configuration time sequence.

Figure 4.2.2-1 MC UE online configuration time sequence

If the MCS UE initial configuration MO has changed from the version stored in the MC UE, the updated MC UE initial configuration MO is downloaded to the MCPTT UE.

If the MCS UE initial configuration MO contains a <default-user-profile> element and the identified default MCS user profile configuration MO(s) have changed from the version stored in the MC UE, the updated default MCS user profile configuration MO(s) are downloaded to the MC UE.

NOTE 1: The default MCS user profile configuration MO(s) define the default identity(s) for the enabled mission critical service(s) and the profile of services available to the user (e.g. emergency MCPTT services) prior to user authentication.

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

The MC UE, using the identities obtained during MC user authentication, subscribes to the MCS UE configuration document, the MCS user profile configuration document and the MCS service configuration document for each enabled MCS 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 MCS group document using the procedure specified in 3GPP TS 24.481 [5]. If these documents have been updated since the current version stored in the MC UE, then the MC 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 MC UE using the notified HTTPS URI of the MCS group document is performed as specified in 3GPP TS 24.481 [5].

NOTE 2: The MC UE can be notified of changes to an configuration documents at any time while using the MCS.

[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.482 [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.483 [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.

This procedure enables the MCS 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.483 [4]; and

B) with the "auid" parameter set to the appropriate application usage identifying a configuration management document;

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.482 [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 MC client; and

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

In order to re-subscribe to notification of changes of a modified list of one or more configuration management documents; a CMC shall send a SIP re-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 SIP re-SUBSCRIBE request, the CMC:

a) if direct subscription is used, shall set the Request URI to a SIP URI containing:

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

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

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

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

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

c) if identity hiding is required, shall perform the confidentiality protection procedures and integrity protection procedures defined in 3GPP TS 24.379 [9] for MC client on the application/vnd.3gpp.mcptt-info+xml MIME body and on the application/resource-lists+xml MIME body using the CSK included in the initial SIP SUBSCRIBE request; and

d) 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.

[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 GC.

[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.482 [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 MCVideo group documents of MCVideo groups identified by MCVideo 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 MCVideo 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.281, clause 7.2.1]

When the MCVideo client performs SIP registration for service authorization the MCVideo client shall perform the registration procedures as specified in 3GPP TS 24.229 [11].

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

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

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

NOTE 1: If the MCVideo client logs off from the MCVideo service but the MCVideo UE remains registered the MCVideo UE performs a re-registration as specified in 3GPP TS 24.229 [11] without both the g.3gpp.mcvideo media feature tag and the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo" in the Contact header field of the SIP REGISTER request.

If the MCVideo client, upon performing SIP registration:

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

2) has available an access-token;

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

4) confidentiality protection is disabled as specified in subclause 6.6.2.3.1; and

5) integrity protection is disabled as specified in subclause 6.6.3.3.1;

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

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

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

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

If the MCVideo client, upon performing SIP registration:

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

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 MCVideo client:

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

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

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

b) shall encrypt the MCVideo client ID of the originating MCVideo client and include the <mcvideo-client-id> element set to the encrypted MCVideo client ID;

3) if confidentiality protection is disabled as specified in subclause 6.6.2.3.1, shall include an application/vnd.3gpp.mcvideo-info+xml MIME body as defined in Annex F.1 with:

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

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

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.mcvideo-info+xml MIME body by following the procedures in subclause 6.6.3.3.3.

[TS 24.281, clause 7.2.1A]

This procedure is only referenced from other procedures.

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

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

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

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

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

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

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

[TS 24.281, clause 7.2.2]

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

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

2) has available an access-token;

then the MCVideo client:

1) shall perform the procedures in subclause 7.2.1A;

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

3) if either confidentiality protection is enabled as specified in 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.180 [8] 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.mcvideo-info+xml MIME body with:

a) the <mcvideo-access-token> element set to the received access-token encrypted using the CSK, as specified in subclause 6.6.2.3.3; and

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

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

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

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

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

a) 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 MCVideo client according to IETF RFC 4354 [53]; and

b) the <selected-user-profile-index> element set to the value contained in the "user-profile-index" attribute of the selected MCVideo user profile as defined in 3GPP TS 24.484 [25]; 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.mcvideo-info+xml MIME body and application/poc-settings+xml MIME body by following the procedures in subclause 6.6.3.3.3.

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

[TS 24.281, clause 7.2.3]

To set, update, remove or refresh the MCVideo service settings, the MCVideo client shall generate a SIP PUBLISH request according 3GPP TS 24.229 [11], IETF RFC 3903 [12] and IETF RFC 4354 [53]. In the SIP PUBLISH request, the MCVideo 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.mcvideo-info+xml MIME body with:

a) the <mcvideo-request-uri> element set to the targeted MCVideo ID encrypted using the CSK, as specified in subclause 6.6.2.3.3; and

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

3) if confidentiality protection is disabled as specified in subclause 6.6.2.3.1, shall include an application/vnd.3gpp.mcvideo-info+xml MIME body as specified in Annex F.1 with:

a) the <mcvideo-request-uri> set to the cleartext targeted MCVideo ID; and

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

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

b) the <selected-user-profile-index> element set to the value contained in the "user-profile-index" attribute of the selected MCVideo user profile as defined in 3GPP TS 24.484 [25]; 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.mcvideo-info+xml MIME body and application/poc-settings+xml MIME body by following the procedures in subclause 6.6.3.3.3.

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

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

[TS 33.180, clause 6.1.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 MC 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

Same pre-test conditions as for MCPTT test case 5.1 (TS 36.579-2 [24]) with the following exception(s):

– The term "MCPTT" is replaced with "MCVideo"

5.1.3.2 Test procedure sequence

Same test procedure sequence as for MCPTT test case 5.1 (TS 36.579-2 [24]) with the following exception(s):

– The term "MCPTT" is replaced with "MCVideo"

5.1.3.3 Specific message contents

Same specific message contents as for MCPTT test case 5.1 (TS 36.579-2 [24]) with the following exception(s):

– The term "MCPTT" is replaced with "MCVideo"

– Condition MCVIDEO is used for all messages.

5.2 Configuration / Group Creation / Group ReGroup Creation / Group ReGroup Teardown

5.2.1 Test Purpose (TP)

(1)

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

ensure that {

when { the UE (MCVideo Client) requests formation of a new MCVideo group }

then { on successful group creation the UE (MCVideo Client) has access to the new group }

}

(2)

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

ensure that {

when { the UE (MCVideo Client) requests the groups to be combined }

then { on successful group regrouping the UE (MCVideo Client) has access to the temporary group }

}

(3)

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

ensure that {

when { the UE (MCVideo Client) requests temporary group tear down }

then { on successful group tear down the UE (MCVideo Client) removes the temporary group }

}

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, clause 7.3.2. The following represents a copy/paste extraction of the requirements relevant to the test purpose; any references within the copy/paste text should be understood within the scope of the core spec they have been copied from. Unless otherwise stated these are Rel-14 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 MCS group by combining MCS groups.

NOTE: The temporary MCS group formation procedure does not ensure that the MCSs of the temporary MCS group are the same as MCSs of each constituent MCS group of the temporary MCS group.

[TS 24.481, clause 6.3.14.2]

In order to form a temporary MCS 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 MCS 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 MCS 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 MCS group to be combined.

Upon reception of an HTTP 2xx response to the sent HTTP POST request, the GMC shall consider the temporary MCS 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 MCS group being formed with an MCS 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 MCS group.

[TS 24.481, clause 6.3.15.2]

In order to tear down a temporary MCS group, the GMC shall send an HTTP DELETE request with Request-URI with an XCAP URI identifying a group document of the temporary MCS 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.

5.2.3 Test description

5.2.3.1 Pre-test conditions

Same pre-test conditions as for MCPTT test case 5.2 (TS 36.579-2 [24]) with the following exception(s):

– The term "MCPTT" is replaced with "MCVideo"

5.2.3.2 Test procedure sequence

Same test procedure sequence as for MCPTT test case 5.2 (TS 36.579-2 [24]) with the following exception(s):

– The term "MCPTT" is replaced with "MCVideo"

5.2.3.3 Specific message contents

Same specific message contents as for MCPTT test case 5.2 (TS 36.579-2 [24]) with the following exception(s):

– The term "MCPTT" is replaced with "MCVideo"

– Condition MCVIDEO is used for all messages.

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

5.3.1 Test Purpose (TP)

(1)

with { UE (MCVideo Client) already provisioned with the group information or a pointer to the group information, that the UE (MCVideo Client) is allowed to be affiliated }

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

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

}

(2)

with { UE (MCVideo Client) already provisioned with the group information or a pointer to the group information, that the UE (MCVideo Client) is allowed to be affiliated }

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

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

}

(3)

with { UE (MCVideo Client) already provisioned with the group information or a pointer to the group information, that the UE (MCVideo Client) is allowed to be affiliated }

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

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

}

(4)

with { UE (MCVideo Client) already provisioned with the group information or a pointer to the group information that the UE (MCVideo Client) is allowed to make affiliation changes for another user }

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

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

}

(5)

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

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

}

(6)

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

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

}

(7)

with { UE (MCVideo Client) already provisioned with the group information or a pointer to the group information, that the UE (MCVideo Client) is allowed to be affiliated }

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

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

}

(8)

with { UE (MCVideo Client) already affiliated with a MCVideo group }

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

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

}

(9)

with { UE (MCVideo Client) already provisioned with the group information or a pointer to the group information, that the UE (MCVideo Client) is allowed to be affiliated }

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

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

}

5.3.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.281, clauses 8.2.1.2, 8.2.1.3, 8.2.1.4, and 8.2.1.5. The following represents a copy/paste extraction of the requirements relevant to the test purpose; any references within the copy/paste text should be understood within the scope of the core spec they have been copied from. Unless otherwise stated, these are Rel-14 requirements.

[TS 24.281, clause 8.2.1.2]

In order:

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

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

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

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

– any combination of the above;

the MCVideo client shall generate a SIP PUBLISH request according to 3GPP TS 24.229 [11], IETF RFC 3903 [12], and IETF RFC 3856 [13].

In the SIP PUBLISH request, the MCVideo client:

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

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

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

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

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

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

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

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

b) shall include the MCVideo client ID of the targeted MCVideo 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 MCVideo client shall send the SIP PUBLISH request according to 3GPP TS 24.229 [11].

[TS 24.281, clause 8.2.1.3]

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

In order to discover MCVideo groups:

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

2) which another MCVideo user is affiliated to;

the MCVideo client shall generate an initial SIP SUBSCRIBE request according to 3GPP TS 24.229 [11], IETF RFC 3856 [13], and IETF RFC 6665 [16].

In the SIP SUBSCRIBE request, the MCVideo client:

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

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

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

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

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

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

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

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

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

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

2) if the MCVideo client wants to de-subscribe, shall set the Expires header field according to IETF RFC 6665 [16], 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 [11], IETF RFC 3856 [13], and IETF RFC 6665 [16], if SIP NOTIFY request contains an application/pidf+xml MIME body indicating per-user affiliation information constructed according to subclause 8.3.1, then the MCVideo client shall determine affiliation status of the MCVideo user for each MCVideo group at the MCVideo 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.281, clause 8.2.1.4]

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

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

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

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

4) shall include an application/vnd.3gpp.mcvideo-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 [11].

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

[TS 24.281, clause 8.2.1.5]

Upon receiving a SIP MESSAGE request containing:

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

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

then the MCVideo client:

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

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

3) if the user accepts the request:

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

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

5.3.3 Test description

5.3.3.1 Pre-test conditions

Same pre-test conditions as for MCPTT test case 5.3 (TS 36.579-2 [24]) with the following exception(s):

– The term "MCPTT" is replaced with "MCVideo"

5.3.3.2 Test procedure sequence

Same test procedure sequence as for MCPTT test case 5.3 (TS 36.579-2 [24]) with the following exception(s):

– The term "MCPTT" is replaced with "MCVideo"

5.3.3.3 Specific message contents

Same specific message contents as for MCPTT test case 5.3 (TS 36.579-2 [24]) with the following exception(s):

– The term "MCPTT" is replaced with "MCVideo"

– Condition MCVIDEO is used for all messages.

5.4 Configuration / Determination of MCVideo Service Settings / Current Active MCVideo Settings / De-subscribe

5.4.1 Test Purpose (TP)

(1)

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

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

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

}

(2)

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

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

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

}

(3)

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

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

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

}

5.4.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.281 clause 7.2.4. The following represents a copy/paste extraction of the requirements relevant to the test purpose; any references within the copy/paste text should be understood within the scope of the core spec they have been copied from. Unless otherwise stated these are Rel-14 requirements.

[TS 24.281, clause 7.2.4]

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

In the SIP SUBSCRIBE request, the MCVideo client:

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

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

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

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

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

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

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

1) the <am-settings> element of the poc-settings+xml MIME body for each MCVideo client identified by the "id" attribute according to IETF RFC 4354 [53] 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 MCVideo client identified by the "id" attribute according to IETF RFC 4354 [53] as the active MCVideo user profile of that MCVideo client.

5.4.3 Test description

5.4.3.1 Pre-test conditions

Same pre-test conditions as for MCPTT test case 5.5 (TS 36.579-2 [24]) with the following exception(s):

– The term "MCPTT" is replaced with "MCVideo"

5.4.3.2 Test procedure sequence

Same test procedure sequence as for MCPTT test case 5.5 (TS 36.579-2 [24]) with the following exception(s):

– The term "MCPTT" is replaced with "MCVideo"

5.4.3.3 Specific message contents

Same specific message contents as for MCPTT test case 5.5 (TS 36.579-2 [24]) with the following exception(s):

– The term "MCPTT" is replaced with "MCVideo"

– Condition MCVIDEO is used for all messages.