8A Group Communication Delivery Method

26.3463GPPMultimedia Broadcast/Multicast Service (MBMS)Protocols and codecsRelease 17TS

8A.1 Overview

The MBMS group communication delivery method delivers a UDP/IP packet flow to the UE. The BM-SC provides group communication delivery by receiving UDP/IP packets and forwarding them over the MBMS path provided by the MBMS Bearer Service. Both IPv4 and IPv6 may be used by the group communication delivery method.

Figure 8A.1 depicts a reference model of the GCSE architecture with a MCPTT Server as the GCS AS, and shows how GCS application data is ingested by the BM-SC via the MB2 interface.

Figure 8A.1: Reference Model of GCS Architecture for MCPTT service delivery over eMBMS via BM-SC group communication delivery method

8A.2 Transport Method

The application transport protocol on top of the MB2 UDP/IP is transparent to the BM-SC and is not defined in this specification.

Upon reception of GCS AS UDP/IP packets, the BM-SC removes the UDP/IP header and performs UDP/ IP encapsulation of the user plane IP data that was received over the MB2-U interface.

NOTE: The current release of this specification does not define any FEC for the group communication delivery method.

If requested by the GCS-AS over the MB2 interface, the BM-SC shall perform ROHC header compression over the broadcast link (between BM-SC and UE). The header compression shall be applied on the encapsulated UDP/IP packets according to the limitations in section 8A.4.

If FEC protection is requested by the GCS-AS, the BM-SC shall use the MBMS FEC scheme as specified by section 8.2.2.

8A.3 Signalling of GCS application service content

8A.3.1 General

The GCS AS signals the GCS application service content to the UE over the GC1 interface.

The GCS application client in the UE will use the signalled information provided by the GCS AS to enable reception of GCS application data over the appropriate MBMS Bearer(s). This signalling shall include TMGI associated to this MBMS bearer, multicast IP address, UDP port and source IP address. The MCPTT server signals group calls over MBMS by combining the announcement of the MBMS bearer (3GPP TS 23.280 [141]), which provides the TMGI and session description parameters, and signalling messages, which indicates the delivery start over MBMS of a group call and provides additional media parameters (3GPP TS 23.379 [142]).

8A.3.2 Void

8A.4 ROHC for GC Delivery Method

8A.4.1 General

If ROHC is enabled through the MB2 for the GC delivery session, then the following conditions shall apply:

– Only the U-mode shall be used throughout the lifetime of the session. Other modes shall not be used.

– A single ROHC channel per GC delivery session shall be used.

– Exactly one of the following alternatives as specified in [138] shall be used:

– the RTP/UDP/IP profile with identifier 0x0001,

– the UDP/IP profile with identifier 0x0002, or

– the uncompressed IP profile with identifier 0x0000.

– UDP flow encoded with profile 0x0001 or profile 0x0002 shall use different context IDs.

– A common context ID may be used for all flows encoded with profile 0x0000.

– The LARGE_CIDS flag may be set to true. LARGE_CIDS value can be derived from the value from the MAX_CID flag.

– ROHC segmentation shall not be used and the MRRU value shall be set to 0

If indicated by the MB2, FEC protection shall also be applied according to the FEC scheme defined in 8.2.2.

8A.5 SDP Exchange for FEC support with the Group Communication delivery method

The GCS-AS can request the BM-SC to apply FEC to protect the flow delivered with the group communication delivery method, as specified in [120] and [121], by including the FEC-Request AVP in the MBMS‑Bearer‑Request AVP. The FEC-Request AVP contains a SDP describing the FEC framework configuration information (see subclause 5.5 of IETF RFC 6363 [31]), which includes identification of the set of source flows, repair flows, and other FEC parameters.

To describe the FEC framework configuration information,

– the exchanged SDP shall include the sender IP address, using the source-filter attribute ("a=source-filter:") as specified in 8.3.3.1,

– the exchanged SDP shall include the destination IP address using the "connection data" field ("c="), as specified in 8.3.3.2,

– the exchanged SDP shall include, at session level, a FEC declaration attribute ("a=FEC-declaration") as specified in 7.3.2.8, a "a=FEC-OTI-extension" attribute specified in 8.3.1.8 and a "a=mbms-repair" attribute, as specified in 8.3.1.8,

– for each RTP/UDP source flow to be protected by FEC, the exchanged SDP shall include a media block

– where the media (‘m-line’) provides the destination port, as specified in 8.3.3.2, and uses ‘UDP/MBMS-FEC/RTP/AVP’ or ‘UDP/MBMS-FEC/RTP/SAVP’ as protocol identifier (see 8.2.2.13a)

– with the "a=FEC" attribute, specified in 7.3.2.8.

– for each repair flow, the exchanged SDP shall include a media block

– where the media (‘m-line’) provides the destination port, as specified in 8.3.3.2, and uses ‘UDP/MBMS-REPAIR’ as protocol identifier (see 8.2.2.13a),

– with the "a=mbms-flowid" attribute, as specified in 8.3.1.9.

The exchanged SDP may also include bandwidth information, as specified in 8.3.1.7.The BM-SC identifies the input RTP source flows to be FEC encoded, based on the source address, destination address and destination port listed in the media blocks using ‘UDP/MBMS-FEC/RTP/AVP’ or ‘UDP/MBMS-FEC/RTP/SAVP’ as protocol identifier. Encoded source flows are outputted by the BM-SC on the same destination address and port.

Source flows that are not described in the exchanged SDP are directly delivered without FEC encoding.