10.7.3 Procedures for MBMS usage

23.2803GPPCommon functional architecture to support mission critical servicesRelease 18Stage 2TS

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

10.7.3.1 Use of pre-established MBMS bearers

10.7.3.1.1 General

In this scenario, the MC service server pre-establishes MBMS bearer(s) in certain pre-configured areas before the initiation of the group communication session. When a user originates a request for a group communication session for one of these areas, the pre-established MBMS bearer(s) is used for the DL media transmission.

The following steps needs to be performed prior the start of the MC group communication session over pre-established MBMS bearer:

– MBMS bearer(s) is Pre-established

– Announce the pre-established MBMS bearer to the MC service clients

When these preparation steps have been done the MC group communication session using MBMS bearer can start.

Both the media packets as well as the application level control signalling (e.g. floor control messages) to the receiving MC service clients are sent on the MBMS bearer. Optionally a separate MBMS bearer could be used for the application level control messages, due to different bearer characteristic requirements.

10.7.3.1.2 Procedure

The procedure figure 10.7.3.1.2-1 shows only one of the receiving MC service clients using an MBMS bearer. There might also be MC service clients in the same MC group communication session that receive the communication on unicast bearers.

Pre-conditions:

– The participating users are already affiliated.

Figure 10.7.3.1.2-1: Use of pre-established MBMS bearers

1a. The MC service server determines to activate MBMS bearer. The activation of the MBMS bearer is done on the MB2-C reference point and according to 3GPP TS 23.468 [18]. This bearer will be used for the MC communication media.

1b. Optionally, the MC service server may also activate an MBMS bearer dedicated for application level control signalling. The activation of the MBMS bearer is done on MB2-C reference point and according to 3GPP TS 23.468 [18].

NOTE 1: The procedure to determine the activation of MBMS bearers is implementation specific.

2a. The MC service server passes the MBMS bearer info for the service description associated with the pre-established MBMS bearer to the MC service client. The MC service client obtains the TMGI, identifying the MBMS bearer, from the service description.

2b. The MC service server may pass the MBMS bearer info for the service description associated with the pre-established floor control MBMS bearer to the MC service client. The MC service client obtains the TMGI, identifying the MBMS bearer, from the service description.

NOTE 2: Step 2a and Step 2b can be done in one MBMS bearer announcement message.

3. The MC service client stores the information associated with the TMGI(s). The MC service client uses the TMGI and other MBMS bearer related information to activate the monitoring of the MBMS bearer by the MC service UE.

4. The MC service client that enters or is in the service area of at least one announced TMGI indicates to the MC service server that the MC service client is able to receive media over MBMS, whereby the MC service server may decide to use the MBMS bearer instead of unicast bearer for MC communication sessions.

NOTE 3: Step 4 is optional for the MC service UE on subsequent MBMS bearer announcements.

5. An MC service group communication session is established.

6. As the MC service server transmits the media over the MBMS bearer, the media packets are detected and delivered to the MC service client.

10.7.3.2 Use of dynamic MBMS bearer establishment

In this scenario depicted in figure 10.7.3.2-1, the MC service server uses a unicast bearer for communication with the UE on the DL at the start of the group communication session. When the MC service server decides to use an MBMS bearer for the DL media transmission, the MC service server establishes an MBMS bearer using the procedures defined in 3GPP TS 23.468 [18]. The MC service server provides MBMS service description information associated with MBMS bearer(s), obtained from the BM-SC, to the UE. The UE starts using the MBMS bearer(s) to receive DL media and stops using the unicast bearer for the DL media transmission.

NOTE 1: The MC service server logic for determining when to establish the new MBMS delivery bearer is implementation specific. For example, the MC service server could decide to establish the MBMS delivery based on the location of the UE’s that are a part of the group communication session.

Figure 10.7.3.2-1: Use of dynamic MBMS bearer establishment

1. An MC service group communication session is established.

2. The downlink data is sent by unicast delivery.

3. The MC service server establishes the MBMS bearer(s) for the group communication session according to the procedures defined in 3GPP TS 23.468 [18]. Service description associated with the MBMS bearer(s) is returned from the BM-SC.

4. The MC service server provides service description information associated with the MBMS bearer to the UE. The MC service UE obtains the TMGI from the announcement message. This message may be sent on an application level control signalling bearer.

5. The MC service UE starts monitoring data over MBMS associated with the TMGI, while in the service area associated with the TMGI.

