Content for TR 38.799 Word version: 19.0.0

5.1 General 5.2 Architecture 5.2.1 Architecture Options for NG interface 5.2.1.1 Option 1 5.2.1.2 Option 2 5.2.1.3 Option 3 5.2.1.4 Option 4 5.2.2 Architecture Options for Xn interface 5.2.2.1 Option A for Xn support without Xn GW 5.2.2.2 Option B for Xn support via Xn GW 5.2.3 Evaluation of Architecture options for the NG interface 5.2.4 Evaluation of Architecture options for the Xn interface 5.3 Access control 5.4 Local services access

5 5G Femto p. 16

5.1 General p. 16

NR Femto enables use cases to provide NR access at home or at enterprise premises. The study of NR Femto is based on following assumptions:

An NR Femto node only supports NR;
No impact on the UE is in scope of the study;
Support for a large number of NR Femto nodes should be possible in a scalable manner.

5.2 Architecture p. 17

5.2.1 Architecture Options for NG interface p. 17

5.2.1.1 Option 1 p. 17

As shown in Figure 5.2.1.1-1, in this option the NR Femto node connects to the 5GC directly as a gNB by means of the NG interface.

Copy of original 3GPP image for 3GPP TS 38.799, Fig. 5.2.1.1-1: Option 1 for NR Femto Architecture

Figure 5.2.1.1-1: Option 1 for NR Femto Architecture
(⇒ copy of original 3GPP image)

5.2.1.2 Option 2 p. 17

Figure 5.2.1.2-1 shows a logical architecture for the NR Femto that has a set of NG interfaces to connect the NR Femto node to the 5GC.

Copy of original 3GPP image for 3GPP TS 38.799, Fig. 5.2.1.2-1: Option 2 for NR Femto Architecture

Figure 5.2.1.2-1: Option 2 for NR Femto Architecture
(⇒ copy of original 3GPP image)

The NG-RAN architecture may deploy an NR Femto Gateway (NR Femto GW) to allow the NG interface between the NR Femto node and the 5GC to support a large number of NR Femto nodes in a scalable manner. The NR Femto GW serves as a concentrator for the C-Plane, specifically the NG-C interface.

The NG interface is defined as the interface:

Between the NR Femto GW and the 5GC;
Between the NR Femto node and the NR Femto GW;
Between the NR Femto node and the 5GC;

The NR Femto GW appears to the AMF as a gNB. The NR Femto GW appears to the NR Femto node as an AMF. The NG interface between the NR Femto node and the 5GC is the same regardless of whether the NR Femto node is connected to the 5GC via an NR Femto GW or not.

5.2.1.3 Option 3 p. 18

An SCTP concentrator acts as an IP proxy between an NR Femto node and the AMF. It addresses the issue of reducing the number of SCTP connections toward the 5GC by leaving the NGAP layer untouched and by concentrating the SCTP layer. The SCTP concentrator is part of the transport layer, and it is transparent to the application layer. This solution was studied for E-UTRAN and is described in detail in TR 37.803.

Copy of original 3GPP image for 3GPP TS 38.799, Fig. 5.2.1.3-1: Option 3 for NR Femto Architecture.

Figure 5.2.1.3-1: Option 3 for NR Femto Architecture.
(⇒ copy of original 3GPP image)

A single SCTP association per NG-C interface instance is used with one pair of stream identifiers for NG-C common procedures. An SCTP concentrator terminates the lower layers so that the AMF does not need to be aware that several peers, with which it maintains NG interfaces, are actually behind the concentrator.

The key characteristics are:

There is a single NGAP association (application layer) between the AMF and each NR Femto node.
There is a single SCTP association (transport layer) between the AMF and the SCTP concentrator.
There is a single SCTP association (transport layer) between the SCTP concentrator and each NR Femto node connected to it.
The SCTP concentrator does not touch the application layer and transports it transparently.
For each NR Femto node, the SCTP concentrator maps the NGAP signaling on the appropriate SCTP association, "switching" between the various SCTP streams from the NG interface between itself and the AMF.
The SCTP concentrator can also act as a "smart NAT", in case the NR Femto nodes are assigned private IP addresses.

