6.1.9 On-network / Short Data Service (SDS) / SDS Session / One-to-one SDS Session / Client Originated (CO)
36.579-73GPPMission Critical (MC) services over LTEPart 7: Mission Critical Data (MCData) User Equipment (UE) Protocol conformance specificationRelease 15TS
6.1.9.1 Test Purpose (TP)
(1)
with { UE (MCDATA Client) registered and authorised for MCDATA Service }
ensure that {
when { the MCDATA User requests to initiate a one-to-one SDS session using the media plane}
then { UE (MCDATA Client) sends a request to establish a one-to-one SDS session and a MSRP connection via a SIP INVITE message and then responds to the SIP 200 (OK) message with a SIP ACK message }
}
(2)
with { UE (MCDATA Client) having received a SIP 200 (OK) message with the a=setup attribute set to "passive" in response to a SIP INVITE message}
ensure that {
when { UE (MCDATA Client) responds to the SIP 200 (OK) message with a SIP ACK message }
then { UE (MCData Client) sends a blank MSRP SEND message to bind the MSRP connection and then sends the one-to-one session SDS message via a MSRP SEND message with a disposition of "DELIVERY" }
}
(3)
with { UE (MCDATA Client) having sent a one-to-one session SDS message using the media plane with a disposition of "DELIVERY" }
ensure that {
when { UE (MCDATA Client) receives a disposition response via a MSRP SEND message }
then { UE (MCDATA Client) responds to the MSRP SEND message by sending a MSRP 200 (OK) message and delivers the notification to the MCDATA User }
}
(4)
with { UE (MCDATA Client) having established a one-to-one SDS session and a MSRP connection }
ensure that {
when { UE (MCDATA Client) receives an MSRP SEND message with a disposition of "READ" }
then { UE (MCDATA Client) responds with a MSRP 200 (OK) message and then renders the contents of the Payload IE to the MCDATA User and then sends a MSRP SEND message with a disposition notification of "READ" }
}
(5)
with { UE (MCDATA Client) having established a one-to-one SDS session }
ensure that {
when { the MCDATA User requests to release the one-to-one SDS session }
then { UE (MCDATA Client) sends a SIP BYE message }
}
6.1.9.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 24.282, clauses 9.2.4.2.3, 9.2.4.2.1, 13.2.2.2.2.1, TS 24.582 clauses 6.1.2.2.1, 6.1.2.4, 6.1.2.5.1, 6.1.2.5.2, 6.1.2.5.3, 6.1.2.6. 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.282, clause 9.2.4.2.3]
The MCData client shall generate a SIP INVITE request in accordance with 3GPP TS 24.229 [5] with the clarifications given below.
The MCData client:
1) shall include the g.3gpp.mcdata.sds media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [16];
2) 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];
3) shall include an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag 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];
4) 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 INVITE request;
5) should include the "timer" option tag in the Supported header field;
6) should include the Session-Expires header field according to IETF RFC 4028 [38]. It is recommended that the "refresher" header field parameter is omitted. If included, the "refresher" header field parameter shall be set to "uac";
7) if a one-to-one SDS session is requested:
a) shall insert in the SIP INVITE request a MIME resource-lists body with the MCData ID of the invited MCData user, according to rules and procedures of IETF RFC 5366 [18];
b) shall contain an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element with:
i) the <request-type> element set to a value of "one-to-one-sds-session"; and
c) if an end-to-end security context needs to be established and the security context does not exist or if the existing security context has expired, then:
i) if necessary, shall instruct the key management client to request keying material from the key management server as described in 3GPP TS 33.180 [26];
ii) shall use the keying material to generate a PCK as described in 3GPP TS 33.180 [26];
iii) shall use the PCK to generate a PCK-ID with the four most significant bits set to "0001" to indicate that the purpose of the PCK is to protect one-to-one communications and with the remaining twenty eight bits being randomly generated as described in 3GPP TS 33.180 [26];
iv) shall encrypt the PCK to a UID associated to the MCData client using the MCData ID of the invited user and a time related parameter as described in 3GPP TS 33.180 [26];
v) shall generate a MIKEY-SAKKE I_MESSAGE using the encapsulated PCK and PCK-ID as specified in 3GPP TS 33.180 [26];
vi) shall add the MCData ID of the originating MCData to the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [26]; and
vii) shall sign the MIKEY-SAKKE I_MESSAGE using the originating MCData user’s signing key provided in the keying material together with a time related parameter, and add this to the MIKEY-SAKKE payload, as described in 3GPP TS 33.180 [26];
…
9) shall set the Request-URI of the SIP INVITE request to the public service identity identifying the participating MCData function serving the MCData user;
NOTE 2: The MCData client is configured with public service identity identifying the participating MCData function serving the MCData user.
10) may include a P-Preferred-Identity header field in the SIP INVITE request containing a public user identity as specified in 3GPP TS 24.229 [5];
11) shall include an SDP offer according to 3GPP TS 24.229 [5] with the clarifications given in subclause 9.2.4.2.1; and
12) shall send the SIP INVITE request towards the MCData server according to 3GPP TS 24.229 [5].
On receipt of a SIP 2xx response to the SIP INVITE request, the MCData client:
1) shall send a SIP ACK request as specified in 3GPP TS 24.229 [5];
2) shall start the SIP Session timer according to rules and procedures of IETF RFC 4028 [38]; and
3) shall interact with the media plane as specified in 3GPP TS 24.582 [15] subclause 6.1.2.2.
[TS 24.282, clause 9.2.4.2.1]
When composing an SDP offer according to 3GPP TS 24.229 [5], IETF RFC 4975 [17], IETF RFC 6135 [19] and IETF RFC 6714 [20] the MCData client:
1) shall include an "m=message" media-level section for the MCData media stream consisting of:
a) the port number;
b) a protocol field value of "TCP/MSRP" or "TCP/TLS/MSRP" for TLS;
c) an "a=sendrecv" attribute;
d) an "a=path" attribute containing its own MSRP URI;
e) set the content type as "a=accept-types:application/vnd.3gpp.mcdata-signalling application/vnd.3gpp.mcdata-payload"; and
f) set the a=setup attribute as "actpass"; and
2) if end-to-end security is required for a one-to-one communication and the security context does not exist or if the existing security context has expired, shall include the MIKEY-SAKKE I_MESSAGE in an "a=key-mgmt" attribute as a "mikey" attribute value in the SDP offer as specified in IETF RFC 4567 [45].
[TS 24.282, clause 13.2.2.2.2.1]
When the MCData client wants to release a MCData communication established over the media plane, the MCData client:
1) shall generate a SIP BYE request according to 3GPP TS 24.229 [5];
2) shall set the Request-URI to the MCData session identity to be released; and
3) shall send the SIP BYE request towards MCData server according to 3GPP TS 24.229 [5].
Upon receiving a SIP 200 (OK) response to the SIP BYE request, the MCData client shall release all media plane resources corresponding to the MCData communication being released.
[TS 24.582, clause 6.1.2.2.1]
Upon receiving an indication to establish MSRP connection for SDS session as the originating MCData client, the MCData client:
1. shall act as an MSRP client according to IETF RFC 6135 [12];
2. shall act according to IETF RFC 6135 [12], as:
a. an "active" endpoint, if a=setup attribute in the received SDP answer is set to "passive"; and
b. an "passive" endpoint, if a=setup attribute in the received SDP answer is set to "active";
3. shall establish the MSRP connection according to the MSRP connection parameters in the SDP answer received in the SIP 200 (OK) response according to IETF RFC 4975 [11];
4. if acting as an "active" endpoint, shall send an empty MSRP SEND request to bind the MSRP connection to the MSRP session from the perspective of the passive endpoint according to the rules and procedures of IETF RFC 4975 [11] and IETF RFC 6135 [12];
Once the MSRP session is established, the MCData client:
1. on receipt of an MSRP request in the MSRP session, shall follow the rules and procedures defined in IETF RFC 4975 [11] and in IETF RFC 6714 [13];
2. If an MSRP SEND request indicates the use of chunking, shall wait until all further MSRP SEND requests for the remaining chunks have been received and shall reassemble the entire set of MSRP requests into the MCData SDS message before delivering the content to the application; and
3. shall handle the received content as described in subclause 6.1.2.6.
On receiving MSRP 200 (OK) response to the first MSRP SEND request, the MCData client can generate and send an SDS message as specified in subclause 6.1.2.4, or can generate and send an SDS disposition notification for a received SDS message as specified in subclause 6.1.2.5, if requested.
Received content and disposition requests shall be handled as specified in subclause 6.1.2.6.
[TS 24.582, clause 6.1.2.4]
An MCData client is allowed to send an one-to-one SDS message only if
1. the <allow-transmit-data> element of an <actions> element is present with a value "true" (see the MCData user profile document in 3GPP TS 24.484 [7]);
2. the size of the SDS message is less than or equal to the value of the <max-data-size-sds-bytes> element in the MCData service configuration document as specified in 3GPP TS 24.484 [7]; and
3. the size of the SDS message is less than or equal to the value of <MaxData1To1> element of the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [7]).
An MCData client is allowed to send a group SDS message only if
1. the <mcdata-allow-transmit-data-in-this-group> element of an <action> element is present with a value "true" as defined in the MCData group document for this MCData group as specified in 3GPP TS 24.481 [4];
2. the size of the SDS message is less than or equal to the value contained in the <mcdata-on-network-max-data-size-for-SDS> as defined in the MCData group document for this MCData group as specified in 3GPP TS 24.481 [4]; and
3. the size of the SDS message is less than or equal to the value contained in the <mcdata-max-data-in-single-request> element of the <entry> element of the MCData group document for this MCData group as specified in 3GPP TS 24.481 [11].
If the above mentioned conditions satisfy, the MCData client:
1. shall generate a SDS SIGNALLING PAYLOAD as specified in subclause 6.1.1.2.2;
2. shall generate a SDS DATA PAYLOAD as specified in subclause 6.1.1.2.3;
3. shall include the SDS SIGNALLING PAYLOAD and SDS DATA PAYLOAD in an MSRP SEND request as specified in subclause 6.1.1.2.4, with the following clarification;
a. shall set To-Path header according to the MSRP URI in the received SDP; and
4. shall send the MSRP SEND request on the established MSRP connection.
NOTE: MSRP chunking, if needed, may affect the number of "Content Type" lines in each MSRP SEND message conveying a chunk, as also specified in subclause 6.1.1.2.4.
[TS 24.582, clause 6.1.2.5.1]
To send an SDS disposition notification, the MCData client:
1. shall generate a SDS NOTIFICATION as specified in subclause 6.1.2.5.2;
2. shall include the SDS NOTIFICATION in an MSRP SEND request as specified in subclause 6.1.2.5.3, with the following clarification;
a. shall set To-Path header according to the MSRP URI in the received SDP; and
3. shall send the MSRP SEND request on the established MSRP connection.
If MSRP chunking is used, the MCData client:
1. shall send further MSRP SEND requests as necessary.
On receiving a non-200 MSRP response to the MSRP SEND request the MCData client shall handle the error as specified in IETF RFC 4975 [11]. To terminate the MSRP session, the MCData client:
1. if there are further MSRP chunks to send, shall abort transmission of these further MSRP chunks; and
2. shall indicate to MCData user that the SDS message or the SDS disposition notification could not be sent.
[TS 24.582, clause 6.1.2.5.2]
In order to generate an SDS notification, the MCData client:
1. shall generate an SDS NOTIFICATION message as specified in 3GPP TS 24.282 [8]; and
2. shall include the SDS NOTIFICATION message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in 3GPP TS 24.282 [8].
When generating an SDS NOTIFICATION message, the MCData client:
1. if sending a delivered notification, shall set the SDS disposition notification type IE as "DELIVERED";
2. if sending a read notification, shall set the SDS disposition notification type IE as "READ";
3. if sending a delivered and read notification, shall set the SDS disposition notification type IE as "DELIVERED AND READ";
4. if the SDS message could not be delivered to the user or application (e.g. due to lack of storage), shall set the SDS disposition notification type IE as "UNDELIVERED";
5. shall set the Date and time IE to the current time;
6. shall set the Conversation ID to the value of the Conversation ID that was received in the SDS message;
7. shall set the Message ID to the value of the Message ID that was received in the SDS message;
8. if the SDS message was destined for the user, shall not include an Application ID IE; and
9. if the SDS message was destined for an application, shall include an Application ID IE set to the value of the Application ID that was included in the SDS message.
[TS 24.582, clause 6.1.2.5.3]
The MCData client shall generate MSRP SEND requests for SDS disposition notification according to IETF RFC 4975 [11].
When generating an MSRP SEND request for SDS disposition notification containing an SDS NOTIFICATION message, the MCData client
1. shall set To-Path header according to the MSRP URI(s) received in the answer SDP;
2. shall set the content type as Content-Type = "application/vnd.3gpp.mcdata-signalling"; and
3. shall set the body of the MSRP SEND request to the generated SDS NOTIFICATION message.
[TS 24.582, clause 6.1.2.6]
Upon receiving an SDS message, the MCData client:
1. shall follow the procedure defined in subclause 6.1.1.3.2, with the following clarification:
a. if SDS Disposition request type IE is present in the received SDS SIGNALLING PAYLOAD message then, shall send an SDS disposition notification as described in subclause 6.1.2.5.
Upon receiving an SDS disposition notification, 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.1.9.3 Test description
6.1.9.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.
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.1.9.3.2 Test procedure sequence
Table 6.1.9.3.2-1: Main Behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
Make the MCData User request to send a one-to-one session SDS message with disposition request "DELIVERY". (NOTE 1) |
– |
– |
– |
– |
|
2 |
Check: Does the UE (MCData Client) perform the procedure for CO MCData Call Establishment specified in TS 36.579-1 [2] Table 5.3C.2.3-1? |
– |
– |
1,2 |
P |
|
3-6 |
Void |
– |
– |
– |
– |
|
7 |
Check: Does the UE (MCData Client) perform the procedure for CO MSRP message transfer specified in TS 36.579-1 [2] Table 5.3C.4.3-1 to send an SDS message with disposition notification type "DELIVERY"? |
– |
– |
2 |
P |
|
8 |
Check: Does the UE (MCData Client) perform the procedure for CT MSRP message transfer specified in TS 36.579-1 [2] Table 5.3C.5.3-1 to receive the disposition notification for the SDS message sent at step 7? |
– |
– |
3 |
P |
|
9 |
Void |
– |
– |
– |
– |
|
10 |
Check: Does the UE (MCDATA Client) deliver the notification to the MCData User? (NOTE 1) |
– |
– |
3 |
P |
|
11 |
Check: Does the UE (MCData Client) perform the procedure for CT MSRP message transfer specified in TS 36.579-1 [2] Table 5.3C.5.3-1 to receive an SDS message with disposition notification type "READ"? |
– |
– |
4 |
P |
|
12 |
Void |
– |
– |
– |
– |
|
– |
EXCEPTION: In parallel to the event described in step 13 the events described in Table 6.1.9.3.2-2 take place. (NOTE 2) |
– |
– |
– |
– |
|
13 |
Check: Does the UE (MCDATA Client) render the contents of the Payload IE to the MCDATA User? (NOTE 1) |
– |
– |
4 |
P |
|
14-15 |
Void |
– |
– |
– |
– |
|
16 |
Make the MCDATA User request to release the one-to-one session SDS message over the media plane. (NOTE 1) |
– |
– |
– |
– |
|
17 |
Check: Does the UE (MCData Client) perform the procedure for CO MCData call release specified in TS 36.579-1 [2] Table 5.3C.6.3-1? |
– |
– |
3 |
P |
|
18 |
The SS releases the RRC connection |
– |
– |
– |
– |
|
NOTE 1: This is expected to be done via a suitable implementation dependent MMI. NOTE 2: The behaviour is handled through parallel actions to allow for implementations which first indicate to the user that there is a message available, but render the message to the user only after the user takes an action to open the message. |
|||||
Table 6.1.9.3.2-2: Parallel Behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
Check: Does the UE (MCData Client) perform the procedure for CO MSRP message transfer specified in TS 36.579-1 [2] Table 5.3C.4.3-1 to send a disposition notification of "READ"? |
– |
– |
2 |
P |
6.1.9.3.3 Specific message contents
Table 6.1.9.3.3-1: SIP INVITE (step 2, Table 6.1.9.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3C.2.3-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition MCDATA_SDS, MCD_1to1 |
||||
|---|---|---|---|---|
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Message-body |
||||
|
MIME body part |
SDP message |
|||
|
MIME-part-body |
As described in Table 6.1.9.3.3-2 |
|||
|
MIME body part |
MCData-Info |
|||
|
MIME-part-body |
MCData-Info as described in Table 6.1.9.3.3-3 |
|||
Table 6.1.9.3.3-2: SDP for SIP INVITE (Table 6.1.9.3.3-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.1-3, condition MCDATA_SDS, SDP_OFFER, SDS_SESSION, MCD_1to1 |
Table 6.1.9.3.3-3: MCDATA-Info (Table 6.1.9.3.3-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-3, condition MCD_1to1 |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
mcdata-info |
||||
|
mcdata-Params |
||||
|
request-type |
"one-to-one-sds-session" |
|||
Table 6.1.9.3.3-4: SIP 200 (OK) (step 2, Table 6.1.9.3.2-1;
step 4, TS 36.579-1 [2] Table 5.3C.2.3-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition INVITE-RSP |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Message-body |
||||
|
SDP message |
As described in Table 6.1.5.9.3-5 |
|||
Table 6.1.9.3.3-5: SDP for SIP 200 (OK) (Table 6.1.9.3.3-4)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-3, condition MCDATA_SDS, SDP_ANSWER, SDS_SESSION |
Table 6.1.9.3.3-6: MSRP SEND (step 7, Table 6.1.9.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3C.4.3-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.12.1-1 |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Content-Type |
||||
|
media-type |
"multipart/mixed" |
|||
|
data |
Message or chunk of message as specified in table 6.1.9.3.3-6A |
|||
Table 6.1.9.3.3-6A: MIME Message (step 7, Table 6.1.9.3.2-1;
step 3, TS 36.579-1 [2] Table 5.3C.4.3-1)
|
Derivation Path: RFC 2046 [38] |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
MIME body part |
MCData Data signalling message |
|||
|
MIME-part-headers |
||||
|
Content-Type |
"application/vnd.3gpp.mcdata-signalling" |
|||
|
MIME-part-body |
MCData Protected Payload Message containing SDS SIGNALLING PAYLOAD as described in table 6.1.9.3.3-6B |
|||
|
MIME body part |
MCData Data message |
|||
|
MIME-part-headers |
||||
|
Content-Type |
"application/vnd.3gpp.mcdata-payload" |
|||
|
MIME-part-body |
DATA PAYLOAD as described in Table 6.1.9.3.3-7 |
|||
Table 6.1.9.3.3-6B: SDS SIGNALLING PAYLOAD (Table 6.1.9.3.3-6A)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.1-1, condition DELIVERED |
Table 6.1.9.3.3-7: Data Payload (Table 6.1.9.3.3-6A)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.9.2-1 |
Table 6.1.9.3.3-8..9: Void
Table 6.1.9.3.3-10: MSRP SEND (step 8, Table 6.1.9.3.2-1;
step 1. TS 36.579-1 [2] Table 5.3C.5.3-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.12.1.2-1 |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Content-Type |
||||
|
media-type |
"application/vnd.3gpp.mcdata-signalling" |
|||
|
data |
MCData Protected Payload Message containing SDS NOTIFICATION as specified in table 6.1.9.3.3-11 |
|||
Table 6.1.9.3.3-11: SDS NOTIFICATION (Table 6.1.9.3.3-10)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.4-1, condition DELIVERED |
Table 6.1.9.3.3-12: MSRP SEND (step 11, Table 6.1.9.3.2-1;
step 1. TS 36.579-1 [2] Table 5.3C.5.3-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.12.1.2-1 |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Content-Type |
||||
|
media-type |
"multipart/mixed" |
|||
|
data |
Message as specified in table 6.1.9.3.3-12A |
|||
Table 6.1.9.3.3-12A: MIME Message (step 11, Table 6.1.9.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3C.5.3-1)
|
Derivation Path: RFC 2046 [38] |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
MIME body part |
MCData Data signalling message |
|||
|
MIME-part-headers |
||||
|
Content-Type |
"application/vnd.3gpp.mcdata-signalling" |
|||
|
MIME-part-body |
MCData Protected Payload Message containing SDS SIGNALLING PAYLOAD as described in table 6.1.9.3.3-13 |
|||
|
MIME body part |
MCData Data message |
|||
|
MIME-part-headers |
||||
|
Content-Type |
"application/vnd.3gpp.mcdata-payload" |
|||
|
MIME-part-body |
DATA PAYLOAD as described in Table 6.1.9.3.3-13A |
|||
Table 6.1.9.3.3-13: SDS SIGNALLING PAYLOAD (Table 6.1.9.3.3-12A)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.1-1, condition READ |
Table 6.1.9.3.3-13A: Data Payload (Table 6.1.9.3.3-12A)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.9.2-2 |
Table 6.1.9.3.3-14: MSRP SEND (step 1, Table 6.1.9.3.2-2;
step 3, TS 36.579-1 [2] Table 5.3C.4.3-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.12.1-1 |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Content-Type |
||||
|
media-type |
"application/vnd.3gpp.mcdata-signalling" |
|||
|
data |
MCData Protected Payload Message containing SDS NOTIFICATION as specified in table 6.1.9.3.3-15 |
|||
Table 6.1.9.3.3-15: SDS NOTIFICATION (Table 6.1.9.3.3-14)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.3-1, condition READ |
Table 6.1.9.3.3-16: SIP BYE (step 17, Table 6.1.9.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3C.6.3-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.2.1-1, condition MO_CALL |
Table 6.1.9.3.3-17: Void