7.2.5 MBS session activation and deactivation

23.2473GPPArchitectural enhancements for 5G multicast-broadcast servicesRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.2.5.1 General

MBS Session activation procedure is for multicast only. MBS Session activation procedure is triggered by MB-SMF, when it receives the notification from MB-UPF for the downlink MBS DL data, or when it receives the request directly from AF or via NEF. The MBS Session activation procedure is used for activating the resources for MBS data at NG-RAN node. The multicast session state transits from Inactive to Active after MBS Session activation procedure, see clause 4.3.

MBS Session deactivation procedure is for multicast only. MBS Session deactivation procedure is triggered by MB-SMF, when it receives the notification from MB-UPF in the case that there is no downlink data to be transmitted for some duration, or when it receives the request directly from AF or via NEF. The MBS Session deactivation procedure is used for deactivating the resources for MBS data at NG-RAN node. The multicast session state transits from Active to Inactive after MBS Session deactivation procedure, see clause 4.3.

7.2.5.2 MBS session activation procedure

The following can trigger the MBS session activation procedure:

– AF requests MB-SMF to activate the MBS session;

– MB-UPF receives the multicast data and notifies MB-SMF.

Figure 7.2.5.2-1: MBS session activation procedure

In this procedure, steps 11 to 15 are executed if the MB-SMF finds out there are shared tunnel established. Steps 11 to 15, if needed, are executed in parallel with steps 2 to 10.

1. The procedure may be triggered by the following events:

– When the MB-UPF receives downlink data for a multicast MBS session, based on the instruction from the MB-SMF (as described in clause 7.2.5.3), the MB-UPF sends N4mb Notification (N4 Session ID) to the MB-SMF for indicating the arrival of DL MBS data.

– The AF sends MBS Activation request (TMGI) to the MB-SMF directly or via NEF.

2. MB-SMF sends Nmbsmf_MBSSession_ContextStatusNotify (MBS Session ID, multicast session state = Active) to SMF(s).

The SMF sets the related multicast MBS session state to Active and finds out the list of UEs that joined the multicast MBS session identified by the related TMGI. If the SMF determines the user plane of the associated PDU session(s) of the UE(s) with respect to the TMGI are activated already, steps 3-8a will be skipped for those UE(s), i.e. executed from step 8b.

3. The SMF invokes Namf_MT_EnableGroupReachability Request (List of UEs, [PDU Session ID of the associated PDU Sessions], TMGI, [UE reachability Notification Address], [most demanding ARP, 5QI of all MBS QoS Flow within MBS session])) to AMF(s). When later UE is reachable, the UE reachability Notification Address is used by the AMF to identify and notify the related SMF.

After receiving the request, for each UE in the list, the AMF determines CM state of the UE: see steps 4 – 7.

4a. If there are UEs involved in the multicast MBS Session and in CM-CONNECTED state, the AMF indicates those UEs to the SMF, using Namf_MT_EnableGroupReachability Response (UE list). Otherwise, the response does not include UE list.

4b. For each UE in the UE list included in step 4a, if the QoS profile(s) for associated PDU Session has not yet been provided, the SMF invokes Namf_Communication_N1N2MessageTransfer (N2 SM information (PDU Session ID, MBS Session ID, [QoS profile(s) for associated QoS flow(s)], [mapping information between the unicast QoS flow and multicast QoS flow])) to the AMF for the UE which is identified in step 4a. The associated unicast QoS Flow(s) as well as the mapping information between the unicast QoS Flow(s) and multicast QoS Flow(s) are included to support the 5GC Individual MBS traffic delivery.

The procedure continues at step 9.

