6.3 Enhanced Status (ES)

36.579-73GPPMission Critical (MC) services over LTEPart 7: Mission Critical Data (MCData) User Equipment (UE) Protocol conformance specificationRelease 15TS

6.3.1 On-network / Enhanced Status (ES) / Client Originated (CO)

6.3.1.1 Test Purpose (TP)

(1)

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

ensure that {

when { the MCDATA User requests to send an Enhanced Status with a disposition of only Delivery }

then { UE (MCDATA Client) sends an Enhanced Status with a disposition request of only Delivery via s SIP MESSAGE message }

}

(2)

with { UE (MCDATA Client) having sent an Enhanced Status with a disposition request of DELIVERY }

ensure that {

when { the UE (MCDATA Client) receives a disposition response via a SIP MESSAGE message from the SS (MCDATA Server) }

then { UE (MCData Client) responds to the SIP MESSAGE message by sending a SIP 200 (OK) message and delivers the notification to the MCDATA User }

}

6.3.1.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.282, clauses 14.2.1.1, 9.2.2.2.1, 6.2.2.1, 6.2.4.1, 12.2.1.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-15 requirements.

[TS 24.282, clause 14.2.1.1]

Upon receiving a request from the MCData user to send an enhanced status to an MCData group and the <mcdata-allow-enhanced-status> element under the <list-service> element as defined in 3GPP TS 24.481 [11] is set to "true", the MCData client:

1) shall use the "id" attribute of the MCData user selected operation value from <mcdata-enhanced-status-operational-values> element under <list-service> element as defined in 3GPP TS 24.481 [11], to generate a group standalone SDS message by following the procedure described in clause 9.2.2.2.1.

[TS 24.282, clause 9.2.2.2.1]

The MCData client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6] with the clarifications given below.

The MCData client:

1) shall build the SIP MESSAGE request as specified in subclause 6.2.4.1;

3) if a group standalone SDS message is to be sent:

a) if the "/<x>/<x>/Common/MCData/AllowedSDS" leaf node present in the group document of the requested MCData group, configured on the group management client as specified in 3GPP TS 24.483 [42] is set to "false", shall reject the request to send SDS and not continue with the rest of the steps in this subclause; and

b) shall insert in the SIP MESSAGE request an application/vnd.3gpp.mcdata-info+xml MIME body with:

i) the <request-type> element set to a value of "group-sds";

ii) the <mcdata-request-uri> element set to the MCData group identity; and

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

4) shall generate a standalone SDS message as specified in subclause 6.2.2.1; and

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

[TS 24.282, clause 6.2.2.1]

In order to generate an SDS message, the MCData client:

1) shall generate an SDS SIGNALLING PAYLOAD message as specified in clause 15.1.2;

2) shall generate a DATA PAYLOAD message as specified in clause 15.1.4;

3) shall include in the SIP request, the SDS SIGNALLING PAYLOAD message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in clause E.1; and

4) shall include in the SIP request, the DATA PAYLOAD message in an application/vnd.3gpp.mcdata-payload MIME body as specified in clause E.2.

When generating an SDS SIGNALLING PAYLOAD message as specified in clause 15.1.2, the MCData client:

1) shall set the Date and time IE to the current time as specified in clause 15.2.8;

2) if the SDS message starts a new conversation, shall set the Conversation ID IE to a newly generated Conversation ID value as specified in clause 15.2.9;

3) if the SDS message continues an existing unfinished conversation, shall set the Conversation ID IE to the Conversation ID value of the existing conversation as specified in clause 15.2.9;

4) shall set the Message ID IE to a newly generated Message ID value as specified in clause 15.2.10;

5) if the SDS message is in reply to a previously received SDS message, shall include the InReplyTo message ID IE with the Message ID value in the previously received SDS message;

6) if the SDS message is for user consumption, shall not include an Application ID IE as specified in clause 15.2.7and shall not include an Extended application ID IE as specified in clause 15.2.24;

7) if the SDS message is intended for an application on the terminating MCData client, shall include:

a) an Application ID IE with a Application ID value representing the intended application as specified in clause 15.2.7; or

b) an Extended application ID IE with an Extended application ID value representing the intended application as specified in clause 15.2.24;

NOTE: The value chosen for the Application ID value is decided by the mission critical organisation.

8) if only a delivery disposition notification is required shall include a SDS disposition request type IE set to "DELIVERY" as specified in clause 15.2.3;

