The most relevant scenarios in regard to gNB-CU-CP are those that will incur a failure of the entire gNB-CU-CP. Such cases would affect all the existing UE contexts under the gNB-CU-CP where the failure occurred. Likewise, the disaggregated gNB architecture allows for very large configurations. A given gNB-CU-CP can host 512 gNB-DUs, and a total of 16,384 cells with existing specifications. Furthermore, each cell may be serving hundreds of UEs Therefore, a gNB-CU-CP failure can incur a very high impact in service availability and user experience for a very large number of UEs. Further, these failure scenarios can incur further problems by generating very high signalling loads from e.g., re-establishment of connections and signalling interfaces. In contrast issues affecting only limited portions of the gNB-CU-CP, for example, trouble incurred from individual hardware blades in a virtualized environment, are not the focus of this study.

In the legacy network architecture, a gNB-CU-DU is only connected to one gNB-CU-CP. With the increasing number of connected gNB-CU-UP and gNB-DU, gNB-CU-CP will be in the risk of failure caused by the large amount of signalling processing. So this SI will introduce a mechanism to allow the gNB-CU-UP and gNB-DU to recovery service. Higher-layer split between gNB-CU and gNB-DU would enable highly-centralized gNB-CU deployment with large coverage area per gNB-CU, especially from C-Plane perspective. Likewise, Higher-layer split between gNB-CU-CP and gNB-CU-UP would enable highly-centralized gNB-CU-CP deployment with large coverage area per gNB-CU-CP. As described in the draft SID, such a centralized gNB-CU(-CP) would be a single point of failure. Hence the resiliency of the gNB-CU(-CP) is highly important. Given the limited time allocated for gNB-CU resiliency, only gNB-CU-CP resiliency should be considered in this release, other network nod, e.g. AMF, gNB CU(non-split CU architecture) should not be considered in this release if time not allowed. Failure condition: Failure condition is the trigger of gNB-CU-CP resiliency. If a network node is considered a failure when it is crashed completely, then it would be too late to recovery. The network should have scheme to switch part or all of the services/connections to another resilient network node to offload before it completely crashes down. The decision of offloading the service/connection can be either of the below:

1. Up to the implantation of gNB-CU-CP
2. The configured threshold from OAM

Both options work and has no impact to RAN3. So the failure condition can be left to network implementation. In addition, if any of the adjacent nodes of gNB-CU-CP, e.g. AMF, gNB-CU-CP and gNB-DU lost the connection to gNB-CU-CP, due to an unexpected gNB-CU-CP failure, adjacent node should be able to activate the resilient gNB-CU-CP automatically.

The most critical cases are failures that may happen if a gNB-CU-CP is deployed in a central office location with responsibility for a high number of gNB-DUs and therefore of cells. There are different failure scenarios that may happen in such a deployment scenario:

1. SW or HW failure in a PNF-based implementation;
2. VNF (SW) or GPP (HW) failure in a virtualized environment (e.g. cloud-based implementation);
3. Failures of NW connections, e.g., TN or server NW card failures;
4. Total failure of central location, e.g., caused by a power shutdown or a disaster case.

For failure scenarios (1) and (2) the gNB-CU(-CP) functionality can be recovered by taking local redundancy in the same central location into account (e.g., based on usage of spare HW (PNF/GPP) for redundancy purposes). A slow recovery can be initiated via OAM orchestrating a new gNB-CU(-CP) instance on the spare HW (e.g., in combination with cloud-based mechanisms in a virtualized environment). A fast recovery approach to bring the outage time down would require active/stand-by operation of a mirror gNB-CU-CP instance in parallel which may be realized in a local environment by appropriate implementation (incl. also cloud-based mechanism in case of virtualization). Slow recovery may also work in case of failure scenarios (3) and (4) using a second central location for orchestrating a new gNB-CU-CP instance via OAM, but the critical and more important issue from an operator's perspective is fast recovery in the geo-redundant case as 3GPP specifications do not provide suitable support for it. Therefore, the failure case where a benefit of a resiliency enhancement in 3GPP specifications is seen would be:

• Outage of gNB-CU(-CP) when deployed in a central location without sufficient local redundancy, but availability of geo-redundancy (SW/HW) is given and fast recovery of gNB-CU(-CP) functionality is required by the operator.

If a gNB-CU-CP fails, the network support for the NR cells is lost and UEs cannot communicate. More specifically, the following can be observed:

• CP signaling redundancy is possible in RAN, but still only one RRC-anchor (gNB-CU-CP) is defined:
  • SRB duplication is possible in DC (PDCP duplicates RRC messages, which are sent via different carriers to/from UE), but losing the main connection to the UE still means CP failure
  • RLF handling:
    • Rel-15: if SCG connection fails, inform the network; if MCG fails, the connection is lost
    • Rel-16: if SCG/MCG connection fails, inform the network via MCG/SCG. There will be MCG/SCG UP downtime due to DRBs suspension.
• CP failure leading to UP failure (UP failure, leading to service interruption time, is probably the most important KPI associated with a CU-CP failure):
  • Generally, an absence of RRC messages is not noted by the UE, so the UE does not know that the CP has failed
    • RRC timer expiry procedures in RRC work as long as RRC connectivity is up. In some cases DRBs suspension is caused by the expiration of timers
  • If the gNB-CU-CP goes down, CP connectivity is not re-established automatically until the failure is detected
  • UP connection could be lost if RRC reconfiguration (critical to maintain UP) is not possible
    • e.g. Handover required; bearer reconfiguration required; meet QoS or other RAN reconfiguration required

There is always a single RRC anchor even for the case of DC; furthermore, there is currently no way for the UE to detect a gNB(-CU(-CP)) failure. A CU-CP failure is essentially a node internal failure (i.e. it may not be the whole logical node that fails).