7.1.1 MBS Session Management

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

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

7.1.1.1 General

The call flows in clause 7.1.1 and clause 7.3 show a "NEF/MBSF", but as detailed in Annex A, there can be different related network deployment involving either only NEF, or MBSF, or both.

The interactions between "NEF/MBSF" and MB-SMF, PCF, BSF and NRF depicted in the call flows apply for NEF, MBSF or a combined NEF and MBSF, depending on network deployment. They may also apply for an AF in the trusted domain where NEF is not mandated.

However, the interactions between AF and "NEF/MBSF" depicted in the call flows only apply for the NEF.

Interactions between AF and MBSF based on the MB2 interface follow TS 23.468 [10] (see Annex C).

Interactions between AF and MBSF based on the xMB interface follow TS 26.348 [11] (see Annex C).

Services offered by the MBSF and related interactions based on that service between MBSF and AF or NEF (if MBSF and NEF are split as shown in configuration 2) are specified in TS 26.502 [18].

Detailed interactions between the MBSF or NEF and the MBSTF are specified in TS 26.502 [18].

7.1.1.2 MBS Session Creation without PCC

This procedure is used by the AF to start the MBS Session towards 5GC and consist of TMGI allocation, and MBS session creation, and they apply to both multicast and broadcast communications unless otherwise stated.

For multicast, MBS session establishment procedure triggered by UE join requests may follow the MBS session creation procedure to reserve resources towards NG-RAN. For broadcast, the MBS session start procedure to reserve resources towards NG-RAN is triggered by the MBS session creation procedure.

For both broadcast and multicast communication, the TMGI allocation may be separated from the MBS Session creation request.

For multicast communication, TMGI allocation procedure is applicable if TMGI is used as MBS Session ID.

Figure 7.1.1.2-1: MBS Session Creation without PCC

Steps 1 to 6 are optional and only applicable if TMGI is used as MBS Session ID and required to be pre-allocated.

1. AF sends Nnef_MBSTMGI_Allocate Request (TMGI number, [MBS service area]) message to NEF/MBSF to request allocation of a TMGI(s) to identify new MBS session(s). The MBS service area indicates the possible service area for those TMGI(s) to be allocated, which may be needed for local MBS.

NOTE 1: Depending on the network deployment and use case, MB-SMF may receive requests from AF directly, or via NEF, or via MBSF, or via NEF and MBSF.

2. NEF/MBSF checks authorization of AF. If geographical area information or civic address information was provided by the AF as MBS service area, NEF/MBSF performs the translation.

NOTE 2: NEF is not required if AF is in trusted domain.

3. NEF/MBSF discovers and selects an MB-SMF using NRF or based on local configuration, possibly based on MBS service area.

4. NEF/MBSF sends an Nmbsmf_TMGI_Allocate Request (TMGI number) message to the MB-SMF.

5. MB-SMF allocates TMGI(s) and returns the TMGI(s) to the NEF/MBSF via the Nmbsmf_TMGI_Allocate response (TMGI(s), expiration time).

6. The NEF or MBSF responds to the AF by sending an Nnef_MBSTMGI_Allocate Response (TMGI(s), expiration time).

7. The AF may perform a Service Announcement towards UEs. The AF informs UEs about MBS Session information with MBS Session ID, e.g. TMGI, SSM, and possibly other information e.g. MBS service area, session description information, etc.

The MBS service area information can be Cell ID list, TAI list, geographical area information or civic address information. Amongst them, Cell ID list and TAI list shall only be used by AFs who reside in trust domain, and when the AFs are aware of such information.

The UE needs to be aware if the service is broadcast or multicast to decide if JOIN is to be performed.