5. [Conditional] If AMF determines that there are UEs in CM-IDLE state and involved in the multicast MBS Session, the AMF figures out the paging area covering all the registration areas of those UE(s), which need to be paged. The AMF may apply paging differentiation as specified in clause 6.12. The AMF sends a Multicast Group paging request message to the NG-RAN node(s) belonging to this Multicast Paging Area with the involved UE list and TMGI as the identifier to be paged if the related NG-RAN node(s) support MBS. If the NG-RAN node(s) do not support MBS, the AMF sends Paging message(s) to the NG-RAN node(s) per UE as described in step 4b in clause 4.2.3.3 of TS 23.502 [6].

NOTE 1: In addition to the paging in clause 6.12, other paging strategies is up to AMF implementation.

NOTE 2: The details of the paging are specified by the RAN WGs.

6. Receiving the paging, the UE(s) in CM-IDLE state sends Service Request message to the AMF, see clause 4.2.3 of TS 23.502 [6].

NOTE 3: Step 6 for a UE can be parallel to step 5 for another UE(s), which has not received any paging yet.

7a/7b. After receiving the Service Request sent by the UE(s),

– Either based on the received PDU Session ID in step 3, the AMF identifies the related SMF and invokes Nsmf_PDUSession_UpdateSMContext request. The procedure continues at step 9; or:

– Based on the received UE reachability Notification Address in step 3, the AMF identifies and notifies the related SMF of the UE(s), which are reachable now and the Location Information, by using the Namf_MT_UEReachabilityInfoNotify message. In this case, it can be a separated notification or combined with step 8.

8a. For UE(s) that do not respond to paging, the AMF informs the SMF of the paging failure in Namf_MT_UEReachabilityInfoNotify.

8b. For UE(s) that is indicated as reachable via the Namf_MT_UEReachabilityInfoNotify message, or user plane of the associated PDU session is activated already but the QoS profile(s) for associated QoS flow(s) needs to be provided for the PDU session, the SMF invokes Namf_Communication_N1N2MessageTransfer (N2 SM information ()) to the AMF same as described in step 4b.

9. The AMF sends N2 request message (N2 SM information ()) to the RAN node.

NOTE 4: A joined UE is not able to receive MBS data if NG-RAN rejects the PDU Session Resource setup request (due to implementation specific reasons, e.g. activation of user plane fails due to the number of UEs reaching a limit).

10a. If the shared tunnel has not been established before, the shared tunnel is established at this step, as defined in clause 7.2.1.4. The NG-RAN configures UE with RRC messages if needed.

10b. Steps 8 to 12 defined in clause 7.2.1.3 are performed. If 5GC Individual MBS traffic delivery is used, the SMF configures the UPF for individual delivery and if necessary, requests the MB-SMF to configure the MB-UPF to send multicast data to the UPF.

11. If the MB-SMF finds out there are shared tunnel established, step11-15 are performed. The MB-SMF invokes Namf_MBSCommunication_N2MessageTransfer Request (TMGI, N2 SM Information (Activation, TMGI)) to the AMF for those NG-RAN nodes, which have shared tunnel with MB-UPF. This step may be performed in parallel with step 2.

NOTE 5: The messages in steps 10a, 11 and 12 are MBS-specific and it is possible that the AMF(s) in steps 10a, 11 and 12 are not associate to any UEs involved in the multicast MBS Session.

12. The AMF sends NGAP activation request message (N2 SM Information ()) to the NG-RAN nodes. For those UEs that have joined in the MBS Session and are in RRC_INACTIVE state, the RAN nodes perform RAN paging as specified in TS 38.300 [9].

13. The NG-RAN nodes responses to AMF by NGAP activation response message. The NG-RAN nodes establish radio resources to transmit multicast MBS session data to the UE(s). The NG-RAN shall not release the radio connection of a UE that has joined into the Multicast MBS session only because no unicast traffic is received for the UE.

14. AMF to MB-SMF: Namf_MBSCommunication_N2MessageTransfer Response ().

15. The MB-SMF sends N4mb Session Modification Request to the MB-UPF to forward the received MBS packets. The MB-UPF responds to the MB-SMF with N4mb Session Modification Response acknowledging the MB-SMF request.