6. The MC service UE detects that it is able to receive data over MBMS associated with the TMGI.

7. The MC service client notifies the MC service server the MBMS listening status associated to the monitored TMGI, (e.g. that it is successfully receiving the TMGI). The MC service client may also notify the MBMS reception quality level of the TMGI. MC service server stops sending media data over unicast way to the MC service client.

NOTE 2: The MBMS reception quality level may be used by the MC service server to make an efficient decision to switch again to a unicast transmission or to take measures to prepare such a switch (e.g. when the quality level indicates that the reception quality of the MBMS bearer is decreasing or reaching an insufficient quality level for the reception of MC services).

8. An MC service group communication session via dynamic MBMS bearer(s) is established.

NOTE 3: Step 8 can occur before step 7.

9. MC service server sends the downlink media for the group communication session over the MBMS.

10.7.3.3 Switching from MBMS bearer to unicast bearer

Figure 10.7.3.3-1 shows the procedure for service continuity when a UE is about to move out of MBMS coverage by switching from MBMS bearer to unicast bearer.

Pre-conditions:

– It is assumed that the MBMS bearer has been activated by MC service server for downlink delivery.

Figure 10.7.3.3-1: Switching from MBMS delivery to unicast delivery

1. The MC service UE detects that it suffers from bad MBMS bearer condition for the corresponding MBMS service. The method to detect is implementation specific.

2. The MC service client notifies the MC service server that it suffers from bad MBMS bearer condition for the corresponding MBMS service by sending the MBMS listening status report.

NOTE 1: To efficiently notify the MC service server, e.g., when the MC service client detects that the reception quality of the MBMS bearer is decreasing or reaching an insufficient quality level for the reception of MC services, the MC service client proactively may send to the MC service server a MBMS listening status report including the MBMS reception quality level.

3. The MC service server sends the downlink data by unicast delivery to the MC service client.

NOTE 2: The unicast bearer may be set up on demand after step 2 or before.

4. During the switching, the MC service client simultaneously receives downlink data through both unicast bearer and MBMS bearer. If there is no downlink data to the MC service client, this step can be skipped.

5. The MC service client ceases to receive the downlink data through MBMS bearer but continues receiving data through unicast bearer.

10.7.3.4 Use of MBMS bearer for application level control signalling

10.7.3.4.1 Description

The MC service server may use an MBMS bearer for application level control signalling, according to this subclause. An MBMS bearer for application level control signalling is typically used for the purposes beyond the benefit for using MBMS for resource efficiency, e.g. for improved MC service performance (KPIs), handling of high load scenarios.

The MBMS bearer for application level control signalling may be used to transmit the following messages:

– Transmission control (e.g. call setup and floor control)

– MBMS bearer announcement for media bearers

– Group application paging

– Group dynamic data (e.g. status of the group)

– Group state (e.g. emergency alerts)

An MBMS bearer for application level control signalling is activated in a service area that is larger than the estimated service for media bearers. The service area for the media bearers mainly based on counting of group members in each defined service area. The MBMS bearer for application level control signalling is also activated with a QoS that is better than MBMS media bearers since the packet loss requirements are much stricter.

The MC service client shall not send responses to group-addressed application level control signalling unless instructed or configured to respond.

10.7.3.4.2 Procedure

The procedure in figure 10.7.3.4.2-1 shows only one of the receiving MC service clients using an MBMS bearer.

Figure 10.7.3.4.2-1: Use of MBMS bearer for application level control signalling

1. The MC service server determines to activate MBMS bearer for application level control signalling, The activation of the MBMS bearer is done on the MB2-C reference point and according to 3GPP TS 23.468 [18].

2. The MC service server passes the MBMS bearer info for the service description associated MBMS bearer to the MC service client. The MC service client obtains the TMGI, identifying the MBMS bearer, from the service description.

3. The MC service client stores the information associated with the TMGI. The MC service client uses the TMGI and other MBMS bearer related information to activate the monitoring of the MBMS bearer by the MC service UE.

4. The MC service client that enters or is in the service area of the announced TMGI indicates to the MC service server that the MC service client is able to receive application level control messages over the MBMS bearer. The MC service client may also indicate at which MBMS reception quality level it has received the MC service media on the MBMS bearer. Hence, the MC service server may decide to use the MBMS bearer for MC application control messages.