8. AF of content provider may provide description for an MBS session (possibly providing information for a previously allocated TMGI to NEF via a Nnef_MBSSession_Create request ([MBS Session ID], MBS service type, MBS Service Information, [TMGI allocation request], [MBS service area], [Any UE indication], [start and end time of the MBS session], [MBS session state], [ingress transport address request indication], [Request for location-dependent session], [FSA ID(s)]). If step 1-6 has not been executed before, the AF may provide an MBS Session ID containing an SSM or it may request that the network allocates an MBS Session ID (i.e., TMGI). The AF provides the MBS service type (i.e. either multicast service or broadcast service) and MBS Service Information (as defined in clause 6.14). The AF may provide the "Any UE indication" (indicating whether a multicast MBS session is "open to any UEs"), MBS service area, start and end time of the MBS session and MBS session state (active/inactive). In addition, the AF request may also indicate that the allocation of an ingress transport address is requested and that the AF request is for a location dependent MBS service.

If geographical area information or civic address information was provided by the AF as MBS service area, NEF/MBSF translates the MBS service area to Cell ID list or TAI list.

For broadcast communication, the AF may determine MBS FSA ID(s) for the Broadcast MBS session based on business agreements and include them in the description of the MBS session.

NOTE 3: MBS session state is applicable for multicast MBS Session.

9. NEF/MBSF checks authorization of content provider.

10. NEF/MBSF discovers MB-SMF candidates and selects MB-SMF as ingress control node, possibly based on MBS service area. If a TMGI is included in step 8, NEF/MBSF finds MB-SMF based on that TMGI.

11. NEF/MBSF sends Nmbsmf_MBSSession_Create Request ([MBS Session ID], MBS service type, [TMGI allocation request], MBS Service Information (as defined in clause 6.14), [MBS service area], [Any UE indication], [start and end time of the MBS session], [MBS session state], [ingress transport address request indication], [FSA ID(s)], [multicast session security context]) to MB-SMF, to request MB-SMF to reserve ingress resources for a MBS distribution session. The NEF/MBSF forwards all parameters it has received from the AF in step 8. If the MBSF decides to insert an MBSTF into the user plane for the MBS session, it also indicates that the allocation of an ingress transport address is requested even if this was not requested in step 8. The request also includes the Any UE indication if provided in step 8. If the MBSF acts as the MBS security function for multicast as defined in TS 33.501 [20], it provides a multicast session security context for the MBS session.

If requested to do so, or if a source specific multicast is provided as MBS Session ID in step 11, the MB-SMF allocates a TMGI.

For broadcast communication, if no MBS FSA ID(s) have been received, the MB-SMF selects MBS FSA ID(s) for the Broadcast MBS session based on local configuration.

12. Void.

13. The MB-SMF derives the required QoS parameters locally based on the MBS Service Information.

14. MB-SMF selects the MB-UPF. If the allocation of an ingress transport address was requested in step 11, the MB-SMF requests the MB-UPF to reserve user plane ingress resources. If multicast transport of the MBS data towards RAN nodes is to be used, the MB-SMF also request the MB-UPF to reserve for the outgoing data a tunnel endpoint and the related identifiers (source IP address, SSM and GTP Tunnel ID) and to forward data received at the user plane ingress resource using that tunnel endpoint.

If the allocation of an ingress transport address was not requested in step 11, the MB-SMF provides the SSM received as MBS Session ID to the MB-UPF and requests the MB-UPF to join the corresponding multicast tree from the content provider. The MB-SMF may also defer the configuration to join the corresponding multicast tree e.g. based on information that the session is inactive, service requirements and MBS start/end time until receiving the first query for the MBS session as part of the establishment procedure in clause 7.2.1.3, or until receiving a request to activate the MBS session via the MBS Session Update procedure in clause 7.1.1.6.

15. If requested, MB-UPF selects an ingress address (IP address and port) and a tunnel endpoint for the outgoing data and provides it to MB-SMF.

16. MB-SMF indicates the possibly allocated ingress address to the NEF/MBSF. MB-SMF may include TMGI if it is allocated in step 11. For broadcast communication, the MB-SMF includes any MBS FSA ID(s) selected in step 11. It also indicates the success or failure of reserving transmission resources.

16a. If a source specific multicast address is provided as MBS Session ID in step 11, the MB-SMF updates its NF profile at the NRF with the serving MBS Session ID. If an MBS service area was received in step 11, the MB-SMF updates its NF profile at the NRF with that information.

NOTE 3: If TMGI is used to represent an MBS Session, MB-SMF does not need to update NRF if the TMGI range(s) supported by an MB-SMF is already included in the MB-SMF profile when MB-SMF register itself into NRF.

17. For broadcast communication, the MB-SMF continues the procedure towards the AMF and NG-RAN as specified in clause 7.3.1 to request the allocation of resources to for the transmission of the broadcast session.

18. [Optional] If the MBSF decides to use an MBSTF, the NEF/MBSF provides the ingress address received in step 16 towards the MBSTF as DL destination. If the allocation of an ingress transport address was requested in step 8, the MBSF requests the MBSTF to allocate the user plane ingress resources. If the allocation of an ingress transport address was not requested in step 8, the MBSF provides the SSM received as Multicast session ID in step 8 and requests the MBSTF to join the corresponding multicast tree from the content provider.

19. [Conditional on step 19] If requested, the MBSTF selects an ingress address (IP address and port) and provides it to NEF/MBSF.

20. The NEF/MBSF-C indicates the possibly allocated ingress address and other parameters (e.g. TMGI) to the AF via an Nnef_MBSSession_Create response ([TMGI], [Allocated ingress address])). If MBS Session ID is not provided in step 8, or the MBS Session ID is SSM, the NEF/MBSF provides the allocated TMGI. If AF requested the allocation of an ingress transport address, the message also includes the allocated ingress address. For broadcast communication, the message also includes any MBS FSA ID(s) received in step 17.

