7 FD media plane procedures

24.5823GPPMission Critical Data (MCData) media plane controlProtocol specificationRelease 17TS

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

7.1 MCData client procedures

7.1.1 General

For file distribution, upon receiving a request from the user or user application the originating client establishes the media plane as specified in 3GPP TS 24.282 [8].

The procedures in clause 7.1.2 and clause 7.1.3 are applicable for one-to-one and group file distribution.

A MCData client which is not permitted to transmit data should not use the procedure in clause 7.1.2.

7.1.2 Originating MCData client procedures

7.1.2.1 Handling MSRP connection

Upon receiving an indication to establish MSRP connection for file distribution as the originating 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]; and

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].

On receiving MSRP 200 (OK) response to the first MSRP SEND request, the MCData client can send the file. To send the file, the MCData client:

1. shall generate MSRP SEND for file distribution request according to IETF RFC 4975 [11]. When generating an MSRP SEND, the MCData client:

a. shall set To-Path header according to the MSRP URI(s) received in the answer SDP;

b. shall set the Content-Type header field = to "application/vnd.3gpp.mcdata-file"; and

c. shall include in the body of the MSRP SEND request the MSRP payload. The MSRP payload is set to the file or part of the file.

2. shall send the MSRP SEND request(s) on the established MSRP connection.

If MSRP chunking is used, the MCData client:

1. shall send further MSRP SEND requests containing the file as necessary;

2. shall wait for a 200 (OK) response to each MSRP SEND request sent; and

3. on receipt of the last 200 (OK) response shall terminate the SIP session as specified in 3GPP TS 24.282 [8].

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;

2. shall indicate to MCData user that the file could not be distributed; and

3. shall terminate the SIP session as specified in 3GPP TS 24.282 [8].

7.1.3 Terminating MCData client procedures

7.1.3.1 Handling MSRP connection

Upon receiving an indication to establish MSRP connection for file distribution as the terminating client, the MCData client:

1. shall act as an MSRP client according to IETF RFC 6135 [12];

2. shall act either as an active endpoint or as an passive endpoint to open the transport connection, according to IETF RFC 6135 [12];

3. shall establish the MSRP connection according to the MSRP connection parameters in the SDP offer received in the SIP INVITE request according to IETF RFC 4975 [11];

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 file before delivering the content to the application; and

3. shall handle the received content as described in clause 7.1.3.2.

7.1.3.2 Handling received content and disposition requests

Upon receiving a file, the MCData client:

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

2. once all the chunks of the file are successfully received, shall indicate to the signalling plane that the file download is completed.

7.2 Participating MCData function procedures

7.2.1 General

For a one-to-one or group file distribution, the media plane is established between the originating MCData client and the originating participating MCData function, the originating participating MCData function and the controlling MCData function, the controlling MCData function and the terminating participating MCData function(s) and each terminating participating MCData function and the terminating MCData client(s) as specified in 3GPP TS 24.282 [8]. The procedures in clause 7.2.2 and clause 7.2.3 are applicable for one-to-one and group file distribution.

7.2.2 Establishing MSRP session to receive the file

To receive a file over MSRP, the participating MCData function:

1. shall act according to IETF RFC 6135 [12], as:

a. an "passive" endpoint, if a=setup attribute in the sent SDP answer was set to "passive"; and

b. an "active" endpoint, if a=setup attribute in the sent SDP answer was set to "active"; and

2. shall establish an MSRP connection according to the MSRP connection parameters in the sent SDP answer response as described in IETF RFC 4976 [14].

7.2.3 Establish MSRP session to send the file

To send a file over MSRP, the participating MCData function:

1. 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"; and

2. shall establish the MSRP connection according to the MSRP connection parameters in the received SDP answer response as described in IETF RFC 4976 [14].

7.2.4 Originating participating MCData function procedures

7.2.4.1 Establish MSRP session with the originating MCData client

The originating participating MCData function should establish the MSRP session with the originating MCData client as specified in clause 7.2.2.

