- How MBS Multicast differs: the content goes to a dedicated set of UEs, each of which joins the session.
- Reception: in RRC_CONNECTED by PTM and/or PTP, or in RRC_INACTIVE by PTM only; never in RRC_IDLE.
- Delivery: 5GC Shared delivery where the NG-RAN node supports MBS, otherwise 5GC Individual delivery in the UE's PDU Session.
In MBS Multicast, the same service and the same content are provided simultaneously to a dedicated set of UEs; not all UEs in the MBS service area are authorised to receive them. To receive the service, the UE performs the MBS Session Join procedure, and the first accepted join triggers the establishment of the multicast session towards NG-RAN and the UE. A UE can receive multicast in RRC_CONNECTED, by PTP and/or PTM, and in RRC_INACTIVE, by PTM only; HARQ feedback and retransmission can be applied to PTP and PTM in RRC_CONNECTED. The gNB decides in which of the two states the UE receives (TS 23.247 V20.0.0 clause 3.1, 7.2.1.1, 6.17; TS 38.300 V19.4.0 clause 16.10.1, 16.10.5.1).
This page follows an MBS Multicast session from its provisioning to the reception of its data by UEs in RRC_CONNECTED, then its deactivation, update and release, in Release 19. Each step names the functions, the message or service, and the clause that defines it. Reception in RRC_INACTIVE (TS 23.247 clause 6.17) and mobility (TS 23.247 clauses 6.3.1 and 7.2.3, TS 38.300 clause 16.10.5.3) are below.
The steps
Network set-up (TS 23.247 clause 7.1):
- N1 (TS 23.247 V20.0.0 clause 7.1.1.1, 7.1.1.2). Provisioning by the AF or the MBS Application Provider
- N2 (TS 23.247 V20.0.0 clause 7.1.1.2 steps 1 to 6). TMGI allocation
- N3 (TS 23.247 V20.0.0 clause 7.1.1.2 steps 8 to 13, 7.1.2). MBS Session creation at the MB-SMF
- N4 (TS 23.247 V20.0.0 clause 7.1.1.2 steps 14 and 15; TS 29.244 V19.6.0 clause 5.34.2.2). MB-UPF configuration
- N5 (TS 23.247 V20.0.0 clause 7.1.1.2 step 7, 7.2.1.3). Service announcement
Join and session establishment (TS 23.247 clause 7.2.1):
- J1 (TS 23.247 V20.0.0 clause 7.2.1.2). The associated PDU Session
- J2 (TS 23.247 V20.0.0 clause 7.2.1.3 step 1). Join request
- J3 (TS 23.247 V20.0.0 clause 7.1.2, 7.2.1.3 steps 2 and 3). MB-SMF discovery and session context
- J4 (TS 23.247 V20.0.0 clause 7.2.1.3 step 4). Authorisation
- J5 (TS 23.247 V20.0.0 clause 7.2.1.3 steps 5 and 6; TS 38.413 V19.4.0 clause 9.3.1.212). N2 SM information towards NG-RAN
- J6 (TS 23.247 V20.0.0 clause 7.2.1.3 step 7, 7.2.1.4; TS 38.413 V19.4.0 clause 8.18.1). Shared delivery towards the NG-RAN node
- J7 (TS 38.401 V19.3.0 clause 8.15.1.2; TS 37.483 V19.4.0 clause 8.6.2.1, 8.6.2.2; TS 38.473 V19.4.0 clause 8.14.6, 8.14.10). Inside the gNB: E1AP and F1AP
- J8 (TS 23.247 V20.0.0 clause 7.2.1.3 steps 7a to 11e). Response, and 5GC Individual delivery
Radio configuration in RRC_CONNECTED:
- 1. RRCReconfiguration with multicast MRBs (TS 38.300 V19.4.0 clause 16.10.5.2; TS 38.331 V19.4.0 clause 5.3.5.6.7, 6.3.2)
- 2. PTM and PTP legs (TS 38.300 V19.4.0 clause 16.10.3; TS 38.331 V19.4.0 clause 6.3.2)
- 3. G-RNTI, HARQ feedback, DRX and common frequency resource (TS 38.331 V19.4.0 clause 6.3.2; TS 38.300 V19.4.0 clause 16.10.5.6, 16.10.5.7; TS 38.213 V19.5.0 clause 18)
- 4. Receiving PTM and PTP (TS 38.300 V19.4.0 clause 16.10.5.4; TS 38.212 V19.4.0 clause 7.3.1.5.2, 7.3.1.5.3; TS 38.321 V19.4.0 clause 5.3.1)
Life cycle:
- A1 (TS 23.247 V20.0.0 clause 7.2.5.2; TS 38.413 V19.4.0 clause 8.5.2, 8.18.3; TS 38.300 V19.4.0 clause 16.10.5.2). Activation, with group paging
- A2 (TS 23.247 V20.0.0 clause 7.2.5.3; TS 38.413 V19.4.0 clause 8.18.4). Deactivation
- A3 (TS 23.247 V20.0.0 clause 7.1.1.6, 7.2.6; TS 38.413 V19.4.0 clause 8.18.5). Session update
- U (TS 23.247 V20.0.0 clause 7.2.1.3 steps 13 to 19). User plane, 5GC Shared and 5GC Individual delivery
- L1 (TS 23.247 V20.0.0 clause 7.2.2.2). Leave requested by the UE
- L2 (TS 23.247 V20.0.0 clause 7.1.1.4, 7.2.2.3). Leave requested by the network, and session release
- L3 (TS 23.247 V20.0.0 clause 7.2.2.4; TS 38.413 V19.4.0 clause 8.18.2). Release of shared delivery
Mobility (TS 23.247 clause 7.2.3):
- H (TS 23.247 V20.0.0 clause 7.2.3.2, 7.2.3.3; TS 38.300 V19.4.0 clause 16.10.5.3.2). Handover between nodes that support MBS, Xn or N2
- T (TS 23.247 V20.0.0 clause 6.3.1, 7.2.3.2, 7.2.3.3; TS 38.300 V19.4.0 clause 16.10.5.3.3). Handover to a node that does not support MBS
- F (TS 23.247 V20.0.0 clause 7.2.3.4; TS 38.300 V19.4.0 clause 16.10.5.3.3). Handover from a node that does not support MBS
- I (TS 23.247 V20.0.0 clause 7.2.3.6). Handover of an inactive session
- R (TS 23.247 V20.0.0 clause 7.2.3.7, 7.2.3.8.1; TS 38.300 V19.4.0 clause 16.10.5.3.5). UEs in RRC_INACTIVE
Implementation blueprint
The whole chain, step by step (Step, Function(s), Interface and message or service, Clause)
| Step | Function(s) | Interface and message or service | Clause |
|---|---|---|---|
| N1. Provisioning | MBS Application Provider, MBSF | Nmb10 (or N33 and Nmb5): Nmbsf_MBSUserService_Create, Nmbsf_MBSUserDataIngestSession_Create; or the AF directly towards the NEF/MBSF | TS 26.502 cl. 5.2, 5.3; TS 23.247 cl. 7.1.1.1 |
| N2. TMGI allocation | AF, NEF/MBSF, MB-SMF | Nnef_MBSTMGI_Allocate; Nmbsmf_TMGI_Allocate (HTTP POST on /tmgi), when a TMGI is the MBS Session ID | TS 23.247 cl. 7.1.1.2; TS 29.532 cl. 5.2.2.2 |
| N3. MBS Session creation | AF, NEF/MBSF, MB-SMF, PCF (if dynamic PCC) | Nnef_MBSSession_Create; Nmbsmf_MBSSession_Create with MBS service type multicast, session state, Any UE indication (HTTP POST on /mbs-sessions); MB-SMF profile in the NRF | TS 23.247 cl. 7.1.1.2, 7.1.1.3, 7.1.2; TS 29.532 cl. 5.3.2.2 |
| N4. MB-UPF | MB-SMF, MB-UPF | N4mb: PFCP Session Establishment Request; the join of the multicast tree may be deferred | TS 23.247 cl. 7.1.1.2; TS 29.244 cl. 5.34.2.2 |
| N5. Announcement | AF or MBSF, UE | Service announcement with the MBS Session ID; MBSF activates the Multicast MBS Session so that UEs can join | TS 23.247 cl. 7.1.1.2, 7.2.1.3; TS 26.502 cl. 5.4, 5.5.1 |
| J1. Associated PDU Session | UE, AMF, SMF, UDM | PDU Session Establishment with the DNN and S-NSSAI for multicast; Nudm_SDM_Get for MBS subscription data | TS 23.247 cl. 7.2.1.2 |
| J2. Join | UE, AMF, SMF | PDU Session Modification Request with MBS Session IDs and join request; Nsmf_PDUSession_UpdateSMContext | TS 23.247 cl. 7.2.1.3 |
| J3. Session context | SMF, NRF, MB-SMF | Nnrf_NFDiscovery_Request with the MBS Session ID; Nmbsmf_MBSSession_ContextStatusSubscribe (HTTP POST on /mbs-sessions/contexts/subscriptions) | TS 23.247 cl. 7.1.2, 7.2.1.3; TS 29.532 cl. 5.3.2.9, table 6.2.3.1-1 |
| J4. Authorisation | SMF | MBS subscription data and Any UE indication | TS 23.247 cl. 7.2.1.3 |
| J5. N2 towards NG-RAN | SMF, AMF, NG-RAN | N2 SM information with MBS Session ID and QoS flow mapping; NGAP PDU Session Resource Modify Request Transfer, MBS Session Setup or Modify Request List | TS 23.247 cl. 7.2.1.3; TS 38.413 cl. 9.3.1.212, 9.3.4.3 |
| J6. Shared delivery | NG-RAN, AMF, MB-SMF, MB-UPF | DISTRIBUTION SETUP REQUEST and RESPONSE; Nmbsmf_MBSSession_ContextUpdate (HTTP POST on /mbs-sessions/contexts/update); N4mb; join of the LL SSM | TS 23.247 cl. 7.2.1.4; TS 38.413 cl. 8.18.1; TS 29.532 cl. 5.3.2.5; TS 29.244 cl. 5.34.2.2 |
| J7. Inside the gNB | gNB-CU-CP, gNB-CU-UP, gNB-DU | E1AP MC Bearer Context Setup and Modification; NGAP Distribution Setup; F1AP Multicast Context Setup, UE context management, Multicast Distribution Setup | TS 38.401 cl. 8.15.1.2; TS 37.483 cl. 8.6.2.1, 8.6.2.2; TS 38.473 cl. 8.14.6, 8.14.10 |
| J8. Response; individual delivery | NG-RAN, AMF, SMF, UPF, MB-SMF, MB-UPF | MBS Support Indicator in the response; N4 to the UPF; N19mb tunnel through Nmbsmf_MBSSession_ContextUpdate | TS 23.247 cl. 7.2.1.3; TS 38.413 cl. 9.3.1.210, 9.3.4.4; TS 29.244 cl. 5.34.3 |
| 1. RRCReconfiguration | gNB, UE | mrb-ToAddModList with MRB-ToAddMod (mbs-SessionId, mrb-Identity, pdcp-Config); SDAP entity per mbs-SessionId | TS 38.300 cl. 16.10.5.2; TS 38.331 cl. 5.3.5.6.7, 6.3.2 |
| 2. PTM and PTP legs | gNB, UE | MulticastRLC-BearerConfig (servedMBS-RadioBearer, isPTM-Entity); RLC-UM or RLC-AM for PTP, DL-only RLC-UM for PTM | TS 38.300 cl. 16.10.3; TS 38.331 cl. 6.3.2 |
| 3. G-RNTI, HARQ, DRX, CFR | gNB, UE | MBS-RNTI-SpecificConfig (G-RNTI or G-CS-RNTI, drx-ConfigPTM, harq-FeedbackEnablerMulticast, harq-FeedbackOptionMulticast); cfr-ConfigMulticast | TS 38.331 cl. 6.3.2; TS 38.213 cl. 18; TS 38.300 cl. 16.10.5.6, 16.10.5.7 |
| 4. PTM and PTP reception | gNB, UE | Group-common PDCCH and PDSCH with the G-RNTI (DCI formats 4_1, 4_2); UE-specific PDCCH and PDSCH with the C-RNTI | TS 38.300 cl. 16.10.5.4; TS 38.212 cl. 7.3.1.5.2, 7.3.1.5.3; TS 38.321 cl. 5.3.1 |
| A1. Activation | AF or MB-UPF, MB-SMF, SMF, AMF, NG-RAN, UE | N4mb report; Nmbsmf_MBSSession_ContextStatusNotify; Namf_MT_EnableGroupReachability; MULTICAST GROUP PAGING; Namf_MBSCommunication_N2MessageTransfer; MULTICAST SESSION ACTIVATION; N4mb Session Modification | TS 23.247 cl. 7.2.5.2; TS 29.518 cl. 5.4.2.4, 5.7.2.2; TS 38.413 cl. 8.5.2, 8.18.3; TS 29.244 cl. 5.34.2.3, 5.34.2.4; TS 38.300 cl. 16.10.5.2 |
| A2. Deactivation | AF or MB-UPF, MB-SMF, SMF, AMF, NG-RAN | N4mb Session Modification (stop forwarding, buffer); Nmbsmf_MBSSession_ContextStatusNotify; MULTICAST SESSION DEACTIVATION | TS 23.247 cl. 7.2.5.3; TS 29.244 cl. 5.34.2.4; TS 38.413 cl. 8.18.4 |
| A3. Update | AF, MB-SMF, AMF, NG-RAN | Nmbsmf_MBSSession Update; MULTICAST SESSION UPDATE, also with the MBS User Plane Failure Indication (Release 19) | TS 23.247 cl. 7.1.1.6, 7.2.6; TS 38.413 cl. 8.18.5; TS 38.300 cl. 16.10.5.1; TS 37.483 cl. 8.6.2.2 |
| U. User plane | AF or MBSTF, MB-UPF, NG-RAN, UPF, UE | N6mb or Nmb9; N3mb (shared) or N19mb then N3 (individual); MRB with PTM or PTP, or the PDU Session's radio bearers | TS 23.247 cl. 7.2.1.3, 6.7; TS 29.244 cl. 5.34.3 |
| L1. UE leave | UE, AMF, SMF, UPF, MB-SMF, NG-RAN | PDU Session Modification Request with leave indication; Nmbsmf_MBSSession_ContextStatusUnsubscribe when the last UE leaves | TS 23.247 cl. 7.2.2.2 |
| L2. Network leave, release | AF, MB-SMF, SMF, AMF, NG-RAN, UE | Nmbsmf_MBSSession_ContextStatusNotify (multicast session release); Namf_Communication_N1N2MessageTransfer; PDU Session Modification Command | TS 23.247 cl. 7.1.1.4, 7.2.2.3 |
| L3. Release of shared delivery | NG-RAN, AMF, MB-SMF, MB-UPF | DISTRIBUTION RELEASE REQUEST and RESPONSE; Nmbsmf_MBSSession_ContextUpdate with leave indication; N4mb; F1AP and E1AP release | TS 23.247 cl. 7.2.2.4; TS 38.413 cl. 8.18.2; TS 38.473 cl. 8.14.7, 8.14.11; TS 37.483 cl. 8.6.2.4 |
Network set-up
The common procedures for multicast and broadcast (TS 23.247 clause 7.1) are used with the MBS service type set to multicast. As for broadcast, the "NEF/MBSF" of the call flows stands for the NEF, the MBSF or both, depending on the deployment.
N1. Provisioning
The AF starts the MBS Session towards the 5G Core with TMGI allocation and MBS Session creation (TS 23.247 clause 7.1.1.2). With MBS User Services, the MBS Application Provider provisions an MBS User Service on the MBSF, and the MBSF provisions the MBS Distribution Sessions on the MBSTF and creates the MBS Session on the MB-SMF (TS 26.502 clauses 5.2 and 5.3). For an MBS Distribution Session of Service type multicast, at the start time the MBSF activates or reactivates the Multicast MBS Session in the MB-SMF, so that UEs can join it (TS 26.502 clause 5.5.1, step 1). Added in Release 19, for the Object Distribution Method the MBSF may configure Object Repair for the MBS Distribution Session in the MBS AS at MBS-9, and the MBSTF and the MBS AS then establish an Object Repair ingest session at MBS-12 (TS 26.502 clause 5.3, steps 9a to 10c).
N2. TMGI allocation
For multicast, TMGI allocation applies if a TMGI is used as MBS Session ID. It follows the same steps as for broadcast: Nnef_MBSTMGI_Allocate from the AF, then Nmbsmf_TMGI_Allocate from the NEF/MBSF to the MB-SMF (TS 23.247 clause 7.1.1.2, steps 1 to 6), an HTTP POST on /tmgi (TS 29.532 clause 5.2.2.2). If no TMGI was allocated beforehand, the AF may provide an SSM as MBS Session ID, or ask the network to allocate a TMGI (TS 23.247 clause 7.1.1.2, step 8).
N3. MBS Session creation at the MB-SMF
For multicast, the AF may also provide the Any UE indication, which says whether the session is open to any UE, the start and end times and the MBS session state, active or inactive (TS 23.247 clause 7.1.1.2, step 8). If the MBSF acts as the MBS security function for multicast, it provides a multicast session security context in Nmbsmf_MBSSession_Create (step 11). The MB-SMF derives the QoS parameters from the MBS Service Information (step 13). At the MB-SMF, the operation is the same HTTP POST on /mbs-sessions; for a multicast session, the request may carry the session activity status, the any-UE indication and the security context (TS 29.532 clause 5.3.2.2).
When a Multicast MBS session is created and its MBS Session ID is not yet in the MB-SMF profile, the MB-SMF updates its profile in the NRF with the MBS Session ID (TS 23.247 clause 7.1.2). After creation, depending on configuration, UEs can join the MBS Session (clause 7.1.1.2, step 22).
N4. MB-UPF configuration
The MB-SMF selects the MB-UPF and configures it on N4mb as for broadcast (TS 23.247 clause 7.1.1.2, steps 14 and 15; TS 29.244 clause 5.34.2.2). For multicast, the MB-SMF may defer the join of the multicast tree from the content provider, for example because the session is inactive, until the first query for the session during the establishment procedure, or until a request to activate it (TS 23.247 clause 7.1.1.2, step 14).
N5. Service announcement
The AF informs UEs of the MBS Session ID, for example the TMGI or the SSM, and possibly of the MBS service area and session description information (TS 23.247 clause 7.1.1.2, step 7). Before it joins, the UE knows at least the MBS Session ID of a multicast group it can join, for example from the service announcement (clause 7.2.1.3). With MBS User Services, the MBSF compiles and distributes the MBS User Service Announcement as specified in TS 26.502 clause 5.4.
Join and session establishment
The MBS Session Join procedure is how a UE informs the 5G Core of its interest in a multicast MBS session; the first accepted join request triggers the establishment of the multicast MBS session towards NG-RAN and the UE (TS 23.247 clause 7.2.1.1).
J1. The associated PDU Session
A PDU Session associated with multicast MBS sessions, the associated PDU Session, is established with the PDU Session Establishment procedure of TS 23.502, with differences (TS 23.247 clause 7.2.1.2). Its DNN and S-NSSAI are those used for the operations on multicast MBS sessions, join and leave. The AMF selects an SMF capable of handling multicast MBS sessions. If the SMF does not have the MBS subscription data of the UE, it retrieves it with Nudm_SDM_Get and subscribes to its changes with Nudm_SDM_Subscribe.
J2. Join request
To join, the UE sends a PDU Session Modification Request over the associated PDU Session, with one or several MBS Session IDs and a join request. Without a suitable PDU Session, it sends a PDU Session Establishment Request with the MBS Session IDs and the join request instead (TS 23.247 clause 7.2.1.3, step 1). UEs can join before the session start time if the service announcement provides it, so that joins at the start time are not rejected for their number (NOTE 1). From the MBS Session ID and the join request, the SMF determines that this is an MBS Session join request (step 2).
J3. MB-SMF discovery and session context
If the SMF has no information about the MBS Session Context, it discovers and selects the MB-SMF through the NRF (TS 23.247 clause 7.2.1.3, step 2): it queries the NRF with the MBS Session ID, and the NRF returns the MB-SMF currently serving the session (clause 7.1.2). If the SMF has not yet subscribed to the MBS Session Context, it invokes Nmbsmf_MBSSession_ContextStatusSubscribe. The MB-SMF answers with the multicast QoS flow information and, if available, the start time, the session state, the Any UE indication, the multicast DL tunnel information and the multicast session security context (clause 7.2.1.3, step 3).
The first such subscription tells the MB-SMF that the first UE is joining. With multicast transport between the MB-UPF and the content provider, if the MB-UPF has not joined the multicast tree at creation, the MB-SMF then asks it to join the multicast tree towards the AF/MBSF (step 3). At the MB-SMF, ContextStatusSubscribe is an HTTP POST on the subscriptions collection for MBS contexts, /mbs-sessions/contexts/subscriptions (TS 29.532 clause 5.3.2.9, table 6.2.3.1-1).
J4. Authorisation
The SMF considers the UE authorised if the UE is authorised to use multicast MBS services, and the MBS Session ID is in its MBS subscription data or the Any UE indication was received. Otherwise it rejects the join with a cause value (TS 23.247 clause 7.2.1.3, step 4). Before the start time, the SMF may accept the join and indicate the start time, or reject it with a cause and optionally a back-off timer. While the session is inactive, the SMF accepts the join.
Release 20 (TS 23.247 V20.0.0) adds roaming for multicast: a roaming UE may join a multicast session provided by the VPLMN through a local breakout PDU session, and the UE needs permission in its UDM subscription data to access MBS services of a VPLMN (clauses 6.22 and 6.4.2). For a session open only to selected UEs, the AF creating the session in the VPLMN provisions the authorisation through a NEF in the HPLMN of the roaming user and includes the VPLMN ID; the SMF in the VPLMN then authorises the join from the subscription data retrieved from the UDM in the HPLMN and from the VPLMN policies on inbound roaming UEs (clause 6.22). The same issue reads differently elsewhere. Clause 4.1: "For roaming users, reception of Multicast/Broadcast Services of the VPLMN is supported." and "For roaming users, reception of Multicast/Broadcast Services of the HPLMN is not supported in this Release." Clause 7.2.1.2, NOTE 2: "In this release, roaming is not supported, i.e. HPLMN and Serving PLMN are the same and subscribed SNPN and serving SNPN are same." The two statements are quoted as written and not reconciled here.
J5. N2 SM information towards NG-RAN
If it accepts the join, the SMF answers the AMF with Nsmf_PDUSession_UpdateSMContext (with Namf_Communication_N1N2MessageTransfer when the join came with a PDU Session Establishment Request). The N2 SM information creates an MBS Session Context in the RAN if none exists, and relates it to the UE's PDU Session context through the MBS Session ID and the mapping between multicast and associated QoS flows. The N1 SM container holds the PDU Session Modification Command (TS 23.247 clause 7.2.1.3, step 5). Based on operator policy, the SMF may prepare for fall-back to 5GC Individual delivery: it maps the multicast QoS flows to unicast QoS flows of the PDU Session, with unused QFIs and the same QoS (step 5).
The N2 message carries the MBS Session IDs the UE joined and, if applicable, the associated QoS flows (step 6). In NGAP, the MBS Session Setup or Modify Request List provides information on the MBS sessions joined by the UE: per session the MBS Session ID, the associated MBS QoS flows with their associated unicast QoS flow identifiers, and the MBS Assistance Information (TS 38.413 clause 9.3.1.212). It is an IE of the PDU Session Resource Modify Request Transfer (clause 9.3.4.3); at PDU Session establishment, the MBS Session Setup Request List of the PDU Session Resource Setup Request Transfer plays the same role (clauses 9.3.1.211 and 9.3.4.1).
If the NG-RAN node supports MBS, 5GC Shared MBS traffic delivery is adopted, and the node uses the MBS Session ID to associate the PDU Session with the multicast MBS session. If it does not, 5GC Individual delivery is used, if the PDU Session's unicast QoS flows include QoS flows for the multicast session (TS 23.247 clause 7.2.1.3, step 6).
J6. Shared delivery towards the NG-RAN node
If no shared tunnel exists yet for the session towards the NG-RAN node, the node establishes shared delivery (TS 23.247 clause 7.2.1.3, step 7). It does so when it serves at least one UE of the multicast session (clause 7.2.1.4, step 1), and regardless of the state of the session (NOTE 2).
- The NG-RAN node sends an N2 MBS Session request towards the AMF. With unicast transport, it allocates a GTP tunnel endpoint and provides the unicast DL tunnel information (TS 23.247 clause 7.2.1.4, step 2). In NGAP this is DISTRIBUTION SETUP REQUEST, non-UE-associated (TS 38.413 clause 8.18.1).
- The AMF selects the MB-SMF serving the session and invokes Nmbsmf_MBSSession_ContextUpdate with the N2 SM information and the NG-RAN Node ID (TS 23.247 clause 7.2.1.4, step 3). At the MB-SMF this is an HTTP POST on
/mbs-sessions/contexts/update, carrying the MBS Distribution Setup Request Transfer IE (TS 29.532 clause 5.3.2.5). - With unicast DL tunnel information, the MB-SMF configures the MB-UPF to send the session's data towards that GTP tunnel endpoint; where NG-RAN nodes share a common user plane entity, only if the shared tunnel is not yet established (TS 23.247 clause 7.2.1.4, step 4). In PFCP, this is the FAR with MBSU and Add MBS Unicast Parameters (TS 29.244 clause 5.34.2.2).
- The MB-SMF answers with the TMGI, the multicast QoS flow information, the session state and, without unicast tunnel information, the multicast DL tunnel information: a transport multicast address, for example an LL SSM, and a GTP tunnel endpoint (TS 23.247 clause 7.2.1.4, step 6).
- The AMF sends the N2 MBS Session response to the NG-RAN node, which joins the multicast transport distribution if it received the multicast DL tunnel information (step 7). In NGAP, if the request carried no Shared NG-U Unicast TNL Information, the MB-SMF interprets that IP multicast is used and includes the Shared NG-U Multicast TNL Information in the response (TS 38.413 clause 8.18.1.2).
J7. Inside the gNB: E1AP and F1AP
TS 38.401 gives an example of the interaction of NGAP, E1AP, F1AP and RRC when a UE joins an active multicast session as the first UE in its serving gNB (clause 8.15.1.2):
- The gNB-CU-CP establishes the multicast bearer context in the gNB-CU-UP; for unicast NG-U transport it retrieves the GTP DL TEID. In E1AP this is MC Bearer Context Setup (TS 37.483 clause 8.6.2.1).
- The gNB-CU-CP triggers the NGAP Distribution Setup procedure; the 5G Core provides the multicast address information, for multicast NG-U transport, and the multicast session QoS parameters (TS 38.401 V19.3.0 clause 8.15.1.2 step 4/5).
- The gNB-CU-CP sets up the MRB resources with E1AP MC Bearer Context Modification (TS 37.483 clause 8.6.2.2).
- The gNB-CU-CP establishes the Multicast Context in the gNB-DU, providing the MRB configuration. In F1AP this is Multicast Context Setup (TS 38.473 clause 8.14.6).
- The gNB-CU-CP retrieves the MRB configuration for the joined UE from the gNB-DU through the F1 UE Context Management procedures (TS 38.401 V19.3.0 clause 8.15.1.2 step 8/9).
- The gNB-DU triggers the establishment of F1-U resources, per gNB-DU, per cell or per MBS Area Session ID; in F1AP this is Multicast Distribution Setup (TS 38.473 clause 8.14.10). The gNB-CU-UP side of F1-U is established with E1AP MC Bearer Context Modification.
- With NG-U multicast transport, the gNB-CU-UP joins the NG-U multicast group (TS 38.401 V19.3.0 clause 8.15.1.2 step 14).
- The gNB terminates the NGAP procedure, and the gNB-CU-CP configures with RRC each UE that joined (TS 38.401 V19.3.0 clause 8.15.1.2 steps 15 and 16).
J8. Response, and 5GC Individual delivery
If the session is active, the NG-RAN node configures the radio resources for the session and configures the UE through AN specific signalling, which delivers the PDU Session Modification Command (TS 23.247 clause 7.2.1.3, steps 7a and 8). Its response to the SMF includes, if it supports MBS, an indication of MBS support, and whether it supports multicast reception in RRC_INACTIVE (step 9). In NGAP, the MBS Support Indicator takes the values "multicast supported" and "multicast supported with reception in RRC inactive" (TS 38.413 clause 9.3.1.210) and is an IE of the PDU Session Resource Modify Response Transfer (clause 9.3.4.4). From it, the SMF determines whether 5GC Individual MBS traffic delivery is used (TS 23.247 clause 7.2.1.3, step 10).
For 5GC Individual delivery, if no shared tunnel exists between the UPF (PSA) and the MB-UPF for the session, the SMF asks the UPF to create one. The UPF either allocates a DL N19mb tunnel endpoint, with unicast transport over N19mb, or joins the multicast distribution. With unicast transport, the SMF gives the tunnel to the MB-SMF in Nmbsmf_MBSSession_ContextUpdate, and the MB-SMF configures the MB-UPF towards the UPF. The SMF then configures the UPF to forward the data within the PDU Session (TS 23.247 clause 7.2.1.3, steps 11a to 11e). On N4, the SMF associates the PDU Session with the multicast MBS session through the MBS Session N4 Control Information IE and new downlink PDRs (TS 29.244 clause 5.34.3.2).
Radio configuration in RRC_CONNECTED
If a UE that joined a multicast session is in RRC_CONNECTED when the session is activated, the gNB may send an RRCReconfiguration message with the relevant MBS configuration (TS 38.300 clause 16.10.5.2). As long as a UE receives the multicast data in RRC_CONNECTED, the NG-RAN does not release its radio connection only because no unicast traffic is received for it (TS 23.247 clause 7.2.5.2, step 13).
Step 1: RRCReconfiguration with multicast MRBs
In the radio bearer configuration, mrb-ToAddModList lists the multicast MRBs to add or modify, and mrb-ToReleaseList those to release. Each MRB-ToAddMod-r17 holds mbs-SessionId-r17, the multicast MBS session the bearer is associated with, mrb-Identity-r17, and a pdcp-Config (TS 38.331 clause 6.3.2). For a multicast MRB that is not part of the UE configuration, the UE establishes a PDCP entity, associates the MRB with its mbs-SessionId, and establishes an SDAP entity for that mbs-SessionId if none exists (TS 38.331 clause 5.3.5.6.7). On release, it releases the PDCP entity and the mrb-Identity (clause 5.3.5.6.6).
Step 2: PTM and PTP legs
| UE state | Multicast MRB configurations (TS 38.300 clause 16.10.3) |
|---|---|
| RRC_CONNECTED, by dedicated RRC signalling | DL-only or bidirectional RLC-UM for PTP; RLC-AM for PTP; DL-only RLC-UM for PTM; two RLC-UM entities, one DL-only for PTP and one DL-only for PTM; three RLC-UM entities, one DL and one UL for PTP and one DL-only for PTM; RLC-AM for PTP with DL-only RLC-UM for PTM |
| RRC_INACTIVE, by broadcast and/or dedicated RRC signalling | DL-only RLC-UM for PTM |
The gNB may change the MRB type of a UE in RRC_CONNECTED with RRC signalling (TS 38.300 clause 16.10.3). In the cell group configuration, MulticastRLC-BearerConfig-r17 associates an RLC bearer with a multicast MRB through servedMBS-RadioBearer, and isPTM-Entity marks the RLC entity used for PTM reception; without it, the entity is used for PTP (TS 38.331 clause 6.3.2). To limit data loss at an MRB type change, the gNB may configure the UE to send a PDCP status report (TS 38.300 clause 16.10.5.3.4).
Step 3: G-RNTI, HARQ feedback, DRX and common frequency resource
| Item | What applies | Clause |
|---|---|---|
| G-RNTI and G-CS-RNTI | MBS-RNTI-SpecificConfig-r17, in g-RNTI-ConfigToAddModList of MAC-CellGroupConfig, sets a G-RNTI, which scrambles the scheduling and transmission of PTM for one or more multicast services, or a G-CS-RNTI for SPS group-common PDSCH. Up to 8 G-RNTIs can be configured, based on the UE capability | TS 38.331 cl. 6.3.2 |
| HARQ feedback | harq-FeedbackEnablerMulticast: feedback always (enabled) or as indicated by the DCI (dci-enabler). harq-FeedbackOptionMulticast: ack-nack is the first HARQ-ACK reporting mode, nack-only the second, in which the UE does not send a PUCCH carrying only ACKs | TS 38.331 cl. 6.3.2; TS 38.213 cl. 18; TS 38.300 cl. 16.10.5.7 |
| DRX | For PTM, multicast DRX per G-RNTI or G-CS-RNTI (drx-ConfigPTM), independent of UE-specific DRX. For PTP, UE-specific DRX; a PTM retransmission via PTP is monitored with the C-RNTI or CS-RNTI during the UE-specific DRX Active Time | TS 38.300 cl. 16.10.5.6; TS 38.331 cl. 6.3.2 |
| Repetition | pdsch-AggregationFactor: number of repetitions for dynamically scheduled multicast data; 1 when absent for a G-RNTI | TS 38.331 cl. 6.3.2 |
| Common frequency resource | cfr-ConfigMulticast: a UE-specific CFR for multicast in one dedicated BWP, within at most one serving cell. The CFR is an MBS frequency region of contiguous PRBs within the DL BWP and with its numerology | TS 38.331 cl. 6.3.2; TS 38.300 cl. 16.10.5.7; TS 38.213 cl. 18 |
Step 4: Receiving PTM and PTP
For PTP, the gNB schedules a UE-specific PDSCH with a UE-specific PDCCH whose CRC is scrambled by a UE-specific RNTI, such as the C-RNTI. For PTM, it schedules a group-common PDSCH with a group-common PDCCH scrambled by a group-common RNTI. When a UE has both legs, the gNB decides dynamically which to use, based on information such as the session QoS requirements, the number of joined UEs and the UE feedback on reception quality (TS 38.300 clause 16.10.5.4). DCI formats 4_1 and 4_2 are used for the scheduling of PDSCH for multicast (TS 38.212 clauses 7.3.1.5.2 and 7.3.1.5.3). The MAC entity acts on downlink assignments received for its C-RNTI or for a G-RNTI configured for multicast MTCH (TS 38.321 clause 5.3.1). The UE receives multicast data from the PCell or from a single SCell at a time (TS 38.300 clause 16.10.5.5).
RRC states
A UE that joined an MBS multicast session receives its data in RRC_CONNECTED or, from Release 18, in RRC_INACTIVE, never in RRC_IDLE. TS 38.300 V19.4.0 clause 16.10.5.2: "A UE can be configured to receive data of MBS multicast session only in RRC_CONNECTED state or RRC_INACTIVE state." When the session is deactivated, "the gNB may move the UE in RRC_CONNECTED state to RRC_IDLE or RRC_INACTIVE state", and group notification by paging "is utilized to page all UEs in RRC_IDLE and RRC_INACTIVE states that joined the associated MBS multicast session" (same clause). A UE in RRC_IDLE therefore only listens for that paging, and moves to RRC_CONNECTED to receive.
Reception in RRC_INACTIVE was introduced in Release 18. In TS 23.247 it was added by CR 0149 (support of MBS multicast reception by UEs in RRC_INACTIVE state) and CR 0159 (support for RRC_INACTIVE UEs receiving multicast MBS data), both at V18.1.0 (March 2023); clause 6.17 is present in V18.8.0 and absent from the V17.12.0 issue. In TR 21.918 it belongs to the work item Enhancements of NR MBS, NR_MBS_enh (clause 12.2). Group paging that tells UEs in RRC_INACTIVE they may receive the session data in that state came with CR 0280 at V18.3.0 (clause 6.17; clause 7.2.5.2, step 12 and NOTE 2).
Reception in RRC_INACTIVE
In MBS Multicast in RRC_INACTIVE, a UE that joined a multicast session keeps receiving it after the gNB releases it from RRC_CONNECTED; this section gives only what differs from reception in RRC_CONNECTED. To provide a multicast service to more UEs in a cell, NG-RAN may move UEs that can receive multicast in RRC_INACTIVE out of RRC_CONNECTED. PTP transmission, SPS and HARQ feedback are not supported for multicast reception in RRC_INACTIVE, so the UE receives by PTM only. In the 5G Core it uses the multicast procedures: NG-RAN may decide to enable reception in RRC_INACTIVE during the join or the activation procedure, or later (TS 23.247 clauses 7.2.1.3 and 7.2.5.2).
- 0. Join the multicast session and be configured for RRC_INACTIVE (in RRC_CONNECTED): 0a. join, 0b. the gNB decision, 0c (TS 23.247 V20.0.0 clause 6.17, 7.2.1.3; TS 38.300 V19.4.0 clause 16.10.5.2; TS 38.331 V19.4.0 clause 5.3.8.3, 6.2.2). RRCRelease
- 1. Obtain the MIB (TS 38.331 V19.4.0 clause 5.2.2.4.1)
- 2. Obtain SIB1, which schedules SIB24 (TS 38.331 V19.4.0 clause 6.3.2)
- 3. SIB24 configures the multicast MCCH (TS 38.331 V19.4.0 clause 5.10.1.1, 6.3.1)
- 4. Receive the multicast MCCH, scheduled with Multicast MCCH-RNTI (TS 38.331 V19.4.0 clause 5.10.1.2; TS 38.321 V19.4.0 clause 7.1)
- 5. The multicast MCCH carries MBSMulticastConfiguration (TS 38.331 V19.4.0 clause 5.10.1.1, 6.2.2)
- 6. The session list gives each session's G-RNTI and MTCH configuration (TS 38.331 V19.4.0 clause 6.3.6)
- 7. Receive the MTCH, scheduled with the G-RNTI (TS 38.331 V19.4.0 clause 5.10.3.2; TS 38.321 V19.4.0 clause 5.3.1; TS 38.212 V19.4.0 clause 7.3.1.5.2)
- A (TS 23.247 V20.0.0 clause 6.17, 7.2.5.2; TS 38.300 V19.4.0 clause 16.10.5.2). Activation and data notification by group paging
- R (TS 38.300 V19.4.0 clause 16.10.5.2, 16.10.5.3.5; TS 23.247 V20.0.0 clause 7.2.3.7). Resuming the RRC connection
Reception in RRC_INACTIVE, step by step (Step, Function(s), Interface and message or service, Clause)
| Step | Function(s) | Interface and message or service | Clause |
|---|---|---|---|
| 0a. Join in RRC_CONNECTED | UE, SMF, AMF, NG-RAN | As for MBS Multicast; the N2 SM information of the response carries the MBS Support Indicator "multicast supported with reception in RRC inactive"; the SMF may send the MBS assistance information | TS 23.247 cl. 6.17, 7.2.1.3; TS 38.413 cl. 9.3.1.210 |
| 0b. Decision | NG-RAN | Session QoS parameters (ARP, 5QI) and MBS assistance information; decision left to NG-RAN | TS 23.247 cl. 6.17, 7.2.1.3; TS 38.300 cl. 16.10.5.1, 16.10.5.2 |
| 0c. Release to RRC_INACTIVE | gNB, UE | RRC: RRCRelease with suspendConfig holding multicastConfigInactive-r18 (inactivePTM-Config-r18, inactiveMCCH-Config-r18), possibly with the PTM configuration | TS 38.300 cl. 16.10.5.2; TS 38.331 cl. 5.3.8.3, 6.2.2; TS 23.247 cl. 7.2.1.3 |
| 1, 2. MIB and SIB1 | gNB, UE | RRC: as for broadcast, with sibType24-v1800 in the SIB mapping | TS 38.331 cl. 5.2.2, 6.3.2 |
| 3. SIB24 | gNB, UE | RRC: multicast MCCH scheduling (multicastMCCH-Config-r18) and common frequency resource (cfr-ConfigMCCH-MTCH-r18) | TS 38.331 cl. 5.10.1, 6.3.1 |
| 4. Multicast MCCH | gNB, UE | MAC, physical layer: PDCCH addressed to Multicast MCCH-RNTI, DCI format 4_0, PDSCH from pdsch-ConfigMCCH for MBS multicast, LCID 0 | TS 38.331 cl. 5.10.1.2, 5.10.2; TS 38.321 cl. 5.3.1, tables 6.2.1-1c and 7.1-1; TS 38.213 cl. 10.1; TS 38.214 cl. 5.1 |
| 5. MBSMulticastConfiguration | gNB, UE | RRC: sessions, neighbour cells, DRX and PDSCH configurations, thresholds | TS 38.331 cl. 6.2.1, 6.2.2 |
| 6. Session list | gNB, UE | RRC: per session, TMGI, G-RNTI, multicast MRBs, MTCH scheduling, threshold index | TS 38.331 cl. 6.3.6 |
| 7. MTCH | gNB, UE | RRC, MAC, physical layer: multicast MRB establishment; G-RNTI for multicast MTCH, DCI format 4_1, LCID from table 6.2.1-1 | TS 38.331 cl. 5.10.3.2; TS 38.321 cl. 5.3.1, table 6.2.1-1; TS 38.212 cl. 7.3.1.5.2; TS 38.213 cl. 10.1 |
| User plane | gNB, UE | SDAP, PDCP, RLC: one DL-only RLC-UM entity for PTM; PDCP state variables from initialRX-DELIV when provided | TS 38.300 cl. 16.10.3; TS 38.323 cl. 7.1; TS 37.324 cl. 4.2 |
| A. Activation | NG-RAN, UE | Group notification (paging with pagingGroupList) that indicates that reception in RRC_INACTIVE is allowed (inactiveReceptionAllowed) | TS 23.247 cl. 6.17, 7.2.5.2; TS 38.300 cl. 16.10.5.2; TS 38.331 cl. 5.3.2.3, 6.2.2 |
| R. Resume | UE, gNB | RRC connection resume: below the RSRP or RSRQ threshold, on a group notification without that indication, without PTM configuration in a new cell, or out of the RNA | TS 38.300 cl. 16.10.5.2, 16.10.5.3.5; TS 23.247 cl. 7.2.3.7, 7.2.3.8 |
Step 0: Join, then release to RRC_INACTIVE
0a. Join. The UE joins the multicast session in RRC_CONNECTED, with the procedure of TS 23.247 clause 7.2.1.3. When a UE joins, and during Xn handover, the NG-RAN node indicates in the N2 SM information that it supports multicast reception in RRC_INACTIVE (TS 23.247 clause 6.17). In NGAP, the MBS Support Indicator then takes the value "multicast supported with reception in RRC inactive" (TS 38.413 clause 9.3.1.210). If the UE's MBS subscription data holds MBS assistance information that names the session, the SMF includes it in the N2 SM information (TS 23.247 clause 7.2.1.3, step 5).
0b. Decision. NG-RAN may use two kinds of information from the 5G Core to decide: the MBS session QoS parameters, such as the most demanding ARP and 5QI of the MBS QoS flows, which the MB-SMF provides during user plane establishment for shared delivery; and the optional MBS assistance information for the session (TS 23.247 clause 6.17). TS 23.247 describes the MBS assistance information as an indication that the UE is preferred to be kept in RRC_CONNECTED while the session it joined is active; the AF provisions it through the NEF in the UDM, as part of the MBS subscription data (clause 6.17). TS 38.300 describes the same information as indicating that the UE is expected to require dedicated resources very frequently (clause 16.10.5.1). How NG-RAN decides is left to its implementation (TS 23.247 clause 6.17, NOTE 1). Whether and when it applies delivery that enables reception in RRC_INACTIVE, at the join or later, is decided by NG-RAN (clause 7.2.1.3, step 16 and NOTE 9). When there is temporarily no data for an active multicast session, the gNB may move the UE to RRC_INACTIVE (TS 38.300 clause 16.10.5.2).
0c. RRCRelease. The suspendConfig of RRCRelease carries multicastConfigInactive-r18, whose presence configures the UE to receive multicast in RRC_INACTIVE. Its inactivePTM-Config-r18 holds an MBSMulticastConfiguration naming the sessions that can be received in RRC_INACTIVE, and optionally their PTM configuration for the cell where they were configured in RRC_CONNECTED; when it is absent, the UE considers that all joined sessions can be received in RRC_INACTIVE. Its inactiveMCCH-Config-r18 gives the multicast MCCH and MTCH configuration of that cell, as a SIB24 (TS 38.331 clause 6.2.2). The UE enters RRC_INACTIVE. If a PTM configuration is provided for at least one session whose G-RNTI it is not told to stop monitoring, and it selects the same cell, it applies that configuration and, if the multicast MCCH is present, monitors the Multicast MCCH-RNTI (TS 38.331 clause 5.3.8.3). The UE may also receive in RRCRelease dedicated frequency priorities, which it applies at cell reselection while it receives multicast in RRC_INACTIVE (TS 38.300 clause 16.10.5.3.5).
Steps 1 to 3: SIB24
SIB1 schedules SIB24 in the same way as SIB20, through a SIB-TypeInfo-v1700 entry whose value is sibType24-v1800. SIB24 contains the information required to acquire the multicast MCCH/MTCH configuration for MBS multicast reception in RRC_INACTIVE. Its fields are multicastMCCH-Config-r18, of the type MCCH-Config-r17 used for broadcast, and cfr-ConfigMCCH-MTCH-r18, of the type CFR-ConfigMCCH-MTCH-r17 (TS 38.331 V19.4.0 clause 6.2.2, 6.3.1, 6.3.2).
Step 4: Receiving the multicast MCCH
The multicast MCCH is transmitted periodically within a configured transmission window. Its transmissions are indicated by a PDCCH addressed to the Multicast MCCH-RNTI. If searchSpaceMulticastMCCH is zero, the monitoring occasions are those of SIB1 (TS 38.331 V19.4.0 clause 5.10.1.2).
| Layer | What applies | Clause |
|---|---|---|
| MAC | The MAC entity reads the MCCH on a downlink assignment for the MCCH-RNTI or the Multicast MCCH-RNTI. Multicast MCCH-RNTI is FFFB, distinct from the broadcast MCCH-RNTI (FFFD) | TS 38.321 cl. 5.3.1, table 7.1-1 |
| MAC | LCID 0 is shared: "Broadcast MCCH or multicast MCCH" | TS 38.321 table 6.2.1-1c |
| Physical layer | DCI format 4_0 with CRC scrambled by the Multicast MCCH-RNTI (searchSpaceMulticastMCCH) | TS 38.212 cl. 7.3.1.5.1; TS 38.213 cl. 10.1 |
| Physical layer | PDSCH parameters from pdsch-ConfigMCCH for MBS multicast | TS 38.214 cl. 5.1 |
The UE acquires the multicast MCCH on a change notification, on selecting a new cell (different from the one configured in RRC_CONNECTED) or reselecting a cell that provides SIB24, after group paging, or when RRCRelease lacks the PTM configuration of a session it still monitors (TS 38.331 V19.4.0 clause 5.10.1.3, 5.10.2.2, 5.10.2.3).
Steps 5 and 6: MBSMulticastConfiguration and the session list
The MulticastMCCH-Message class is the set of RRC messages sent on the multicast MCCH (TS 38.331 clause 6.2.1). Its message, MBSMulticastConfiguration, contains the control information for multicast services transmitted via multicast MRBs to UEs in RRC_INACTIVE (clause 6.2.2). Its fields are mbs-SessionInfoListMulticast-r18, mbs-NeighbourCellList-r18, drx-ConfigPTM-List-r18, pdsch-ConfigMTCH-r18, mtch-SSB-MappingWindowList-r18 and thresholdMBS-List-r18, the list of reception quality thresholds for RRC connection resume.
MBS-SessionInfoListMulticast gives the multicast sessions and, for each, its G-RNTI and scheduling information (clause 6.3.6). Compared with the broadcast entry, MBS-SessionInfoMulticast-r18 adds thresholdIndex-r18, pdcp-SyncIndicator-r18 and stopMonitoringRNTI-r18. In MRB-RLC-ConfigMulticast-r18, the logical channel identity is a choice of logicalChannelIdentitymulticast-r18 and logicalChannelIdentityExt-r18 (TS 38.331 V19.4.0 clause 6.3.6).
When there is temporarily no data for an active multicast session, or when it is deactivated, the network tells the UE to stop monitoring the G-RNTI through MBSMulticastConfiguration (TS 38.331 V19.4.0 clause 5.10.1.1).
Step 7: Receiving the MTCH
On establishing a multicast MRB (TS 38.331 clause 5.10.3.2), the UE establishes a PDCP and an RLC entity from mrb-ListMulticast, configures MAC with mtch-SchedulingInfo and the physical layer with mbs-SessionInfoListMulticast, searchSpaceMulticastMTCH and pdsch-ConfigMTCH, establishes an SDAP entity if needed, and receives DL-SCH with the G-RNTI unless told to stop monitoring it. Release (clause 5.10.3.3) mirrors the broadcast case.
| Layer | What applies | Clause |
|---|---|---|
| MAC | Downlink assignment reception names the G-RNTI configured for multicast MTCH | TS 38.321 cl. 5.3.1 |
| MAC | The multicast MTCH logical channel uses LCID 1 to 32 of table 6.2.1-1, "DCCH, DTCH and multicast MTCH"; table 6.2.1-1c covers only broadcast MTCH | TS 38.321 tables 6.2.1-1 and 6.2.1-1c |
| Physical layer | DCI format 4_1 with CRC scrambled by the G-RNTI, for PDCCH receptions in RRC_INACTIVE (searchSpaceMulticastMTCH). DCI format 4_1 is used to schedule PDSCH for multicast | TS 38.212 cl. 7.3.1.5.2; TS 38.213 cl. 10.1 |
TS 38.300 also states for RRC_INACTIVE: PTP transmission, SPS and HARQ feedback are not supported; slot-level repetition of the multicast MTCH is optional; the maximum is one MIMO layer; multicast DRX is configured per G-RNTI.
Activation and resume
A. Activation and data notification. When the 5G Core activates the session, it activates it in the NG-RAN nodes serving joined UEs. When NG-RAN pages the group to activate the session and decides to enable reception in RRC_INACTIVE, it also indicates that the session data may be received in RRC_INACTIVE; the joined UEs in RRC_INACTIVE in those cells may then stay in RRC_INACTIVE and receive it (TS 23.247 clause 6.17). gNBs that support MBS also use group notification to notify UEs in RRC_INACTIVE when a session is already active and the gNB has data to deliver (TS 38.300 clause 16.10.5.2). In the Paging message, inactiveReceptionAllowed indicates whether a UE with a valid PTM configuration for a TMGI of the PagingGroupList stays in RRC_INACTIVE to receive the session (TS 38.331 clause 6.2.2). If the UE has been told to stop monitoring the G-RNTI of all its joined sessions in a cell, it does not monitor the Multicast MCCH-RNTI until a group notification arrives (TS 38.300 clause 16.10.5.2).
R. Resume. Upon a group notification that does not indicate multicast reception in RRC_INACTIVE, the UE resumes the connection and moves to RRC_CONNECTED. If it is notified both by group notification and by UE-specific paging, it follows the UE-specific paging and goes to RRC_CONNECTED (TS 38.300 clause 16.10.5.2). The UE also resumes when the serving cell falls below the configured threshold, and, during an active session, when the new cell provides no PTM configuration or multicast MCCH (TS 38.300 clause 16.10.5.3.5; see below). If it moves out of the RAN Notification Area within the Registration Area, it resumes the connection as in TS 23.247 clause 7.2.3.7; out of the Registration Area, it performs a Mobility Registration Update (TS 23.247 clauses 7.2.3.8.3 and 7.2.3.8.4).
Moving between cells in RRC_INACTIVE
- A UE in RRC_INACTIVE continues receiving without resuming the RRC connection if it can acquire the PTM configuration of the new cell from its multicast MCCH. Otherwise, during an active session, it resumes the connection (TS 38.300 V19.4.0 clause 16.10.5.3.5).
- The gNB may indicate that the cells of the RAN Notification Area (RNA) are synchronised in PDCP COUNT for a session. On reselecting such a cell, the UE does not initialise the PDCP state variables. In TS 38.323, the initial value of RX_DELIV of a multicast MRB is set by
initialRX-DELIVif provided. - The UE resets MAC on cell selection or reselection. On a transition from RRC_CONNECTED to RRC_INACTIVE in the same cell, it can keep the multicast MRBs it used, with the same LCIDs (TS 38.331 V19.4.0 clause 5.10.3.1).
- The UE resumes the RRC connection when the latest measured RSRP or RSRQ of the serving cell falls below the threshold configured by the network, per session, in RRCRelease or on the multicast MCCH (TS 38.300 V19.4.0 clause 16.10.5.3.5).
Activation and deactivation
Activation and deactivation apply to multicast only. The MB-SMF triggers activation when the MB-UPF notifies it of downlink data, or on a request from the AF, directly or through the NEF; the session then moves from Inactive to Active. It triggers deactivation when the MB-UPF notifies it that there has been no downlink data for some duration, or on a request from the AF; the session moves from Active to Inactive (TS 23.247 clause 7.2.5.1).
A1. Activation, with group paging
- The MB-UPF, as instructed by the MB-SMF at deactivation, sends an N4mb notification when downlink data arrives, or the AF sends an activation request (TS 23.247 clause 7.2.5.2, step 1). In PFCP, the MB-UPF reports downlink data with a PFCP Session Report Request carrying a Downlink Data Report IE (TS 29.244 clause 5.34.2.3).
- The MB-SMF sends Nmbsmf_MBSSession_ContextStatusNotify with the state Active to the SMFs. Each SMF finds the UEs that joined the session (TS 23.247 clause 7.2.5.2, step 2).
- The SMF invokes Namf_MT_EnableGroupReachability towards the AMFs with the list of UEs (step 3). The AMF answers with the UEs in CM-CONNECTED (TS 29.518 clause 5.4.2.4), for which the SMF sends the N2 SM information if the QoS profiles of the associated PDU Session have not yet been provided (TS 23.247 clause 7.2.5.2, step 4b).
- For UEs in CM-IDLE, the AMF sends a Multicast Group paging request with the UE list and the TMGI to the NG-RAN nodes of the paging area that support MBS, or per-UE paging to nodes that do not (step 5). In NGAP this is MULTICAST GROUP PAGING (TS 38.413 clause 8.5.2), and in F1AP the gNB-CU passes it to the gNB-DU in a MULTICAST GROUP PAGING message (TS 38.473 clause 8.14.5). Paged UEs send a Service Request (TS 23.247 clause 7.2.5.2, step 6).
- If the MB-SMF finds shared tunnels, it invokes Namf_MBSCommunication_N2MessageTransfer with an activation for the NG-RAN nodes that have one, in parallel with step 2 (TS 23.247 clause 7.2.5.2, step 11; TS 29.518 clause 5.7.2.2). The AMF sends the NGAP activation request, MULTICAST SESSION ACTIVATION REQUEST (TS 38.413 clause 8.18.3). The NG-RAN nodes perform RAN paging for joined UEs in RRC_INACTIVE (TS 23.247 clause 7.2.5.2, step 12), and establish the radio resources (step 13).
- The MB-SMF asks the MB-UPF, with N4mb Session Modification, to forward the MBS packets (step 15). In PFCP, it sets the FAR Apply Action back to FSSM and/or MBSU (TS 29.244 clause 5.34.2.4).
In NG-RAN, the group notification is addressed with the P-RNTI on the PDCCH. Its paging message contains the MBS session ID and pages all UEs in RRC_IDLE and RRC_INACTIVE that joined the session, without paging them individually (TS 38.300 clause 16.10.5.2). In RRC_IDLE, the UE forwards each TMGI of pagingGroupList that matches a session it joined to the upper layers (TS 38.331 clause 5.3.2.3). Unless the notification indicates that reception in RRC_INACTIVE is allowed, the UEs reconnect or resume and move to RRC_CONNECTED (TS 38.300 clause 16.10.5.2).
For UEs that use power saving functions, such as MICO mode with Active Time or extended DRX, Release 18 added coordinated reception (TS 23.247 clauses 6.16 and 7.2.10; absent from V17.12.0). The UE learns the start time and scheduled activation times from the service announcement, wakes up at those times, and joins in RRC_CONNECTED before receiving; when the AMF performs group paging at activation, it also includes the CM-IDLE UEs that use power saving functions (clause 7.2.10).
A2. Deactivation
- The MB-UPF notifies the MB-SMF that no data is received for the session, or the AF sends a deactivation request (TS 23.247 clause 7.2.5.3, step 1).
- The MB-SMF sends an N4mb Session Modification Request to the MB-UPF, with Buffered Downlink Traffic detection when activation is to follow incoming data (step 2). In PFCP, the FAR Apply Action changes from FSSM and/or MBSU to BUFF and NOCP, or to DROP or BUFF when the AF requested the deactivation (TS 29.244 clause 5.34.2.4).
- The MB-SMF notifies the SMFs, which set the session to Inactive and, for UEs with 5GC Individual delivery, remove the associated QoS flows (TS 23.247 clause 7.2.5.3, steps 3 and 4a).
- For the NG-RAN nodes with a shared tunnel over N3mb, the MB-SMF sends Namf_MBSCommunication_N2MessageTransfer with a deactivation, and the AMF sends the NGAP deactivation request (steps 5 and 6), MULTICAST SESSION DEACTIVATION REQUEST (TS 38.413 clause 8.18.4).
- The NG-RAN node keeps the multicast MBS Session Context and the N3mb shared tunnel (TS 23.247 clause 7.2.5.3, step 7).
There is no explicit deactivation indication to the UE (TS 23.247 clause 7.2.5.3, NOTE 3). When a multicast session is deactivated, the gNB may move a UE in RRC_CONNECTED to RRC_IDLE or RRC_INACTIVE (TS 38.300 clause 16.10.5.2). In a split gNB, the gNB-CU-CP can ask the gNB-CU-UP to suspend the downlink transmission and buffer arriving data; the gNB-CU-UP then reports downlink data arrival with MC Bearer Notification (TS 37.483 clauses 8.6.2.1 and 8.6.2.6).
A3. Session update
The AF updates the MBS service area or the MBS Service Information with MBS Session Update, and can also activate or deactivate the session with it (TS 23.247 clause 7.1.1.6, step 1). For multicast, the MB-SMF continues towards the AMF and NG-RAN with clause 7.2.5 for activation and deactivation, and clause 7.2.6 for QoS and service area updates (clause 7.1.1.6, step 7). In NGAP, the AMF sends MULTICAST SESSION UPDATE REQUEST, with which the NG-RAN node updates the MBS QoS profile and/or the MBS Service Area (TS 38.413 clause 8.18.5).
Added in Release 19, if the 5G Core detects a shared NG-U path failure, it may notify the gNB, and the gNB may allocate new shared NG-U resources to replace the old ones, as specified in TS 23.527 (TS 38.300 clause 16.10.5.1). In NGAP, the notification is a MULTICAST SESSION UPDATE REQUEST whose MBS User Plane Failure Indication is set to "NG-U path failure detected": the NG-RAN node may then provide new NG-U transport information with the Distribution Setup procedure, or release the failed one with the Distribution Release procedure (TS 38.413 clause 8.18.5.2). Inside the gNB, E1AP MC Bearer Context Modification can carry an MC Bearer Context NG-U TNL Info at NG-RAN Replace Request, for which the gNB-CU-UP considers the shared NG-U resources of the session released and allocates new ones (TS 37.483 clause 8.6.2.2.2).
User plane
The MB-UPF receives the multicast PDUs either directly from the content provider or through the MBSTF (TS 23.247 clause 7.2.1.3, step 13). When the MBSF is involved, the tunnel between the MBSTF and the MB-UPF is established at MBS Session creation (NOTE 11).
| 5GC Shared delivery | 5GC Individual delivery | |
|---|---|---|
| From the MB-UPF | In the N3mb tunnel of the session to the NG-RAN node; one tunnel per multicast session, MBS service area and NG-RAN node, shared by all UEs that joined through that node (step 14) | In the N19mb tunnel of the session to the UPF; one tunnel per multicast session and UPF, shared by all its associated PDU Sessions (step 17) (TS 23.247 V20.0.0 clause 7.2.1.3 steps 14 and 17) |
| Then | The UPF forwards the data in the N3 tunnel of each associated PDU Session (step 18) (TS 23.247 V20.0.0 clause 7.2.1.3 step 18) | |
| Over the radio | The MBS Radio Bearer, with PTP or PTM (step 16) | The radio bearers of the associated QoS flows of the PDU Session (step 19) (TS 23.247 V20.0.0 clause 7.2.1.3 steps 16 and 19) |
The UPF allocates only one N19mb downlink tunnel per multicast session, with unicast transport over N19mb, or joins the multicast group, with multicast transport. The SMF may instruct the UPF to change the QFI of the downlink packets of a multicast QoS flow to the QFI of the associated unicast QoS flow (TS 29.244 clauses 5.34.3.1 and 5.34.3.2). In the UE, SDAP maps MBS QoS flows to MRBs without an SDAP header, and the PDCP entity of an MRB can use header compression (TS 37.324 clause 4.2.2; TS 38.323 clause 4.2.2).
Leave and release
L1. Leave requested by the UE
The UE sends a PDU Session Modification Request with a leave indication and the MBS Session ID (TS 23.247 clause 7.2.2.2, step 1). With 5GC Individual delivery, the SMF reconfigures the UPF to stop distributing the data in the PDU Session, and the UPF releases the N19mb tunnel or leaves the multicast tree when no PDU Session needs it (steps 3a and 3b). With 5GC Shared delivery, the SMF tells NG-RAN to remove the UE from the session (step 7), and the NG-RAN node removes it (step 10).
If the UE was the last joined UE served by the SMF, the SMF unsubscribes from the MBS Session Context with Nmbsmf_MBSSession_ContextStatusUnsubscribe. With multicast transport between the MB-UPF and the content provider, when the last SMF subscribed to the session unsubscribes, which is when the last UE leaves the session, the MB-SMF asks the MB-UPF to stop forwarding and may ask it to leave the multicast tree if the MB-UPF joined it when the first UE joined (TS 23.247 clause 7.2.2.2, step 12). If the UE was the last one of the session in the NG-RAN node, the node releases shared delivery (step 13). In the radio configuration, the multicast MRBs are released through mrb-ToReleaseList, and the UE releases the SDAP entities of multicast sessions left without a multicast MRB (TS 38.331 clause 5.3.5.6.1). Release of the associated PDU Session implicitly leaves its multicast sessions (TS 23.247 clause 7.2.2.2, NOTE).
L2. Leave requested by the network, and session release
When the AF deletes the session, the MB-SMF triggers the release towards the SMFs (TS 23.247 clause 7.1.1.4, step 5). It notifies each SMF with Nmbsmf_MBSSession_ContextStatusNotify (multicast session release), and the SMF removes all joined UEs from the session (clause 7.2.2.3, step 1a). The SMF can also remove one UE, for example on a subscription change from the UDM (clause 7.2.2.3). For UEs with an activated user plane, the SMF uses Namf_Communication_N1N2MessageTransfer: the N1 SM container tells the UE it was removed and why, and the N2 SM information tells NG-RAN to remove the UE (step 3). For an active session, the MB-SMF may first deactivate the session in NG-RAN to release the radio resources early (clause 7.2.2.3).
L3. Release of shared delivery
The NG-RAN node may release shared delivery when the last UE leaves the context of the session, at handover of the last UE, or at MBS session deletion. While the session is inactive, shared delivery is not released if at least one UE of the session is in RRC_CONNECTED (TS 23.247 clause 7.2.2.4).
- The NG-RAN node sends an N2 MBS Session release request to the AMF, with the unicast DL tunnel information if unicast transport is used (TS 23.247 clause 7.2.2.4, step 2). In NGAP this is DISTRIBUTION RELEASE REQUEST (TS 38.413 clause 8.18.2).
- The AMF invokes Nmbsmf_MBSSession_ContextUpdate, with a leave indication if this is the last NG-RAN node it controls for the session (TS 23.247 clause 7.2.2.4, step 3).
- With unicast transport, if no other NG-RAN node uses the DL GTP tunnel, the MB-SMF releases the N3mb tunnel in the MB-UPF with N4mb Session Modification (step 4) (TS 23.247 V20.0.0 clause 7.2.2.4 step 4).
- The AMF answers the NG-RAN node, which deletes the GTP tunnel information or leaves the multicast distribution tree, and releases its local resources (step 7) (TS 23.247 V20.0.0 clause 7.2.2.4 step 7).
In the gNB, F1AP Multicast Distribution Release lets the gNB-DU release the F1-U tunnels, Multicast Context Release lets the gNB-CU release the multicast context in the gNB-DU (TS 38.473 clauses 8.14.11 and 8.14.7), and E1AP MC Bearer Context Release releases the resources in the gNB-CU-UP (TS 37.483 clause 8.6.2.4).
Mobility
A UE may move from one NG-RAN node to another after it has joined a multicast session. TS 23.247 supports multicast mobility between NG-RAN nodes that both support MBS, and between a node that supports MBS and one that does not, in either direction; in both cases minimisation of data loss should be supported (TS 23.247 clauses 6.3.1 and 7.2.3.1). During an active session, mobility between a node that supports MBS and one that does not requires the mobility procedure to provide the appropriate MBS traffic delivery method at the target node. The procedures add to the Xn and N2 handover procedures of TS 23.502 (clauses 7.2.3.2 and 7.2.3.3). In NG-RAN, mobility builds on the existing functions of TS 38.300 clause 9.2, and lets the UE continue receiving its multicast services via PTM or PTP in the new cell after handover (TS 38.300 clauses 16.10.5.3.1 and 16.10.5.3.2).
- H (TS 23.247 V20.0.0 clause 7.2.3.2, 7.2.3.3; TS 38.300 V19.4.0 clause 16.10.5.3.2). Handover between nodes that support MBS: Xn (X1 to X7) or N2 (N1 to N4)
- T (TS 23.247 V20.0.0 clause 6.3.1, 7.2.3.2, 7.2.3.3; TS 38.300 V19.4.0 clause 16.10.5.3.3). Handover to a node that does not support MBS (T1 to T3)
- F (TS 23.247 V20.0.0 clause 7.2.3.4; TS 38.300 V19.4.0 clause 16.10.5.3.3). Handover from a node that does not support MBS (F1 to F3)
- I (TS 23.247 V20.0.0 clause 7.2.3.6). Handover of an inactive session
- R (TS 23.247 V20.0.0 clause 7.2.3.8.1, 7.2.3.8.2, 7.2.3.8.3, 7.2.3.8.4, 7.2.3.7). UEs in RRC_INACTIVE: within the RNA, out of the RNA, out of the Registration Area, and resume in another node
Mobility, step by step (Step, Function(s), Interface and message or service, Clause)
| Step | Function(s) | Interface and message or service | Clause |
|---|---|---|---|
| X1. Before handover | SMF, source NG-RAN | At the join, the mapping of the multicast QoS flows to unicast QoS flows of the associated PDU Session is given to NG-RAN | TS 23.247 cl. 6.3.1, 7.2.3.2 |
| X2. Handover preparation | Source and target gNB | Xn: the multicast sessions the UE joined, in the UE context information; service area per Area Session ID; data forwarding proposal and MRB PDCP sequence numbers | TS 38.300 cl. 16.10.5.3.2; TS 23.247 cl. 7.2.3.2 |
| X3. Shared delivery at the target | Target gNB, AMF, MB-SMF, MB-UPF | NGAP Distribution Setup, for each session with ongoing data and no MBS Session Resources at the target | TS 38.300 cl. 16.10.5.3.2; TS 38.413 cl. 8.18.1; TS 23.247 cl. 7.2.1.4 |
| X4. Handover execution | Source gNB, target gNB, UE | RRC container with the MBS configuration decided by the target; PDCP entities of multicast MRBs re-established or kept | TS 38.300 cl. 16.10.5.3.2 |
| X5. Path switch | Target NG-RAN, AMF, SMF | PATH SWITCH REQUEST with the MBS Support Indicator in the Path Switch Request Transfer; Nsmf_PDUSession_UpdateSMContext; path switch acknowledgement | TS 23.247 cl. 7.2.3.2, steps 1, 5 and 6; TS 38.413 cl. 8.4.4.2 |
| X6. Delivery method | SMF, UPF | Case A, target supports MBS: N4 Session Modification for the unicast PDU Session only. Case B, it does not: 5GC Individual delivery is set up as in step 11 of clause 7.2.1.3 | TS 23.247 cl. 7.2.3.2, steps 3 and 4 |
| X7. Release at the source | Source gNB, AMF, MB-SMF | NGAP Distribution Release, for a session with no remaining joined UE | TS 38.300 cl. 16.10.5.3.2; TS 38.413 cl. 8.18.2 |
| N1. Handover Required | Source NG-RAN, S-AMF, T-AMF | HANDOVER REQUIRED with a RAN container: MBS Session information, associated PDU Session information, QoS flow mapping; the T-AMF gets the PDU Session and MBS session information | TS 23.247 cl. 7.2.3.3, steps 1 and 2 |
| N2. SMF | T-AMF, SMF | Nsmf_PDUSession_UpdateSMContext; the response carries the MBS session ID and optionally the QoS flow mapping in the N2 SM information | TS 23.247 cl. 7.2.3.3, step 3 |
| N3. Handover Request | T-AMF, target NG-RAN, MB-SMF | HANDOVER REQUEST; MBS Active Session Information Source to Target List; a target that supports MBS sets up shared delivery if needed | TS 23.247 cl. 7.2.3.3, step 4; TS 38.413 cl. 8.4.2.2; TS 23.247 cl. 7.2.1.4 |
| N4. Acknowledge | Target NG-RAN, T-AMF, SMF, UPF | HANDOVER REQUEST ACKNOWLEDGE with the MBS Support Indicator in the Handover Request Acknowledge Transfer; Nsmf_PDUSession_UpdateSMContext; then as X6 | TS 23.247 cl. 7.2.3.3, steps 5 and 12 to 15; TS 38.413 cl. 8.4.2.2 |
| T1. Optional reconfiguration | Source gNB, UE | The MRB is switched to a DRB before the handover; otherwise the target may apply full configuration | TS 38.300 cl. 16.10.5.3.3 |
| T2. Target resources | Target gNB, source gNB | PDU Session Resources mapped to the multicast session; with data forwarding, the source changes the QFIs of the forwarded packets to those of the associated PDU Session | TS 38.300 cl. 16.10.5.3.3; TS 23.247 cl. 7.2.3.5 |
| T3. Switch to 5GC Individual | SMF, MB-SMF, UPF, MB-UPF | From the absence of the MBS support indication; N3 tunnel of the PDU Session towards the target; GTP tunnel between the UPF and the MB-UPF activated if needed | TS 38.300 cl. 16.10.5.3.3; TS 23.247 cl. 6.3.1 |
| F1. Handover | Source and target NG-RAN, AMF, SMF | Existing Xn or N2 handover; the associated QoS flows of the associated PDU Session are handed over; the target indicates MBS support in the N2 SM information | TS 23.247 cl. 7.2.3.4; TS 38.300 cl. 16.10.5.3.3 |
| F2 (Xn). Shared delivery | SMF, AMF, target NG-RAN, MB-SMF | After the handover, PDU Session Resource Modification with the joined MBS Session IDs; the target may set up shared delivery and answers when it is available | TS 23.247 cl. 7.2.3.4; TS 38.300 cl. 16.10.5.3.3 |
| F2 (N2). Shared delivery | SMF, target NG-RAN, MB-SMF | During preparation, the MBS session information in the N2 SM information of the NGAP HANDOVER REQUEST; the target adds the UE to the MBS Session Context and sets up shared delivery if needed | TS 23.247 cl. 7.2.3.4; TS 38.300 cl. 16.10.5.3.3 |
| F3. Switch to 5GC Shared | SMF, UPF | N4 Session Modification: the UPF no longer forwards the multicast data in the PDU Session; the SMF may release the shared tunnel between the UPF and the MB-UPF | TS 23.247 cl. 6.3.1, 7.2.3.4 |
| I. Inactive session | Source and target NG-RAN, SMF | MBS session ID without Active MBS Session Information; shared tunnel established if needed, no radio resources; towards a node without MBS, the SMF removes the associated QoS flows | TS 23.247 cl. 7.2.3.6 |
| R1. Within the RNA | UE, gNB | Multicast MCCH of the new cell; resume if the PTM configuration is missing; PDCP COUNT synchronisation within the RNA; resume threshold | TS 23.247 cl. 7.2.3.8.2; TS 38.300 cl. 16.10.5.3.5 |
| R2. Out of the RNA, within the RA | UE, NG-RAN, AMF, SMF | RRC connection resume as in R4 | TS 23.247 cl. 7.2.3.8.3 |
| R3. Out of the RA | UE, AMF, SMF | Mobility Registration Update, which activates the associated PDU Sessions | TS 23.247 cl. 7.2.3.8.4 |
| R4. Resume in another node | UE, NG-RAN, AMF, SMF, MB-SMF | Context retrieval; shared delivery set up if needed; Path Switch Request with or without the MBS support information; on failure, RRC_IDLE and NAS signalling recovery | TS 23.247 cl. 7.2.3.7 |
| R5. Support for reception in RRC_INACTIVE | Target NG-RAN, SMF, source NG-RAN | N2 SM information in the Path Switch Request (Xn) or Handover Request Ack (N2) indicates support for multicast reception in RRC_INACTIVE; MBS Assistance Information from the SMF or from the source node | TS 23.247 cl. 7.2.3.8.1; TS 38.413 cl. 9.3.1.210 |
Between nodes that support MBS
During handover preparation, the source gNB tells the target gNB, in the UE context information, which multicast sessions the UE has joined. For a local multicast service with location dependent content, service area information per Area Session ID may be provided for each active session (TS 38.300 clause 16.10.5.3.2). In TS 23.247, the source NG-RAN has already been given the MBS Session Resource information, and the UE context holds the mapping between the multicast QoS flows and the unicast QoS flows of the associated PDU Session; that mapping is provided when the UE joins the session (TS 23.247 clauses 7.2.3.2 and 6.3.1).
The source gNB may propose data forwarding for some MRBs to minimise data loss, and may exchange their PDCP sequence numbers with the target gNB: (TS 38.300 V19.4.0 clause 16.10.5.3.2)
- Lossless handover is supported between cells that support MBS if the UE is configured with a PTP RLC AM entity in the target cell MRB, whether or not it had one in the source cell (TS 38.300 V19.4.0 clause 16.10.5.3.2).
- For lossless handover, the network has to ensure DL PDCP COUNT value synchronisation and continuity between the source and the target cell. Data forwarding and a PDCP status report from the UE can also be used (TS 38.300 V19.4.0 clause 16.10.5.3.2).
For each session with ongoing data and no MBS Session Resources at the target gNB, the target sets up the MBS user plane resources towards the 5G Core with the NGAP Distribution Setup procedure. With unicast transport, the target gives the MB-SMF its tunnel endpoint; with multicast transport, it receives the IP multicast address from the MB-SMF (TS 38.300 clause 16.10.5.3.2).
During handover execution, the MBS configuration decided by the target gNB is sent to the UE through the source gNB, in an RRC container. The PDCP entities of the multicast MRBs in the UE can be re-established or kept. When the UE connects, the target gNB indicates to the SMF that it supports MBS. After the handover, the source gNB may release the MBS user plane resources with the NGAP Distribution Release procedure for any session without a remaining joined UE (TS 38.300 clause 16.10.5.3.2).
In the 5G Core, at Xn handover the target NG-RAN sends the N2 Path Switch Request to the AMF and, if it is MBS-capable, indicates in the N2 SM information that it supports MBS. From that information the SMF determines whether 5GC Shared or 5GC Individual delivery is used. If the target supports MBS, the SMF modifies the N4 session of the UPF for the unicast PDU Session only; if it does not, 5GC Individual delivery is set up as in step 11 of clause 7.2.1.3 (TS 23.247 clause 7.2.3.2). In NGAP, the indication is the MBS Support Indicator in the Path Switch Request Transfer of the PATH SWITCH REQUEST (TS 38.413 clause 8.4.4.2).
At N2 handover, the source NG-RAN sends Handover Required with a RAN container holding the MBS Session information, the associated PDU Session information and the QoS flow mapping. The target AMF obtains from the SMF, with Nsmf_PDUSession_UpdateSMContext, the MBS session ID and optionally the QoS flow mapping in the N2 SM information. A target that supports MBS uses the multicast MBS session information to allocate RAN resources, and establishes shared delivery towards the MB-SMF through the AMF if it does not have it; a target that does not support MBS ignores that information and delivers the data in the associated QoS flows of the PDU Session. The target answers with Handover Request Ack, indicating in the N2 SM information whether it supports MBS, and the SMF determines the delivery method as for Xn (TS 23.247 clause 7.2.3.3). In NGAP, the MBS Active Session Information Source to Target List in the HANDOVER REQUEST makes the target NG-RAN node consider the indicated sessions active and establish their resources, and the MBS Support Indicator travels in the Handover Request Acknowledge Transfer of the HANDOVER REQUEST ACKNOWLEDGE (TS 38.413 clause 8.4.2.2).
Between a node that supports MBS and one that does not
Towards a node without MBS
At mobility to a cell that does not support MBS, the target gNB sets up PDU Session Resources mapped to the multicast session. The 5G Core infers from the absence of the "MBS-support" indication, in the Path Switch Request (Xn handover) or Handover Request Acknowledge (NG handover), that delivery has to switch to 5GC Individual MBS traffic delivery. If data forwarding is applied, the source gNB infers from the handover preparation response that the target does not support MBS, and changes the QFIs of the forwarded packets to those of the associated PDU Session, when the mapping is available. The source gNB may know before handover preparation that the target does not support MBS (TS 38.300 clause 16.10.5.3.3).
In TS 23.247, the N3 tunnel of the PDU Session used for 5GC Individual delivery is then established towards the target node, and the SMF and the MB-SMF activate the GTP tunnel between the UPF and the MB-UPF if needed (TS 23.247 clause 6.3.1).
The source gNB can switch the MRB to a DRB before the handover. TS 38.300 notes that without that prior reconfiguration, the target gNB may not understand the AS configuration, causing full configuration (clause 16.10.5.3.3).
From a node without MBS
When the source node does not support MBS, the session data reaches the UE by 5GC Individual delivery, and the UE is handed over with the existing Xn or N2 handover procedures. The 5G Core infers from the presence of the "MBS-support" indicator that delivery can switch from 5GC Individual to 5GC Shared (TS 23.247 clause 7.2.3.4; TS 38.300 clause 16.10.5.3.3):
- After an Xn handover, if the target supports MBS, the SMF modifies the associated PDU Session at the target with the multicast MBS session information in the N2 SM information, which may trigger the target to establish shared delivery. NG-RAN answers the modification once shared delivery to the UE is available. In TS 38.300, the SMF gives the target gNB the MBS Session IDs the UE joined with the PDU Session Resource Modification procedure.
- For an N2 handover, the SMF includes the multicast MBS session information in the N2 SM information during handover preparation; in TS 38.300, in the NGAP Handover Request. A target that supports MBS adds the UE to the MBS Session Context and establishes shared delivery if needed.
The SMF then changes the delivery to 5GC Shared: with N4 Session Modification it configures the UPF not to forward the multicast data in the associated PDU Session, and, if no PDU Session needs it any more, it may release the shared tunnel between the UPF and the MB-UPF (TS 23.247 clause 7.2.3.4). Data loss can be minimised and duplicates avoided by comparing the MBS QFI sequence numbers received over the shared NG-U tunnel with those received over the unicast or forwarding tunnels (TS 38.300 clause 16.10.5.3.3).
Minimisation of data loss
| Mechanism | In the specifications |
|---|---|
| Sequence numbers | The MB-UPF adds a sequence number per MBS QoS flow to each packet it sends to NG-RAN nodes and UPFs; a UPF that forwards the packet does not change it (TS 23.247 clause 7.2.3.5) |
| Data forwarding between MBS nodes | Data may be forwarded from the source to the target node; the PDCP number is exchanged in handover preparation (TS 23.247 clause 7.2.3.5) |
| PDCP COUNT from the sequence number | With one QoS flow mapped to an MRB, the gNB sets the PDCP COUNT to the DL MBS QFI sequence number received over NG-U (TS 38.300 clause 16.10.5.1) |
| Shared NG-U termination | NG-RAN nodes that share a common user plane entity can allocate identical PDCP numbers in cells of different nodes (TS 23.247 clause 7.2.3.5; TS 38.300 clause 16.10.5.1) |
| Towards a node without MBS | The data is forwarded in data forwarding tunnels allocated by the target for the mapped unicast QoS flows of the associated PDU Session (TS 23.247 clause 7.2.3.5) |
| From a node without MBS | Directly after the handover the target still receives the data by individual delivery, with the MB-UPF sequence numbers, while shared delivery is being established; it then receives the sequence numbers over shared delivery (TS 23.247 clause 7.2.3.5) |
| MRB reconfiguration | When the MRB type changes, the gNB may ask the UE for a PDCP status report (TS 38.300 clause 16.10.5.3.4) |
Handover of an inactive session
If the MBS session is in the Inactive state, the target NG-RAN is given the MBS session ID but no Active MBS Session Information; the lack of that information implies that the session is inactive. A target that supports MBS establishes the shared tunnel with the MB-UPF if it does not have it, but does not allocate radio resources. After a handover to a target that does not support MBS, the SMF removes the associated QoS flow information (TS 23.247 clause 7.2.3.6).
UEs in RRC_INACTIVE
How a UE in RRC_INACTIVE keeps receiving when it changes cells (multicast MCCH of the new cell, PDCP COUNT synchronisation within the RNA, the resume threshold) is under Reception in RRC_INACTIVE above (TS 38.300 clause 16.10.5.3.5). In the 5G Core, TS 23.247 distinguishes three cases for a UE in CM-CONNECTED with RRC_INACTIVE that receives multicast data (clause 7.2.3.8.1):
- Within the RAN Notification Area (RNA): the UE may keep receiving in RRC_INACTIVE, or resume the connection, as specified in TS 38.300 (TS 23.247 V20.0.0 clause 7.2.3.8.2).
- Out of the RNA, within the Registration Area (RA): the UE resumes the connection as in clause 7.2.3.7 (clause 7.2.3.8.3) (TS 23.247 V20.0.0 clause 7.2.3.8.3).
- Out of the RA: the UE performs the Mobility Registration Update procedure, which activates the associated PDU Sessions, so that shared or individual delivery can be established towards the new NG-RAN node (clause 7.2.3.8.4) (TS 23.247 V20.0.0 clause 7.2.3.8.4).
When the UE resumes in another NG-RAN node and the context retrieval succeeds (TS 23.247 clause 7.2.3.7):
- in a node that supports MBS, if the retrieved UE context holds MBS session information, the node establishes 5GC Shared delivery if it does not have it, then sends a Path Switch Request with the MBS support information; (TS 23.247 V20.0.0 clause 7.2.3.7)
- in a node that supports MBS, if the context holds no MBS session information, the Path Switch Request carries the MBS support information, and the SMF then provides the MBS information and any associated QoS flows, after which the node establishes 5GC Shared delivery; (TS 23.247 V20.0.0 clause 7.2.3.7)
- in a node that does not support MBS, the Path Switch Request carries no MBS support information; if the session is still inactive, the SMF removes the associated QoS flow information (TS 23.247 V20.0.0 clause 7.2.3.7).
If the context retrieval fails, the UE moves to RRC_IDLE and starts NAS signalling recovery, including the activation of its PDU Sessions (clause 7.2.3.7) (TS 23.247 V20.0.0 clause 7.2.3.7).
For delivery to UEs in RRC_INACTIVE, the handover and resume procedures above have additions (TS 23.247 clause 7.2.3.8.1). A target node that supports multicast reception in RRC_INACTIVE indicates it to the SMF in the N2 SM information of the Path Switch Request (Xn) or the Handover Request Ack (N2); in NGAP, the MBS Support Indicator then has the value "multicast supported with reception in RRC inactive" (TS 38.413 clause 9.3.1.210). If MBS assistance information is available for a session the UE joined, the SMF includes it in the N2 SM information it sends to the target. After an Xn handover or a resume towards a node that supports reception in RRC_INACTIVE from one that does not, the SMF modifies the associated PDU Session to provide it; at Xn handover or resume, the source node also passes the MBS assistance information it holds to the target.
Sources for this page
- How MBS Multicast differs: TS 38.300 V19.4.0, clauses 16.10.1 and 16.10.5.2; TS 23.247 V20.0.0, clause 7.2.1.1.
- Network set-up: TS 23.247 V20.0.0, clauses 7.1.1.1 to 7.1.1.4, 7.1.1.6 and 7.1.2; TS 26.502 V19.6.0, clauses 5.2 to 5.5.1; TS 29.532 V20.0.0, clauses 5.2.2.2 and 5.3.2.2; TS 29.244 V19.6.0, clause 5.34.2.2.
- Join and session establishment: TS 23.247 V20.0.0, clauses 7.2.1.1 to 7.2.1.4; TS 29.532 V20.0.0, clauses 5.3.2.5 and 5.3.2.9, table 6.2.3.1-1; TS 38.413 V19.4.0, clauses 8.18.1, 9.3.1.210 to 9.3.1.212, 9.3.4.1, 9.3.4.3 and 9.3.4.4; TS 38.401 V19.3.0, clause 8.15.1.2; TS 37.483 V19.4.0, clauses 8.6.2.1 and 8.6.2.2; TS 38.473 V19.4.0, clauses 8.14.6 and 8.14.10; TS 29.244 V19.6.0, clauses 5.34.3.1 and 5.34.3.2.
- Radio configuration: TS 38.300 V19.4.0, clauses 16.10.3, 16.10.5.2, 16.10.5.3.4 and 16.10.5.4 to 16.10.5.7; TS 38.331 V19.4.0, clauses 5.3.5.6.1, 5.3.5.6.6, 5.3.5.6.7 and 6.3.2; TS 38.213 V19.5.0, clause 18; TS 38.212 V19.4.0, clauses 7.3.1.5.2 and 7.3.1.5.3; TS 38.321 V19.4.0, clause 5.3.1.
- Activation, deactivation and update: TS 23.247 V20.0.0, clauses 7.1.1.6 and 7.2.5; TS 29.518 V19.8.0, clauses 5.4.2.4 and 5.7.2.2; TS 29.244 V19.6.0, clauses 5.34.2.3 and 5.34.2.4; TS 38.413 V19.4.0, clauses 8.5.2 and 8.18.3 to 8.18.5; TS 38.473 V19.4.0, clause 8.14.5; TS 37.483 V19.4.0, clauses 8.6.2.1 and 8.6.2.6; TS 38.300 V19.4.0, clause 16.10.5.2; TS 38.331 V19.4.0, clause 5.3.2.3.
- User plane: TS 23.247 V20.0.0, clause 7.2.1.3; TS 29.244 V19.6.0, clauses 5.34.3.1 and 5.34.3.2; TS 37.324 V19.0.0, clause 4.2.2; TS 38.323 V19.1.0, clause 4.2.2.
- Leave and release: TS 23.247 V20.0.0, clauses 7.1.1.4 and 7.2.2; TS 38.413 V19.4.0, clause 8.18.2; TS 38.473 V19.4.0, clauses 8.14.7 and 8.14.11; TS 37.483 V19.4.0, clause 8.6.2.4; TS 38.331 V19.4.0, clause 5.3.5.6.1.
- RRC_INACTIVE, How it differs, join and decision: TS 23.247 V20.0.0, clauses 6.17, 7.2.1.3 and 7.2.5.2; TS 38.300 V19.4.0, clauses 16.10.5.1, 16.10.5.2, 16.10.5.4 and 16.10.5.7; TS 38.413 V19.4.0, clause 9.3.1.210.
- RRC_INACTIVE, Release 18 addition: TS 38.331 V18.11.0 compared with TS 38.331 V17.17.0 (SIB24, clause 5.10); TS 38.321 V18.10.0 compared with V17.15.0 (table 7.1-1).
- RRC_INACTIVE, Configuration and continuity: TS 38.300 V19.4.0, clauses 16.10.3, 16.10.5.2, 16.10.5.3.5, 16.10.5.4, 16.10.5.6 and 16.10.5.7.
- RRC_INACTIVE, Core side: TS 23.247 V20.0.0, clauses 4.3, 6.17, 7.2.1.3, 7.2.3.7 and 7.2.3.8.
- RRC_INACTIVE, RRC procedures and messages: TS 38.331 V19.4.0, clauses 5.3.2.3, 5.3.8.3, 5.10.1 to 5.10.3, 6.2.1, 6.2.2, 6.3.1, 6.3.2 and 6.3.6.
- RRC_INACTIVE, MAC: TS 38.321 V19.4.0, clause 5.3.1, tables 6.2.1-1, 6.2.1-1c and 7.1-1.
- RRC_INACTIVE, Physical layer: TS 38.212 V19.4.0, clauses 7.3.1.5.1 and 7.3.1.5.2; TS 38.213 V19.5.0, clause 10.1; TS 38.214 V19.5.0, clause 5.1.
- RRC_INACTIVE, User plane: TS 38.323 V19.1.0, clause 7.1; TS 37.324 V19.0.0, clause 4.2.
- RRC states: TS 38.300 V19.4.0, clause 16.10.5.2.
- Release 18 attribution (RRC_INACTIVE, power saving, group paging): TS 23.247 V18.8.0 and V20.0.0, clauses 6.16, 6.17, 7.2.5.2 and 7.2.10, and the change history (CR 0149, CR 0159, CR 0280), compared with V17.12.0; TR 21.918 V18.0.0 clause 12.2 (NR_MBS_enh).
- Release 20 (TS 23.247 V20.0.0), roaming for multicast: clauses 4.1, 6.4.2, 6.22 and 7.2.1.2 (NOTE 2).
- Mobility: TS 23.247 V20.0.0, clauses 6.3.1, 7.2.1.4 and 7.2.3.1 to 7.2.3.8.4; TS 38.300 V19.4.0, clauses 16.10.5.1 and 16.10.5.3.1 to 16.10.5.3.5; TS 38.413 V19.4.0, clauses 8.4.2.2, 8.4.4.2, 8.18.1, 8.18.2 and 9.3.1.210.
- Added in Release 19 (shared NG-U path failure, Object Repair): TS 38.300 V19.4.0, clause 16.10.5.1; TS 38.413 V19.4.0, clause 8.18.5.2; TS 37.483 V19.4.0, clause 8.6.2.2.2; TS 26.502 V19.6.0, clause 5.3; each compared with the Release 18 issue (TS 38.300 V18.11.0, TS 38.413 V18.11.0, TS 37.483 V18.6.0, TS 26.502 V18.6.0).