21. Same as step 7. The AF may also perform a service announcement at this stage.

22. For multicast communication, depending on configuration UEs can join the MBS Session as specified in clause 7.2.1.

7.1.1.3 MBS Session Creation with PCC

Deployment of dynamic PCC is optional. This clause describes the procedure when dynamic PCC is deployed.

Figure 7.1.1.3-1: MBS Session Creation with PCC

Steps 1 to 7 are optional and only applicable if TMGI is used as MBS Session ID and required to be pre-allocated.

1 to 9: Same as in Figure 7.1.1.2-1.

10. The NEF/MBSF may optionally, based on local configuration, decide to interact with the PCF.

NOTE 1: In the deployment without NEF and MBSF, the AF optionally interacts with PCF in steps 11-18.

If the NEF/MBSF decided to interact with the PCF, steps 11 to 19 are performed, and in step 20 the MBS Service Information is not provided to the MB-SMF.

If the NEF/MBSF decided not to interact with the PCF, steps 12 to 19 are skipped, and in step 20 the MBS Service Information is provided to the MB-SMF.

11. [Conditional] If the PCF did not receive an MBS Session ID from the AF in step 8, the NEF/MBSF sends an Nmbsmf_TMGI_Allocate Request (1) message to the MB-SMF and the MB-SMF allocates a TMGI and returns the TMGI to the NEF/MBSF via the Nmbsmf_TMGI_Allocate response (TMGI, expiration time).

12. [Conditional] If the NEF/MBSF receives the Request for location-dependent session from the AF and if there is a need to select the same PCF for the location dependent MBS Sessions, the NEF/MBSF first uses the BSF Discovery service to discover whether there is a PCF serving the MBS session with the MBS Session ID by using Nbsf_management_Discovery operation. If there is a PCF registered for the MBS Session ID, the NEF/MBSF interacts with that PCF and skips the following step 13.

NOTE 2: This step is not necessary in a deployment with a single PCF.

13. [Conditional] If step 12 was not executed or the interaction with the BSF revealed that no PCF is registered for the MBS Session ID, the NEF/MBSF discovers the PCF candidates by interacting with the NRF and selects a PCF, possibly based on MBS service area.

14. The NEF/MBSF sends an Npcf_MBSPolicy_Authorization_Create Request (MBS Session ID, MBS Service Information (as defined in clause 6.14)) to the PCF.

15. [Optional] The PCF may retrieve authorization information for the MBS session from the UDR (see clause 6.10.2) and takes it into account for the subsequent authorization and QoS allowance check.

NOTE 3: This step is not necessary in a deployment with a single PCF if authorization data are stored in the PCF.

16. The PCF determines whether the request is authorized and if the request is authorized, the PCF derives the required QoS parameters based on the received MBS Service Information and determines whether this QoS is allowed. If the required QoS is allowed, the PCF generates the policy information for the MBS session (as defined in clause 6.10) and stores it together with the MBS Session ID.

17. If the request is authorized and the required QoS is allowed, the PCF registers at the BSF that it handles the MBS session by using Nbsf_management_Register Request (MBS Session ID, PCF ID). It provides an identifier that the policy association is for MBS and the MBS Session ID, its own PCF ID and optionally its PCF set ID.

NOTE 4: This step is not necessary in a deployment with a single PCF.

