Content for TS 23.247 Word version: 18.7.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.2.6 Multicast session update procedure 7.2.8 Service request procedure 7.2.9 AF provisioning multicast MBS Session Authorization information 7.2.9a AF provisioning MBS Session assistance information 7.2.10 Multicast MBS procedures for UEs using power saving functions
...

7.2.6 Multicast session update procedure p. 93

Multicast MBS session update procedure is invoked by the AF to update the service requirement (result in multicast QoS parameters update and/or multicast QoS flow addition/removal) and/or MBS Service Area for an ongoing Multicast MBS session.

If the MBSF acts as the MBS security function for multicast as defined in TS 33.501, it may use this procedure to provide an updated MSK and optional updated MTK in addition for the MBS session via the control plane.

For the interaction between AF or MBSF and MB-SMF, see clauses 7.1.1.6 and 7.1.1.7.

Reproduction of 3GPP TS 23.247, Fig. 7.2.6-1: Multicast MBS Session update procedure

Figure 7.2.6-1: Multicast MBS Session update procedure

Step 1.

This procedure is triggered by the MB-SMF receiving the updated service requirement, an updated multicast session security context from the MBSF and/or MBS Service Area for a multicast MBS Session, see clauses 7.1.1.6 and 7.1.1.7.

Step 2.

The AF providing the updated service area may also inform UEs at application level about the new service area via a service announcement.

For QoS updates steps 3 to 7 are performed.

For MBS Service Area update steps 3 to 7 may be performed to allow NG-RAN to terminate data transmission in the area which is no longer in the MBS Service Area.

Step 3.

The MB-SMF invokes Namf_MBSCommunication_N2MessageTransfer service operation (MBS Session ID, [Area Session ID], N2 SM message container (TMGI, [QoS profile(s) for multicast MBS session], [MBS Service Area], [Area Session Id])) to the AMF(s).

Step 4.

The involved AMF sends N2 MBS session request (N2 SM message container) to NG-RAN nodes handling the multicast MBS session and possible Area Session ID based on the RAN node IDs stored in the AMF for the MBS session.

Step 5.

The NG-RAN node updates the QoS profile and/or MBS Service Area for the multicast MBS session based on the N2 MBS session request. If only QoS parameters are updated without multicast QoS flows added/removed, the NG-RAN may also update the QoS parameters of the associating PDU Sessions.

For MBS Service Area update, the NG-RAN updates the MBS Session Context with the updated MBS Service Area. The NG-RAN stops transmission of the related multicast data in the cell(s) which is within the old MBS Service Area but now outside the updated MBS Service Area. The NG-RAN also configures the UE not to receive the MBS data over the radio interface if the NG-RAN detects the UE(s) was in the previous MBS Service Area but is outside the updated MBS Service Area. If the NG-RAN node no longer serves any cells within the updated MBS service area, it requests to release shared delivery resource as defined in clause 7.2.2.4.

Step 6.

The NG-RAN node(s) acknowledges N2 MBS session request by sending an N2 MBS session Response message to the AMF.

Step 7.

The AMF invokes the Nmbsmf_MBSSession_ContextUpdate () to the MB-SMF.

Step 8.

The MB-SMF sends Nmbsmf_MBSSession_ContextStatusNotify request (MBS Session ID, [QoS profiles for multicast for MBS session], [MBS Service Area], [Area Session ID], [updated multicast session security context]) to the SMFs. For MBS Service Area updates, if an Area Session ID exists, the MB-SMF provides the MBS Service Area corresponding to the Area Session ID to the SMFs involved in the multicast MBS session. For QoS updates, the MB-SMF notifies SMFs handling all MBS service areas.

Step 9.

The SMF determines the affected UEs it serves based on the multicast MBS Session ID and Area Session ID (if provided) received in the step 8.

The subsequent steps 10 to 12 are executed for each affected UE. For QoS updates, steps 10 and 11 are skipped.

Step 10.

