Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.280  Word version:  17.8.0

Top   Top   Up   Prev   Next
1…   5…   7…   7.4…   7.5…   8…   9…   10…   10.1.2…   10.1.3…   10.1.5…   10.2…   10.2.3…   10.2.5…   10.3…   10.7…   10.7.3…   10.7.3.7…   10.7.3.10…   10.8…   10.8.4…   10.9…   10.9.3…   10.9.3.8…   10.10…   10.11…   10.12…   10.13…   10.13.3…   10.14…   10.15…   10.15.3…   A…   B…

 

10.7.3.7  Service continuity in MBMS scenariosWord‑p. 139

10.7.3.7.1  GeneralWord‑p. 139
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 anotherWord‑p. 139
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.
Copy of original 3GPP image for 3GPP TS 23.280, Figure 10.7.3.7.2-1: Two MBMS bearer using overlapping MBSFN areas
Up
The procedural steps will work as follows:
Copy of original 3GPP image for 3GPP TS 23.280, Figure 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.
The MC service client sends a location information report to the MC service server. For that, the UE uses the SAI information found in the system information block (SIB) transmitted by the radio cells.
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.
Copy of original 3GPP image for 3GPP TS 23.280, Figure 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
10.7.3.7.3  Service continuity with a UE-to-Network relayWord‑p. 142
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.
Copy of original 3GPP image for 3GPP TS 23.280, 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
Up
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.
Copy of original 3GPP image for 3GPP TS 23.280, Figure 10.7.3.7.3-2: Service continuity over MBMS bearer using UE-to-network relay
Up
Step 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.
Step 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 TS 23.303.
Step 3.
Normal service continuity procedure for a UE-to-network relay. This may be done according to annex B.
Step 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 TS 23.303.
Step 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.
Up

10.7.3.8  MBMS suspension notificationWord‑p. 144

10.7.3.8.1  DescriptionWord‑p. 144
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  ProcedureWord‑p. 144
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
Copy of original 3GPP image for 3GPP TS 23.280, Figure 10.7.3.8.2-1:	MBMS suspension notification from MC service client
Up
Step 1.
The MC service server sends an MBMS suspension reporting instruction to the MC service client.
Step 2.
RAN decides to suspend the MBMS bearer, according to existing procedures in TS 36.300.
Step 3.
An MBMS suspension indication is sent in the MSI (MCH Scheduling Information), according to existing procedures in TS 36.300.
Step 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.
Up

10.7.3.9  Multi-server bearer coordinationWord‑p. 145

10.7.3.9.1  GeneralWord‑p. 145
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.
Up
10.7.3.9.2  ProceduresWord‑p. 145
10.7.3.9.2.1  MBMS bearer coordination independent on broadcasted media Word‑p. 145
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.
Copy of original 3GPP image for 3GPP TS 23.280, Figure 10.7.3.9.2.1-1: Multiple server MBMS procedure
Up
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
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.
Up
10.7.3.9.2.2  MBMS bearer coordination within one group call Word‑p. 147
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.
Copy of original 3GPP image for 3GPP TS 23.280, Figure 10.7.3.9.2.2-1: Multiple server MBMS procedure
Up
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
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. 12. The MC service server 2 (MBMS bearer control role) respond to the request by sending a media distribution release request.
Up

Up   Top   ToC