Content for  TS 23.247  Word version:  18.7.0

UE may move from one NG-RAN node to another NG-RAN node after UE has joined the MB Session. There are various mobility scenarios possible, depending on whether one of the involved NG-RAN nodes supports MBS. During an active MBS Session, mobility between an NG-RAN supporting MBS and an NG-RAN node not supporting MBS requires the mobility procedure to provide the appropriate MBS traffic delivery method at the target NG-RAN node.

This clause describes an Xn based handover with MBS traffic delivered to the UE at the source NG-RAN node supporting MBS.

The following additions apply compared to clause 4.9.1.2 of TS 23.502: Before Handover: The source NG RAN has been provided with MBS Session Resource information (including the MBS Session ID and multicast QoS flow information) and the UE Context information contains a mapping information within the PDU Session Resource associated with the MBS Session Resource, e.g. including mapped unicast QoS Flows associated with the multicast QoS flow(s) of the MBS Session Resource. Handover Preparation Phase: At Xn handover, the target NG-RAN is provided with MBS session information by the source NG-RAN which causes:

• an MBS non-supporting target NG-RAN node to prepare the unicast resources according to associated QoS flow(s) information.
• an MBS supporting target NG-RAN node to allocate to the UE shared NG-RAN resources according to the MBS session information. If the 5GC Shared MBS traffic delivery for the indicated multicast MBS Session has not been established in target NG-RAN, target NG-RAN triggers setup of the resources for the 5GC Shared MBS traffic delivery, see clause 7.2.1.4 for details.

The SMF differentiates two cases: Case A) The target NG-RAN supports MBS. Step 3 applies and step 4 is skipped. Case B) The target NG-RAN does not support MBS. Step 3 is skipped, step 4 applies.

This clause describes the N2 based handover with MBS traffic delivered to the UE at the source NG-RAN node supporting MBS.

The following additions apply compared to clause 4.9.1.3 of TS 23.502):

When the UE has joined the multicast MBS session and the source NG-RAN node does not support MBS, the 5GC Individual MBS traffic delivery method is used for the multicast MBS session data delivery. When the Xn/N2 based handover procedure is triggered, the UE is handed over to the target NG-RAN node per existing Xn /N2 based handover procedure defined in TS 23.502. The following applies for an Xn based handover from an NG-RAN node not supporting 5G MBS:

• The source NG-RAN node requests the associated QoS Flow(s) in the associated PDU session to be handed over to the target NG-RAN node.
• In the Path Switch Request message, the target NG-RAN node, if MBS-capable, indicates it supports MBS to the SMF in the N2 SM information.
• After successful handover, if the target NG-RAN node supports MBS, the SMF triggers modification of the associated PDU Session at the target NG-RAN node by including the multicast MBS session related information in N2 SM Information as described in step 7 of clause 7.2.1.3, which may trigger the target NG-RAN node to initiate establishment of shared delivery as described in clause 7.2.1.4. NG-RAN provides the response to the request for the modification of the PDU session when the shared delivery of the MBS session data to the related UE (if applicable) is available
• Based on the response of PDU session modification procedure, the SMF changes the MBS session data delivery method from 5GC Individual MBS traffic delivery method to 5GC shared MBS traffic delivery method, and sends N4 Session modification message to UPF to configure UPF to not forward the received multicast MBS session data via the associated PDU Session. If there are no multicast MBS session data forwarding via the associated PDU session(s) needed, the SMF may also release the shared tunnel between the UPF and MB-UPF.

The following applies for an N2 based handover from an NG-RAN node not supporting MBS:

• During handover preparation phase, the SMF includes the multicast MBS session related information in N2 SM Information as described in step 7 of clause 7.2.1.3 and sends it to the target NG-RAN. The target NG-RAN, if MBS-capable, indicates it supports MBS to SMF in N2 SM information. If the target NG-RAN node supports MBS, the target NG-RAN node adds the UE into the MBS Session Context. If 5GC Shared MBS traffic delivery for the indicated multicast MBS session has not been established towards the target NG-RAN, the target NG-RAN uses the multicast MBS Session related information to allocate RAN resources to deliver the MBS data and initiates the shared delivery establishment towards the MB-SMF as described in clause 7.2.1.4.
• Based on the received MBS support information in N2 SM information from the target NG-RAN, the SMF determines the MBS data delivery method for the multicast MBS session. The SMF configures UPF to not forward the received multicast service data to the associated PDU Session via N4 Session modification message, i.e. SMF changes 5GC individual MBS traffic delivery to 5GC shared MBS traffic delivery. If there are no multicast MBS session data forwarding via the associated PDU session(s), the SMF may also release the shared tunnel between the UPF and MB-UPF.