5. The MC service server transmit MC application control messages

10.7.3.5 MBMS bearer announcement over MBMS bearer

10.7.3.5.1 Description

The MBMS announcement may be done on either a unicast bearer or a MBMS bearer. Using a unicast bearer for MBMS bearer announcement provides an interactive way of doing announcement. The MC service server will send the MBMS bearer announcement message to the MC service client regardless if there is an MBMS bearer active or the MC service client can receive the data on the MBMS bearer with sufficient quality. The benefit of the existing procedure is that it gives a secure way to inform the MC service client about the MBMS bearer and how to retrieve the data on the MBMS bearer.

When there is more than one MBMS bearer active in the same service area for MC service, there are not the same reasons to use unicast bearer for additional MBMS bearer announcement. Instead a MBMS bearer for application level control signalling can be used to announce additional MBMS bearers.

The MBMS bearer announcement messages are sent on an MBMS bearer used for application control messages. This bearer will have a different QoS setting compared to an MBMS bearer used for media, since application signalling messages are more sensitive to packet loss.

10.7.3.5.2 Procedure

The procedure defined below enables the MC service to announcement a new MBMS bearer.

Pre-conditions:

– An MBMS bearer used for MC service application control messages must have been pre-established and announced to the MC service client.

– Additional MBMS bearer information may have already been announced to the client.

Figure 10.7.3.5.2-1: MBMS bearer announcement over an MBMS bearer used for application control messages

1. The MC service client monitors an MBMS bearer that is used for MC service application signalling messages, such as bearer announcement messages.

2. The MC service server activates a new MBMS bearer.

3. The MC service server announce the MBMS bearer to the MC service client. The bearer may have just been activated or may have already been running for some time. The step may be repeated as needed.

4. The MC service server sends a MBMS bearer announcement on the MBMS bearer used for MC application control messages. The MBMS bearer announcement contains the identity of the MBMS bearer (i.e. the TMGI) and may optionally include additional information about the newly announced bearer. Required and optional MBMS bearer announcement details may have already been provided. In this case the MBMS bearer identity could be used as a key for such MBMS bearer details.

5. The MC service clients start to monitor the newly announced MBMS bearer.

6. If requested by the MC service server, the MC service client sends an acknowledgement of the MBMS bearer to the MC service server.

7. The MC service server de-announce the MBMS bearer.

8. The MC service server sends a MBMS bearer de-announcement message that contains the identity of the MBMS bearer.

9. The MC service client stops monitoring the de-announced MBMS bearer.

The same procedure can also be used to modify existing MBMS bearer announcement information. Example of such modification could be addition of UDP ports or modification of codec in the SDP.

10.7.3.6 MBMS bearer quality detection

10.7.3.6.1 Description

The MC service client and MC service server use this procedure to report and take action on the MBMS bearer quality. An MC service client monitors an MBMS bearer to receive MC service media. Based on the received quality (e.g. radio level quality, transport level quality), the MC service client needs to inform the MC service server that the MC service client is able to receive the MC service media on the MBMS bearer with sufficient quality or not able to receive the MC service media on the MBMS bearer with sufficient quality. Furthermore, based on the received quality, the MC service client may notify the MC service server at which MBMS reception quality level it has received the MC service media on the MBMS bearer.

The issue can be more complex since the MC service client needs to estimate the quality of the bearer even in the scenario when there are no data currently transmitted on the MBMS bearer (e.g. between MCPTT group call). The reason for this is that an MC service client that has entered an area with significantly degraded MBMS quality, might not even notice that an MC service communication is ongoing, meanwhile the MC server still assumes that the MC service client can receive the media being broadcasted.

To estimate the MBMS bearer quality, for example as an equivalent BLER (Block Error Rate), when no data is sent is implementation specific. This estimation can be dependent on for example the modulation and coding scheme (MCS) and measurements from the reference signals from the eNB(s). Other metrics (e.g. RTP packet loss) may be used to estimate the MBMS bearer quality.

10.7.3.6.2 Procedure

The MC service client shall indicate the ability of the MC service client to receive the MBMS bearer.

Pre-conditions:

– There is an MBMS bearer activated and the MBMS bearer information is announced to the MC service client

– The MC service client is located in the MBMS broadcasting area

– The MC service UE monitors SIB-13 (or SIB-20) and (SC-)MCCH to receive the modulation and coding scheme