9) if only a read disposition notification is required shall include a SDS disposition request type IE set to "READ" as specified in clause 15.2.3; and

10) if both a delivery and read disposition notification is required shall include a SDS disposition request type IE set to "DELIVERY AND READ" as specified in clause 15.2.3.

When generating an DATA PAYLOAD message for SDS as specified in clause 15.1.4, the MCData client:

1) shall set the Number of payloads IE to the number of Payload IEs that needs to be encoded, as specified in clause 15.2.12;

2) if end-to-end security is required for a one-to-one communication, shall include the Security parameters and Payload IE with security parameters as described in 3GPP TS 33.180 [26]. Otherwise, if end-to-end security is not required for a one-to-one communication, shall include the Payload IE as specified in clause 15.1.4; and

3) for each Payload IE included:

a) if the payload is text, shall set the Payload content type as "TEXT" as specified in clause 15.2.13;

b) if the payload is binary data, shall set the Payload content type as "BINARY" as specified in clause 15.2.13;

c) if the payload is hyperlinks, shall set the Payload content type as "HYPERLINKS" as specified in clause 15.2.13;

d) if the payload is location, shall set the Payload content type as "LOCATION" as specified in clause 15.2.13;

e) if payload is enhanced status for a group, shall set the Payload content type as "ENHANCED STATUS" as specified in subclause 15.2.13; and

f) shall include the data to be sent in the Payload data.

[TS 24.282, clause 6.2.4.1]

This subclause is referenced from other procedures.

In a SIP MESSAGE request, the MCData client:

1) when sending SDS messages or SDS disposition notifications:

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

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

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

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

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

[TS 24.282, clause 12.2.1.2]

Upon receipt of a:

"SIP MESSAGE request for SDS disposition notification for terminating MCData client"; or

"SIP MESSAGE request for FD disposition notification for terminating MCData client";

the MCData client:

1) shall decode the contents of the application/vnd.3gpp.mcdata-signalling MIME body; and

2) shall deliver the notification to the user or application.

6.3.1.3 Test description

6.3.1.3.1 Pre-test conditions

System Simulator:

– SS (MCDATA Server)

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

IUT:

– UE (MCDATA Client)

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

– The <max-payload-size-sds-cplane-bytes> element in the MCData service configuration document as specified in 3GPP TS 24.484 [12], shall be large enough to allow the sending of the standalone SDS message using the signalling plane.

Preamble:

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

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

– UE States at the end of the preamble

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

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

6.3.1.3.2 Test procedure sequence

Table 6.3.1.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the MCDATA User request to send an enhanced status to Group A using Enhanced Status Id "1" with disposition request "DELIVERY".

(NOTE 1)

2-2B

Check: Does the UE (MCData Client) perform steps 1a1-3 of the procedure for CO SDS or FD message transfer using signalling plane specified in TS 36.579-1 [2] Table 5.3C.1.3-1 to send an Enhanced Status with Enhanced Status Id "1" and disposition request "DELIVERY"?

(NOTE 2)

1

P

3

Void

4

Check: Does the UE (MCData Client) perform the procedure for MCX SIP MESSAGE CT specified in TS 36.579-1 [2] Table 5.3.33.3-1 to receive the disposition notification for the SDS message sent at step 2A?

2

P

5

Void

6

Check: Does the UE (MCDATA Client) deliver the notification to the MCDATA User?

(NOTE 1)

2

P

NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

NOTE 2: The RRC connection is not released at the end of the procedure.

6.3.1.3.3 Specific message contents