7.2.4.2 Establish MSRP session with the controlling MCData function

The originating participating MCData function should establish the MSRP session with the controlling MCData function as specified in clause 7.2.3.

7.2.4.3 Handling of received MSRP messages

Upon receiving an MSRP SEND request from the originating MCData client, the originating participating MCData function:

1. if an MSRP connection is not established with the controlling MCData function then, shall establish the MSRP connection as specified in clause 7.2.4.2. Otherwise, shall use the existing MSRP connection; and

2. shall forward the received MSRP SEND request to the controlling MCData function according to the rules and procedures of IETF RFC 4975 [11].

Upon receiving an MSRP 200 (OK) response from the controlling MCData function, the participating MCData function shall forward the MSRP 200 (OK) response to the originating MCData client according to the rules and procedures of IETF RFC 4975 [11].

Upon receiving an error MSRP response from the controlling MCData function, the participating MCData function shall forward the error MSRP response to the originating MCData client according to the rules and procedures of IETF RFC 4975 [11].

7.2.5 Terminating participating MCData function procedures

7.2.5.1 Establish MSRP session with the controlling MCData function

The terminating participating MCData function should establish the MSRP session with the controlling MCData function as specified in clause 7.2.2.

7.2.5.2 Establish MSRP session with the terminating MCData client

The terminating participating MCData function should establish MSRP session to terminating MCData client as specified in clause 7.2.3.

7.2.5.3 Handling of received MSRP messages

Upon receiving an MSRP SEND request from the controlling MCData function, the terminating participating MCData function:

1. shall generate and send a MSRP 200 (OK) response for the received MSRP SEND request to the controlling MCData function, according to the rules and procedures of IETF RFC 4975 [11]; and

2. if the indication to store the received file for later delivery is received from the signaling plane, the participating function:

a) shall receive and store the file; and

b) shall indicate to the signalling plane that the file download is completed as specified in 3GPP TS 24.282 [8] clause 10.2.5.3.4;

otherwise:

a) shall forward the received MSRP SEND request to the terminating MCData client according to the rules and procedures of IETF RFC 4975 [11].

Upon receiving an error MSRP response from the terminating MCData client, the participating MCData function shall forward the error MSRP response to the originating MCData client according to the rules and procedures of IETF RFC 4975 [11].

7.3 Controlling MCData function procedures

7.3.1 General

7.3.2 Establishing MSRP session

7.3.2.1 MSRP session establishment with originating MCData client

To establish the MSRP connection with the originating MCData client, the controlling MCData function performs below procedures:

1. shall act as an MSRP client and establish TLS connection with the originating participating MCData function, if exists, otherwise the originating MCData client, according to the rules and procedures as described in IETF RFC 4975 [11];

2. shall act as an MSRP client to send MSRP SEND requests according to the rules and procedures described in IETF RFC 6135 [12];

3. shall act as an "passive" endpoint according to the rules and procedures described in IETF RFC 6135 [12];

4. shall establish the MSRP connection with originating MCData client, according to the rules and procedures described in IETF RFC 6135 [12]; and

5. acting as a "passive" endpoint, shall wait for MSRP SEND request on established MSRP connection, to bind the MSRP connection to the MSRP session according to the rules and procedures of IETF RFC 4975 [11] and IETF RFC 6135 [12].

7.3.2.2 MSRP session establishment with terminating MCData client

To establish the MSRP connection with the terminating MCData client, the controlling MCData function performs below procedures:

1. shall act as an MSRP client and establish TLS connection with the terminating participating MCData function, if exists, otherwise the terminating MCData client, according to the rules and procedures as described in IETF RFC 4975 [11];

2. shall act as an MSRP client to send MSRP SEND requests according to the rules and procedures described in IETF RFC 6135 [12];

3. 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";

4. shall establish the MSRP connection with each terminating MCData client identified in the 3GPP TS 24.282 [8], according to the rules and procedures described in IETF RFC 6135 [12]; and