Point 5 above descends from the multi-streaming capabilities of SCTP. The AMF can map NGAP signaling for different NR Femto nodes on different streams over the same SCTP association. The concentrator receives the messages, terminates the SCTP connection, and maps each message on a new SCTP association toward the appropriate NR Femto node according to the stream number used. Since there can be up to 65535 streams in an SCTP association, in principle it is possible to address a large number of NR Femto nodes from the same AMF through the same SCTP concentrator. The SCTP concentrator handles the appropriate switching between each stream number on the SCTP concentrator-AMF association and each NR Femto node-SCTP concentrator association (see Figure 5.2.1.3-1). This functionality is completely contained in the SCTP concentrator and only requires that the AMF and NR Femto nodes map NGAP signaling to different peers, on different SCTP stream identifiers.

5.2.1.4 Option 4 p. 19

In this option, the NR Femto node is a gNB-DU as defined in TS 38.401. The gNB-CU is used as the concentration node for connecting the NR Femto nodes to 5GC on both control plane and user plane.

Copy of original 3GPP image for 3GPP TS 38.799, Fig. 5.2.1.4-1: Option 4 for NR Femto Architecture

Figure 5.2.1.4-1: Option 4 for NR Femto Architecture
(⇒ copy of original 3GPP image)

5.2.2 Architecture Options for Xn interface p. 19

5.2.2.1 Option A for Xn support without Xn GW p. 19

As shown in Figure 5.2.2.1-1, in this option the NR Femto Node connects to the other NR Femto Node(s)/gNB(s) directly as a gNB by means of the Xn interface.

Copy of original 3GPP image for 3GPP TS 38.799, Fig. 5.2.2.1-1: OptionA Xn interface Architecture for NR Femto

Figure 5.2.2.1-1: OptionA Xn interface Architecture for NR Femto
(⇒ copy of original 3GPP image)

5.2.2.2 Option B for Xn support via Xn GW p. 20

As shown in Figure 5.2.2.2-1, the logical architecture for NR Femto node when Xn connectivity via the Xn GW is supported.

Copy of original 3GPP image for 3GPP TS 38.799, Fig. 5.2.2.2-1: NR Femto operating with Xn GW - Logical Architecture

Figure 5.2.2.2-1: NR Femto operating with Xn GW - Logical Architecture
(⇒ copy of original 3GPP image)

Support for the Xn GW relies on following principles:

A NR Femto node connects to a single Xn GW only. Each NR Femto node is preconfigured with information about which Xn GW it connects to, e.g. an IP address of the Xn GW.
There is no limitation on the number of Xn GWs a gNB may connect to.
Interface between two Xn GWs is not supported. The routing of XnAP messages via more than one Xn GW (i.e. more than two SCTP hops) is not allowed.
XnAP contexts only exist in the two peer NR Femto nodes or in the NR Femto node and its peer gNB (same as without Xn GW). The peer XnAP contexts define an "XnAP association" between peer NR Femto nodes or between the NR Femto node and its peer gNB which spans over two SCTP associations (one per each hop).
The Xn GW puts no constraints on the Xn user plane interface (Xn-U).
For each NR Femto node or gNB connected to the Xn GW, the Xn GW maintains the association information, i.e. the mapping of the Global gNB ID to the TNL address(es).

5.2.3 Evaluation of Architecture options for the NG interface p. 20

Option 1: direct connection of NR Femto to 5GC

Pros:

Already supported by current architecture.
Less CP latency and no processing delay due to absence of a concentration stage.
Suitable for certain deployments depending on number of NR Femtos to connect and/or virtualization support of the 5GC.
Local breakout can be supported.

Cons:

Not suitable for certain deployments with large number of NR Femtos and/or 5GC not virtualized.
Not suitable for residential deployments with frequent switch on/off of NR Femtos.

