Content for TS 23.247 Word version: 18.4.0

1… 4… 4.2… 4.3 5… 6… 6.6… 7… 7.1.1.2 7.1.1.3 7.1.1.4… 7.1.1.6… 7.1.2… 7.2… 7.2.2… 7.2.3… 7.2.4… 7.2.4.3… 7.2.5… 7.2.6… 7.3… 7.3.5… 7.5… 8… 9… 9.2… 9.3… 9.4… A…

7.3.5 MBS Session Delivery Status Indication for Broadcast 7.3.6 Broadcast MBS Session Release Require 7.3.7 Transport change for resource sharing across broadcast MBS Sessions during network sharing 7.3.8 Broadcast MBS procedures for UEs using power saving functions 7.4 MBS procedures for inter System Mobility 7.4.1 Inter-system mobility with interworking at service layer
...

7.3.5 MBS Session Delivery Status Indication for Broadcast p. 104

The MBS Session Delivery Status Indication for broadcast is used by the MB-SMF to notify the AF/AS of conditions affecting the delivery of the MBS session (e.g. MBS session created, MBS session terminated, etc.). The occurrence of the indicated condition may have been detected at the MB-SMF or may have been reported to the MB-SMF by other entities involved in the MBS session delivery.

Reproduction of 3GPP TS 23.247, Fig. 7.3.5-1: MBS Session Delivery Status Indication for Broadcast

Figure 7.3.5-1: MBS Session Delivery Status Indication for Broadcast

Step 1.

The external AF subscribes event for delivery status towards the NEF, and the NEF subscribes corresponding event towards the MB-SMF (step 1a), or the legacy AS request status report towards the MBSF, and the MBSF subscribes event for delivery status towards the MB-SMF (step 1b), or the internal AF subscribes event for delivery status towards the MB-SMF (step 1c).

Step 2.

The MB-SMF notifies the TMGI and the event towards the NEF, and the NEF notifies the TMGI and corresponding event towards the external AF (step 2a), or the MB-SMF notifies the TMGI and the event towards the MBSF, and the MBSF sends Delivery Status Indication to legacy AS with the TMGI and the corresponding event (step 2b), or the MB-SMF notifies the TMGI and the event towards the internal AF (step 2c).

For the "MBS session started" event, after the MB-SMF contacts AMFs to request the establishment of the Broadcast MBS session, the MB-SMF may wait until it has received a Namf_MBSBroadcast_ContextCreate Response or Namf_MBSBroadcast_ContextStatusNotify with the indication of the completion of the operation from each AMF (see clause 7.3.1) before determining that the Broadcast MBS session has been started.

7.3.6 Broadcast MBS Session Release Require p. 105

When NG-RAN is not able continue to provide the Broadcast MBS Session, e.g. due to lack of radio resources, NG-RAN may initiate Broadcast Session Release Require procedure.

Reproduction of 3GPP TS 23.247, Fig. 7.3.6-1: Broadcast MBS Session Release Require

Figure 7.3.6-1: Broadcast MBS Session Release Require

Step 1.

If NG-RAN cannot continue to provide the Broadcast MBS session, e.g. due to lack of radio resources, the NG-RAN sends Broadcast Session Release Require (MBS Session ID) to the AMF.

Step 2.

The AMF initiates Broadcast Session Release towards the NG-RAN as defined in steps 4 - 7 in clause 7.3.2.

Step 3.

If unicast transport applies in N3mb, the AMF receives the DL tunnel Info for the Broadcast MBS Session from the NG-RAN in step 2. The AMF notifies the MB-SMF about the DL tunnel release via Namf_MBSBroadcast_ContextStatusNotify with N3mb DL Tunnel Info and corresponding NG-RAN ID. If multicast transport applies in N3mb, only when Broadcast Session Release Require is performed for all the NG-RANs involved in the MBS session which are managed by the AMF, the AMF notifies the MB-SMF about radio resource release via Namf_MBSBroadcast_ContextStatusNotify indicating radio resource release.

Step 3a-3b.

This step applies if the AF subscribed to a Delivery Status Indication (see clause 7.3.5). If Broadcast Session Release Require is performed by all the NG-RANs, i.e. for unicast N3mb transport, the MB-SMF releases all the DL tunnel Info for the broadcast MBS Session, and for multicast N3mb transport, the MB-SMF receives radio resource release from all the AMFs for the broadcast MBS Session, the MB-SMF notifies the AF directly of the situation by invoking Nmbsmf_MBSSession_StatusNotify, or the MB-SMF notifies the AF via NEF/MBSF (if deployed) by invoking Nmbsmf_MBSSession_StatusNotify service operation to the NEF/MBSF which then invokes Nnef_MBSSession_StatusNotify service operation to the AF

Step 4.

The MB-SMF performs N4mb Session Modification to let MB-UPF stop the broadcast data forwarding towards the indicated DL tunnel and release the DL tunnel as specified in step 6a of clause 7.3.3.

7.3.7 Transport change for resource sharing across broadcast MBS Sessions during network sharing |R18| p. 106

The procedure in this clause is performed when one of the following events occur and resource sharing across broadcast MBS Sessions in network sharing as specified in clause 6.18 is applied:

When a broadcast MBS session, from which the shared NG-RAN receives a DL MBS data stream, is released, and the NG-RAN node determines to request to receive an DL MBS data stream from another operator's CN with a remaining broadcast MBS session.
When the shared NG-RAN fails to receive DL data stream from an operator's CN (e.g. due to failure in the user plane) and the NG-RAN node determines to request to receive the DL MBS data stream via another operator's CN.

Reproduction of 3GPP TS 23.247, Fig. 7.3.7-1: Transport change for resource sharing across broadcast MBS Sessions during network sharing