– The MC service UE monitors the cell specific reference signal and when MBSFN transmission is used, the MBSFN specific reference signals

Figure 10.7.3.6.2-1: MBMS bearer quality detection

1. The MC service client determines that the MBMS bearer quality shall be reported to the MC service server. The MC service client may determine the MBMS bearer quality by using the BLER of the received data. When no data is received, the quality estimation can consider the reference signals and the modulation and coding scheme (MCS). The UE may also use predictive methods to estimate the expected MBMS bearer quality (e.g. speed and direction) to proactively inform the MBMS service server of an expected loss of the MBMS bearer quality. The MC service client may also map the determined MBMS bearer quality to a MBMS reception quality level. The MBMS reception quality level indicates at which specific MBMS bearer quality level the MC service media has been received. Based on the MBMS reception quality level, the MC service server may efficiently decide to switch to another bearer or to take measures to prepare such a switch.

Editor’s note: The set of MBMS reception quality levels and the mapping of the determined MBMS bearer quality to those levels are FFS.

NOTE 1: When MBSFN transmission is used, the MBSFN reference signal needs to be used and when SC-PTM is used the cell specific reference signal needs to be used. With the measured reference signal, the reference signal received quality (RSRQ) can be calculated.

2. If the MBMS bearer quality reaches a certain threshold, the MC service client sends an MBMS listening status report. The threshold is used to define the MBMS listening status, which indicates if the MBMS bearer quality has been acceptable or not to receive a specific MC service media. If the MBMS bearer quality is mapped to a different MBMS reception quality level, the MC service client may send an MBMS listening status report including the MBMS reception quality level.

NOTE 2: Prior sending the MBMS listening status report, it could be beneficial to also include information for different alternatives e.g. another MBMS bearer might have better quality and could be a better option than a transfer of the communication to unicast.

NOTE 3: The threshold used to indicate MBMS bearer quality depends on service type (i.e. MCPTT, MCVideo or MCData) and the metrics used. The metrics used and the associated thresholds are out of scope of this specification.

3. The MC service server may send additional proposal for measurements e.g. information about neighbouring MBMS bearers. This message may be an MBMS bearer announcement message.

10.7.3.7 Service continuity in MBMS scenarios

10.7.3.7.1 General

This subclause specify service continuity scenario when MBMS bearers are used. There are different solutions for different scenarios.

10.7.3.7.2 Service continuity when moving from one MBSFN to another

The service continuity solution described in this subclause is suitable in the scenario when multiple MBMS bearers are used with the purpose to cover a larger area. In mission critical communication several media streams may be multiplexed in one MBMS bearer. Furthermore, one media stream (e.g. MCPTT group call) may be sent on more than one MBMS bearer if the receiving users are distributed over more than one MBMS service area. An MC service client that is interested in receiving a media stream that is broadcasted in both MBMS bearers is a candidate for this service continuity procedure.

Figure 10.7.3.7.2-1 illustrates a deployment scenario that provides service continuity between two MBSFN areas. Two different MBMS bearers are activated (TMGI 1 and TMGI 2), the activation of the bearers is done in the two MBSFN areas (MBSFN 1 and MBSFN 2). The MBSFN areas 1 and 2 are partially overlapping, meaning that some transmitting cells belong to both MBSFN area 1 and MBSFN area 2.

Figure 10.7.3.7.2-1: Two MBMS bearer using overlapping MBSFN areas

The procedural steps will work as follows:

Figure 10.7.3.7.2-2: Service continuity when moving from one MBSFN to another

1. The UE is located in MBSFN 1 and can listen to TMGI 1. No additional MBMS bearers that the MC service client is interested in are active in the current cell.

2. The MC service client notifies the MC service server that it is successfully receiving the MC service media over TMGI 1. The MC service client may also notify the MBMS reception quality level of TMGI 1.

NOTE 1: The MBMS reception quality level may be used by the MC service server to make an efficient decision to switch to another MBMS bearer or to a unicast bearer, or to take measures to prepare such a switch (e.g. when the quality level indicates that the reception quality of the MBMS bearer is decreasing or reaching an insufficient quality level for the reception of MC services).

3. The UE moves into a new cell in which both TMGI 1 and TMGI 2 are active. This cell is part of both MBSFN area 1 and MBSFN area 2, and broadcast the same service on both TMGIs.