[Conditional] For an MBS Service Area update, if the SMF previously subscribed at the AMF to notifications about the UE moving in or out of a subscribed "Area Of Interest", the SMF updates the subscription with the new MBS Service Area as area of interest.

Step 11.

[Optional] When the MBS Service Area is updated, if the SMF does not have the latest UE location, the SMF queries AMF which then query the NG-RAN for the current location of the UE to determine whether the UE is within the updated MBS Service Area.

Step 12.

For MSK updates, the SMF also triggers PDU Session Modification procedure and provides the updated multicast session security context in the N1 SM container.

For MBS Service Area update, the SMF triggers the PDU Session Modification procedure as defined in TS 23.502 with the following enhancement:

The SMF also updates the PDU session resources associated to the multicast MBS session with the new MBS service area in an N2 container. The RAN node serving the PDU session starts or terminates transmission of multicast content in cells which are added or removed in the updated service area, respectively, and if necessary, interacts with the MB-SMF to start or terminate the distribution of multicast data to the RAN node.
Towards the UE, the SMF provides the MBS service area in N1 SM container to the UE. For a UE previously inside the MBS service area but now outside the updated MBS service area of the multicast MBS session, the SMF may alternatively, based on operator policy, inform the UE in the N1 SM container that the UE has been removed from the multicast MBS session.
Towards the NG-RAN, the SMF provides the updated MBS service area in N2 SM information. For a NG-RAN node supporting MBS, it starts transmission of multicast content in cells which are added in the updated MBS service area if UEs within the Multicast MBS session are within those cells, and if necessary, the NG-RAN interacts with the MB-SMF to start the distribution of multicast data to the RAN node. The RAN node stops transmission of multicast content in cells which are removed from the updated MBS service area, and if necessary, the NG-RAN interacts with the MB-SMF to terminate the distribution of multicast data to the RAN node
For Individual delivery and a local Multicast MBS session the following applies: For a UE previously inside the service area but now outside the updated MBS service area, the SMF removes associated unicast QoS flows for the multicast MBS session. For a UE previously outside the service area but now inside the updated service area, the SMF adds associated unicast QoS flows for the multicast MBS session to the PDU session resources.

7.2.7 Void

7.2.8 Service request procedure p. 96

If the multicast MBS session is in Inactive state, the UE can go to CM-IDLE state or the user plane of the associated PDU Session may be deactivated even when the UE is in CM-CONNECTED state. When user plane of the associated PDU session is activated again, the SMF sends the MBS session information to NG-RAN during Service Request procedure as specified in TS 23.502. The MBS session information indicates that this MBS session is in Inactive state; and:

For the MBS supporting NG-RAN node, the NG-RAN establish the shared tunnel with the MB-UPF as usual. However, as the MBS session is in Inactive state, the NG-RAN node will not allocate related radio resource.
For the non-MBS supporting NG-RAN node, the unicast QoS flow associated with the MBS session are not established.

The service request procedure can also be executed while the multicast MBS session is in Active state: The UE can go to CM-IDLE state due to AN release as specified in TS 23.502. In addition, to activate the associated PDU session(s) parts of the service request procedure can also be executed during the Mobility Registration Update procedure as specified in clause 4.2.2.2.2 of TS 23.502. When the service request procedure is executed, the SMF provides the MBS session information indicating that the UE joined the MBS session to the NG-RAN within N2 SM container for the associated PDU Session.

7.2.9 AF provisioning multicast MBS Session Authorization information p. 96

The AF provisions the multicast MBS session authorization information for multicast MBS sessions that are not open to "any UE". The procedure specified in clause 4.15.6.2 of TS 23.502 is reused with the following enhancements:

The AF may provision the MBS Session Authorization information to the 5GC. The MBS Session Authorization information is associated with a group of UEs.

Table 7.2.9-1: MBS Session Authorization information

Parameters	Description
MBS Session Authorization information	One or more MBS Session IDs.
MBS Session Authorization information	A group of UEs identified by an External Group ID.