18. The PCF sends an Npcf_MBSPolicy_Authorization_Create Response (Result indication) to the NEF/MBSF.

If the request is not authorized or the required QoS is not allowed, the PCF indicates so in the response to the NEF/MBSF which in turn informs the AF about it (by sending the Nnef_MBSSession_Create Response) and ends this procedure.

19. Same as step 10 in Figure 7.1.1.2-1.

20. Same as step 11 in Figure 7.1.1.2-1 with the difference that the MBS Service Information is not present if the optional interaction between AF/NEF/MBSF and PCF has been performed (as the MBS Service Information was provided to the PCF in step 14).

21. The MB-SMF discovers the PCF using NRF.

22. The MB-SMF sends an Npcf_MBSPolicyControl_Create Request (MBS Session ID, [MBS Service Information (as defined in clause 6.14)]) for the MBS session towards the PCF. The MB-SMF forwards the MBS Service Information to the PCF if received from the NEF/MBSF in the previous step 20.

If PCF receives MBS Service Information from the MB-SMF, the PCF performs the subsequent steps 23 to 26. If the PCF does not receive MBS Service Information from the MB-SMF, but has previously determined policy information for the MBS session (see step 16) corresponding to the MBS Session ID received from the MB-SMF, the PCF continues with step 27.

23. If the PCF is not handling the MBS Session ID, the PCF uses the BSF Register service to check whether there is already a PCF serving the MBS session. If so, the PCF skips steps 24 to 26 and indicates in step 27 that the PCF serving the MBS session shall be contacted.

NOTE 5: This step is not necessary in a deployment with a single PCF.

24. [Optional] The PCF may retrieve authorization information for the MBS session from the UDR (see clause 6.10.2) and takes it into account for the subsequent authorization and QoS allowance check.

NOTE 6: This step is not necessary if authorization data are stored in the PCF.

25. The PCF determines whether the request is authorized and if the request is authorized, the PCF derives the required QoS parameters based on the received MBS Service Information and determines whether this QoS is allowed. If the required QoS is allowed, the PCF generates the policy information for the MBS session (as defined in clause 6.10) and stores it together with the MBS Session ID.

26. If the request is authorized and the required QoS is allowed the PCF registers at the BSF that it handles the MBS session by using Nbsf_management_Register Request (MBS Session ID, PCF ID). It provides an identifier that the policy association is for MBS and the MBS Session ID, its own PCF ID and optionally its PCF set ID.

NOTE 7: This step is not necessary in a deployment with a single PCF.

27. The PCF responds with Npcf_MBSPolicyControl_Create Response ([policy information for the MBS session (as defined in clause 6.10)], Result indication).

If the request is not authorized or the required QoS is not allowed, the PCF indicates so in the response to the MB-SMF which in turn informs the AF about it (by sending the Nmbsmf_MBSSession_Create Response) and ends this procedure.

If another PCF is serving the MBS session, the PCF indicates that another PCF serving the MBS session shall be contacted and provides an ID of that other PCF. The MB-SMF then repeats step 22 towards that other PCF.

28-37: Same as steps 14-22 in Figure 7.1.1.2-1.

NOTE 8: Steps 33-36 can be executed in parallel to step 32.

7.1.1.4 MBS Session Deletion without PCC

This procedure is used by the AF to delete the MBS Session. This procedure may also include TMGI de-allocation. The procedures apply to both multicast and broadcast communications unless otherwise stated. This procedure releases the reserved resources in both 5GC and NG-RAN.

Figure 7.1.1.4-1: MBS Session Deletion without PCC

1. AF of content provider may request to delete the MBS session (MBS Session ID).

2/3. If an MBSTF was inserted into the user plane, the MBSF request the MBSTF to release user plane resources.

4. NEF/MBSF requests MB-SMF to delete resources for the MBS session.

5. For Broadcast MBS session, the MB-SMF triggers resource release towards the AMFs as specified in clause 7.3.2. For Multicast MBS session, the MB-SMF triggers resource release towards the SMFs as specified in clause 7.2.2.3.

6/7. MB-SMF requests the MB-UPF to release user plane resources.

8. [Conditional] If MB-SMF configured the profile with an MBS Session ID when the MBS session was created, the MB-SMF updates its NF profile at NRF to release the MBS Session ID.