Table 6.3.1.3.3-1: SIP MESSAGE (step 2A, Table 6.3.1.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3C.1.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.1-1, condition MCDATA_SDS, MCDATA_SIGNALLING, MCDATA_PAYLOAD

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCData-Info

MIME-part-body

MCData-Info as described in Table 6.3.1.3.3-2

MIME body part

MCData Data signalling message

MIME-part-body

MCData Protected Payload Message containing SDS SIGNALLING PAYLOAD as described in Table 6.1.3.3.3-2A

MIME body part

MCData Data message

MIME-part-body

MCData Protected Payload Message containing DATA PAYLOAD as described in Table 6.3.1.3.3-3

Table 6.3.1.3.3-2: MCDATA-Info (Table 6.3.1.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-3, condition MCD_grp

Table 6.3.1.3.3-2A: SDS SIGNALLING PAYLOAD (Table 6.3.1.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.1-1, condition DELIVERED

Table 6.3.1.3.3-3: DATA PAYLOAD (Table 6.3.1.3.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Payload

Payload content type

‘00000110’B

ENHANCED STATUS

TS 24.282 [31], Table 15.2.13-2

Payload data

"1"

The id as defined in the MCData Group Configuration Document

TS 36.579-1 [2], Table 5.5.7.3-1

Table 6.3.1.3.3-4: SIP MESSAGE (step 4, Table 6.3.1.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3.33.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.2-1, condition MCDATA_SDS, MCDATA_SIGNALLING

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCData Info

MIME-part-body

As described in Table 6.3.1.3.3-5

MIME body part

MCData Data signalling message

MIME-part-body

MCData Protected Payload Message containing SDS NOTIFICATION as described in Table 6.3.1.3.3-6

Table 6.3.1.3.3-5: MCDATA-Info (Table 6.3.1.3.3-4)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.2-3

Information Element

Value/remark

Comment

Reference

Condition

mcdata-info

mcdata-Params

mcdata-calling-group-id

Encrypted <mcdata-calling-group-id> with mcdataURI set to px_MCData_Group_A_ID

Encrypted according to TS 36.579-1 [2] Table 5.5.3.2.2-3A

Table 6.3.1.3.3-6: SDS NOTIFICATION (Table 6.3.1.3.3-4)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.4-1, condition DELIVERED

Table 6.3.1.3.3-7: Void

6.3.2 On-network / Enhanced Status (ES) / Client Terminated (CT)

6.3.2.1 Test Purpose (TP)

(1)

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

ensure that {

when { the MCDATA User receives an Enhanced Status with a disposition request of "DELIVERY" }

then { UE (MCDATA Client) responds by sending a SIP 200 (OK) message and sends a SIP MESSAGE message with a disposition notification of "DELIVERED" and renders the operational value of the received Enhanced Status ID as enhanced status to the MCDATA User }

}

6.3.2.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.282, clauses 14.2.1.2, 9.2.2.2.2, 9.2.1.2, 9.2.1.3, 12.2.1.1, 6.2.3.1, 6.2.4.1. 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-15 requirements.

[TS 24.282, clause 14.2.1.2]

Upon receiving a "SIP MESSAGE request for standalone SDS for terminating MCData client", the MCData client:

1) shall follow the procedure defined in clause 9.2.2.2.2;

2) shall match the received value with an "id" attribute of the operational values from the <mcdata-enhanced-status-operational-values> element of the MCData group document as defined in 3GPP TS 24.481 [11]; and

3) if a match is found, shall render the operational value as enhanced status to the MCData user. Otherwise shall discard the received message.

[TS 24.282, clause 9.2.2.2.2]

Upon receipt of a "SIP MESSAGE request for standalone SDS for terminating MCData client", the MCData client:

3) if the SIP MESSAGE request contains an application/mikey MIME body containing a MIKEY-SAKKE I_MESSAGE:

a) shall extract the MCData ID of the originating MCData user from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [26];

b) shall convert the MCData ID to a UID as described in 3GPP TS 33.180 [26];

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

d) if authentication verification of the MIKEY-SAKKE I_MESSAGE fails, shall reject the SIP MESSAGE request with a SIP 606 (Not Acceptable) response, and include warning text set to "136 authentication of the MIKEY-SAKKE I_MESSAGE failed" in a Warning header field as specified in subclause 4.9 and not continue with rest of the steps in this subclause; and

e) if the signature of the MIKEY-SAKKE I_MESSAGE was successfully validated:

i) shall extract and decrypt the encapsulated PCK using the terminating user’s (KMS provisioned) UID key as described in 3GPP TS 33.180 [26]; and

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

NOTE: With the PCK successfully shared between the originating MCData client and the terminating MCData client, both clients are able to exchange end-to-end secure message.

4) shall generate a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [5];

5) shall send the SIP 200 (OK) response towards the MCData server according to rules and procedures of 3GPP TS 24.229 [5]; and

6) shall handle the received message as specified in subclause 9.2.1.2.

[TS 24.282, clause 9.2.1.2]

When a MCData client has received a SIP request containing:

– an application/vnd.3gpp.mcdata-signalling MIME body as specified in subclause E.1; and

– an application/vnd.3gpp.mcdata-payload MIME body as specified in subclause E.2;