4. Location information are provided from the MC service UE via the Location management client to the Location management server. For that, the MC service UE uses the SAI information found in the system information block (SIB) transmitted by the radio cells. The location management server provides the location information to the MC service server.

NOTE 2: Whether the MC service server has subscribed for notifications, as described in clause 10.9.3.6.1 of the present document, Event-trigger location information notification procedure, or uses on-demand requests, as described in clause 10.9.3.6.2 of the present document, On-demand usage of location information procedure, is out of scope.

5. The MC service server sends to the MC service client a MBMS bearer announcement with information related to TMGI 2 (if the MC service server had not done it before). Hence, the MC service client knows that TMGI 2 transmits the same MC service media.

6. The MC service client notifies the MC service server that it is successfully receiving TMGI 1 and TMGI 2. The MC service client may also notify the MBMS reception quality level per TMGI.

7. The MC service client may receive the MC service media over both MBMS bearers, i.e. TMGI 1 and TMGI 2. The MC service client may also verify that it is the same content sent on both bearers. The duplicated packets may also be used to perform error corrections.

8. The UE moves into a new cell in MBSFN area 2, where only TMGI 2 is active.

9. The MC service client notifies the MC service server that it is successfully receiving the MC service media over TMGI 2. The MC service client may also notify the MBMS reception quality level of TMGI 2.

10. The MC service client receives the MC service media only over TMGI 2.

This service continuity procedure mitigates the risk of packet loss that may occur if the UE would request to transfer the media stream to a unicast bearer when moving into the new area and then back to a multicast bearer when the UE can listen to TMGI 2. However, it is still required that the MC service client sends a location report (and MBMS listening report), as described in steps 4-6 above. To send the location report and the MBMS listening report by the MC service client to the MC service server a unicast bearer is needed. The location report from the MC service client is required, since the MC service server must know that the UE has entered a new area and can only listen to MBMS bearer active in that area. If this is not done the MC service server might send a media stream that the MC service client is required to listen to on the MBMS bearer 1, since the MC service server still assumes that the UE is located in the MBSFN area 1.

The solution can be improved as illustrated in figure 10.7.3.7.2-3. In this case two different MBMS bearers are activated (TMGI 1 and TMGI 2), these MBMS bearers are used only for media. An application level signalling bearer is activated (TMGI 9), in both MBSFN areas. This bearer is used for floor control messages and other application level signalling messages that are sent on the MBMS bearer TMGI 9. A similar concept was already introduced in 3GPP TS 23.179 [7] subclause 10.10.2, where the procedure allowed a separate MBMS bearer for floor control signalling. The application level signalling bearer will be used for all control messages needed for both media MBMS bearer (TMGI 1 and TMGI2).

By using an application level signalling bearer (e.g. TMGI 9) the MC service clients can receive floor control messages for all calls going on in the areas of both TMGI 1 and TMGI 2. A MC service client that is located in the area of TMGI 2 and is interested in a MCPTT group call transmission only going on in TMGI 1, can with the information received in TMGI 9 initiate a unicast bearer and request to receive that specific call over a unicast instead. Without the information received over TMGI 9 the MC service client must immediately report that the MC service client has left the broadcast area that the MC service server assumes that the MC service client is located in. With the use of TMGI 9 there is no immediate need for the MC service client to inform the MC service server of a location change.

Figure 10.7.3.7.2-3: Two MBMS bearer using overlapping MBSFN areas with a separate MC application signalling bearer

The procedural steps in this scenario will be the same as described above in this subclause. However, in this scenario the MC service client is not required to initiate a unicast bearer to send location report (or MBMS listening report). The UE may move between the two MBMS bearers (TMGI 1 and TMGI 2) without the need to report an area change. A condition for this to work is that there is an application level signalling bearer (TMGI 9) activated in the full area (i.e. the area of both TMGI 1 and TMGI 2). The TMGI 9 will broadcast all floor control messages for all calls ongoing in both areas. If the UE is in coverage of one of the two MBMS bearers that does not transmit the media of interest the UE can report to the server that it is not able to listen to the media over the MBMS bearer, which triggers the server to use a unicast bearer instead.

10.7.3.7.3 Service continuity with a UE-to-Network relay

This procedure handles a scenario when UE is moving from a location when the UE is experiencing good reception of the MBMS bearer to a location outside the MBMS service coverage. The MC service client apply a service continuity procedure to ensure that the service can be maintained and that the packet loss can be minimized during transition to a UE-to-Network relay connection. The solution also provides the benefit that it offloads the cell when UEs that normally would trigger a transfer from MBMS bearers to unicast bearers when moving outside the MBMS coverage area.