Option 2: NR Femto GW

Pros:

Only one SCTP association from 5GC to NR Femto GW, so it can support large number of femtos and/or no virtualization of 5GC.
5GC is shielded from frequent switch on/off of the NR Femtos.
Enables operators who have already deployed 4G Femtos using HeNB GW to capitalize on operating model and integration process of 5G Femtos.
Foreseen specification impacts are already well known from 4G.
Allows to decouple concentration of CP and concentration of UP: concentration of UP is optional i.e. the NR Femto GW can concentrate CP only while the NR Femto connects directly to the UPF.
Local breakout can be supported.

Cons:

Some stage3 specification impact.
Some processing delay for CP message.

Option 3: SCTP concentrator

Pros:

Only one SCTP association from 5GC to SCTP concentrator due to using multi-streaming.
Local breakout can be supported.
Only stage2 specification impact.

Cons:

The solution requires consistent configuration and handling of SCTP stream identifiers.
The solution requires consistent SCTP implementation of AMF, SCTP concentrators and NR Femtos.
Some processing delay for CP message.
Does not provide an evolution path for operators that have already deployed a HeNB GW for E-UTRAN.

Option 4: NR Femto as a gNB-DU

Pros:

Reuse existing split gNB architecture.

Cons:

F1-C was not designed to face frequent switch on/off. Usually F1-C is operated by the network operator and statically configured.
Foreseen additional interoperability issue of F1 compared to NG.
F1-C carried over internet backhaul can lead to latency and reliability issue not meeting the stringent requirement for F1-C interface.
This option forces the concentration of User Plane and not only control plane i.e. concentration of CP only while NR Femto UP connects directly to UPF is not possible.
Does not provide an evolution path for operators that have already deployed a HeNB GW for E-UTRAN.
Specification impact for F1 needs to be further assessed.
Local breakout requires collocation of NR Femto with CU UP.

5.2.4 Evaluation of Architecture options for the Xn interface p. 22

Following Table concludes the comparison of the two Xn interface options.

Table 5.2.4-1: Evaluation of Architecture options for the Xn interface

Option	Pros	Cons
A	Already supported by current architecture. Less CP latency and no processing delay due to absence of a concentration stage.
B	Can support large number of Xn connections for one NR Femto node. Enables operators who have already deployed HeNBs using X2 GW to capitalize on operating model and integration process of 5G Femto nodes. Foreseen specification impacts are already well known from 4G.	Some stage3 specification impacts. Some processing delay for CP message. Hard to select an optimal deployment location of the Xn GW.

5.3 Access control p. 22

With the existing CAG mechanism, the open, hybrid and closed access mode, can be supported as follows:

To support the open access mode: The NR Femto node activates a PLMN cell, which can be accessed by legacy UE without access control of CAG.
To support the hybrid access mode: The NR Femto activates a cell shared by both PLMN and CAG, through broadcasting both the plmn-IdentityInfoList and the npn-IdentityInfoList-r16 in the SIB1, but without the cellReservedForOtherUse. Then, this cell is accessible to UEs which have the allowed CAG list including a CAG-ID broadcasted by the cell. For the legacy UE not supporting CAG, this cell is viewed as a normal PLMN cell.
To support the closed access mode: The NR Femto node activates an NPN-only cell by broadcasting the cellReservedForOtherUse IE with value "true", then this cell can only be accessed by the UEs whose allowed CAG list includes a CAG-ID broadcasted by the cell.

5.4 Local services access p. 23

In order to support access to local services, NR Femto nodes reuse LADN and edge computing functionality as specified in TS 23.501 and TS 23.548.

The local UPF may be either stand-alone or co-located with the NR Femto node.

The following aspects, out of RAN3 scope, have been identified and may require further analysis:

Aspect #1:

Scalability of local UPF discovery e.g. when using mobile edge computing solutions,

Aspect #2:

N4 interface switch-on/off,

Aspect #3:

N4 interface aggregation.