the MCData Client:

1) shall decode the contents of the application/vnd.3gpp.mcdata-signalling MIME body;

2) shall decode the contents of the application/vnd.3gpp.mcdata-payload MIME body;

5) shall identify the number of Payload IEs in the DATA PAYLOAD message from the Number of payloads IE in the DATA PAYLOAD message;

6) if the SDS SIGNALLING PAYLOAD message does not contain an Application ID IE:

a) shall determine that the payload contained in the DATA PAYLOAD message is for user consumption

b) may notify the MCData user; and

c) shall render the contents of the Payload IE(s) to the MCData user;

7) if the SDS SIGNALLING PAYLOAD message contains an Application ID IE:

a) shall determine that the payload contained in the DATA PAYLOAD message is not for user consumption,

b) shall not notify the MCData user;

c) if the Application ID value is unknown, shall discard the SDS message; and

d) if the Application ID value is known, shall deliver the contents of the Payload IE(s) to the identified application;

NOTE 1: If required, the MCData client decrypts the Payload IEs before rendering the SDS message to the user or delivering the SDS message to the application.

NOTE 3: User consent is not required before accepting the data.

8) may store the message payload in local storage along with the Conversation ID, Message ID, InReplyTo message ID and Date and time; and

9) if the received SDS SIGNALLING PAYLOAD message contains an SDS disposition request type IE shall follow the procedures in subclause 9.2.1.3.

[TS 24.282, clause 9.2.1.3]

To handle the disposition requests, the MCData client:

1) If the SDS disposition request type IE is set to:

a) "DELIVERY" then, shall send a delivered notification as described in subclause 12.2.1.1;

b) "READ", shall send a read notification as described in subclause 12.2.1.1, when a display indication is received; or

c) "DELIVERY AND READ" then, shall start timer TDU1 (delivery and read).

[TS 24.282, clause 12.2.1.1]

The MCData client shall follow the procedures in this subclause to:

– indicate to an MCData client that an SDS message was delivered, read or delivered and read when the originating client requested a delivery, read or delivery and read report;

– indicate to the participating MCData function serving the MCData user that an SDS message was undelivered. The participating MCData function can store the message for later re-delivery;

– indicate to an MCData client that a request for FD was accepted, deferred or rejected; or

– indicate to an MCData client that a file download has been completed;

Before sending a disposition notification the MCData client needs to determine:

– the controlling MCData function that sent the SDS or FD message request. The MCData client determines the controlling MCData function from the contents of the <mcdata-controller-psi> element contained in the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SDS or FD message request;

– the group identity related to an SDS or FD message request received as part of a group communication. The MCData client determines the group identity from the contents of the <mcdata-calling-group-id> element contained in the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SDS or FD message request; and

– the MCData user targeted for the disposition notification. The MCData client determines the targeted MCData user from the contents of the <mcdata-calling-user-id> element contained in the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SDS or FD message request.

The MCData client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6] with the clarifications given below.

The MCData client:

1) shall build the SIP MESSAGE request as specified in subclause 6.2.4.1;

2) shall follow the rules specified in subclause 6.4 for the handling of MIME bodies in a SIP message when processing the remaining steps in this subclause;

3) shall insert in the SIP MESSAGE request an application/resource-lists+xml MIME body containing the MCData ID of the targeted MCData user, according to rules and procedures of IETF RFC 5366 [18];

4) shall insert in the SIP MESSAGE request an application/vnd.3gpp.mcdata-info+xml MIME body with an <mcdata-controller-psi> element containing the PSI of the controlling MCData function;

5) if sending a disposition notification in response to an MCData group data request, shall include an <mcdata-calling-group-id> element set to the MCData group identity in the application/vnd.3gpp.mcdata-info+xml MIME body;

6) if requiring to send an SDS notification, shall generate an SDS NOTIFICATION message and include it in the SIP MESSAGE request as specified in subclause 6.2.3.1;

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

[TS 24.282, clause 6.2.3.1]

In order to generate an SDS notification, the MCData client:

1) shall generate an SDS NOTIFICATION message as specified in subclause 15.1.5; and

2) shall include in the SIP request, the SDS NOTIFICATION message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in subclause E.1.

When generating an SDS NOTIFICATION message as specified in subclause 15.1.5, the MCData client:

1) if sending a delivered notification, shall set the SDS disposition notification type IE as "DELIVERED" as specified in subclause 15.2.5;

