6 NG-RAN architecture

38.4013GPPArchitecture descriptionNG-RANRelease 17TS

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

6.1 Overview

6.1.1 Overall Architecture of NG-RAN

Figure 6.1-1: Overall architecture

The NG-RAN consists of a set of gNBs connected to the 5GC through the NG interface.

NOTE: As specified in TS 38.300 [2], NG-RAN could also consists of a set of ng-eNBs, an ng-eNB may consist of an ng-eNB-CU and one or more ng-eNB-DU(s). An ng-eNB-CU and an ng-eNB-DU is connected via W1 interface. The general principle described in this clause also applies to ng-eNB and W1 interface, if not explicitly specified otherwise.

An gNB can support FDD mode, TDD mode or dual mode operation.

gNBs can be interconnected through the Xn interface.

A gNB may consist of a gNB-CU and one or more gNB-DU(s). A gNB-CU and a gNB-DU is connected via F1 interface.

One gNB-DU is connected to only one gNB-CU.

NOTE: In case of network sharing with multiple cell ID broadcast, each Cell Identity associated with a subset of PLMNs corresponds to a gNB-DU and the gNB-CU it is connected to, i.e. the corresponding gNB-DUs share the same physical layer cell resources.

NOTE: For resiliency, a gNB-DU may be connected to multiple gNB-CUs by appropriate implementation.

NG, Xn and F1 are logical interfaces.

For NG-RAN, the NG and Xn-C interfaces for a gNB consisting of a gNB-CU and gNB-DUs, terminate in the gNB-CU. For EN-DC, the S1-U and X2-C interfaces for a gNB consisting of a gNB-CU and gNB-DUs, terminate in the gNB-CU. The gNB-CU and connected gNB-DUs are only visible to other gNBs and the 5GC as a gNB. A possible deployment scenario is described in Annex A.

The node hosting user plane part of NR PDCP (e.g. gNB-CU, gNB-CU-UP, and for EN-DC, MeNB or SgNB depending on the bearer split) shall perform user inactivity monitoring and further informs its inactivity or (re)activation to the node having C-plane connection towards the core network (e.g. over E1, X2). The node hosting NR RLC (e.g. gNB-DU) may perform user inactivity monitoring and further inform its inactivity or (re)activation to the node hosting control plane, e.g. gNB-CU or gNB-CU-CP.

UL PDCP configuration (i.e. how the UE uses the UL at the assisting node) is indicated via X2-C (for EN-DC), Xn-C (for NG-RAN) and F1-C. Radio Link Outage/Resume for DL and/or UL is indicated via X2-U (for EN-DC), Xn-U (for NG-RAN) and F1-U.

The NG-RAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL).

The NG-RAN architecture, i.e. the NG-RAN logical nodes and interfaces between them, is defined as part of the RNL.

For each NG-RAN interface (NG, Xn, F1) the related TNL protocol and the functionality are specified. The TNL provides services for user plane transport, signalling transport.

In NG-Flex configuration, each NG-RAN node is connected to all AMFs of AMF Sets within an AMF Region supporting at least one slice also supported by the NG-RAN node. The AMF Set and the AMF Region are defined in TS 23.501 [3].

If security protection for control plane and user plane data on TNL of NG-RAN interfaces has to be supported, NDS/IP TS 33.501 [13] shall be applied.

6.1.2 Overall architecture for separation of gNB-CU-CP and gNB-CU-UP

The overall architecture for separation of gNB-CU-CP and gNB-CU-UP is depicted in Figure 6.1.2-1.

NOTE: NG-RAN could also consist of a set of ng-eNBs, an ng-eNB may consist of an ng-eNB-CU-CP, one or more ng-eNB-CU-UP(s), and one or more ng-eNB-DU(s). An ng-eNB-CU-CP and an ng-eNB-CU-UP is connected via the E1 interface. An ng-eNB-DU is connected to an ng-eNB-CU-CP via the W1-C interface, and to an ng-eNB-CU-UP via the W1-U interface. The general principle described in this clause also applies to ng-eNB and its corresponding E1 and W1 interfaces, if not explicitly specified otherwise.

