Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.280  Word version:  19.1.0

Top   Top   Up   Prev   Next
1…   5…   5.2.8…   6   7…   7.3.2   7.4…   7.4.3…   7.5…   8…   9…   9.2.2…   9.2.2.2…   9.3…   10…   10.1.2…   10.1.3…   10.1.4.3…   10.1.4.5…   10.1.5…   10.1.6…   10.2…   10.2.3…   10.2.4.2…   10.2.4.3…   10.2.5…   10.2.7…   10.3…   10.6…   10.7…   10.7.3…   10.7.3.4…   10.7.3.7…   10.7.3.7.3   10.7.3.8…   10.7.3.10…   10.8…   10.8.4…   10.8.5…   10.9…   10.9.3…   10.9.3.5…   10.9.3.8…   10.9.3.9…   10.9.3.9.3…   10.9.3.9.4…   10.9.3.10…   10.9.3.10.4…   10.9.3.10.6…   10.10…   10.10.1.2.3…   10.10.2…   10.10.3…   10.10.3.3…   10.10.3.4…   10.11…   10.11.5…   10.12…   10.13…   10.13.3…   10.13.7…   10.13.10…   10.14…   10.15…   10.15.3…   10.15.3.3…   10.15.3.4…   10.16…   10.17…   11…   11.3…   11.5…   11.5.2…   11.5.3…   11.5.3.3.2A…   11.5.4…   A…   B…   C…

 

10.7.3.7  Service continuity in MBMS scenariosp. 146

10.7.3.7.1  Generalp. 146
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 anotherp. 146
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.
Reproduction of 3GPP TS 23.280, Fig. 10.7.3.7.2-1: Two MBMS bearer using overlapping MBSFN areas
Up
The procedural steps will work as follows:
Reproduction of 3GPP TS 23.280, Fig. 10.7.3.7.2-2: Service continuity when moving from one MBSFN to another
Up
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 8.
The UE moves into a new cell in MBSFN area 2, where only TMGI 2 is active.
Step 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.
Step 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 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.
Reproduction of 3GPP TS 23.280, Fig. 10.7.3.7.2-3: Two MBMS bearer using overlapping MBSFN areas with a separate MC application signalling bearer
Up
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.
Up

Up   Top   ToC