Tech-invite3GPPspaceIETF RFCsSIP
indexN21222324252627282931323334353637384‑5x

Content for  TS 23.247  Word version:  18.2.0

Top   Top   Up   Prev   Next
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 Broadcastp. 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
Up
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.
Up

7.3.6  Broadcast MBS Session Release Requirep. 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
Up
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.
Up

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

The procedure in this clause is performed when one of the following events occurs under the condition that the resource sharing across broadcast MBS Sessions in network sharing was previously applied and the NG-RAN determined to receive only a single copy of MBS data as specified in clause 6.17:
  • A broadcast MBS session, from which the shared NG-RAN receives DL data stream, is released, and no DL data stream is received in the NG-RAN from the remaining broadcast MBS session(s) with the same Associated Session ID.
  • When the shared NG-RAN fails to receive DL data stream from the CN (e.g., due to failure in the user plane), the NG-RAN attempts to get the DL data stream via another CN's user plane.
Reproduction of 3GPP TS 23.247, Fig. 7.3.7-1: Transport change for resource sharing across broadcast MBS Sessions during network sharing
Up
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 and the N3mb DL Tunnel Info.
Step 4.
The AMF transfers the Namf_MBSBroadcast_ContextStatusNotify request to the MB-SMF, which contains the N2 message.
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.
Up

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

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

7.4  MBS procedures for inter System Mobilityp. 107

7.4.1  Inter-system mobility with interworking at service layerp. 107

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).
    • 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.
  • 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).
Up

Up   Top   ToC