Figure 10.7.3.7.3-1 below illustrates the concept of this procedure. In the figure UE A (with the MC service client) is first within the MBMS coverage (the far right most location). The MBMS coverage is represented by the dashed circle. The UE A is the moving outside the MBMS coverage and first enters a location in which the MBMS signal is not good enough, but in this location there is still coverage to use unicast bearers. Unicast bearers use link adaption and retransmission so the coverage area for unicast bearers is larger than the coverage of the MBMS bearers. The solid circle outer line represents the coverage of the unicast bearer.

A UE that is leaving the area of MBMS coverage may in this scenario trigger a ProSe discovery procedure to initiate the establishment a relay communication path to UE-R. A UE that is receiving media over an MBMS bearer (and is in idle mode) and for the moment does not need a unicast bearer is costly (from a resource efficiency point of view) to transfer to a unicast bearer due to the need for retransmissions and robust coding in the outer part of cell.

When the ProSe communication path is established the UE A may continue to receive the media over the relay UE-R.

Figure 10.7.3.7.3-1: UE A is moving from a position in MBMS coverage to outside the network coverage passing an area where only unicast is possible

The procedure defined in this subclause allows for MBMS bearer service continuity when UE is moving from a MBMS coverage area to outside the MBMS coverage area. The procedure applies when the UE is not finding a target cell with good RSRP/RSRQ (receiving strong reference signals from other cells), which could trigger normal cell reselection procedure. In such scenario other aspects should be evaluated to trigger to a relay communication path.

Pre-conditions:

– The MC service client UE is not using a unicast bearer when this procedure applies.

Figure 10.7.3.7.3-2: Service continuity over MBMS bearer using UE-to-network relay

1. The MC service client estimate the MBMS bearer quality. The MC service clients also measure the reference signals from other cells to estimate the possibilities to transfer to unicast and perform a cell reselection procedure.

2. If the MBMS bearer quality has reach a certain threshold the MC service client performs ProSe UE-to-network relay discovery over PC5 and establishes a secure point-to-point link with the relay (UE-R) over PC5. As part of this process the remote UE is mutually authenticated at PC5 layer with either the relay or with the network as specified in 3GPP TS 23.303 [14].

3. Normal service continuity procedure for a UE-to-network relay. This may be done according to annex B.

4. The MC service client informs the UE-R about the reception of media over the MBMS bearer. This includes sending the TMGIs, MBMS SAIs and ProSe per packet priority to the UE-R. This procedure is specified in 3GPP TS 23.303 [14].

5. The UE-R will relay the MBMS media using one-to-many ProSe Direct Communication. The UE-R may also relay requests to transfer the media flow from multicast to unicast and vice versa.

10.7.3.8 MBMS suspension notification

10.7.3.8.1 Description

In this procedure the MC sevice client is requested by the MC service server to send a MBMS suspension report. This request for MBMS suspension report can be included in the MBMS bearer announcement and the MC service server may choose to only send this request for MBMS suspension report to a subset of all MC service clients.

10.7.3.8.2 Procedure

The information flow below defines a procedure in which the MC service client notifies the MC service server about an MBMS suspension decision in RAN.

The MC service server can decide on a subset of all UE’s in the MBMS broadcast area that shall report on MBMS bearer suspension. When the MC service server make the decision of the UE subset, consideration shall be taken to the location of the UEs, since UEs location is dynamically changed. This means that the MBMS suspension reporting instruction may need to be updated regularly based on the UEs mobility.

Pre-conditions:

– It is assumed that there is at least one active MBMS bearer

Figure 10.7.3.8.2-1: MBMS suspension notification from MC service client

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

NOTE: This message may be included in the MBMS bearer announcement message and may be sent both on a unicast bearer and a multicast bearer.

2. RAN decides to suspend the MBMS bearer, according to existing procedures in 3GPP TS 36.300 [21].

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

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

10.7.3.9.1 General

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 support multi-server bearer coordination shall use this procedure.

NOTE: Within one group communication session, multiple MC service servers (participating role) might be involved. Multiple MBMS service areas might have sufficient MC service group members to warrant multiple MBMS bearers to be used and therefore multiple MC service servers (MBMS bearer control role) might be involved. For brevity, this clause only illustrates the simplest case.