5) shall set the Date and time IE to the current time to as specified in subclause 15.2.8;

6) shall set the Conversation ID to the value of the Conversation ID that was received in the SDS message as specified in subclause 15.2.9;

7) shall set the Message ID to the value of the Message ID that was received in the SDS message as specified in subclause 15.2.10;

8) if the SDS message was destined for the user, shall not include an Application ID IE as specified in subclause 15.2.7; and

[TS 24.282, clause 6.2.4.1]

This subclause is referenced from other procedures.

In a SIP MESSAGE request, the MCData client:

1) when sending SDS messages or SDS disposition notifications:

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

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

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

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

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

6.3.2.3 Test description

6.3.2.3.1 Pre-test conditions

System Simulator:

– SS (MCDATA Server)

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

IUT:

– UE (MCDATA Client)

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

– The <max-payload-size-sds-cplane-bytes> element in the MCData service configuration document as specified in 3GPP TS 24.484 [12], shall be large enough to allow the sending of the standalone SDS message using the signalling plane.

Preamble:

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

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

– UE States at the end of the preamble

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

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

6.3.2.3.2 Test procedure sequence

Table 6.3.2.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1-1B

Check: Does the UE (MCData Client) perform steps 1a1-3 of the procedure for MCX SIP MESSAGE CT specified in TS 36.579-1 [2] Table 5.3.33.3-1 to receive an Enhanced Status with disposition request "DELIVERY"?

(NOTE 2)

1

P

3

Check: Does the UE (MCData Client) perform the procedure for CO SDS or FD message transfer using signalling plane specified in TS 36.579-1 [2] Table 5.3C.1.3-1 to send a disposition notification of "DELIVERED"?

1

P

4

Void

5

Check: Does the UE (MCDATA client) render the operational value of the received Enhanced Status ID as enhanced status to the MCDATA User?

(NOTE 1)

1

P

NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

NOTE 2: The RRC connection is not released at the end of the procedure.

6.3.2.3.3 Specific message contents

Table 6.3.2.3.3-1: SIP MESSAGE (step 1A, Table 6.3.2.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3.33.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.2-1, condition MCDATA, PRIVATE-CALL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCData-Info

MIME-part-body

MCData-Info as described in Table 6.3.2.3.3-2

MIME body part

MCData Data signalling message

MIME-part-body

MCData Protected Payload Message containing SDS SIGNALLING PAYLOAD as described in Table 6.3.2.3.3-3

MIME body part

MCData Data message

MIME-part-body

MCData Protected Payload Message containing DATA PAYLOAD as described in TS 36.579-1 [2] Table 6.3.2.3.3-4

Table 6.3.2.3.3-2: MCDATA-Info (Table 6.3.2.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.2-3, condition MCD_grp

Table 6.3.2.3.3-3: SDS SIGNALLING PAYLOAD (Table 6.3.2.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.2-1, condition DELIVERED

Table 6.3.2.3.3-4: DATA PAYLOAD (Table 6.3.2.3.3-1)

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

Payload

Payload content type

‘00000110’B

ENHANCED STATUS

TS 24.282 [31], Table 15.2.13-2

Payload data

"0"

The id as defined in the MCData Group Configuration Document

TS 36.579-1 [2], Table 5.5.7.3-1

Table 6.3.2.3.3-5: Void

Table 6.3.2.3.3-6: SIP MESSAGE (step 3, Table 6.3.2.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3C.1.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.1-1, condition MCDATA_SDS, RESOURCE_LISTS, MCDATA_SIGNALLING

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCData-Info

MIME-part-headers

MCData-Info described in Table 6.3.2.3.3-7

MIME body part

MCData Data signalling message

MIME-part-body

MCData Protected Payload Message containing SDS NOTIFICATION as described in Table 6.3.2.3.3-8

Table 6.3.2.3.3-7: MCDATA-Info (Table 6.3.2.3.3-6)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-3

Information Element

Value/remark

Comment

Reference

Condition

mcdata-info

mcdata-Params

mcdata-calling-group-id

Encrypted <mcdata-request-uri> with mcdataURI set to px_MCData_Group_A_ID

Encrypted according to TS 36.579-1 [2] Table 5.5.3.2.1-3A

Table 6.3.2.3.3-8: SDS NOTIFICATION (Table 6.3.2.3.3-6)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.3-1, condition DELIVERED