Figure 6.1.2-1. Overall architecture for separation of gNB-CU-CP and gNB-CU-UP

– A gNB may consist of a gNB-CU-CP, multiple gNB-CU-UPs and multiple gNB-DUs;

– The gNB-CU-CP is connected to the gNB-DU through the F1-C interface;

– The gNB-CU-UP is connected to the gNB-DU through the F1-U interface;

– The gNB-CU-UP is connected to the gNB-CU-CP through the E1 interface;

– One gNB-DU is connected to only one gNB-CU-CP;

– One gNB-CU-UP is connected to only one gNB-CU-CP;

NOTE 1: For resiliency, a gNB-DU and/or a gNB-CU-UP may be connected to multiple gNB-CU-CPs by appropriate implementation.

– One gNB-DU can be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP;

– One gNB-CU-UP can be connected to multiple DUs under the control of the same gNB-CU-CP;

NOTE 2: The connectivity between a gNB-CU-UP and a gNB-DU is established by the gNB-CU-CP using Bearer Context Management functions.

NOTE 3: The gNB-CU-CP selects the appropriate gNB-CU-UP(s) for the requested services for the UE. In case of multiple CU-UPs they belong to same security domain as defined in TS 33.210 [18].

NOTE 4: Data forwarding between gNB-CU-UPs during intra-gNB-CU-CP handover within a gNB may be supported by Xn-U.

6.1.3 Overall Architecture of IAB

Figure 6.1.3-1: Overall architecture of IAB

The NG-RAN supports IAB by the IAB-node wirelessly connecting to the gNB capable of serving the IAB-nodes, named IAB-donor.

The IAB-donor consists of an IAB-donor-CU and one or more IAB-donor-DU(s). In case of separation of gNB-CU-CP and gNB-CU-UP, the IAB-donor may consist of an IAB-donor-CU-CP, multiple IAB-donor-CU-UPs and multiple IAB-donor-DUs.

The IAB-node connects to an upstream IAB-node or an IAB-donor-DU via a subset of the UE functionalities of the NR Uu interface (named IAB-MT function of IAB-node). The IAB-node provides wireless backhaul to the downstream IAB-nodes and UEs via the network functionalities of the NR Uu interface (named IAB-DU function of IAB-node).

The F1-C traffic between an IAB-node and IAB-donor-CU is backhauled via the IAB-donor-DU and the optional intermediate hop IAB-node(s).

The F1-U traffic between an IAB-node and IAB-donor-CU is backhauled via the IAB-donor-DU and the optional intermediate hop IAB-node(s).

All functions specified for a gNB-DU are equally applicable for an IAB-DU and IAB-donor-DU, unless otherwise stated, and all functions specified for a gNB-CU are equally applicable for an IAB-donor-CU, unless otherwise stated. All functions specified for the UE context are equally applicable for managing the context of IAB-MT, unless otherwise stated.

6.1.4 Protocol stacks of IAB

Figure 6.1.4-1 shows the protocol stack for F1-U between IAB-DU and the IAB-donor-CU-UP, and Figure 6.1.4-2 shows the protocol stack for F1-C between IAB-DU and the IAB-donor-CU-CP. In these example figures, F1-U and F1-C traffic are carried over two backhaul hops.

NOTE: F1 needs to be security-protected as described in TS 33.501. The security layer is not shown in the Figure 6.1.4-1, Figure 6.1.4-2 and Figure 6.1.4-3.

Figure 6.1.4-1: Protocol stack for F1-U of IAB

Figure. 6.1.4-2: Protocol stack for F1-C of IAB

Figure 6.1.4-3 shows the protocol stack for F1-C between IAB-DU and the IAB-donor-CU-CP, when the F1-C traffic is exchanged via the MeNB.

IAB-node

F1AP

SCTP

F1AP

SCTP

X2AP

SCTP

X2AP

SCTP

LTE RRC

LTE PDCP

LTE RLC

LTE MAC

LTE PHY

LTE RRC

LTE PDCP

LTE RLC

LTE MAC

LTE PHY

IAB-DU

IAB-MT

MeNB

IAB-donor-CU-CP

LTE-Uu

X2-C