Figure 7.3.7-1: Transport change for resource sharing across broadcast MBS Sessions during network sharing

Step 1.

The NG-RAN selects another broadcast MBS Session that is delivering the same content via another CN to establish user plane, utilizing the broadcast MBS session context stored in the NG-RAN.

If unicast transport of N3mb applies, continue at step 3.

Step 2.

If multicast transport of N3mb applies, the NG-RAN joins the multicast group towards the LL SSM provided by the CN and continues at step 8.

Step 3.

If unicast transport of N3mb applies, the NG-RAN allocates N3mb DL Tunnel Info, and sends N2 message (e.g. BROADCAST SESSION TRANSPORT REQUEST) to the AMF, including the MBS Session ID, the N3mb DL Tunnel Info and optional Area session ID.

Step 4.

The AMF transfers the Namf_MBSBroadcast_ContextStatusNotify request to the MB-SMF, which contains the N2 message.

Step 4a.

The MB-SMF returns Namf_MBSBroadcast_ContextStatusNotify response.

Step 5.

The MB-SMF sends an N4mb Session Modification Request to the MB-UPF to allocate the N3mb point-to-point transport tunnel for a replicated MBS stream for the MBS Session. The MB-UPF sends N4mb Session Modification Response to the MB-SMF.

Step 6.

The AMF forwards the received N2 information in N2 message (e.g. BROADCAST SESSION TRANSPORT RESPONSE) to the NG-RAN.

Step 7.

The NG-RAN receives the media stream from the MB-UPF via N3mb multicast transport or unicast transport.

Step 8.

The NG-RAN sends the received packets using the existing radio resource.

7.3.8 Broadcast MBS procedures for UEs using power saving functions |R18| p. 107

For a UE using power saving function to receive broadcast MBS Session data, the following apply:

If a UE is in RRC_CONNECTED mode due to other reasons at the start time or the scheduled activation times, the UE follows normal connected mode procedures.
If a UE is in RRC_IDLE state and reachable (e.g. in active time in MICO or PTW for eDRX) at the start time or the scheduled activation times) the UE follows normal idle mode or inactive mode procedures), the UE follows normal idle mode procedure.
If a UE is in RRC_IDLE mode or CM-CONNECTED with RRC_INACTIVE state and not reachable (i.e. in deep sleep) at the start time or the scheduled activation times, the UE leaves the deep sleep state only to perform procedures related to MBS, the UE leaves the deep sleep state only to receive the MBS broadcast service, but should not update the AMF to become reachable for paging to minimize signalling load.

NOTE 1:
UE would therefore still be considered unreachable for paging in the AMF.
When the UE is in the middle of an MBS data transfer, and the UE is scheduled to move to deep sleep due to power saving, e.g. end of PTW for extended idle mode DRX, expiration of active time for MICO, or the UE transitioning from CM-CONNECTED to CM-CONNECTED with RRC_INACTIVE state with eDRX or the UE transitioning from CM-CONNECTED to CM-IDLE in the case of MICO with no active time, then the UE does not go to deep sleep during the remainder of the current MBS data transfer.

NOTE 2:
If at the end of the current MBS data transfer the UE knows there is another MBS data transfer scheduled soon, depending on the time between MBS data transfers, the UE can decide to go to sleep between MBS data transfers.

7.4 MBS procedures for inter System Mobility p. 108

7.4.1 Inter-system mobility with interworking at service layer p. 108

For inter-system mobility with interworking at service layer, i.e. the same multicast service is provided via eMBMS in E-UTRAN and MBS, the UE is instructed to switch between MBS and eMBMS:

Mobility from MBS to eMBMS.
When moving to E-UTRAN/EPC, the UE initiates procedures as defined in TS 23.246 to receive MBMS service for the TMGI(s).
If the UE has one or more unicast PDU Sessions (including, but not limited to, the PDU Session used for MBS and for another service (e.g. Public Safety service) with the QoS Flow(s) for the other service) moving to EPS, and if the handover procedure from 5GS to EPS using N26 interface described in clause 4.11.1.2.1 of TS 23.502 is used:
- For the PDU Session used also for MBS, the SMF+PGW-C removes the UE from the Multicast MBS session context(s), if it exists, upon receiving a Modify Bearer Request of the PDU Session from the SGW (i.e. step 14a of clause 4.11.1.2.1 of TS 23.502).
  
  NOTE 3:
  When 5GS to EPS mobility is complete, if there is pending request of removing a UE from a released MBS Session (see step 2 of clause 7.2.2.3), the pending request is also removed locally.
- The NG-RAN removes the UE from the Multicast MBS session context(s) if it exists, or removes the whole multicast session context if the UE is the last one for the Multicast MBS session (e.g. after receiving the UE Context Release Command message sent by the AMF).
For 5GS to EPS Idle mode mobility with no N26, when the UE moves to the EPS and performs E-UTRAN/EPS attach according to step 8 of clause 4.11.2.4.1 of TS 23.502, if the UE does not maintain registration in 5GC, upon reachability time-out, the AMF may implicitly detach the UE and release the possible remaining PDU Session(s) in 5GC. The SMF+PGW-C removes the UE from the Multicast MBS session context(s), if it exists, upon receiving a tracking area update from the UE.

NOTE 4:
When 5GS to EPS mobility is complete, if there is pending request of removing a UE from a released MBS Session (see step 2 of clause 7.2.2.3), the pending request is also removed locally.
Mobility from eMBMS to MBS.
When the UE has moved to NR/5GC, it triggers the multicast context and multicast flow setup/modification via PDU Session Modification procedures as defined in clause 6.8 to receive MBS transport for the TMGI(s).