Content for  TS 23.280  Word version:  19.4.0

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.

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.

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.

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

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.

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.

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.

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.

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

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

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.

The procedural steps will work as follows:

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

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.

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.

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.