5. if acting as an "active" endpoint, shall send an empty MSRP SEND request on each established MSRP connection, to bind the MSRP connection to the MSRP session according to the rules and procedures of IETF RFC 4975 [11] and IETF RFC 6135 [12].

7.3.3 Handling of received MSRP messages

Upon receiving a MSRP SEND request from the originating participating MCData function, the Controlling function:

1. shall generate and send a MSRP 200 (OK) response for the received MSRP SEND requests to the originating participating MCData function, according to the rules and procedures of IETF RFC 4975 [11]; and

2. shall forward the received MSRP SEND requests to each terminating MCData client with which a successful MSRP connection was established, according to the rules and procedures of IETF RFC 4975 [11]. Following clarifications apply to the generated MSRP SEND request:

a. shall modify the To-Path header according to the MSRP URI received in the answer SDP from the MCData client in accordance with rules and procedures of IETF RFC 4975 [11]; and

b. shall modify the From-Path header to the controlling MCData function’s own MSRP URI, according to the rules and procedures of IETF RFC 4975 [11].

7.4 FD using MBMS delivery via MB2 interface

7.4.1 General Description

The procedures for group FD using MBMS delivery via the MB2 interface can be seen as extensions of the procedures for group FD media delivery using unicast. The procedures of the originating client, originating participating function and controling function are those used for unicast session delivery for group FD. Only the terminating participating function and the terminating client are involved in MBMS delivery over MB2 interface functionality for group FD.

The procedures assume that consistent with 3GPP TS 24.282 [8], an MSRP session has already been established and the originating and terminating MCData clients have already completed successfully the SDP offer/answer negotiation. It is further assumed that the terminating MCData participating function has already sent an MBMS bearer announcement message providing information about the MBMS bearer and subchannel intended for MBMS delivery and that the terminating MCData client has received and processed the MBMS bearer announcement message, as described in 3GPP TS 24.282 [8].

During the session, the terminating MCData participating function intercepts MSRP SEND messages arriving from the originating side, and, after eliminating duplicates, encapsulates them unchanged as payload in (S)RTP/UDP/IP (see IETF RFC 3711 [17]) packets and transmits them on an MBMS bearer towards the terminating MCData client. Upon reception, the terminating MCData client decapsulates the payload and processes it as an MSRP SEND message within the MSRP session, arriving from the originating side.

NOTE 1: Since MSRP chunking is supported for unicast delivery, it is also supported for MBMS delivery.

NOTE 2: If SRTP (see IETF RFC 3711 [17]), rather than RTP, is used to securely protect packets sent on MBMS bearer, MuSiK (see 3GPP TS 24.282 [8] and 3GPP TS 33.180 [15]) may be employed to provide protection in addition to the security mechanisms that protect the unicast MSRP traffic.

NOTE 3: The terminating participating function, which can use listening status reports from the MCData clients, the presence, absence or content of the FILE DOWNLOAD COMPLETED report, as well as other information, decides whether to use unicast or MBMS delivery on an individual MCData client and file basis. At any time during a session, the terminating participating server can toggle between unicast and MBMS delivery.

7.4.2 Procedures for the terminating MCData client

7.4.2.1 Handling the MSRP connection

The terminating MCData client shall execute the procedure for MSRP connection establishment described in clause 7.1.3.1.

7.4.2.2 Receiving Map Group To Bearer and Unmap Group To Bearer

While MBMS delivery is expected, the terminating MCData client shall monitor the general purpose MBMS subchannel.

When receiving a Map Group To Bearer message over the general purpose MBMS subchannel, the MBMS interface in the MCData client:

1) shall associate the TMGI in the TMGI field, the MBMS subchannel for media with the MCData group identity in the MCData Group ID field; and

2) shall start or continue the procedure described in clause 7.4.2.3.

When receiving the Unmap Group To Bearer message referring to the current communication over a MBMS subchannel, the MBMS interface in the MCData client:

1) shall remove the association between the TMGI, the MBMS subchannel for media in the group session identified by the MCData Group ID field, if such an association exists; and