9. MB-SMF responds to the NEF/MBSF.

10. The NEF/MBSF responds to the AF.

11. [Optional] AF requests NEF/MBSF to de-allocate TMGI(s),

12. [Conditional on step 11] NEF/MBSF forwards request to de-allocate TMGI(s) to MB-SMF.

13. [Conditional on step 12] The MB-SMF responds to the NEF or MBSF by sending a de-allocate TMGI Response message.

14. [Conditional on step 13] NEF or MBSF forwards de-allocate TMGI Response message to AF.

7.1.1.5 MBS Session Deletion with PCC

This procedure is used by the AF to release the MBS Session. This procedure may also include TMGI de-allocation. The procedures apply to both multicast and broadcast communications unless otherwise stated. This procedure releases the reserved resources in both 5GC and NG-RAN.

Figure 7.1.1.5-1: MBS Session Deletion with PCC

1-3. Same as in Figure 7.1.1.4-1.

For the interaction with the PCF in this procedure, the NEF/MBSF applies the same decision that was taken in step 10 in Figure 7.1.1.3-1 during the MBS Session Creation with PCC procedure:

If the NEF/MBSF decided to interact with the PCF, steps 4 to 5 are performed.

If the NEF/MBSF decided not to interact with the PCF, steps 4 to 5 are skipped.

NOTE 1: If NEF and MBSF is not deployed, the AF optionally interacts with PCF in steps 4 to 5.

4. The NEF/MBSF sends an Npcf_MBSPolicyAuthorization_Delete Request to the PCF that handles the MBS Session.

5. The PCF sends an Npcf_MBSPolicyAuthorization_Delete Response to the NEF/MBSF.

6. Same as step 4 in Figure 7.1.1.4-1.

7. The MB-SMF sends the Npcf_MBSPolicyControl_Delete Request to request the deletion of the SM Policy Association with the PCF.

8. The PCF sends the Npcf_MBSPolicyControl_Delete Response to the MB-SMF.

9. The PCF de-registers at the BSF that it handles the MBS session.

10-19. Same as steps 5-14 in Figure 7.1.1.4-1.

7.1.1.6 MBS Session Update without PCC

This procedure is used by the AF to update the MBS service area and/or MBS Service Information. Updating MBS Service Information may lead to addition of new MBS QoS Flow(s), removal of existing MBS QoS Flow(s) or update of existing MBS QoS Flow(s). The procedure applies to both multicast and broadcast communications unless otherwise stated.

If the MBSF acts as the MBS security function for multicast as defined in TS 33.501 [20], it may use this procedure to provide an MSK for the MBS session via the control plane. In this case the MBSF may initiate this procedure and steps 1, 2 and 10 do not apply.

NOTE: The procedure is not applicable if no MSK but only the MTK is to be updated.

For local multicast services and location dependent multicast services, the AF may perform a Service Announcement towards UEs to update the MBS service area before the MBS Session Update procedure is started or after the MBS Session Update procedure is completed.

Figure 7.1.1.6-1: MBS Session Update without PCC

1. AF of content provider initiates MBS Session Update to a NEF/MBSF, e.g. to update MBS service area and/or update MBS Service Information (as defined in clause 6.14), or to activate or deactivate an MBS session. AF may provide updated information for an MBS session (identified by MBS session ID) by sending an Nnef_MBSSession_Update Request (MBS Session ID, [MBS Service Information], [MBS service area], [MBS session state (active/inactive)]).

If geographical area information or civic address information was provided by the AF as MBS service area, NEF/MBSF translates the MBS service area to Cell ID list or TAI list.

2. NEF checks authorization of AF.

3. NEF/MBSF sends Nmbsmf_MBSSession_Update Request to MB-SMF forwarding the updated information received from the AF in step 1. If the MBSF acts as the MBS security function for multicast as defined in TS 33.501 [20], it may provide an updated multicast session security context for the MBS session in the Nmbsmf_MBSSession_Update Request.

4. The MB-SMF derives any updated QoS parameters locally under consideration of the updated MBS Service Information. This may lead to addition of new MBS QoS Flow(s), removal of existing MBS QoS Flow(s) or update of existing MBS QoS Flow(s).

5-6. MB-SMF may need to update MB-UPF, e.g. if new MBS QoS Flow is to be created, or existing MBS QoS Flow is to be deleted.

