Content for &nbsp; TS 23.280 &nbsp; Word version:&nbsp; 19.4.0

The MC service server sends an MBMS suspension reporting instruction to the MC service client.

RAN decides to suspend the MBMS bearer, according to existing procedures in TS 36.300.

An MBMS suspension indication is sent in the MSI (MCH Scheduling Information), according to existing procedures in TS 36.300.

Figure 10.7.3.9.2.1-1: Multiple server MBMS procedure

The MC service client detect the MBMS suspension and sends an MBMS suspension report.

MC service client that is not instructed to send an MBMS suspension report shall still detect the MBMS suspension indication from RAN (step 3). An MC service client shall in this case not send other types of report (e.g. MBMS listening reports).

The same procedure can be applied at MBMS resumption or other MBMS events that may be detected by the MC service client.

10.7.3.9 Multi-server bearer coordination p. 152

10.7.3.9.1 General p. 152

To avoid allocating duplicate bearers for an MBMS service area, a single MC service server may manage all the MBMS media transmission for all groups and users within a particular MBMS service area. An MC service server controlling the MBMS bearer has the MBMS bearer control role. Different MC service servers may allocate bearers as needed and make them available for other MC service servers to use. The use of the procedure in this sub clause is optional. MC system that supports multi-server bearer coordination shall use this procedure.

10.7.3.9.2 Procedures p. 152

10.7.3.9.2.1 MBMS bearer coordination independent on broadcasted media p. 152

The procedure in this sub clause may be used when two or more MC service servers are serving users in the same area and are configured to share MBMS bearers for that specific area. The MC service servers may be of the same kind or different kind. The MC service servers are not participating in the same group call, which means that each MC service server broadcast media independently of each other.

Pre-conditions:

All MC service servers are configured with the contact information of those MC service servers that are configured to take the MBMS bearer control role.

Reproduction of 3GPP TS 23.280, Fig. 10.7.3.9.2.1-1: Multiple server MBMS procedure

The MC service server 1 evaluates whether multicast is desired for each service area in which MC service group members are located, based upon the locations, affiliation status and other factors.

The MC service server 1 determines whether another MC service server has already established a bearer with coverage for the MBMS service area where multicast is desired. To do this, the MC service server 1 consults a pre-configured list of MC service servers and sends them a discover bearer request. This request may be sent to several MC service servers.

The MC service server 2 (MBMS bearer control role) responds with a discover bearer response indicating whether there is an MBMS bearer available in the specific MBMS service area with the requested bandwidth. The discover bearer response message includes the TMGI of the bearer that is shared between the MC service servers. If the bearer of interest has insufficient bandwidth, the polling MC service server 1 may resort to unicast, or may allocate another bearer for the congested area. If a duplicate bearer is allocated for the same area, the bearer should not be shared with other servers and may be torn down as soon as the congestion on the original bearer clears up, in order to conserve resources.

For any MBMS service areas not covered by another MC service server, the MC service server 1 prepares to distribute media to those MBMS service areas via multicast by setting up a bearer. The bearer set up by the MC service server 1 may then become available for other MC service servers (controlling role) for other MC service groups.

The MC service server 1 performs the MBMS bearer announcement and the MBMS listening reporting according relevant procedures specified in this specification. If the MC service server 2 is authorized to receive MBMS related location information from the users utilizing the services from MC service server 1, the MC service server 2 may optionally do the MBMS bearer announcement and handling the listening reports on behalf of MC service server 1. Listening reports shall in this case be sent to both MC service server 1 and MC service server 2.

The MC service server 1 sends a media distribution request to the MC service server 2 (MBMS bearer control role). The media distribution request is sent to reserve the specified capacity in the MBMS bearer.

MC service server 2 (MBMS bearer control role) sends a media distribution response to the MC service server 1 indicating whether the request can be supported and supplies details about the bearer.

Figure 10.7.3.9.2.2-1: Multiple server MBMS procedure

The MC service server 1 establishes a group communication session via the bearer, informing MBMS connected MC service clients 1 and 2 that a group communication session is about to start on the MBMS bearer. This step is equivalent to MapGroupToBearer in MCPTT.

Step 8.

MC service client 2 sends media on the uplink to the MC service server 1

Step 9.

The MC service server 1 forwards the media to MC service server 2 (MBMS bearer control role).

Step 10.

The MC service server 2 (MBMS bearer control role) distributes the media to MBMS served MC service client 1 via multicast.

Step 11.

The MC service server 1 sends a media distribution release request, informing the MC service server 2 (MBMB bearer control role) to request the MC service server 2 (MBMS bearer control role) to release the capacity that was reserved in step 5.

Step 12.

The MC service server 2 (MBMS bearer control role) respond to the request by sending a media distribution release request.

10.7.3.9.2.2 MBMS bearer coordination within one group call p. 154

The procedure in this sub clause may be used when two MC service servers are serving users in the same area and are configured to share MBMS bearers for that specific area. The MC service servers are of the same kind, and the MC service servers may participate in the same group call, and by that have a need to broadcast the same content.

Pre-conditions:

All MC service servers are configured with the contact information of those MC service servers that are configured to take the MBMS bearer control role.

Reproduction of 3GPP TS 23.280, Fig. 10.7.3.9.2.2-1: Multiple server MBMS procedure

The MC service server 1 evaluates whether multicast is desired for each service area in which MC service group members are located, based upon the locations, affiliation status and other factors.