Fig. 6.1.4-3: Protocol stack for IAB F1-C traffic exchanged via the MeNB

Figure 6.1.4-4 shows the protocol stack for F1-C between IAB-DU and the IAB-donor-CU-CP, when the F1-C traffic is exchanged via the MgNB.

IAB-node

F1AP

SCTP

F1AP

SCTP

XnAP

SCTP

XnAP

SCTP

NR RLC

NR MAC

NR PHY

NR RRC

NR PDCP

NR RLC

NR MAC

NR PHY

IAB-DU

IAB-MT

MgNB

IAB-donor-CU-CP

NR-Uu

Xn-C

NR PDCP

NR RRC

Fig. 6.1.4-4: Protocol stack for IAB F1-C traffic exchanged via the MgNB

Figure 6.1.4-5 shows the protocol stack for F1-C between IAB-DU and the IAB-donor-CU-CP, when the F1-C traffic is exchanged via the SgNB.

IAB-node

F1AP

SCTP

F1AP

SCTP

XnAP

SCTP

XnAP

SCTP

NR RRC RRC

NR PDCP

NR RLC

NR MAC

NR PHY

NR RRC

NR PDCP

NR RLC

NR MAC

NR PHY

IAB-DU

IAB-MT

SgNB

IAB-donor-CU-CP

NR-Uu

Xn-C

Fig. 6.1.4-5: Protocol stack for IAB F1-C traffic exchanged via the SgNB

6.1.5 Overall Architecture of NR MBS

The overall architecture specified in clause 6.1.1 and 6.1.2 applies for NR MBS.

Upon establishment of a MBS Session resource by the 5GC, the gNB-CU triggers the establishment of MRBs, involving the gNB-DU. If E1 is deployed, the gNB-CU-CP triggers establishment of respective MBS UP resources in the gNB-CU-UP.

The gNB-DU assigns the G-RNTI.

A shared F1-U tunnel is used between the gNB-CU and the gNB-DU for PTM transmission of a MRB, and for the data transmission of a split MRB. The gNB-DU assigns the DL GTP-U TEID and provides it to the gNB-CU. If E1 is deployed the gNB-CU-CP forwards it to the gNB-CU-UP.

For both broadcast and multicast, DL flow control maybe used for the shared F1-U tunnel established for the MRB, as specified in TS 38.425 [24].

6.1.6 Protocol stacks of L2 UE-to-Network Relay

The protocol stacks for the user plane and control plane of L2 U2N Relay architecture are described in Figure 6.1.6-1 and Figure 6.1.6-2, respectively. The Uu SRAP is terminated between U2N relay UE and gNB-DU.

Figure 6.1.6-1: User plane protocol stack for L2 UE-to-Network Relay

Figure 6.1.6-2: Control plane protocol stack for L2 UE-to-Network Relay

6.2 NG-RAN identifiers

6.2.1 Principle of handling Application Protocol Identities

An Application Protocol Identity (AP ID) is allocated when a new UE-associated logical connection is created in either an NG-RAN node or an AMF. An AP ID shall uniquely identify a logical connection associated to a UE over the NG interface or Xn interface within a node (NG-RAN node or AMF) or over the F1 interface or over the E1 interface or over the W1 interface. Upon receipt of a message that has a new AP ID from the sending node, the receiving node shall store the AP ID of the sending node for the duration of the logical connection. The receiving node shall assign the AP ID to be used to identify the logical connection associated to the UE and include it as well as the previously received new AP ID from the sending node, in the first returned message to the sending node. In all subsequent messages to and from sending node, both AP IDs of sending node and receiving node shall be included. For MBS-associated logical connections of the E1 interface and the F1 interface the same principles for AP IDs apply as for UE-associated logical connections.

The definitions of AP IDs as used on NG interface or Xn interface or F1 interface or E1 interface are shown below:

RAN UE NGAP ID:

A RAN UE NGAP ID shall be allocated so as to uniquely identify the UE over the NG interface within an gNB. When an AMF receives an RAN UE NGAP ID it shall store it for the duration of the UE-associated logical NG-connection for this UE. Once known to an AMF this is included in all UE associated NGAP signalling.

The RAN UE NGAP ID shall be unique within the logical NG-RAN node.