NOTE 6: Depending on implementation, step 15 can be executed after the first successful response in step 14 to shorten the activation time, or buffering at the MB-UPF can be applied sufficiently long for the majority of RAN nodes to activate the MBS session to reduce packet loss.

7.2.5.3 MBS session deactivation procedure

Figure 7.2.5.3-1: MBS session deactivation procedure

In this procedure, steps 3 to 4 and steps 5 to 9 are executed in parallel.

1. The procedure may be triggered by the following events:

– When MB-UPF detects there is no data receives for the MBS Session, MB-UPF sends MB-N4 Notification (N4 Session ID) to the MB-SMF for deactivating the MBS session.

– AF sends MBS Deactivation request (TMGI) to the MB-SMF directly or via NEF.

2. The MB-SMF sends an N4mb Session Modification Request (TMGI, [Buffered Downlink Traffic detection]) to the MB-UPF. The Buffered Downlink Traffic detection is requested by MB-SMF to be informed by the MB-UPF about incoming MBS data. The MB-SMF triggers MBS session activation once informed. If the MBS session is to be activated via the AF request directly, the Buffered Downlink traffic detection is not needed, but the MB-SMF still instructs the MB-UPF to stop forwarding and possibly to buffer MBS data.

MB-UPF to MB-SMF: N4mb Session Modification Response acknowledging the MB-SMF request.

NOTE 1: It is up to stage 3 to determine whether MB-UPF keeps the DL F-TEID(s) for N3mb and N19mb interfaces.

3. The MB-SMF sends Nmbsmf_MBSSession_ContextStatusNotify request (MBS Session ID) to the SMFs.

Based on the received MBS Session ID, the SMF sets the indicated multicast MBS session state to Inactive:

‐ If the SMF finds out there are UE(s) that joined the indicated multicast MBS session and use 5GC Individual MBS traffic delivery, step 4 is performed for those UE(s).

‐ If SMF find there are no UE(s) that joined the indicated MBS session and use 5GC Individual MBS traffic delivery, no further operation for SMF is required.

4a. [Conditional] For UE(s) for which the 5GC individual delivery is used, step 3b and steps 4-8 in clause 4.3.3.2 of TS 23.502 [6] are performed to remove the associated QoS flow(s) related to the multicast MBS session.

NOTE 2: Whether the associated QoS Flow(s) are removed from UE, NG-RAN, or only resource in NG-RAN is removed is up to implementation.

4b [Conditional] For UE(s) for which the 5GC individual delivery is used, the related SMF(s) may keep the shared tunnel that is used for Individual MBS traffic delivery over N19mb interface. If the SMF decides to release the shared tunnel, steps 3 to 6 in clause 7.2.2.2 need to be performed.

5. If the MB-SMF finds out there are shared tunnel established over N3mb interface, the MB-SMF sends Namf_MBSCommunication_N2MessageTransfer Request (TMGI, N2 SM information (Deactivation, TMGI)) to the AMFs.

6. The AMF sends NGAP deactivation request message (N2 SM information ()) to the NG-RAN nodes.

7. The NG-RAN node keeps the multicast MBS Session Context and N3mb shared tunnel for the multicast MBS session.

If the MBS Session Context indicates no UE for the multicast MBS session (e.g. due to UE becomes CM-IDLE state), the NG-RAN triggers release of the shared delivery as described in clause 7.2.2.4.

8. NG-RAN acknowledges the NGAP deactivation Response message.

9. The AMF invokes Namf_MBSCommunication_N2MessageTransfer Response to acknowledge the service for MB-SMF.

When the MBS session is in "Inactive" state and handover procedure is triggered, it is defined in clause 7.2.3.6.

NOTE 3: There is no explicit "deactivation" indication to the UE, how the UE is changed to IDLE state is defined in TS 38.300 [9].