2) shall cease monitoring the associated MBMS bearer and subchannel for media and, if the MSRP session is still ongoing, shall resume or continue file delivery via media plane over unicast.

7.4.2.3 Receiving media packets

The terminating MCData client shall:

1. while MBMS delivery is expected, monitor the MBMS bearer and subchannel indicated by the Map Group To Bearer message; and

2. for each received (S)RTP media packet, until a SIP BYE is received or until an implementation dependent timeout occurs:

a. decapsulate the payload out of the (S)RTP packet and, if SRTP rather than RTP is used (see IETF RFC 3711 [17]), decrypt and validate the payload;

b. if the media packet was received via an MBMS bearer with the TMGI associated to the group, accept the payload as correctly destined for the terminating MCData client, regardless of whether or not the To‑Path header of the MSRP SEND message in the payload matches the terminating MCData client’s MSRP URI (i.e. the MSRP URI provided in the answer SDP to the controlling function during the MSRP session establishment, in accordance with rules and procedures of IETF RFC 4975 [11]); and

c. process the payload as a received MSRP SEND message during the established MSRP session, according to clause 7.1.3.1, in the context of the media flow formed by previously received MSRP SEND messages, whether delivered via unicast or via MBMS.

7.4.3 Procedures for the terminating MCData participating function

7.4.3.1 Establishing MSRP sessions

The terminating MCData participating function:

1. shall establish an MSRP session with the controlling MCData function according to clause 7.2.5.1; and

2. shall establish an MSRP session with the terminating MCData client according to clause 7.2.5.2.

7.4.3.2 Sending Map Group To Bearer and Unmap Group To Bearer

The terminating MCData participating function:

1. shall build a Map Group To Bearer message (see clause 11.2.4) to include:

a. the TMGI of the MBMS bearer to carry the traffic;

b. the identifier of the media stream; and

c. the MCData Group identifier field; and

2. shall send (repetitively, at short, implementation dependent time intervals) the Map Group To Bearer message over the general purpose MBMS subchannel.

When the MSRP session with the terminating MCData client (see clause 7.4.3.1) ends, the terminating MCData participating function shall build the corresponding Unmap Group To Bearer message (see clause 11.2.5) and shall send it over the general purpose MBMS subchannel.

7.4.3.3 Receiving media packets intended for a terminating MCData client

When receiving an MSRP SEND message that the terminating participating function considers qualified for MBMS delivery and is destined to one of the MCData clients listening to the MBMS subchannel, the terminating participating MCData function:

NOTE 1: An MSRP SEND message that does not qualify for MBMS delivery or is not destined to an MCData client listening to the MBMS subchannel is handled as an MSRP SEND message to be delivered over unicast (see clause 7.2.5.3).

1. shall generate and send an MSRP 200 (OK) response for the received MSRP SEND message to the controlling MCData function, according to the rules and procedures of IETF RFC 4975 [11];

2. shall check if the media packet that encapsulates the MSRP SEND message is already sent over the MBMS subchannel or not;

3. if the media packet is already sent over the MBMS subchannel, shall discard the MSRP SEND message; and

4. otherwise:

a. shall build an (S)RTP/UDP/IP (see IETF RFC 3711 [17]) media packet with the IP address and UDP port number indicated in the sent Map Group To Bearer message and with the received MSRP SEND message as payload, security protected if SRTP is used, per IETF RFC 3711 [17] and 3GPP TS 33.180 [15]; and

b. shall transmit the built (S)RTP/UDP/IP packet on the MBMS bearer identified by the TMGI indicated in the sent Map Group To Bearer message.

NOTE 2: To save over-the air resources, the terminating MCData participating function releases or reduces the bandwidth of the unicast downlink bearers used for unicast file delivery. However, to enable the ability of rapid switching between unicast and MBMS delivery, the terminating MCData participating function can keep the unicast bearers intact.

Upon receiving error MSRP responses (see IETF RFC 4975 [11]) from the terminating MCData client, the terminating MCData participating function shall forward the error MSRP responses towards the originating MCData client.