The MC service server is an instantiation of a GCS AS. For the MC service server to know the status of the MBMS bearer, and thus know the networks ability to deliver the service, it is required that the network provides MBMS bearer event notifications to the MC service server. The different events notified to the MC service server include the MBMS bearer start result (e.g. when the first cell successfully allocated MBMS resources), including information if any cells fail to allocate MBMS resources to a specific MBMS bearer, the current status of the MBMS bearer, MBMS bearer suspension/resume or overload scenarios.
At the first indication of a successful MBMS session start procedure, the BM-SC sends a MBMS bearer event notification, indicating that the MBMS bearer is ready to use.
The BM-SC notifies the MC service server of certain MBMS related events including references to affected MBMS services areas or list of cells. Example of such events may be radio resources not available, overload, MBMS suspension.
Application layer FEC can be used to recover the packet losses when delivering a MC service over MBMS, to reach its required level of QoS.
Support of FEC is optional for the MC service servers and MC service clients
Adding FEC introduces an extra latency in the end to end media transport. This extra latency is bounded to fulfil the low latency requirements for mission critical services.
FEC can be applied by the BM-SC if required by the MC service server (subclause 10.7.3.11.2), or directly by the MC service server (subclause 10.7.3.11.3). FEC is decoded by the MC service client. Either method is independent of the other.
The MC service server may consider the listening status reports from previous MBMS bearer quality detection procedures (subclause 10.7.3.6) to adjust the FEC parameters when delivering over a new MBMS bearer.
In this procedure, depicted in Figure 10.7.3.11.2-1, the MC service server asks the BM-SC to apply FEC to a set of medias, transported by a MBMS bearer, using the Setup FEC request.
This procedure can be applied when using pre-established MBMS bearers (10.7.3.1) or dynamic MBMS bearers (10.7.3.2).
Pre-condition:
The MC service server has already activated a MBMS Bearer, with the MBMS Bearer request specified in TS 23.468.
The MC service server decides to set up FEC for a set of MC service media flows. The request is done on the MB2-C reference point. It includes the following elements: the TMGI of the bearer transporting those media, the media descriptions (codecs, transport protocols, bitrates, destination ip addresses and ports), the identification of the FEC repair packet flow (IP destination and port), an upper bound to the additional latency resulting to FEC application. The MC Service server may perform this request several times to protect separately different sets of media transported within the same MBMS bearer.
If the BM-SC can satisfy the request, the Setup FEC response includes a modified list of media information and FEC information. The response also includes an identifier to the FEC process instance, which can be used to release the application of FEC for these media flows.
The MC service server announces the MBMS bearer to the MC service client with the MBMS bearer announcement procedure, including the modified list of medias information and FEC information within the SDP information.
When the MC service server decides to transmit the MC service media flow for a group communication, the MC service server sends to the group a message identifying the MC service media flow and the TMGI of the MBMS bearer, such as the MapGroupToBearer message for MCPTT, specified in TS 23.379, or the MapGroupToBearer message for MCVideo, specified in TS 23.380.
The MC service client performs FEC decoding of the encoded media flows in accordance to the announced FEC information and delivers the decoded flows to the media player.
In this procedure, depicted in Figure 10.7.3.11.3-1, FEC encoding is performed by the MC service server. The MC service server includes the FEC information within the MBMS bearer announcement. The FEC decoding is performed by the MC service client.
As media packets arrive from the originating MC service UE (not shown in diagram), the media is processed by the media distribution function on the MC service server.
The MC service server sends the media with FEC to the MC service client (both payload source packets and the FEC repair packets are sent on the MB2-U to the BM-SC, which transparently forwards them unmodified to the MC service client).
Support of ROHC over MBMS is optional for the MC service servers and MC service clients. If header compression and FEC are both applied to a communication over MBMS, the header compression shall be performed after the FEC encoding.
These procedures can be applied when using pre-established MBMS bearers (see clause 10.7.3.1) or dynamic MBMS bearers (see clause 10.7.3.2).
In this procedure, depicted in Figure 10.7.3.12.2-1, header compression is performed by the MC service server. The MC service server includes the ROHC information within the MBMS bearer announcement. The header decompression is performed by the MC service client.
The MC service server sends MBMS bearer announcement message with ROHC information to the MC service clients. The ROHC information contains the list of ROHC profiles and the ROHC context identifier range).
When the MC service server decides to transmit the MC service media flow for a group communication, the MC service server sends to the group a message identifying the MC service media flow and the TMGI of the MBMS bearer, such as the MapGroupToBearer message for MCPTT, specified in TS 23.379, or the MapGroupToBearer message for MCVideo, specified in TS 23.281.
As media packets arrive from the originating MC service UE (not shown in diagram), the media is processed by the media distribution function on the MC service server.
In this procedure, depicted in Figure 10.7.3.12.3-1, the MC service server asks the BM-SC to compress headers for a set of medias, transported by a MBMS bearer, using the Setup ROHC request.
Pre-condition:
The MC service server has already activated a MBMS Bearer, with the MBMS Bearer request specified in TS 23.468.
The MC service server decides to set up ROHC within a MBMS bearer. The request is done on the MB2-C reference point. It includes the following elements: the ROHC configuration, the list of RTP and UDP flows to be header compressed, characterized by their destination IPs and port numbers. For each of these flows, the request may indicate a target periodicity for the full header packets.
When the MC service server decides to transmit the MC service media flow for a group communication, the MC service server sends to the group a message identifying the MC service media flow and the TMGI of the MBMS bearer, such as the MapGroupToBearer message for MCPTT, specified in TS 23.379, or the MapGroupToBearer message for MCVideo, specified in TS 23.281.
The MC service server, e.g., MCPTT server, may use the MBMS bearer to inform the status of a group communication (indicating the group call is on-going or not) when the group call is set up on unicast bearers. The affiliated clients that will perform late entry chat group calls or rejoin calls may use this group status information to decide whether to join the calls. The information flows for group status notification are specified in subclause 10.7.2.12.