To minimize data loss of a multicast MBS session during the handover procedure the following functions apply:

• For each MBS QoS flow, the MB-UPF adds a sequence number in each data packet of the MBS session sent by the MB-UPF and forwarded to all related NG-RAN nodes and UPFs via GTP-U tunnel. When the UPF forwards the received MBS data packet, the sequence number shall not be changed.
• If both the source NG-RAN node and target NG-RAN node support MBS, to minimize data loss of the MBS session either of, or a combination of, the following methods may be applied, as specified in TS 38.300:
  • Data may be forwarded from source NG-RAN node to target NG-RAN node. In handover preparation phase, the MBS progress information (i.e. PDCP number) is exchanged between source NG-RAN node and target NG-RAN node.
  • NG-RAN nodes share a common user plane entity, denoted as shared NG-U termination in TS 38.300, which allows the allocation of identical PDCP numbers to MBS users data when delivered to UEs in cells served by different NG-RAN nodes.
• If source NG-RAN node supports MBS and target NG-RAN node does not support MBS, the multicast MBS session data is forwarded from source NG-RAN node to target NG-RAN node via data forwarding tunnels allocated by the target NG-RAN node associated with the mapped unicast QoS flows within the associated PDU session according to the data forwarding mechanism defined in TS 23.502.
• If source NG-RAN node does not support MBS and target NG-RAN node supports MBS, for Xn/N2 handover, the multicast MBS session data is forwarded to the target NG-RAN node as the data forwarding mechanism defined in TS 23.502. Directly after the handover the target NG-RAN node thus still receives MBS session data via individual delivery. The UPF forwards multicast MBS session data within the associated PDU session which includes the sequence number received from the MB-UPF to the target NG-RAN node. Shared delivery of MBS data towards the target RAN node is being established as described in clause 7.2.1.4 and the target RAN node receives sequence numbers as part of the MBS data with sequence numbers via shared delivery.

If the MBS session is in Inactive state, the following differences apply as compared to the handover procedures for the MBS session in Active state:

• The target NG-RAN is provided with the MBS session ID, but is not provided with Active MBS Session Information by the source NG-RAN as specified in TS 38.423 and in TS 38.413.
• For Xn/N2 based handover, the information that MBS session is Inactive state is implied by the lack of Active MBS Session Information provided from the source RAN node towards the target RAN node.
• For the MBS supporting NG-RAN node, the target NG-RAN establishes the shared tunnel with the MB-UPF as usual, if it hasn't been established before. However, as the MBS session is in Inactive state, the NG-RAN node will not allocate related radio resource.
• After a handover to a target NG-RAN node not supporting MBS, the SMF removes the associated QoS flow(s) information.

If an MBS session is in Inactive state, the UE may be in CM-CONNECTED with RRC_INACTIVE state. If an MBS Session is in Active state, the UE may also be in CM-CONNECTED with RRC_INACTIVE state as specified in clause 16.10.5.2 of TS 38.300. The UE may resume the connection in a different NG-RAN node as specified in clauses 4.8.2.2 and 4.8.2.2a of TS 23.502, with following enhancement when the context retrieval is successful:

• For an MBS supporting NG-RAN:
  • if the UE context retrieved from the last serving NG-RAN includes MBS session information and the NG-RAN node has not yet established the 5GC Shared MBS traffic delivery for the MBS session, the NG-RAN establishes the 5GC Shared MBS traffic delivery as specified in clause 7.2.1.4. The NG-RAN then sends Path Switch Request indicating the MBS support information;
  • if the UE context retrieved from the last serving NG-RAN does not include MBS session information, Path Switch Request sent from NG-RAN includes the MBS support information. Based on the MBS support information, the SMF, after acknowledging the path switch request, provides the MBS related information and if applicable the associated QoS flow(s) information to the NG-RAN as specified in clause 7.2.1.3. The NG-RAN establishes the 5GC Shared MBS traffic delivery as specified in clause 7.2.1.4.
  • For an MBS non-supporting NG-RAN, Path Switch Request sent from NG-RAN does not include the MBS support information. If the MBS session is still inactive, the SMF, after acknowledging the path switch request, removes the associated QoS flow(s) information if it was provided before.

If the UE context retrieval fails, the UE is moved into RRC_IDLE state as per TS 38.300. The UE initiates the NAS signalling recovery including activating PDU Session(s) (see TS 24.501). When the associated PDU session(s) is activated during registration procedure (see clause 4.2.2.2.2 of TS 23.502) or service request procedure (see clause 4.2.3.2 of TS 23.502), clause 7.2.8 applies.