7. For broadcast communication, the MB-SMF continues the procedure towards the AMF and NG-RAN as specified in clause 7.3.3. For multicast communication, the MB-SMF continues the procedure towards the AMF and NG-RAN as specified in clause 7.2.5 (for service activation/deactivation), 7.2.6 (for QoS updates and service area updates).

8. If an MBS service area is being updated, the MB-SMF stores the new service area in its profile at the NRF.

9. MB-SMF responds to the NEF/MBSF with a Nmbsmf_MBSSession_Update Response.

10. NEF/MBSF responds to the AF with a Nnef_MBSSession_Update Response.

7.1.1.7 MBS Session Update with PCC

Figure 7.1.1.7-1: MBS Session Update with PCC

1-2. Same as in Figure 7.1.1.6-1.

3. For the interaction with the PCF in this procedure, the NEF/MBSF applies the same decision that was taken in step 10 in Figure 7.1.1.3-1 during the MBS Session Creation with PCC procedure unless the MBS session update only relates to an activation or deactivation of the MBS session and/or an MBS service area update and thus no PCF interactions are required.

If the NEF/MBSF decided to interact with the PCF, steps 4 to 6 are performed and in step 7 an indication that the PCF has to be contacted is provided, and MBS Service Information is not provided to the MB-SMF.

If the NEF/MBSF decided not to interact with the PCF, steps 4 to 6 are skipped and MBS Service Information is provided to the MB-SMF in step 7.

NOTE 1: In the deployment without NEF and MBSF, the AF optionally interacts with PCF in steps 4 – 6.

4. NEF/MBSF sends an Npcf_MBSPolicy_Authorization_Update Request (application session context, [MBS Service Information]) to the PCF forwarding the updated information received from the AF in step 1.

5. The PCF determines whether the update is authorized and if the update is authorized, the PCF derives the update for the QoS parameters based on the received MBS Service Information and determines whether this new QoS is allowed. If the new QoS is allowed, the PCF updates the policy information for the MBS session (as defined in clause 6.10) accordingly. If the policy information for the MBS session has changed, the PCF shall provide an indication that the PCF has to be contacted.

6. The PCF sends an Npcf_MBSPolicy_Authorization_Update Response (Result indication, [indication that the PCF has to be contacted]) to the NEF/MBSF.

If the update is not authorized or the new QoS is not allowed, the PCF indicates so in the response to the NEF/MBSF which in turn informs the AF about it (by sending the Nnef_MBSSession_Update Response) and ends this procedure.

7. The NEF/MBSF sends Nmbsmf_MBSSession_Update Request to the MB-SMF forwarding the updated information received from the AF in step 1. If the NEF/MBSF has decided not to interact with the PCF, the NEF/MBSF send the indication that the PCF has to be contacted, in addition.

If the NEF/MBSF has decided to interact with the PCF and thus provided the updated MBS Service Information to the PCF in step 4, the updated MBS Service Information is not forwarded. The NEF/MBSF forwards the indication that the PCF has to be contacted, if received from the PCF.

8. If the MB-SMF does not receive the indication that the PCF has to be contacted, the MB-SMF decides whether to interact with the PCF. If it decides not to interact with the PCF, it continues with step 11. Otherwise, the MB-SMF sends an Npcf_MBSPolicyControl_Update Request (MBS Policy Association ID, [MBS Service Information]) for the MBS session towards the PCF. The MB-SMF forwards the MBS Service Information to the PCF if received from the NEF/MBSF in the previous step 7.

If PCF receives MBS Service Information from the MB-SMF, the PCF performs the subsequent step 9. If the PCF does not receive MBS Service Information from the MB-SMF, the PCF identifies any updated policy information for the MBS session (as defined in clause 6.10) corresponding to the MBS Session ID received from the MB-SMF and continues with step 10.

9. The PCF determines whether the update is authorized and if the update is authorized, the PCF derives the update for the QoS parameters based on the received MBS Service Information and determines whether this new QoS is allowed. If the new QoS is allowed, the PCF updates the policy information for the MBS session (as defined in clause 6.10) accordingly.

10. The PCF responds with Npcf_MBSPolicyControl_Update Response ([updated policy information for the MBS session], Result indication).

11.-16. Same as steps 5-10 in Figure 7.1.1.6-1.