AMF UE NGAP ID:

An AMF UE NGAP ID shall be allocated so as to uniquely identify the UE over the NG interface within the AMF. When a NG-RAN node receives an AMF UE NGAP ID it shall store it for the duration of the UE-associated logical NG-connection for this UE. Once known to a NG-RAN node this ID is included in all UE associated NGAP signalling.

The AMF UE NGAP ID shall be unique within an AMF Set as specified in TS 23.501 [3].

Old NG-RAN node UE XnAP ID:

An Old NG-RAN node UE XnAP ID shall be allocated so as to uniquely identify the UE over the Xn interface within a source NG-RAN node. When a target NG-RAN node receives an Old NG-RAN node UE XnAP ID it shall store it for the duration of the UE-associated logical Xn-connection for this UE. Once known to a target NG-RAN node this ID is included in all UE associated XnAP signalling. The Old NG-RAN node UE XnAP ID shall be unique within the logical NG-RAN node.

New NG-RAN node UE XnAP ID:

A New NG-RAN node UE XnAP ID shall be allocated so as to uniquely identify the UE over the Xn interface within a target NG-RAN node. When a source NG-RAN node receives a New NG-RAN node UE XnAP ID it shall store it for the duration of the UE-associated logical Xn-connection for this UE. Once known to a source NG-RAN node this ID is included in all UE associated XnAP signalling. The New NG-RAN node UE XnAP ID shall be unique within the logical NG-RAN node.

M-NG-RAN node UE XnAP ID:

An M-NG-RAN node UE XnAP ID shall be allocated so as to uniquely identify the UE over the Xn interface within an M-NG-RAN node for dual connectivity. When an S-NG-RAN node receives an M-NG-RAN node UE XnAP ID it shall store it for the duration of the UE-associated logical Xn-connection for this UE. Once known to an S-NG-RAN node this ID is included in all UE associated XnAP signalling. The M-NG-RAN node UE XnAP ID shall be unique within the logical NG-RAN node.

S-NG-RAN node UE XnAP ID:

A S-NG-RAN node UE XnAP ID shall be allocated so as to uniquely identify the UE over the Xn interface within an S-NG-RAN node for dual connectivity. When an M-NG-RAN node receives a S-NG-RAN node UE XnAP ID it shall store it for the duration of the UE-associated logical Xn-connection for this UE. Once known to an M-NG-RAN node this ID is included in all UE associated XnAP signalling. The S-NG-RAN node UE XnAP ID shall be unique within the logical NG-RAN node.

gNB-CU UE F1AP ID:

A gNB-CU UE F1AP ID shall be allocated so as to uniquely identify the UE over the F1 interface within a gNB-CU. When a gNB-DU receives a gNB-CU UE F1AP ID it shall store it for the duration of the UE-associated logical F1-connection for this UE. The gNB-CU UE F1AP ID shall be unique within the gNB-CU logical node.

gNB-DU UE F1AP ID:

A gNB-DU UE F1AP ID shall be allocated so as to uniquely identify the UE over the F1 interface within a gNB-DU. When a gNB-CU receives a gNB-DU UE F1AP ID it shall store it for the duration of the UE-associated logical F1-connection for this UE. The gNB-DU UE F1AP ID shall be unique within the gNB-DU logical node.

gNB-CU-CP UE E1AP ID:

A gNB-CU-CP UE E1AP ID shall be allocated so as to uniquely identify the UE over the E1 interface within a gNB-CU-CP (respectively an ng-eNB-CU-CP, or an eNB-CP as defined in TS 36.401[28]). When a gNB-CU-UP (respectively an ng-eNB-CU-UP, or an eNB-UP as defined in TS 36.401[28]) receives a gNB-CU-CP UE E1AP ID it shall store it for the duration of the UE-associated logical E1-connection for this UE. The gNB-CU-CP UE E1AP ID shall be unique within the gNB-CU-CP (respectively the ng-eNB-CU-CP, or the eNB-CP as defined in TS 36.401[28]) logical node.

gNB-CU-UP UE E1AP ID:

A gNB-CU-UP UE E1AP ID shall be allocated so as to uniquely identify the UE over the E1 interface within a gNB-CU-UP (respectively an ng-eNB-CU-UP, or an eNB-UP as defined in TS 36.401[28]). When a gNB-CU-CP (respectively an ng-eNB-CU-CP, or an eNB-CP as defined in TS 36.401[28]) receives a gNB-CU-UP UE E1AP ID it shall store it for the duration of the UE-associated logical E1-connection for this UE. The gNB-CU-UP UE E1AP ID shall be unique within the gNB-CU-UP (respectively the ng-eNB-CU-UP, or the eNB-UP as defined in TS 36.401[28]) logical node.

ng-eNB-CU UE W1AP ID:

An ng-eNB-CU UE W1AP ID shall be allocated so as to uniquely identify the UE over the W1 interface within an ng-eNB-CU. When an ng-eNB-DU receives an ng-eNB-CU UE W1AP ID it shall store it for the duration of the UE-associated logical W1-connection for this UE. The ng-eNB-CU UE W1AP ID shall be unique within the ng-eNB-CU logical node.

ng-eNB-DU UE W1AP ID:

An ng-eNB-DU UE W1AP ID shall be allocated so as to uniquely identify the UE over the W1 interface within an ng-eNB-DU. When an ng-eNB-CU receives an ng-eNB-DU UE W1AP ID it shall store it for the duration of the UE-associated logical W1-connection for this UE. The ng-eNB-DU UE W1AP ID shall be unique within the ng-eNB-DU logical node.

gNB-CU MBS F1AP ID:

A gNB-CU MBS F1AP ID shall be allocated so as to uniquely identify the MBS Session Context over the F1 interface within a gNB-CU. When a gNB-DU receives a gNB-CU MBS F1AP ID it shall store it for the duration of the MBS-associated logical F1-connection for that MBS Session. The gNB-CU MBS F1AP ID shall be unique within the gNB-CU logical node.

gNB-DU MBS F1AP ID:

A gNB-DU MBS F1AP ID shall be allocated so as to uniquely identify the MBS Session Context over the F1 interface within a gNB-DU. When a gNB-CU receives a gNB-DU MBS F1AP ID it shall store it for the duration of the MBS-associated logical F1-connection for this MBS Session. The gNB-DU MBS F1AP ID shall be unique within the gNB-DU logical node.

gNB-CU-CP MBS E1AP ID:

A gNB-CU-CP MBS E1AP ID shall be allocated so as to uniquely identify the MBS Session Context over the E1 interface within a gNB-CU-CP. When a gNB-CU-UP receives a gNB-CU-CP MBS E1AP ID it shall store it for the duration of the MBS-associated logical E1-connection for that MBS Session. The gNB-CU-CP MBS E1AP ID shall be unique within the gNB-CU-CP logical node.

gNB-CU-UP MBS E1AP ID:

A gNB-CU-UP MBS E1AP ID shall be allocated so as to uniquely identify the MBS Session Context over the E1 interface within a gNB-CU-UP. When a gNB-CU-CP receives a gNB-CU-UP MBS E1AP ID it shall store it for the duration of the MBS-associated logical E1-connection for this MBS Session. The gNB-CU-UP MBS E1AP ID shall be unique within the gNB-CU-UP logical node.

6.2.2 gNB-DU ID

The gNB-DU ID is configured at the gNB-DU and used to uniquely identify the gNB-DU at least within a gNB-CU.

6.2.3 ng-eNB-DU ID

The ng-eNB-DU ID is configured at the ng-eNB-DU and used to uniquely identify the ng-eNB-DU at least within an ng-eNB-CU. The ng-eNB-DU provides its ng-eNB-DU ID to the ng-eNB-CU during the W1 Setup procedure. The ng-eNB-DU ID is used only within W1AP procedures.

6.2.4 gNB-CU-UP ID

The gNB-CU-UP ID is configured at the gNB-CU-CP and used to uniquely identify the gNB-CU-UP at least within a gNB-CU-CP. The gNB-CU-UP provides its gNB-CU-UP ID to the gNB-CU-CP during the E1 Setup procedure. The gNB-CP-UP ID is used only within E1AP procedures.