Figure 10.7.3.10.2-1: MBMS bearer event notification

The MC service client 2 initiate a group call that is subject for multicast transmission. In this scenario there are more than one MC service server (i.e. MC service server 1 and MC service server 3) that serves MC service clients that are affiliated to the group, and by that should receive the media in the group call.

Step 6a.

The MC service server 1 sends a media distribution request to the MC service server 2 (MBMS bearer control role). The media distribution request includes the MC group identifier. This indicates that the media distribution request is used for this specific group call.

Step 6b.

The MC service server 3 sends a media distribution request to the MC service server 2 (MBMS bearer control role). The media distribution request includes the MC group identifier. This indicates that the media distribution request is used for this specific group call.

Step 7a.

The MC service server 2 (MBMS bearer control role) sends a media distribution response to the MC service server 1 indicating whether the request can be supported and supplies details about the bearer. This also includes details on which media stream that should be used for broadcasting the media on the MBMS bearer. This information is used in the MapGroupToBearer message sent by the MC service server when setting up the group call.

Step 7b.

The MC service server 2 (MBMS bearer control role) sends a media distribution response to the MC service server 3 indicating that the group call is already transmitted on the MBMS bearer by another MC service server. Based on the information, the MC service server 3 could decide to not broadcast media if media is already being broadcasted.

Step 8a.

The media is sent from the MC service client 2 to MC service server 1, which is the participating server for the MC service group of the group call.

Step 8b.

The media is forwarded to all MC service servers that are serving users that takes part in the group call.

Step 9.

The MC service server 1 forwards the media to MC service server 2 (MBMS bearer control role).

Step 10.

The MC service server 2 (MBMS bearer control role) distributes the media to MBMS served MC service client 1 via multicast.

Step 11.

The MC service server 1 sends a media distribution release request, informing the MC service server 2 (MBMS bearer control role) to request the MC service server 2 (MBMS bearer control role) to release the capacity that was reserved in step 5. The media distribution release request shall only be sent when the group call is terminated.

Step 12.

The MC service server 2 (MBMS bearer control role) respond to the request by sending a media distribution release request.

10.7.3.10 MBMS bearer event notification |R15| p. 156

10.7.3.10.1 General p. 156

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.

10.7.3.10.2 Procedure p. 157

The procedure in Figure 10.7.3.10.2-1 shows notification information flows from MC service server to BM-SC.

Reproduction of 3GPP TS 23.280, Fig. 10.7.3.10.2-1: MBMS bearer event notification

The MC service server activates an MBMS bearer. The activation of the MBMS bearer is done on the MB2-C reference point and according to TS 23.468.

The BMSC will respond to the activation with an Activate MBMS bearer response message, according to TS 23.468.

The EPC and RAN will initiate the MBMS session start procedure according to TS 23.246. This procedure is outside the scope of this specification.

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 MC service server starts to use the MBMS bearer according to the MBMS procedures in this specification.

An event from RAN related to the MBMS session is received by the BM-SC.

Figure 10.7.3.11.2-1: Application of FEC by the BM-SC

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.

Step 8.

The MC service server may decide, based on the received events, to switch to unicast transmission for relevant MC service clients.

10.7.3.11 Use of FEC to protect MBMS transmissions |R15| p. 158

10.7.3.11.1 General p. 158

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.

10.7.3.11.2 FEC encoding by the BM-SC p. 158

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.

Reproduction of 3GPP TS 23.280, Fig. 10.7.3.11.2-1: Application of FEC by the BM-SC

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 server sends the downlink media to the BM-SC on the MB2-U reference points and according to TS 23.468.

The BM-SC performs FEC encoding of the downlink media in accordance to the announced FEC algorithm and parameters and delivers it over MBMS.

Figure 10.7.3.11.3-1: Application of FEC by the MC service server

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.

10.7.3.11.3 FEC encoding by the MC service server p. 159

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.

Reproduction of 3GPP TS 23.280, Fig. 10.7.3.11.3-1: Application of FEC by the MC service server

The MC service server sends MBMS bearer announcement message with FEC information to the MC service clients.

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 performs FEC encoding and processing in accordance with the selected FEC algorithm.

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

Figure 10.7.3.12.2-1: Header compression by the MC service server

MC service client performs FEC decoding and processing in accordance with the selected FEC algorithm

10.7.3.12 Header compression over MBMS with ROHC |R15| p. 160

10.7.3.12.1 General p. 160

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

10.7.3.12.2 Header compression by the MC service server p. 160

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.

Reproduction of 3GPP TS 23.280, Fig. 10.7.3.12.2-1: Header compression by the MC service server

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

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 performs header compression in accordance with the ROHC information.

The MC service server sends the header compressed media to the MC service client

Figure 10.7.3.12.3-1: Header compression by the BM-SC

The MC service client performs header decompression in accordance to the ROHC information

10.7.3.12.3 Header compression by the BM-SC p. 161

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.

Reproduction of 3GPP TS 23.280, Fig. 10.7.3.12.3-1: Header compression by the BM-SC

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.

If the BM-SC can satisfy the request, the Setup ROHC response confirm the application of header compression.

The MC service server announces the MBMS bearer to the MC service client with the MBMS bearer announcement procedure, including the ROHC information.

The MC service server sends the downlink media to the BM-SC on the MB2-U reference points and according to TS 23.468.

The BM-SC compresses headers of the downlink media in accordance to the announced ROHC parameters and delivers it over MBMS.