The AF may support multicast MBS group membership management and provide parameters as described in Table 7.2.9-2.

Table 7.2.9-2: Multicast MBS group membership management parameters

Parameters	Description
List of GPSI	List of multicast group members, each member is identified by GPSI.
External Group ID	Identifier for multicast MBS group.

If a new multicast MBS group is created, the UDM shall assign a unique Internal Group ID for the multicast MBS group and include the newly assigned Internal Group ID in the Nudr_DM_Create Request message.
If the AF is authorised by the UDM to provision the MBS Session Authorization information, the UDM resolves the GPSI of each MBS session group member to SUPI, and requests to create, update or delete the provisioned MBS Session Authorization information as part of the MBS subscription data for each SUPI via Nudr_DM_Create/Update/Delete Request message, and the message includes the provisioned MBS Session Authorization information.

7.2.9a AF provisioning MBS Session assistance information |R18| p. 97

After the AF obtains the MBS Session ID of a multicast MBS Session as specified in clauses 7.1.1.2 and 7.1.1.3, the AF may provision the MBS Session assistance information for the UE(s) via NEF to UDM using the procedure of external parameter provisioning as specified clause 4.15.6.2 of TS 23.502 with the following enhancements:

the AF may provision MBS Session Assistance Information, which indicates that a UE is preferred to be kept connected when the related MBS Session the UE joined is active.

Table 7.2.9a-1: MBS Session Assistance information

Parameters	Description
MBS Session Assistance information	A list of UEs represented by GPSIs that are preferred to be kept connected when the MBS Session represented by the indicated MBS session ID the UE joined is active.
	MBS Session ID.

If the AF is authorised by the UDM to provision the UE list MBS Assistance information, the UDM resolves the GPSI to SUPI, and requests to create, update or delete the provisioned UE list MBS Assistance information as part of the MBS subscription data for each SUPI.

7.2.10 Multicast MBS procedures for UEs using power saving functions |R18| p. 97

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

For an multicast MBS session, a UE needs to join the multicast session as defined in clause 7.2.1.3 prior to MBS data reception. To join the multicast session, the UE needs to be in RRC_CONNECTED state. The UE may select any suitable time when it is in RRC_CONNECTED state or transition to RRC_CONNECTED state before joining the multicast session.

NOTE 1:
If the UE has not previously joined the multicast MBS session, at the possible scheduled activation time it performs MBS join procedure. Whether the UE performs MBS join procedure in advance and stays "joined" or every time at activation time is left up to UE implementation.
At MBS Session Activation, when the AMF perform group paging, the AMF also includes the CM-IDLE UEs using power saving function(s).
If a UE is in RRC_CONNECTED state or in CM-IDLE state or CM-CONNECTED with RRC_INACTIVE state, and reachable (e.g. in active time in MICO or PTW for eDRX), due to other reasons at the start time and the scheduled activation times, the UE follows the related MBS procedures (e.g. clause 7.2.1 for UE join and clause 7.2.5.2 for MBS Session Activation).
If a UE is in CM-IDLE state or CM-CONNECTED with RRC_INACTIVE and in deep sleep (i.e. unreachable for paging to the network) at the possible start time and the possible scheduled activation times, the UE leaves the deep sleep state at the session start time and the possible scheduled activation times to allow MBS related procedures (e.g. clause 7.2.1 for UE join and clause 7.2.5.2 for MBS Session Activation):
- At the possible start time, an RRC_IDLE or CM-CONNECTED with RRC_INACTIVE UE needs to send a request to transition to RRC_CONNECTED state and join the multicast MBS session (if not done before).
  
  NOTE 2:
  The UE become reachable in the network for the unicast service as well.
- At the possible scheduled activation times, an RRC_IDLE UE that already joined the multicast MBS session needs to listen for paging requests and if paged by the network follow the existing procedures in clause 7.2.5.2.
  
  NOTE 3:
  How long the UE need to listen to paging is left up to UE implementation.
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-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 4:
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.