NOTE 1: This identity is also used to uniquely identify the ng-eNB-CU-UP at least within an ng-eNB-CU-CP in case CP/UP separation is implemented in ng-eNB.

NOTE 2: This identity is also used to uniquely identify the eNB at least within an eNB-CP in case CP/UP separation is implemented in eNB.

6.3 Transport addresses

The transport layer address parameter is transported in the radio network application signalling procedures that result in establishment of transport bearer connections.

The transport layer address parameter shall not be interpreted in the radio network application protocols and reveal the addressing format used in the transport layer.

The formats of the transport layer addresses are further described in TS 38.414 [5], TS 38.424 [6] and TS 38.474 [7].

6.4 UE associations in NG-RAN Node

There are several types of UE associations needed in the NG-RAN node: the "NG-RAN node UE context" used to store all information needed for a UE and the associations between the UE and the logical NG and Xn connections used for NG/XnAP UE associated messages. An "NG-RAN node UE context" exists for a UE in CM_CONNECTED.

Definitions:

NG-RAN node UE context:

An NG-RAN node UE context is a block of information in an NG-RAN node associated to one UE. The block of information contains the necessary information required to maintain the NG-RAN services towards the active UE. An NG-RAN node UE context is established when the transition to RRC CONNECTED for a UE is completed or in the target NG-RAN node after completion of handover resource allocation during handover preparation, in which case at least UE state information, security information, UE capability information and the identities of the UE-associated logical NG-connection shall be included in the NG-RAN node UE context.

For Dual Connectivity an NG-RAN node UE context is also established in the S-NG-RAN node after completion of S-NG-RAN node Addition Preparation procedure.

If radio bearers are requested to be setup during a UE Context setup or modification procedure, the UE capabilities are signalled to the receiving node as part of the UE context setup or modification procedures.

Bearer context:

A bearer context is a block of information in a gNB-CU-UP node associated to one UE that is used for the sake of communication over the E1 interface. It may include the information about data radio bearers, PDU sessions and QoS-flows associated to the UE. The block of information contains the necessary information required to maintain user-plane services toward the UE.

UE-associated logical NG/Xn/F1/E1-connection:

NGAP, XnAP, F1AP and E1AP provide means to exchange control plane messages associated with the UE over the respectively NG-C, Xn-C, F1-C or E1 interface.

A UE-associated logical connection is established during the first NGAP/XnAP/F1AP message exchange between the NG/Xn/F1 peer nodes.

The connection is maintained as long as UE associated NG/XnAP/F1AP messages need to be exchanged over the NG/Xn/F1 interface.

The UE-associated logical NG-connection uses the identities AMF UE NGAP ID and RAN UE NGAP ID.

The UE-associated logical Xn-connection uses the identities Old NG-RAN node UE XnAP ID and New NG-RAN node UE XnAP ID, or M-NG-RAN node UE XnAP ID and S-NG-RAN node UE XnAP ID.

The UE-associated logical F1-connection uses the identities gNB-CU UE F1AP ID and gNB-DU UE F1AP ID.

The UE-associated logical E1-connection uses the identities gNB-CU-CP UE E1AP ID and gNB-CU-UP UE E1AP ID.

When a node (AMF or gNB) receives a UE associated NGAP/XnAP/F1AP/E1AP message the node retrieves the associated UE based on the NGAP/XnAP/F1AP/E1AP ID.

UE-associated signalling:

UE-associated signalling is an exchange of NGAP/XnAP/F1AP/E1AP messages associated with one UE over the UE-associated logical NG/Xn/F1/E1-connection.

NOTE1: The UE-associated logical NG-connection may exist before the NG-RAN node UE context is setup in the NG-RAN node.

NOTE2: The UE-associated logical F1-connection may exist before the UE context is setup in the gNB-DU.

NOTE3: The general principle described in this clause also applies to ng-eNB and W1/E1 interface, if not explicitly specified otherwise.

6.5 MBS Session associations in NG-RAN Node

The following MBS Session associations are defined in the NG-RAN node to support NR MBS:

NG-RAN MBS session resource context: Encompasses CP and UP, transport and radio resources to support an MBS Session. For multicast it also encompasses the MBS Session state (active, de-activated) and information about joined UEs. If an MBS session resource within a gNB serves multiple MBS service areas, as specified in TS 23.247 [27] the same NG RAN MBS session resource context may be associated with multiple NG-U resources. For a multicast MBS session, NG-U resources are setup or released by the gNB upon UE mobility or UEs leaving or joining the multicast MBS session.

MBS Session context in a gNB-DU:

The definition of an MBS Session context in a gNB-DU applicable for broadcast and multicast.

An MBS Session context in a gNB-DU

– is a block of information associated to an MBS Session, which may consist of one or several MRB Contexts;

– corresponds to either one or several F1-U tunnels.

MRB Context in a gNB-DU:

An MRB Context is a block of information in a gNB-DU associated to an MRB (MRB “instance”). The gNB-DU sets up resources for each MRB Context in a gNB-DU associated to an MBS Session context

– based on information provided within MBS Session Context related information as received by the gNB-DU (e.g. MRB QoS, MBS service area information, etc.), and,

– for multicast, based on the UE Contexts established for RRC_CONNECTED UEs within the gNB-DU containing joining information of the UE for the respective multicast session.

– for broadcast, the gNB-DU determines whether F1-U tunnels are setup per gNB-DU or per MBS Area Session ID served by the gNB-DU.

– for multicast, the gNB-DU determines whether F1-U tunnels are setup per gNB-DU or per cell served by the DU or per MBS Area Session ID served by the gNB-DU or for ptp restransmissions or for a ptp-only MRB leg.

For multicast, for each MRB, the gNB-DU provides the MRB specific Uu configuration to the gNB-CU to configure the UE.

Multicast F1-U Context:

A Multicast F1-U Context is a block of information in a gNB-DU to control the F1-U tunnels associated to the MRB Contexts established for a multicast MBS session. A Multicast F1-U Context is either established per gNB-DU or per cell served by the gNB-DU or per MBS Area Session ID served by the gNB-DU or for ptp restransmissions or for a ptp-only MRB leg. Several Multicast F1-U contexts may exist in parallel in a gNB-DU for the same multicast MBS session.

Allocation and usage of MRB ID values on NG-RAN interfaces for multicast MBS sessions:

– F1 interface: an MRB ID signalled on an F1 interface instance identifies uniquely an MRB among all MRB contexts in an gNB-DU, allocated for all active multicast MBS sessions served by that gNB-DU. The value of each MRB ID is the same value as communicated to UEs served by that gNB-DU.

– E1 interface: an MRB ID signalled on an E1 interface instance identifies uniquely an MRB among all MRBs allocated for a multicast MBS session.

– Xn interface, NG interface: MRB IDs are signalled on Xn/NG interfaces for providing MBS QoS flow to MRB mapping information and data forwarding information from the source gNB. The value of the MRB ID signalled on the Xn/NG interface is the same value as communicated to UEs at the source cell.

Allocation and usage of MRB ID values on NG-RAN interfaces for broadcast MBS sessions:

– An MRB ID signalled on NG-RAN interfaces identifies uniquely an MRB among all MRBs allocated for a broadcast MBS sesssion.

MBS-associated logical F1/E1-connection:

F1AP and E1AP provide means to exchange control plane messages associated with an MBS session over the respective F1/E1 interface.

An MBS-associated logical connection is established during the first F1AP/E1AP message exchange between the F1/E1 peer nodes.

The connection is maintained as long as MBS associated F1AP/E1AP messages need to be exchanged over the F1/E1 interface.

The MBS-associated logical F1-connection uses the identities gNB-CU MBS F1AP ID and gNB-DU MBS F1AP ID.

The MBS-associated logical E1-connection uses the identities gNB-CU-CP MBS E1AP ID and gNB-CU-UP MBS E1AP ID.

When a node (DU or CU or CU-CP and CU-UP) receives an MBS associated F1AP/E1AP message the node retrieves the associated MBS session based on the F1AP/E1AP ID.

MBS-associated signalling:

MBS-associated signalling is an exchange of F1AP/E1AP messages associated with one MBS session over the MBS-associated logical F1/E1-connection.