Content for TR 38.799 Word version: 19.0.0
6 Conclusions
6.1 Conclusion and Recommendation for WAB
6.2 Conclusion and Recommendation for NR Femto
6.2.1 Architecture for NG interface
6.2.2 Architecture for Xn interface
6.2.3 Access Control
6.2.4 Access to Local Services
$ Change history
6 Conclusions p. 23
6.1 Conclusion and Recommendation for WAB p. 23
RAN3 confirms the feasibility of WAB functionality and recommends that a normative phase for WAB is pursued. The conclusions of the WAB part of the SI are as follows:
- The normative work for WAB should be based on the functionalities, terminology and requirements captured in the present TR. Addition of further details during normative phase is not precluded.
-
The normative work should consider the following architectural aspects for WAB according to the present TR:
- Backhauling of the WAB-gNB's NG, Xn and OAM traffic is conducted over the WAB-MT's PDU session(s).
- WAB-gNBs can establish Xn interface(s) with the WAB-MT's serving BH RAN node and with other surrounding gNBs.
- The interface between the WAB-MT and the co-located WAB-gNB is out-of-scope for the normative phase.
- Split architecture of the WAB-gNB is out-of-scope for the normative phase.
- Authorization procedures for the WAB-MT are out of RAN3 scope, and are expected to be handled by SA2. RAN3 should define the WAB-node behaviour in case the authorization status of the WAB-MT and/or WAB-gNB changes.
- The normative phase should define the integration procedure for WAB nodes following the description in the present TR.
- Mobility procedures to be used for the UEs served by a WAB-gNB are legacy UE mobility procedures. Mobility of the WAB-MTs is based on legacy UE mobility procedures.
- During the normative phase, handling of WAB-gNB's traffic (including Xn, NG and OAM traffic) during WAB-node mobility should be defined, including the case where the WAB-MT's BH PDU session changes.
-
During the normative phase, the procedure to support the UE's AMF change for UEs connected to, or camped on, a WAB-gNB, should be defined in cooperation with SA2.
- Solutions for mobility will be further analysed during normative phase.
- RAN3 concludes that the two-logical-gNB solution is feasible.
- It remains to be verified, based on feedback from SA2 and, potentially, RAN2 if needed, whether the single-gNB solution is feasible and whether enhancements are needed.
- During the normative phase, enhancements to the UE's ULI that reflect the WAB node's location should be defined.
-
During the normative phase, the handling of the following should be discussed and captured:
- PCI collision.
- Reconfiguration of TAC and RANAC on WAB-gNBs.
- Avoidance of multi-hop WAB topology.
- Radio-resource coordination between access and backhaul links.
-
The normative phase may further discuss the following:
- Handling of backhaul link degradation by the backhaul network and the WAB-gNB.
- Xn connection management (e.g., potential avoidance of setting up Xn between WAB-gNBs, dynamic establishment/removal of Xn connectivity with BH-RAN-node and surrounding NG-RAN-nodes).
- NG connection management (e.g., procedures for NG connection removal/suspension).
- QoS (e.g., PDB, PER).
- Handling of RRC_INACTIVE UEs.
6.2 Conclusion and Recommendation for NR Femto p. 24
6.2.1 Architecture for NG interface p. 24
Option 1, namely direct connection of an NR Femto node to the 5GC via the NG interface, is already possible.
In order to maintain the existing infrastructure for an operator who has deployed LTE HeNBs, Option 2 with an optional NR Femto GW is recommended for a normative phase.
6.2.2 Architecture for Xn interface p. 24
Option A, namely direct connection of an NR Femto node to other NR Femto nodes / gNBs via the Xn interface, is already possible.
6.2.3 Access Control p. 24
For Access control, NR Femto reuses the existing CAG functionalities, no stage3 impact has been identified.
6.2.4 Access to Local Services p. 24
$ Change history p. 25
