5.3 Generic test procedures for UE MCS operation
36.579-13GPPMission Critical (MC) services over LTEPart 1: Common test environmentRelease 15TS
5.3.1 General
The purpose of the procedures specified in the following clauses is to facilitate test description by providing procedure sequences which can be referred from the relevant TCs specified e.g. in 3GPP TS 36.579-2 [2], 3GPP TS 36.579-3 [3], 3GPP TS 36.579-6 [84], 3GPP TS 36.579-7 [85].
The procedures specified are required to ensure that any MC service can take place or specific MC relevant pre-conditions are met before a test case can be executed.
5.3.2 MCX Authorization/Configuration and Key Generation
5.3.2.1 Initial conditions
Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.System Simulator:
– SS (MCX 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 [6] clause 4.4. The simulated Cell 1 shall belong to PLMN1 (the PLMN specified for MCX operation in the MCX configuration document).
Implementation Under Test (IUT):
– UE (MCX client)
– The MCX Client has been provisioned with the Initial UE Configuration Data as specified in clause 5.5.8.1 allowing for the location of the configuration management server for configuration of the MCX UE initial configuration management object (MO) and the default MCX user profile configuration management object (MO).
– 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 [94] 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 test USIM set as defined in clause 5.5.10 is inserted.
The UE is attached to EPS services.
– 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].
5.3.2.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.2.3 Procedures
Table 5.3.2.3-1: MCX user authentication
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
---|---|---|---|---|---|
U – S |
Message |
||||
1-2 |
Void |
– |
– |
– |
– |
– |
EXCEPTION: Depending on the UE capabilities, the UE (MCX client) executes the sequence described in Table 5.3.2.3-1A |
– |
– |
– |
– |
– |
EXCEPTION: The messages below up to and including step 7 are transmitted over a secure TLS tunnel that has been established by the UE (MCX client) as specified by 3GPP TS 33.310 [70], to the authorisation endpoint of the IdM server as specified in 3GPP TS 33.180 [94] using the configured URL of the authorisation endpoint of the IdM server as specified in the "<x>/OnNetwork/AppServerInfo/IDMSAuthEndpoint" leaf node, Table 5.5.8.1-1. |
– |
– |
– |
– |
– |
EXCEPTION: Steps 3a1-3b1 describe behaviour that depends on UE implementation of the OpenID Connect protocol; the "lower case letter" identifies a step sequence that takes place when one or the other is the case. |
– |
– |
– |
– |
3a1 |
The UE (MCX client) sends an OpenID Connect Authentication Request using HTTP GET. |
–> |
HTTP GET (Authorization) |
– |
P |
3b1 |
The UE (MCX client) sends an OpenID Connect Authentication Request using HTTP POST. |
–> |
HTTP POST (Authorization) |
– |
P |
4 |
The SS sends a HTTP 200 (OK) including the HTML form requesting username and password. |
<– |
HTTP 200 (OK) |
– |
– |
5 |
Make the UE user provide user credentials: username and password (px_MCX_User_A_username, px_MCX_User_A_password). NOTE 2 |
– |
– |
– |
– |
6 |
The UE (MCX client) sends an HTTP POST Request message to the SS containing user name and password. |
–> |
HTTP POST |
– |
P |
7 |
The SS sends a HTTP 302 (Found) as the OpenID Connect Authentication Response containing an authorization code. |
<– |
HTTP 302 (Found) |
– |
– |
8 |
Void |
– |
– |
– |
– |
– |
EXCEPTION: The messages in steps 9 to 10 are transmitted over a secure TLS tunnel that has been established by the UE (MCX client) as specified by 3GPP TS 33.310 [70] to the token endpoint of the IdM server as specified in 3GPP TS 33.180 [94] using the configured URL of the token endpoint of the IdM server as specified in the "/<x>/OnNetwork/AppServerInfo/IDMSTokenEndpoint" leaf node, Table 5.5.8.1-1. |
– |
– |
– |
– |
9 |
The UE (MCX client) sends an HTTP POST Request message to the SS (OIDC Token Request message), passing the authorization code obtained in step 7. |
–> |
HTTP POST |
– |
P |
10 |
The SS sends a HTTP 200 (OK) providing id_token, access_token and refresh token. |
<– |
HTTP 200 (OK) |
– |
– |
– |
EXCEPTION: The messages in steps 11 to 14 are transmitted over a secure TLS tunnel that has been established by the UE (MCX client) as specified by 3GPP TS 33.310 [70] to the HTTP Proxy as specified in 3GPP TS 33.180 [94] using the configured URL of the HTTP Proxy as specified in the "/<x>/OnNetwork/AppServerInfo/HTTPproxy" leaf node, Table 5.5.8.1-1. |
– |
– |
— |
|
11 |
The UE (MCX client) sends a HTTP POST message presenting the access token obtained in step 10 to the SS over HTTP for Key Management Initialisation. NOTE: Step 11 is the start of the second stage which was started in Step 2. Steps 11 through 14 involve Key Management Authorization. The MCX Client/Key Management Client presents the access token to the Key Management Server. The end result is the user gets specific key material. |
–> |
HTTP POST |
– |
P |
12 |
The SS replies to the UE with identity specific key information. |
<– |
HTTP 200 (OK) |
– |
– |
13 |
The UE (MCX client) sends a HTTP POST message presenting an access token to the SS over HTTP for Key Material Request. |
–> |
HTTP POST |
– |
P |
14 |
The SS replies to the UE with identity specific key information. |
<– |
HTTP 200 (OK) |
– |
– |
15-32 |
Void |
– |
– |
– |
– |
NOTE 1: Void. NOTE 1A: Void. NOTE 2: The UE is expected to prompt the MCX user for their username and password, or it may be stored on the UE. The provision of the username/password is expected to be done via a suitable implementation dependent MMI. |
Table 5.3.2.3-1A: MCX Initial UE Configuration Request
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The UE (MCX client) sends an HTTP GETrequestto retrieve the initial UE configuration from the Server |
–> |
HTTP GET (initial UE configuration) |
– |
P |
2 |
The SS sends a HTTP 200 (OK) including the initial UE configuration document |
<– |
HTTP 200 (OK) |
– |
– |
Table 5.3.2.3-2: MCX Service Authorization and Key Generation
St |
Procedure |
Message Sequence |
TP |
Verdict |
|||||
U – S |
Message |
||||||||
– |
EXCEPTION: In parallel to procedure of all steps below the behaviour of table 5.3.2.3-2A, the behaviour of table 5.3.2.3-2B and the behaviour of table 5.3.2.3-2C takes place. |
– |
– |
– |
– |
||||
– |
EXCEPTION: Steps 1a1-1b2 describe behaviour that depends on UE implementation; the "lower case letter" identifies a step sequence that takes place when one or the other is the case. NOTE: Step 1a1 is the start of the third stage which was started in Step 3 of table 5.3.2.3-1. Steps 1a1 and 1b1 involve User Service Authorization. |
– |
– |
– |
– |
||||
1a1 |
The UE (MCX client) sends a SIP REGISTER request for service authorisation. |
–> |
SIP REGISTER |
– |
P |
||||
1a2 |
The SS (MCX server) sends SIP 200 (OK). NOTE: The user is now authorized for MCX service. |
<– |
SIP 200 (OK) |
– |
– |
||||
1a3 |
The UE (MCX client) sends a SIP PUBLISH request for update of PoC-settings (NOTE 1). |
–> |
SIP PUBLISH |
– |
P |
||||
1a4 |
The SS (MCX server) sends SIP 200 (OK). |
<– |
SIP 200 (OK) |
– |
– |
||||
1b1 |
The UE (MCX client) sends a SIP PUBLISH request for service authorisation and update of PoC-settings (NOTE 1). |
–> |
SIP PUBLISH |
— |
P |
||||
1b2 |
The SS (MCX server) sends SIP 200 (OK). NOTE: The user is now authorized for MCX service. |
<– |
SIP 200 (OK) |
– |
|||||
NOTE 1: The PoC-settings document contains the user profile index of the selected user profile. |
Table 5.3.2.3-2A: Configuration management subscription and notification procedure
St |
Procedure |
Message Sequence |
TP |
Verdict |
||
U – S |
Message |
|||||
1 |
The UE (MCX client) sends a SIP SUBSCRIBE – subscription to multiple documents simultaneously – to the SS containing the access token and a resource list mime body containing a list of the following documents: MCX UE Configuration document, MCX User Profile Configuration Document, and the MCX Service configuration document. The base URI of each list entry is set to the CMS XCAP-ROOT-URI. NOTE: Step 1 is the start of the fourth stage which was started in Step 3 of table 5.3.2.3-1. Steps 1 through 10 involve Configuration Management Authorization. The end result of the fourth stage is that the MCX Client receives 3 configuration documents: UE Configuration Document, User Profile Configuration Document, and the Service Configuration Document. |
–> |
SIP SUBSCRIBE |
– |
P |
|
2 |
The SS sends a SIP 200 (OK) message. |
<– |
SIP 200 (OK) |
– |
– |
|
3 |
The SS sends a SIP NOTIFY message to the UE that contains the XCAP-URI of the documents. |
<– |
SIP NOTIFY |
– |
– |
|
– |
EXCEPTION: The order of steps 4, 5, 7 and 9 depends on UE and SS implementation and is not checked by the implementation |
– |
– |
– |
– |
|
4 |
The UE (MCX client) sends a SIP 200 (OK) message. |
–> |
SIP 200 (OK) |
– |
P |
|
5 |
The UE (MCX client) sends an HTTP GET Request message to the SS that contains the access token and the XCAP-URI of the MCX UE Configuration Document. NOTE: The MCX Client is requesting the MCX UE Configuration Document. |
–> |
HTTP GET |
– |
P |
|
6 |
The SS sends the HTTP 200 (OK) message including the MCX UE Configuration Document. |
<– |
HTTP 200 (OK) |
– |
– |
|
7 |
The UE (MCX client) sends an HTTP GET Request message to the SS that contains the access token and the XCAP-URI of the MCX User Profile Configuration Document. NOTE: The MCX Client is requesting the MCX User Profile Configuration Document. |
–> |
HTTP GET |
– |
P |
|
8 |
The SS sends the HTTP 200 (OK) message including the MCX User Profile Configuration Document. NOTE: The MCX User Profile Configuration Document includes information on MCX groups including for which groups the MCX Client is a member. The MCX User Profile Configuration Document includes Group A as a group for which the MCX Client is a member and is implicitly affiliated. Group A is used as the default group for all test cases in TS 36.579-2 and TS 36.579-3. |
<– |
HTTP 200 (OK) |
– |
– |
|
9 |
The UE (MCX client) sends an HTTP GET Request message to the SS that contains the access token and the XCAP-URI of the MCX Service Configuration Document. NOTE: The MCX Client is requesting the MCX Service Configuration Document. |
–> |
HTTP GET |
– |
P |
|
10 |
The SS sends the HTTP 200 (OK) message including the MCX Service Configuration Document. |
<– |
HTTP 200 (OK) |
– |
— |
Table 5.3.2.3-2B: Group document subscription and notification procedure
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The UE (MCX client) sends a SIP SUBSCRIBE to the SS, containing the access token and a resource list mime body and a list of the Groups to be obtained. The base URI of each list entry is set to the GMS XCAP-ROOT-URI, and the MCX group ID identifies a group document. NOTE: Step 1 is the start of the fifth stage which was started in Step 2 of table 5.3.2.3-1. Steps 1 through 6 involve Group Management Authorization. The end result is the MCX Client will receive group information for Group A. The MCX Client will also get the Group Master Key (GMK) for the group which will be used to derive keys for the group. There will also be a Group User Key Identifier (GUK-ID), and a Group Master Key Identifier (GMK-ID). According TS 33.180 [94], clause 7.4.1, the GMK shall be used as the MIKEY Traffic Generating Key (TGK) and the GUK-ID shall be used as the MIKEY CSB ID. These shall be used to generate the SRTP Master Key and SRTP Master Salt as specified in IETF RFC 3830 [24]. |
–> |
SIP SUBSCRIBE |
– |
P |
2 |
The SS sends a SIP 200 (OK) message. |
<– |
SIP 200 (OK) |
– |
– |
3 |
The SS sends a SIP NOTIFY message to the UE that contains the XCAP-URI of the Group documents. |
<– |
SIP NOTIFY |
– |
– |
– |
EXCEPTION: The order of steps 4 and 5 depends on UE and SS implementation and is not checked by the implementation |
– |
– |
– |
– |
4 |
The UE (MCX client) sends a SIP 200 (OK) message. |
–> |
SIP 200 (OK) |
– |
P |
5 |
The UE (MCX client) sends an HTTP GET Request message to the SS that contains the access token and the XCAP-URI of the Group Configuration document. |
–> |
HTTP GET |
– |
P |
6 |
The SS sends the HTTP 200 (OK) message including the Group Document ‘MCX UE Configuration document’. NOTE 1 |
<– |
HTTP 200 (OK) |
– |
– |
– |
EXCEPTION: Steps 7a1-7a2 describe behaviour that depends on UE implementation; the "lower case letter" identifies a step sequence that takes place when one or the other is the case. |
– |
– |
||
7a1 |
IF the Resource-Lists received from the UE at step 1 contains an entry referring to an MCX-GKTP document THEN the SS sends a SIP NOTIFY message to the UE containing the group key transport payloads (GKTP) document. |
<– |
SIP NOTIFY |
||
7a2 |
The UE (MCX client) sends a SIP 200 (OK) message. |
–> |
SIP 200 (OK) |
||
NOTE 1: This completes MCX service enabling on the UE. |
Table 5.3.2.3-2C: Group communication key retrieval procedure
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS starts timer Timer_1 = 5 seconds. |
– |
– |
– |
– |
– |
EXCEPTION: Steps 2a5-3a1 describe behaviour that depends on UE implementation; the "lower case letter" identifies a step sequence that takes place when one or the other is the case. |
– |
– |
– |
– |
2a1 |
The UE (MCX client) sends a SIP SUBSCRIBE to the SS, creating a new dialog and containing the access token and a resource list mime body containing an entry to request group key transport payloads (GKTP) document. |
–> |
SIP SUBSCRIBE |
– |
P |
2a2 |
The SS sends a SIP 200 (OK) message |
<– |
SIP 200 (OK) |
– |
– |
2a3 |
The SS sends a SIP NOTIFY message to the UE containing the group key transport payloads (GKTP) document. |
<– |
SIP NOTIFY |
– |
– |
2a4 |
The UE (MCX client) sends a SIP 200 (OK) message. |
–> |
SIP 200 (OK) |
– |
P |
2a5 |
The SS stops Timer_1. |
– |
– |
– |
– |
2b1 |
Timer_1 expires |
– |
– |
||
NOTE: This key retrieval from the GMS is necessary for the MCX UE under test to enable ciphering exchanged media in group communications. |
5.3.2.4 Specific message contents
Table 5.3.2.4-1: HTTP GET (Step 3a1, Table5.3.2.3-1 )
Derivation Path: Table 5.5.4.2-1, condition AUTH |
Table 5.3.2.4-2: HTTP POST (Step 3b1, Table 5.3.2.3-1)
Derivation Path: Table 5.5.4.3-1, condition AUTH |
Table 5.3.2.4-3: HTTP 200 (OK) (Step 4, Table 5.3.2.3-1)
Derivation Path: Table 5.5.4.6-1 |
||||
Information Element |
Value/remark |
Comment |
Reference |
Condition |
Content-Type |
||||
media-type |
"text/html" |
RFC 2854 [111] |
||
Message-body |
||||
HTML form |
<!DOCTYPE html> <html> <body> <form action="/idms/userauth" method="post"> Username: <input type="text" name="user"><br> Password: <input type="password" name="password"><button type="submit">Login</button> </form> </body> </html> |
"/idms/userauth" given by tsc_MCX_IdMS_userauth_UriPath is the URI to be used by the UE as request URI in the HTTP POST request for user authentication |
HTML 4.01 Specification [105] |
Table 5.3.2.4-4: HTTP POST (Step 6, Table 5.3.2.3-1)
Derivation Path: Table 5.5.4.3-1, condition USERAUTH |
Table 5.3.2.4-5: HTTP 302 (Found) (Step 7, Table 5.3.2.3-1)
Derivation Path: Table 5.5.4.8-1, condition AUTH. |
Table 5.3.2.4-6: HTTP POST (Step 9, Table 5.3.2.3-1)
Derivation Path: Table 5.5.4.3-1, condition TOKEN |
Table 5.3.2.4-7: HTTP 200 (OK) (Step 10, Table 5.3.2.3-1)
Derivation Path: Table 5.5.4.6-1, condition TOKEN |
Table 5.3.2.4-8: HTTP POST (Step 11, Table 5.3.2.3-1)
Derivation Path: Table 5.5.4.33-1, condition KMSINIT. |
Table 5.3.2.4-9: HTTP 200 (OK) (Step 12, Table 5.3.2.3-1)
Derivation Path: Table 5.5.4.6-1, condition KMSINIT. |
Table 5.3.2.4-10: HTTP POST (Step 13, Table 5.3.2.3-1)
Derivation Path: Table 5.5.4.3-1, condition KMSKEY. |
Table 5.3.2.4-11: HTTP 200 (OK) (Step 14, Table 5.3.2.3-1)
Derivation Path: Table 5.5.4.6-1, condition KMSKEY. |
Table 5.3.2.4-12: SIP REGISTER (Step 1a1, Table 5.3.2.3-2)
Derivation Path: Table 5.5.2.13-1, condition CONFIG |
Table 5.3.2.4-13: SIP PUBLISH (Step 1b1, Table 5.3.2.3-2)
Derivation Path: Table 5.5.2.11-1, condition CONFIG |
Table 5.3.2.4-13A: SIP PUBLISH (Step 1a3, Table 5.3.2.3-2)
Derivation Path: Table 5.5.2.11-1, condition POC-SETTINGS-EVENT |
Table 5.3.2.4-14: SIP SUBSCRIBE (Step 1, Table 5.3.2.3-2A)
Derivation Path: Table 5.5.2.14-1, condition CONFIG |
Table 5.3.2.4-15: SIP NOTIFY (Step 3, Table 5.3.2.3-2A)
Derivation Path: Table 5.5.2.8-1, condition CONFIG |
Table 5.3.2.4-16: HTTP GET (Step 5, Table 5.3.2.3-2A)
Derivation Path: Table 5.5.4.2-1, condition UECONFIG. |
Table 5.3.2.4-17: HTTP GET (Step 7, Table 5.3.2.3-2A)
Derivation Path: Table 5.5.4.2-1, condition UEUSERPROF. |
Table 5.3.2.4-18: HTTP GET (Step 9, Table 5.3.2.3-2A)
Derivation Path: Table 5.5.4.2-1, condition UESERVCONFIG. |
Table 5.3.2.4-19: HTTP 200 (OK) (Step 6, Table 5.3.2.3-2A)
Derivation Path: Table 5.5.4.6-1, condition UECONFIG. |
Table 5.3.2.4-20: HTTP 200 (OK) (Step 8, Table 5.3.2.3-2A)
Derivation Path: Table 5.5.4.6-1, condition UEUSERPROF. |
Table 5.3.2.4-21: HTTP 200 (OK) (Step 10, Table 5.3.2.3-2A)
Derivation Path: Table 5.5.4.6-1, condition UESERVCONFIG. |
Table 5.3.2.4-22: SIP SUBSCRIBE (Step 1, Table 5.3.2.3-2B)
Derivation Path: Table 5.5.2.14-1, condition GROUPCONFIG |
Table 5.3.2.4-22A: Void
Table 5.3.2.4-22B: SIP NOTIFY (Step 3, Table 5.3.2.3-2B)
Derivation Path: Table 5.5.2.8-1, condition GROUPCONFIG |
Table 5.3.2.4-23: HTTP GET (Step 5, Table 5.3.2.3-2B)
Derivation Path: Table 5.5.4.2-1, condition GROUPCONFIG |
Table 5.3.2.4-24: HTTP 200 (OK) (Step 6, Table 5.3.2.3-2B)
Derivation Path: Table 5.5.4.6-1, condition GROUPCONFIG. |
Table 5.3.2.4-25: Void
Table 5.3.2.4-26: SIP 200 (OK) (Steps 1a2, 1a4, 1b2, Table 5.3.2.3-2, step 2, Table 5.3.2.3-2A, step 2, Table 5.3.2.3-2B)
Derivation Path: Table 5.5.2.17.1.2-1 |
Table 5.3.2.4-27: SIP 200 (OK) (Step 4, Table 5.3.2.3-2A, step 4, Table 5.3.2.3-2B)
Derivation Path: Table 5.5.2.17.1.1-1 |
Table 5.3.2.4-28: HTTP GET (Step 1, Table 5.3.2.3-1A)
Derivation Path: Table 5.5.4.2-1, condition UEINITIALCONFIG |
Table 5.3.2.4-29: HTTP 200 (OK) (Step 2, Table 5.3.2.3-1A)
Derivation Path: Table 5.5.4.6-1, condition UEINITIALCONFIG |
Table 5.3.2.4-30: SIP SUBSCRIBE (Step 1, Table 5.3.2.3-2C)
Derivation Path: Table 5.5.2.14-1, condition GROUPCONFIG |
||||
Message-body |
||||
MIME body part |
Resource-lists |
|||
MIME-part-headers |
||||
Content-Type |
"application/resource-lists+xml" |
|||
MIME-part-body |
Resource-lists as described in Table 5.3.2.4-31 |
Table 5.3.2.4-31: Resource-Lists in SIP SUBSCRIBE (Table 5.3.2.4-30)
Derivation Path: Table 5.5.3.3.1-1 condition GROUPKEY |
Table 5.3.2.4-32: SIP NOTIFY (Step 7a, Table 5.3.2.3-2B and Step 3, Table 5.3.2.3-2C)
Derivation Path: Table 5.5.2.14-1, condition GROUPCONFIG |
||||
Message-body |
||||
xcap-diff document |
xcap-diff document as described in Table 5.3.2.4-33 |
Table 5.3.2.4-33: Xcap-Diff Document (Table 5.3.2.4-32)
Derivation Path: Table5.5.3.12-2, condition GROUPKEY |
5.3.2A – 5.3.2B Void
5.3.3 MCX pre-established session establishment CO
5.3.3.1 Initial conditions
Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.
System Simulator:
– SS (MCX 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 [6] clause 4.4. The simulated Cell 1 shall belong to PLMN1 (the PLMN specified for MCX operation in the MCX configuration document)
IUT:
– UE (MCX client)
– The UE has performed the procedure for MCX Authorization/Configuration and Key Generation as specified in clause 5.3.2 and thereby the MCX client is authorised for and able to use the MCX service including making group and private calls on- and off-network, and, the MCX user is registered for receiving MCX service through the MCX Client.
5.3.3.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.3.3 Procedure
Table 5.3.3.3-1: MCX pre-established session establishment CO
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Void |
– |
– |
– |
– |
1A |
EXCEPTION: The E-UTRA/EPC actions which are related to the MCX call establishment as described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place. |
– |
– |
– |
– |
2-7 |
Void |
– |
– |
– |
– |
8 |
Check: Does the UE (MCX Client) send a SIP INVITE message in order to create a pre-established session? |
–> |
SIP INVITE |
– |
P |
8A |
The SS sends SIP 100 Trying |
<– |
SIP 100 Trying |
– |
– |
9 |
Void |
– |
– |
– |
– |
10 |
The SS (MCX server) responds with a SIP 200 (OK) message. |
<– |
SIP 200 (OK) |
– |
– |
10A |
Check: Does the UE (MCX Client) respond with a SIP ACK message? |
–> |
SIP ACK |
– |
P |
11 |
Void |
– |
– |
– |
– |
11A |
The SS waits 2 seconds to ensure that lower layer signalling (TCP) is finished. |
– |
– |
– |
– |
12 |
The SS transmits an RRCConnectionRelease message. |
<– |
RRC: RRCConnectionRelease |
– |
– |
5.3.3.4 Specific message contents
Table 5.3.3.4-1: SIP INVITE (step 8, Table 5.3.3.3-1)
Derivation Path: Table 5.5.2.5.1-1 |
||||
Information Element |
Value/remark |
Comment |
Reference |
Condition |
Contact |
RFC 3261 [22 RFC 3840 [33] |
|||
feature-param |
"+g.3gpp.mcptt" |
This media feature tag when used in a SIP request or a SIP response indicates that the function sending the SIP message supports Mission Critical Push To Talk (MCPTT) communication. |
||
feature-param |
"audio" |
This feature tag indicates that the device supports audio as a streaming media type. |
||
Accept |
RFC 3261 [22] |
|||
media-range[1] |
"application/sdp” |
|||
Answer-Mode |
not present |
|||
Content-Type |
||||
media-type |
"application/sdp" |
|||
Message-body |
||||
SDP Message |
SDP message as described in Table 5.5.3.1.1-1 with conditions PRE_ESTABLISHED_SESSION, INITIAL_SDP_OFFER |
Table 5.3.3.4-2: SIP 200 (OK) (step 10, Table 5.3.3.3-1)
Derivation Path: Table 5.5.2.17.1.2-1 with 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 |
5.3.3A Void
5.3.4 MCX CT session establishment/modification without provisional responses other than 100 Trying
5.3.4.1 Initial conditions
As specified in the test case which calls the procedure in its entirety or refers to parts of it.
Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.
5.3.4.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.4.3 Procedure
Table 5.3.4.3-1: MCX CT session establishment/modification without provisional responses other than 100 Trying
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Step 1a1 describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called. |
– |
– |
– |
– |
1a1 |
IF in RRC_IDLE state, the E-UTRA/EPC actions which are related to the MCX call establishment as described in clause 5.4.4 ‘Generic Test Procedure for MCX CT communication in E-UTRA’ take place. |
– |
– |
– |
– |
2 |
The SS (MCX Server) sends a SIP INVITE requesting the establishment/modification of an MCX call. |
<– |
SIP INVITE |
– |
– |
– |
EXCEPTION: Step 3a1 describes behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that take place if the UE responds to a SIP INVITE with a SIP 100 (Trying). |
– |
– |
– |
– |
3a1 |
The UE (MCX client) sends SIP 100 (Trying) |
–> |
SIP 100 (Trying) |
– |
– |
4 |
Check: Does the UE (MCX client) respond to the SIP INVITE with SIP 200 (OK)? |
–> |
SIP 200 (OK) |
– |
P |
5 |
The SS (MCX server) sends a SIP ACK to acknowledge the session establishment/modification |
<– |
SIP ACK |
– |
– |
5.3.4.4 Specific message contents
All message contents are as specified in clause 5.5 with the following clarifications:
none
Table 5.3.4.4-1: Void
5.3.5 MCX CT group call establishment, manual commencement
5.3.5.1 Initial conditions
As specified in the test case which calls the procedure in its entirety or refers to parts of it.
Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.
5.3.5.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.5.3 Procedure
Table 5.3.5.3-1: MCX CT group call establishment, manual commencement
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Steps 1a1describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called. |
– |
– |
– |
– |
1a1 |
IF in RRC_IDLE state, the E-UTRA/EPC actions which are related to the MCX call establishment described in clause 5.4.4 ‘Generic Test Procedure for MCX CT communication in E-UTRA’ take place. |
– |
– |
– |
– |
2 |
The SS (MCX Server) sends an initial SIP INVITE requesting the establishment of an MCX group call. |
<– |
SIP INVITE |
– |
– |
– |
EXCEPTION: Step 3a1 describes behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that take place if the UE responds to a SIP INVITE with a SIP 100 (Trying) |
– |
– |
– |
– |
3a1 |
The UE (MCX client) sends SIP 100 (Trying). |
–> |
SIP 100 (Trying) |
– |
– |
4 |
The SS starts timer Timer_1 = 5 seconds. |
– |
– |
– |
– |
– |
EXCEPTION: Steps 5a1 to 5c1 describe behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that may take place if the UE responds reliably or unreliably to a SIP INVITE with a SIP 183 (Session Progress) |
– |
– |
– |
– |
5a1 |
Check: Does the UE (MCX client) send SIP 183 (Session Progress) unreliably? |
–> |
SIP 183 (Session Progress) |
– |
P |
5a2 |
The SS stops Timer_1. |
– |
– |
– |
– |
5b1 |
Check: Does the UE (MCX client) send SIP 183 (Session Progress) reliably? |
–> |
SIP 183 (Session Progress) |
– |
P |
5b2 |
The SS stops Timer_1. |
– |
– |
– |
– |
5b3 |
The SS (MCX Server) acknowledges the receipt of SIP 183 (Session Progress) |
<– |
PRACK |
– |
– |
5b4 |
The UE (MCX Client) responds PRACK with SIP 200 (OK) |
–> |
SIP 200 (OK) |
– |
– |
5c1 |
Check: Does Timer_1 expire? |
– |
– |
– |
P |
5A |
Check: Does the UE (MCX client) notify the User of the incoming call request? (NOTE 1) |
– |
– |
– |
P |
6 |
Make UE (MCX User) accept the call (NOTE 1) |
– |
– |
– |
– |
7 |
Check: Does the UE (MCX client) respond to the SIP INVITE with SIP 200 (OK)? |
–> |
SIP 200 (OK) |
– |
P |
8 |
The SS (MCX server) sends a SIP ACK to acknowledge the session establishment |
<– |
SIP ACK |
– |
– |
NOTE 1: This expected to be done via a suitable implementation dependent MMI. |
5.3.5.4 Specific message contents
All message contents are as specified in clause 5.5 with condition GROUP-CALL where applicable and with the following clarifications:
Table 5.3.5.4-1 to 3: Void
5.3.6 MCX CT private call establishment, manual commencement
5.3.6.1 Initial conditions
The same initial conditions apply as specified in clause 5.3.3.1.
Within the context of this procedure, MCX refers to MCPTT or MCVideo
5.3.6.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.6.3 Procedure
Table 5.3.6.3-1: MCX CT private call establishment, manual commencement
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Step 1a1 describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called. |
– |
– |
– |
– |
1a1 |
IF in RRC_IDLE state, the E-UTRA/EPC actions which are related to the MCX call establishment described in clause 5.4.4 ‘Generic Test Procedure for MCX CT communication in E-UTRA’ take place. |
– |
– |
– |
– |
2 |
The SS (MCX Server) sends an initial SIP INVITE requesting the establishment of an MCX private call. |
<– |
SIP INVITE |
– |
– |
– |
EXCEPTION: Step3a1 describes behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that take place if the UE responds to a SIP INVITE with a SIP 100 (Trying) |
– |
– |
– |
– |
3a1 |
The UE (MCX client) sends SIP 100 (Trying). |
–> |
SIP 100 (Trying) |
– |
– |
– |
EXCEPTION: Steps 4a1 to 4b3 describe behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that takes place if the UE responds either unreliably or reliably to a SIP INVITE with a SIP 180 (Ringing) |
– |
– |
– |
– |
4a1 |
Check: Does the UE (MCX client) send a SIP 180 (Ringing) unreliably? |
–> |
SIP 180 (Ringing) |
– |
P |
4b1 |
Check: Does the UE (MCX client) send a SIP 180 (Ringing) reliably? |
–> |
SIP 180 (Ringing) |
– |
P |
4b2 |
The SS (MCX Server) acknowledges the receipt of SIP 180 (Ringing) |
<– |
PRACK |
– |
– |
4b3 |
The UE (MCX Client) responds PRACK with SIP 200 (OK) |
–> |
SIP 200 (OK) |
– |
– |
4A |
Check: Does the UE (MCX client) notify the User of the incoming call request? (NOTE 1) |
– |
– |
– |
P |
5 |
Make UE (MCX User) accept the call |
– |
– |
– |
– |
6 |
Check: Does the UE (MCX client) respond to the SIP INVITE with SIP 200 (OK)? |
–> |
SIP 200 (OK) |
– |
P |
7 |
The SS (MCX server) sends a SIP ACK to acknowledge the session establishment |
<– |
SIP ACK |
– |
– |
NOTE 1: This expected to be done via a suitable implementation dependent MMI. |
5.3.6.4 Specific message contents
All message contents are as specified in clause 5.5 with condition PRIVATE-CALL where applicable and in the test case calling the procedure, with the following clarifications:
Table 5.3.6.4-1 to 1A: Void
Table 5.3.6.4-2: SIP 180 (Ringing) (step 4b1, Table 5.3.6.3-1)
Derivation Path: Table 5.5.2.16.2.1-1 with condition 100rel |
Table 5.3.6.4-3: Void
5.3.7 to 5.3.9 Void
5.3.10 MCX CO call release
5.3.10.1 Initial conditions
As specified in the test case which calls the procedure.
Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.
5.3.10.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.10.3 Procedure
Table 5.3.10.3-1: MCX CO call release
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Check: Does the UE (MCX Client) send a SIP BYE request to terminate the MCX session? |
–> |
SIP BYE |
– |
P |
2 |
The SS (MCX Server) responds with a SIP 200 (OK) message? |
<– |
SIP 200 (OK) |
– |
– |
3 |
The SS waits 2 seconds before the SS deactivates the dedicated EPS bearer and releases the RRC connection. NOTE: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished and any not allowed behaviour captured. |
– |
– |
– |
– |
5.3.10.4 Specific message contents
All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:
none
5.3.11 Void
5.3.12 MCX CT call release
5.3.12.1 Initial conditions
As specified in the test case which calls the procedure.
Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.
5.3.12.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.12.3 Procedure
Table 5.3.12.3-1: MCX CT call release
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS (MCX Server) sends a SIP BYE request to terminate the MCX session. |
<– |
SIP BYE |
– |
– |
2 |
Check: Does the UE (MCX Client) respond with a SIP 200 (OK) message? |
–> |
SIP 200 (OK) |
– |
P |
3 |
The SS waits 2 seconds before the SS deactivates the dedicated EPS bearer and releases the RRC connection. NOTE: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished. |
– |
– |
– |
– |
5.3.12.4 Specific message contents
All message contents are as specified in clause 5.5. and in the test case calling the procedure, with the following clarifications:
none
5.3.13 – 21 Void
5.3.22 MCX NW initiated notifications regarding temporary group creation or tear down
5.3.22.1 Initial conditions
As specified in the test case which calls the procedure in its entirety or refers to parts of it.
Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.
5.3.22.2 Definition of system information messages
–
5.3.22.3 Procedure
Table 5.3.22.3-1: MCX NW initiated notifications regarding temporary group creation or tear down
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS (MCX server) sends a SIP NOTIFY to the UE informing about change of group A’s configuration document. |
<– |
SIP NOTIFY |
– |
– |
2 |
The UE sends a SIP 200 (OK) message to the SS. |
–> |
SIP 200 (OK) |
– |
– |
2A-2F |
Void |
– |
– |
– |
– |
3 |
The UE (MCX client) sends an HTTP GET Request message to the SS that contains the access token and the XCAP-URI of the Group Configuration document. |
–> |
HTTP GET |
– |
– |
4 |
The SS (MCX server) sends the HTTP 200 (OK) message including the updated Group Document |
<– |
HTTP 200 (OK) |
– |
– |
5 |
The SS (MCX server) sends a SIP NOTIFY message to the UE containing the group key transport payloads (GKTP) document including the group keys. |
<- |
SIP NOTIFY |
– |
– |
5a1-5a2 |
Void |
– |
– |
– |
– |
6 |
The UE (MCX client) sends a SIP 200 (OK) message. |
–> |
SIP 200 (OK) |
– |
– |
5.3.22.4 Specific message contents
All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:
Table 5.3.22.4-1: SIP NOTIFY (Step 1)
Derivation Path: Table 5.5.2.8-1, condition GROUPCONFIG |
|||||
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Message-body |
|||||
MIME body part |
xcap-diff |
||||
MIME-part-body |
Xcap-diff as described in Table 5.3.22.4-1A |
Table 5.3.22.4-1A: Xcap-diff document in SIP NOTIFY (Table 5.3.22.4-1)
Derivation Path: Table 5.5.3.12-2, condition GROUPCONFIG |
Table 5.3.22.4-2: SIP 200 (OK) (Steps 2, 6)
Derivation Path: Table 5.5.2.17.1.1-1 |
Table 5.3.22.4-2A..2G: Void
Table 5.3.22.4-3: HTTP GET (Step 3)
Derivation Path: Table 5.5.4.2-1, condition GROUPCONFIG |
Table 5.3.22.4-4: HTTP 200 (OK) (Step 4)
Derivation Path: Table 5.5.4.6-1, condition GROUPCONFIG |
||||
Information Element |
Value/remark |
Comment |
Reference |
Condition |
Message-body |
||||
group-configuration |
As described in Table 5.3.22.4-5 |
Group Configuration document returned |
Table 5.3.22.4-5: Group Configuration document (Table 5.3.22.4-4)
Derivation Path: Table 5.5.7.4-2 |
||||
---|---|---|---|---|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
list-service[1] |
||||
mcpttgi:on-network-regrouped |
TS 24.481 [31] clause 7.2.4.2 |
TEMPGROUPCREATE |
||
temporary-MCPTT-group-ID attribute |
px_MCPTT_Group_T_ID |
MCS temporary group identity |
TS 24.481 [31] clause 7.2.4.2 |
MCPTT |
px_MCVideo_Group_T_ID |
MCVIDEO |
|||
px_MCData_Group_T_ID |
MCDATA |
|||
temporary-MCPTT-group-requestor attribute |
px_MCPTT_ID_User_B |
Identity of the responsible for formatting the MCS temporary group. |
TS 24.481 [31] clause 7.2.4.2 |
MCPTT |
px_MCVideo_ID_User_B |
MCVIDEO |
|||
px_MCData_ID_User_B |
MCDATA |
|||
constituent-MCPTT-group-IDs |
TS 24.481 [31] clause 7.2.4.2 |
|||
constituent-MCPTT-group-ID[1] |
px_MCPTT_Group_A_ID |
MCS group ID of a constituent MCS group of the temporary MCS group |
TS 24.481 [31] clause 7.2.4.2 |
MCPTT |
px_MCVideo_Group_A_ID |
MCVIDEO |
|||
px_MCData_Group_A_ID |
MCDATA |
|||
constituent-MCPTT-group-ID[1] |
px_MCPTT_Group_B_ID |
MCS group ID of a constituent MCS group of the temporary MCS group |
TS 24.481 [31] clause 7.2.4.2 |
MCPTT |
px_MCVideo_Group_B_ID |
MCVIDEO |
|||
px_MCData_Group_B_ID |
MCDATA |
|||
protect-media |
"true" |
Indicates whether confidentiality and integrity of media is required on the MCPTT temporary group |
TS 24.481 [31] clause 7.2.4.2 |
|
protect-floor-control-signalling |
"true" |
Indicates whether confidentiality and integrity of floor control signalling is required on the temporary MCPTT group |
TS 24.481 [31] clause 7.2.4.2 |
Condition |
Explanation |
TEMPGROUPCREATE |
Procedure is used for creation of a temporary group (but not for tear down) |
Table 5.3.22.4-5A: Void
Table 5.3.22.4-6: SIP NOTIFY (Step 5)
Derivation Path: Table 5.5.2.14-1, condition GROUPCONFIG |
||||
Message-body |
||||
xcap-diff document |
xcap-diff document as described in Table 5.3.22.4-7 |
Table 5.3.22.4-7: xcap-diff document for MCX group configuration (Table5.3.22.4-6)
Derivation Path: Table 5.5.3.12-2, condition GROUPKEY |
||||
Information Element |
Value/remark |
Comment |
Reference |
Condition |
xcap-diff |
encrypted according to NOTE 1 of Table 5.5.3.12-2 |
|||
element[1] |
||||
sel attribute |
Doc-Sel & "~~" & Node-Sel |
Document and node selector for Group T according to NOTEs 2a, 2b and 3 of Table 5.5.3.12-2 |
||
GKTPs |
group key transport payloads (GKTP) document as described in Table 5.3.22.4-8 |
Table 5.3.22.4-8: group key transport payloads (GKTP) document (Table 5.3.22.4-7)
Derivation Path: TS 24.481 [11] clause 7.7 |
||||
Information Element |
Value/remark |
Comment |
Reference |
Condition |
GKTPs |
||||
GMK-GKTPs |
||||
GKTP[1] |
MIKEY message as used in group communication key retrieval procedure |
MIKEY message containing the GMK for Group A |
TS 33.180 [94] |
|
id attribute |
Same value as used in group communication key retrieval procedure |
|||
on-network-regrouped-GKTPs[1] |
TEMPGROUPCREATE |
|||
temporary-MCPTT-group-ID attribute |
px_MCPTT_Group_T_ID |
MCPTT |
||
px_MCVideo_Group_T_ID |
MCVIDEO |
|||
px_MCData_Group_T_ID |
MCDATA |
|||
GKTP[1] |
MIKEY message as described in Table 5.3.22.4-9 |
MIKEY message containing the GMK for Group T |
TS 33.180 [94] |
|
id attribute |
arbitrary value |
unique charstring assigned by the SS |
Condition |
Explanation |
TEMPGROUPCREATE |
Procedure is used for creation of a temporary group (but not for tear down) |
Table 5.3.22.4-9: MIKEY-SAKKE I_MESSAGE (GMK distribution by the SS) (Table 5.3.22.4-8)
Derivation Path: Table 5.5.9.1-3 |
|||
---|---|---|---|
Field |
Value/remark |
Comment |
Condition |
General Extension Payload { |
|||
Content { |
|||
Payload { |
|||
Data { |
See TS 33.180 [94] clause E.6 |
||
Group IDs { |
|||
Number of Group IDs |
‘1’ |
||
Group ID |
px_MCPTT_Group_T_ID |
The ID for the group associated with the key. |
MCPTT |
px_MCVideo_Group_T_ID |
MCVIDEO |
||
px_MCData_Group_T_ID |
MCDATA |
||
} |
|||
} |
|||
} |
|||
..} |
|||
} |
5.3.23 – 25 Void
5.3.26 MCX CO Group Creation
5.3.26.1 Initial conditions
As specified in the test case which calls the procedure.
Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.
5.3.26.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.26.3 Procedure
Table 5.3.26.3-1: MCX CO Group Creation procedure
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1a1-1a2 |
Void |
– |
– |
– |
– |
1 |
Check: Does the UE (MCX Client) send a HTTP PUT to the SS to request for creation of the new group? |
–> |
HTTP PUT |
– |
P |
2 |
The SS (MCX Server) sends a HTTP 201 (Created). |
<– |
HTTP 201 (Created) |
– |
– |
3-5 |
Void |
5.3.26.4 Specific message contents
All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:
none
Table 5.3.26.4-1 to -5: Void
5.3.27 MCX CO Temporary Group Creation
5.3.27.1 Initial conditions
As specified in the test case which calls the procedure.
Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.
5.3.27.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.27.3 Procedure
Table 5.3.27.3-1: MCX CO Temporary Group Creation procedure
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Check: Does the UE (MCX Client) send a HTTP POST to the SS to request for creation of a temporary group? |
–> |
HTTP POST |
– |
P |
2 |
The SS (MCX Server) sends a HTTP 200 (OK) containing the GMOP group-regroup-creation-response. |
<– |
HTTP 200 (OK) |
– |
– |
5.3.27.4 Specific message contents
All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:
none
Table 5.3.27.4-1 to -2: Void
5.3.28 MCX CO Temporary Group Tear Down
5.3.28.1 Initial conditions
As specified in the test case which calls the procedure.
Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.
5.3.28.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.28.3 Procedure
Table 5.3.28.3-1: MCX CO Temporary Group Creation procedure
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Check: Does the UE (MCX Client) send a HTTP DELETE to the SS to request for tear down of a temporary group? |
–> |
HTTP DELETE |
– |
P |
2 |
The SS (MCX Server) sends a HTTP 200 (OK). |
<– |
HTTP 200 (OK) |
– |
– |
5.3.28.4 Specific message contents
All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:
None
Table 5.3.28.4-1: Void
5.3.29 MCX Subscription and Notification
5.3.29.1 Initial conditions
As specified in the test case which calls the procedure in its entirety or refers to parts of it.
Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.
5.3.29.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.29.3 Procedure
Table 5.3.29.3-1: MCX Subscription and Notification
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Step 1a1 describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called. |
– |
– |
– |
– |
1a1 |
IF in RRC_IDLE state, the E-UTRA/EPC actions which are related to the MCX call establishment described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place. |
– |
– |
– |
– |
2 |
Check: Does the UE (MCX Client) send a SIP SUBSCRIBE message request? |
–> |
SIP SUBSCRIBE |
– |
P |
3 |
The SS (MCX Server) responds to the SIP SUBSCRIBE message with a SIP 200 (OK) message. |
<– |
SIP 200 (OK) |
– |
– |
4 |
The SS (MCX Server) sends a SIP NOTIFY message |
<– |
SIP NOTIFY |
– |
– |
5 |
The UE (MCX Client) responds with a SIP 200 (OK) message. |
–> |
SIP 200 (OK) |
||
6 |
SS (MCX Server) releases the E-UTRA connection. |
– |
– |
– |
– |
5.3.29.4 Specific message contents
All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:
none
5.3.30 MCX SIP MESSAGE Request – Accept CO
5.3.30.1 Initial conditions
As specified in the test case which calls the procedure.
Within the context of this procedure, MCX refers to MCPTT or MCVideo
5.3.30.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.30.3 Procedure
Table 5.3.30.3-1: MCX SIP MESSAGE Request – Accept CO
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Step 1a1 describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called. |
– |
– |
– |
– |
1a1 |
IF in RRC_IDLE state, the E-UTRA/EPC actions which are related to the MCX call establishment as described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place. |
– |
– |
– |
– |
2 |
Check: Does the UE (MCX Client) send a SIP MESSAGE message? |
–> |
SIP MESSAGE |
– |
P |
3 |
The SS (MCX Server) responds with a SIP 200 (OK) message? |
<– |
SIP 200 (OK) |
– |
– |
4 |
The SS (MCX server) sends SIP MESSAGE accepting the request. |
<– |
SIP MESSAGE |
– |
– |
5 |
Check: Does the UE (MCX Client) respond with a SIP 200 (OK) message? |
–> |
SIP 200 (OK) |
– |
P |
6 |
The SS waits 2 seconds before the SS deactivates the dedicated EPS bearer and releases the RRC connection. NOTE: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished and any not allowed behaviour captured. (NOTE 1) |
– |
– |
– |
– |
NOTE 1: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished. |
5.3.30.4 Specific message contents
All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:
None
5.3.31 MCX SIP MESSAGE Request – Accept CT
5.3.31.1 Initial conditions
As specified in the test case which calls the procedure.
Within the context of this procedure, MCX refers to MCPTT or MCVideo
5.3.31.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.31.3 Procedure
Table 5.3.31.3-1: MCX SIP MESSAGE Request – Accept CT
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Step 1a1 describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called. |
– |
– |
– |
– |
1a1 |
IF in RRC_IDLE state, the E-UTRA/EPC actions which are related to the MCX call establishment as described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place. |
– |
– |
– |
– |
2 |
The SS (MCX server) sends SIP MESSAGE |
<– |
SIP MESSAGE |
– |
– |
3 |
Check: Does the UE (MCX Client) respond with a SIP 200 (OK) message? |
–> |
SIP 200 (OK) |
– |
P |
4 |
Check: Does the UE (MCX Client) send a SIP MESSAGE message? |
–> |
SIP MESSAGE |
– |
P |
5 |
The SS (MCX Server) responds with a SIP 200 (OK) message? |
<– |
SIP 200 (OK) |
– |
– |
6 |
The SS waits 2 seconds before the SS deactivates the dedicated EPS bearer and releases the RRC connection. NOTE: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished and any not allowed behaviour captured. (NOTE 1) |
– |
– |
– |
– |
NOTE 1: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished. |
5.3.31.4 Specific message contents
All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:
None
5.3.32 MCX SIP MESSAGE CO
5.3.32.1 Initial conditions
As specified in the test case which calls the procedure.
Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData
5.3.32.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.32.3 Procedure
Table 5.3.32.3-1: MCX SIP MESSAGE CO
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Step 1a1 describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called. |
– |
– |
– |
– |
1a1 |
IF in RRC_IDLE state, the E-UTRA/EPC actions which are related to the MCX call establishment as described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place. |
– |
– |
– |
– |
2 |
Check: Does the UE (MCX Client) send a SIP MESSAGE message? |
–> |
SIP MESSAGE |
– |
P |
3 |
The SS (MCX Server) responds with a SIP 200 (OK) message? |
<– |
SIP 200 (OK) |
– |
– |
4 |
The SS waits 2 seconds before the SS deactivates the dedicated EPS bearer and releases the RRC connection. NOTE: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished and any not allowed behaviour captured. (NOTE 1) |
– |
– |
– |
– |
NOTE 1: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished. |
5.3.32.4 Specific message contents
All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:
None
5.3.33 MCX SIP MESSAGE CT
5.3.33.1 Initial conditions
As specified in the test case which calls the procedure.
Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData
5.3.33.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.33.3 Procedure
Table 5.3.33.3-1: MCX SIP MESSAGE CT
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Step 1a1 describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called. |
– |
– |
– |
– |
1a1 |
IF in RRC_IDLE state, the E-UTRA/EPC actions which are related to the MCX call establishment as described in clause 5.4.4 ‘Generic Test Procedure for MCX CT communication in E-UTRA’ take place. |
– |
– |
– |
– |
2 |
The SS (MCX server) sends SIP MESSAGE |
<– |
SIP MESSAGE |
– |
– |
3 |
Check: Does the UE (MCX Client) respond with a SIP 200 (OK) message? |
–> |
SIP 200 (OK) |
– |
P |
4 |
The SS waits 2 seconds before the SS deactivates the dedicated EPS bearer and releases the RRC connection. NOTE: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished and any not allowed behaviour captured. (NOTE 1) |
– |
– |
– |
– |
NOTE 1: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished. |
5.3.33.4 Specific message contents
All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:
None
5.3.34 MCX Group Affiliation Status Change
5.3.34.1 Initial conditions
As specified in the test case which calls the procedure.
Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData
5.3.34.2 Definition of system information messages
The E-UTRA default system information messages as defined in TS 36.508 [6] are used.
5.3.34.3 Procedure
Table 5.3.34.3-1: MCX Group Affiliation Status Change
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Step 1a1 describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called. |
– |
– |
– |
– |
1a1 |
IF in RRC_IDLE state, the E-UTRA/EPC actions which are related to the MCX call establishment as described in clause 5.4.4 ‘Generic Test Procedure for MCX CT communication in E-UTRA’ take place. |
– |
– |
– |
– |
2 |
Check: Does the UE (MCX Client) send a SIP PUBLISH message? |
–> |
SIP PUBLISH |
– |
P |
3 |
The SS responds to the SIP PUBLISH message with a SIP 200 (OK) message. |
<– |
SIP 200 (OK) |
– |
– |
4 |
The SS sends a SIP NOTIFY message informing about the status change progress. |
<– |
SIP NOTIFY |
– |
– |
5 |
The UE responds with a SIP 200 (OK) |
–> |
SIP 200 (OK) |
– |
– |
6 |
The SS sends a SIP NOTIFY informing about the affiliation status of the user. |
<– |
SIP NOTIFY |
– |
– |
7 |
The UE responds with a SIP 200 (OK) |
–> |
SIP 200 (OK) |
– |
– |
8 |
The SS waits 2 seconds before the SS deactivates the dedicated EPS bearer and releases the RRC connection. NOTE: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished and any not allowed behaviour captured. (NOTE 1) |
– |
– |
– |
– |
NOTE 1: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished. |
5.3.34.4 Specific message contents
All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:
None