10.7.3.9.2 Procedures

10.7.3.9.2.1 MBMS bearer coordination independent on broadcasted media

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.

Figure 10.7.3.9.2.1-1: Multiple server MBMS procedure

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

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

NOTE: MC service servers of the same type can be configured to discover bearers from a single server. The single server then becomes a centralized entity for MBMS bearer control for the MC service. Similarly, all MC service servers of all types can be configured to discover bearers from a single server. The single server then becomes a centralized MBMS bearer controller for all MC services.

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

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

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

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

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

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

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

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

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.

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

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.

Figure 10.7.3.9.2.2-1: Multiple server MBMS procedure

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

NOTE 1: MC service servers of the same type can be configured to discover bearers from a single server. The single server then becomes a centralized entity for MBMS bearer control for the MC service. Similarly, all MC service servers of all types can be configured to discover bearers from a single server. The single server then becomes a centralized MBMS bearer controller for all MC services.

NOTE 2: Step 1-4 is also performed by MC service server 3, but is not shown in the procedure to make it easier to read.

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

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.

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.

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.

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.

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.

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

NOTE 3: The figure above does not visualize the participating server for the MC service group and controlling server for the MC service group. The media is sent to all participating servers for the MC service group which are the servers that decide on unicast or multicast transmission.

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

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

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

10.7.3.10.1 General

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.

Editor’s note: The procedure defined in this sub clause requires an enhancement to GCSE and RAN and is therefore subject to implementation in EPC and RAN.

10.7.3.10.2 Procedure

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

Figure 10.7.3.10.2-1: MBMS bearer event notification

1. 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 3GPP TS 23.468 [18].

2. The BMSC will respond to the activation with an Activate MBMS bearer response message, according to 3GPP TS 23.468 [18].

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

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

5. The MC service server starts to use the MBMS bearer according to the MBMS procedures in this specification.

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

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

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

NOTE: Steps 6-8 should be seen as example events from the network that may occur and possible actions taken by the MC service server. These steps may be done at any time and repeatedly during the life time of an MBMS bearer.

10.7.3.11 Use of FEC to protect MBMS transmissions

10.7.3.11.1 General

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

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:

1. The MC service server has already activated a MBMS Bearer, with the MBMS Bearer request specified in 3GPP TS 23.468 [18].

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

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

2. If the BM-SC can satisfy the request, the Setup FEC response includes a modified list of media information and FEC information. The reponse also includes an identifier to the FEC process instance, which can be used to release the application of FEC for these media flows.

NOTE 1: Source media packets may be modified by the application of FEC (e.g. addition of a footer of header), leading to a modification of the delivery protocol to be announced within the media information.

NOTE 2: The Release FEC request is not shown on the figure.

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

4. 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 3GPP TS 23.379 [16], or the MapGroupToBearer message for MCVideo, specified in 3GPP TS 23.380 [12].

5. The MC service server sends the downlink media to the BM-SC on the MB2-U reference points and according to 3GPP TS 23.468 [18].

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

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

Editor’s note: the need for a MC service server ability to turn off/on the production of repair packets on the BM-SC during the media transmission must be discussed, and may impact the procedure.

10.7.3.11.3 FEC encoding by the MC service server

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.

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

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

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

3. The MC service server performs FEC encoding and processing in accordance with the selected FEC algorithm.

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

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

10.7.3.12.1 General

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

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.

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

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

2. 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 3GPP TS 23.379 [16], or the MapGroupToBearer message for MCVideo, specified in 3GPP TS 23.281 [12].

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

4. The MC service server performs header compression in accordance with the ROHC information.

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

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

10.7.3.12.3 Header compression by the BM-SC

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:

1. The MC service server has already activated a MBMS Bearer, with the MBMS Bearer request specified in 3GPP TS 23.468 [18].

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

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

NOTE 1: The MC service server can later modify the ROHC configuration by performing again the Setup ROHC request.

NOTE 2: The Release ROHC request is also not shown on the figure.

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

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

5. The MC service server sends the downlink media to the BM-SC on the MB2-U reference points and according to 3GPP TS 23.468 [18].

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

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

10.7.3.13 Use of MBMS bearer for group status

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 is specified in subclause 10.7.2.12.

NOTE: The procedure described in clause 10.7.3.4 can be used for the transmission of the group status notification.