Managing central unit failure

Abstract

Various example embodiments relate to apparatuses and methods relating to user equipment state transitions, such as for preventing user equipment in a radio access network from transitioning to a radio resource control idle mode during a failure of a central unit in a split radio access network architecture. A user equipment may receive a central unit failure indication from a distributed unit in a radio access network, the central unit failure indication indicating a failure of a first central unit in the radio access network associated with the distributed unit, and preventing the user equipment from transitioning to the radio resource control idle mode during the failure of the first central unit.

Description

Technical Field

[0001] Various example embodiments described herein relate generally to communication technology, and more particularly to apparatus and methods regarding user equipment (UE) state transitions, such as for preventing the UE from transitioning to a radio resource control (RRC) idle mode during a failure of a central unit (CU) in a split radio access network (RAN) architecture. Background Art

[0002] Certain abbreviations that may appear in the specification and / or drawings are defined as follows:

[0003] AMF: Access and Mobility Management Function

[0004] CN: Core Network

[0005] CP: Control plane

[0006] CU: Central Unit

[0007] DL: Downlink

[0008] DU: Distributed Unit

[0009] E1: Interface between CU-CP and CU-UP

[0010] F1: Interface between CU and DU

[0011] F1-C: F1 control surface

[0012] F1-U: F1 user plane

[0013] gNB: Next Generation Node-B

[0014] NG-RAN: Next Generation Radio Access Network

[0015] OAM: Operations Administration and Maintenance

[0016] PDCP: Packet Data Convergence Protocol

[0017] PDU: Protocol Data Unit

[0018] RLF: Radio Link Failure

[0019] RRC: Radio Resource Control

[0020] SDAP: Service Data Adaptation Protocol

[0021] SRB: Signalling Radio Bearer

[0022] UE: User Equipment

[0023] UL: Uplink

[0024] UP: User plane

[0025] Xn: Interface between NG-RAN nodes

[0026] The next generation radio access network (NG-RAN) may have a split architecture, where a next generation Node B (gNB) includes a central unit (CU) and one or more distributed units (DU). A gNB-DU is connected to only one gNB-CU, while a gNB-CU may be connected to one or more gNB-DUs. Each gNB-DU may support one or more cells. The split architecture allows for flexible hardware implementation to accommodate different use cases, and it may reduce the overall cost of the network. Summary of the invention

[0027] A brief summary of example embodiments is provided below to provide a basic understanding of some aspects of various embodiments. It should be noted that this summary is not intended to identify key features of basic elements or define the scope of the embodiments, and its sole purpose is to introduce some concepts in a simplified form as a prelude to the more detailed description provided below.

[0028] In a first aspect, an example embodiment of a user equipment in a radio access network is provided. The user equipment may include: at least one processor; and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the user equipment to at least: receive a central unit failure indication from a distributed unit in the radio access network, the central unit failure indication indicating a failure of a first central unit in the radio access network associated with the distributed unit, and prevent the user equipment from transitioning to a radio resource control idle mode during the failure of the first central unit.

[0029] In a second aspect, an example embodiment of a distributed unit in a radio access network is provided. The distributed unit may include: at least one processor; and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the distributed unit to at least: start buffering radio resource control messages received from one or more user equipment in the radio access network when the distributed unit determines a failure of a first central unit in the radio access network, the first central unit being active and associated with the distributed unit, and send a central unit failure indication indicating the failure of the first central unit to the one or more user equipment.

[0030] In a third aspect, an example embodiment of a second central unit in a radio access network is provided. The second central unit may include: at least one processor; and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the second central unit to at least: send a backup central unit activation indication to a distributed unit in the radio access network, the backup central unit activation indication indicating that the second central unit is to be activated to replace a first central unit in the radio access network, the first central unit being active and associated with the distributed unit.

[0031] Example embodiments of methods, apparatus, and computer program products are also provided. Such example embodiments generally correspond to the example embodiments described above, and for convenience, repeated descriptions thereof are omitted here.

[0032] Other features and advantages of example embodiments of the present disclosure will also be apparent from the following description of specific embodiments when read in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of example embodiments of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Some example embodiments will now be described, by way of non-limiting examples, with reference to the accompanying drawings.

[0034] Figure 1 is a schematic block diagram illustrating a split architecture of the next generation Node-B.

[0035] Figure 2 is a schematic message sequence chart illustrating the loss of Radio Resource Control (RRC) messages due to a central unit failure.

[0036] Figure 3 is a schematic message sequence chart illustrating a process according to an example embodiment of the present disclosure.

[0037] Figure 4 is a schematic message sequence chart illustrating a process according to an example embodiment of the present disclosure.

[0038] Figure 5 is a schematic flow chart illustrating a process according to an example embodiment of the present disclosure.

[0039] Figure 6 is a schematic functional block diagram illustrating an apparatus according to an example embodiment of the present disclosure.

[0040] Figure 7 is a schematic functional block diagram illustrating an apparatus according to an example embodiment of the present disclosure.

[0041] Figure 8 is a schematic functional block diagram illustrating an apparatus according to an example embodiment of the present disclosure.

[0042] Fig. 9 is a schematic structural block diagram illustrating devices in a communication system in which example embodiments of the present disclosure may be implemented.

[0043] Throughout the drawings, the same or similar reference numerals denote the same or similar elements, and repeated description of the same elements will be omitted. DETAILED DESCRIPTION

[0044] Below, some example embodiments are described in detail with reference to the accompanying drawings. The following description includes specific details, which are intended to provide a thorough understanding of various concepts. However, it will be appreciated by those skilled in the art that these concepts can be practiced without these specific details. In some cases, well-known circuits, technologies, and components are shown in block diagram form to avoid obscuring the concepts and features described.

[0045] As used herein, the term "network equipment" refers to any suitable equipment or entity that can provide a cell or coverage, through which a terminal device can access a network or receive a service. Network equipment can generally be referred to as a base transceiver station (BTS), a base station (BS), or some other suitable term. The term "base station" or "base transceiver station" used herein can represent a node B (NodeB or NB), an evolved node B (eNodeB or eNB), a next generation node B (gNB), or a next generation enhanced node B (ng-eNB). The base station can be embodied as a macro base station, a relay node, or a low power node (such as a micro base station or a femto base station). The base station may also include or may be referred to as a RAN (radio access network) node, and may be composed of several distributed network units, such as a central unit (CU), one or more distributed units (DU), one or more remote radio heads (RRHs) or remote radio units (RRUs). The number and function of these distributed units depend on the selected split RAN architecture.

[0046] As used herein, the term "terminal device" or "user equipment" (UE) refers to any device or entity that can communicate wirelessly with network devices or each other. Examples of terminal devices may include mobile phones, mobile terminals, mobile stations (MS), subscriber stations, portable subscriber stations, access terminals, personal digital assistants (PDAs), computers, wearable devices, vehicle-mounted communication devices, machine type communication (MTC) devices, D2D communication devices, V2X communication devices, sensors, etc. The term "terminal device" may be used interchangeably with UE, user terminal, mobile terminal, mobile station, or wireless device.

[0047] Figure 1The split architecture of the next generation Node B (gNB) 110 is illustrated, through which some example embodiments of the present disclosure may be implemented. It should be understood that the gNB 110 is shown as an example, and the split architecture may also be applied to other base stations, such as eNB, ng-eNB, super 5G base station, 6G base station, or future base station.

[0048] like Figure 1 As shown in , the gNB 110 may include: a central unit (CU) 112, and one or more distributed units (DU) 114 (two DUs 114a, 114b are shown as examples). The CU 112 may be separated into a control plane (CP) 112-1 and multiple user planes (UP) 112-2. The gNB-CU-CP 112-1 is a logical node that hosts the control plane portion of the radio resource control (RRC) protocol and the packet data convergence protocol (PDCP) of the gNB 110, and the gNB-CU-UP 112-2 is a logical node that hosts the user plane portion of the PDCP protocol and the service data adaptation protocol (SDAP) of the gNB 110. The gNB-DU 114 is a logical node that hosts the radio link control (RLC), media access control (MAC), and physical (PHY) layers of the gNB 110, and its operation is partially controlled by the gNB-CU 112. The gNB-CU-UP 112-2 is connected to the gNB-CU-CP 112-1 through an E1 interface, and the gNB-DU 114 is connected to the gNB-CU-CP 112-1 through an F1-C interface, and is connected to the gNB-CU-UP 112-2 through an F1-U interface. One gNB-CU-UP 112-2 is connected to only one gNB-CU-CP 112-1, and one gNB-DU 114 is connected to only one gNB-CU-CP 112-1. Each gNB-DU 114 may support one or more cells.

[0049] like Figure 1As shown in , since the gNB-CU-CP 112-1 controls multiple gNB-DUs 114, each of which supports one or more cells, the resilience of the gNB-CU-CP 112-1 is critical to providing service continuity and avoiding downtime. If a gNB-CU-CP 112-1 fails, it will take a long time to establish a new F1 interface from scratch, which will result in a lot of downtime before a large number of UEs are released and the system is restored. The 3GPP specification does not exclude the gNB-DU 114 from being connected to more than one gNB-CU 112 to achieve resilience, but it violates the current cardinality rules of the RAN architecture and will cause other problems. For example, radio resource management (RRM) performed by multiple gNB-CU-CPs 112-1 will lead to resource fragmentation and new coordination overhead between gNB-CU-CPs.

[0050] Another option is to deploy a standby gNB-CU to achieve geographic redundancy resilience, and the standby gNB-CU can be activated when the current active gNB-CU-CP112-1 fails. However, the failure detection of the active gNB-CU and the activation of the standby gNB-CU are also a rather long process, as it is usually associated with a long failure detection timer (to avoid false detection) and gNB-CU activation time. Standby gNB-CU activation also involves additional time because all gNB-DUs served by the active gNB-CU need to be notified of the activation of the standby gNB-CU. Due to various reasons, the long time between the failure of the active gNB-CU and the completion of the activation of the standby gNB-CU may cause a radio link failure (RLF) of the UE. For example, when the UE sends an uplink (UE) RRC message to the network but fails to receive any response from the network, the UE can declare RLF and transition to radio resource control (RRC) idle mode. For another example, if the mobile UE fails to receive an RRC reconfiguration message when a handover command should be received, the mobile UE will also declare RLF and transition to RRC idle mode. On the network side, failure of the active gNB-CU can result in multiple UEs performing random access simultaneously after declaring RLF, which is not a preferred scenario. Bursts are impactful and resource allocation and processing becomes an extremely complex task in a split gNB, especially when the split gNB includes a large number of DUs.

[0051] Figure 2 is a schematic message sequence diagram illustrating the loss of RRC messages due to gNB-CU failure. Figure 2 As shown in FIG, in addition to the active gNB-CU 112, a standby gNB-CU 116 is provided. When the active gNB-CU 112 fails, the standby gNB-CU 116 will be activated and take over the role of the active gNB-CU 112.

[0052] At T0, the active gNB-CU 112 and the standby gNB-CU 116 may synchronize data with each other. For example, UE context information and operation administration and maintenance (OAM) configuration information may be synchronized between the active gNB-CU 112 and the standby gNB-CU 116.

[0053] At T1, the active gNB-CU 112 may experience an unexpected failure, but the gNB-DU 114 associated with the gNB-CU 112 may not be immediately aware of the failure of the gNB-CU 112.

[0054] At T2, UE 120 may send an UL signaling message (i.e., an RRC message) for a signaling radio bearer (SRB) to gNB-DU 114 via a PDCP control plane PDU.

[0055] At T3, since the gNB-DU 114 is unaware that the gNB-CU 112 has failed, the gNB-DU 114 may send an RRC message to the gNB-CU 112 as usual, but the failed gNB-CU 112 cannot receive the RRC message or synchronize the RRC message to the standby gNB-CU 116.

[0056] At T4, the gNB-DU 114 may become aware of the gNB-CU failure, for example, through failure detection or notification received from the network.

[0057] At T5, the standby gNB-CU 116 may be activated and associated with the gNB-DU 114. Thereafter, the newly activated gNB-CU 116 takes over the role of the failed gNB-CU 112, and the gNB-DU 114 may send an RRC message to the gNB-CU 116.

[0058] However, the RRC message sent to the gNB-DU 114 at T2 is lost at the gNB-DU 114 because it is delivered neither to the failed gNB-CU 112 nor to the standby gNB-CU 116. When the standby gNB-CU 116 becomes active, it will not receive the lost RRC message because the gNB-DU 114 does not perform retransmission of the message. It may happen that the RRC message from the UE 120 is an important message such as an RRC Reconfiguration Complete message, and the non-reception of the RRC Reconfiguration Complete message may be regarded as an RRC reconfiguration failure, which will result in an RRC reestablishment procedure. In addition, in the PDCP control layer at the gNB-CU-CP, a hole is created in the PDCP reception sequence due to the RRC message loss, so the receiving entity has to wait until the t-Reordering timer expires, which increases the signaling processing time and reduces the efficiency of the network.

[0059] Hereinafter, example embodiments of an apparatus, method, and computer program product for preventing one or more UEs from transitioning to RRC idle mode during a failure of an active gNB-CU will be described in detail with reference to the accompanying drawings. In some example embodiments, when a UE is informed of a failure of an active gNB-CU, the UE may be configured to prevent transitioning to RRC idle mode by suspending transmission to the active gNB-CU via a signaling radio bearer and / or extending a timer (if it is running or active). This may reduce ineffective operations at the UE during a gNB-CU failure and save power consumption of the UE. In addition, a burst of multiple UEs performing random access procedures simultaneously after entering RRC idle mode may be avoided. In some example embodiments, a gNB-DU may buffer RRC messages received from a UE during a failure of an active gNB-CU and, upon being notified that a standby gNB-CU has been successfully activated, send the buffered RRC messages to the newly activated gNB-CU (i.e., the standby gNB-CU). This may reduce or avoid uplink RRC message loss during a gNB-CU failure.

[0060] Figure 3is a schematic message sequence chart illustrating a process 200 according to an example embodiment of the present disclosure. The process 200 may be performed, for example, at a standby gNB-CU 116, a currently active gNB-CU 112, one or more gNB-DUs 114 associated with the active gNB-CU 112, and one or more UEs 120 served by each of the one or more gNB-DUs 114. For ease of description, only one UE 120 and one gNB-DU 114 are discussed below. The UE 120, the gNB-DU 114, the active gNB-CU 112, and the standby gNB-CU 116 may each include a plurality of parts, modules, components, or elements for performing the operations in the process 200, and these parts, modules, components, or elements may be implemented in various ways, including but not limited to software, hardware, firmware, or any combination thereof. In Figure 3 In the process 200 shown in FIG. 2 , operations represented by dashed lines may be optionally or selectively performed in some example embodiments, or may be omitted in other example embodiments.

[0061] refer to Figure 3 At 210, the active gNB-CU 112 may synchronize data with a standby gNB-CU 116, which is provided as a backup for the active gNB-CU 112. If the active gNB-CU 112 fails, the standby gNB-CU 116 may be activated and take over the role of the active gNB-CU 112. The standby gNB-CU 116 may periodically obtain synchronization data from the active gNB-CU 112 so that when the active gNB-CU 112 fails, the standby gNB-CU 116 may replace the active gNB-CU 112 to serve the gNB-DU 114 and the UE 120. For example, UE context information, operation administration and maintenance (OAM) configuration information, etc. may be synchronized between the active gNB-CU 112 and the standby gNB-CU 116.

[0062] At 212, the active gNB-CU 112 may send a precoded RRC message to the gNB-DU 114. The precoded RRC message may be sent to the gNB-DU 114 via an F1 Application Protocol (F1AP) message (e.g., a gNB-CU Configuration Update message). In other example embodiments, the precoded RRC message may be sent to the gNB-DU 114 from an operations administration and maintenance (OAM) function (not shown). In the event that the active gNB-CU 112 fails, the precoded RRC message may be encoded to be sent to the UE 120. For example, the precoded RRC message may include a CU failure indication to be sent to the UE 120, which will be discussed in detail later.

[0063] At this point, it is assumed that active gNB-CU 112 is functioning well. For example, when UE 120 sends an RRC message (e.g., RRC message 1) to gNB-DU 114 at 214, gNB-DU 114 may successfully forward the RRC message to active gNB-CU 112 at 216. In some example embodiments, active gNB-CU 112 may also synchronize the RRC message received at 216 to standby gNB-CU 116.

[0064] At 218, the active gNB-CU 112 may determine that there is a certain probability that the active gNB-CU 112 will fail. For example, the active gNB-CU 112 may determine the probability of a failure by running an internal fault detection algorithm or based on a fault indication received from another network node or function (e.g., from an OAM function), such as via a Management Data Analysis Service (MDAS, also referred to as MDA MnS), or an Open RAN (O-RAN) near real-time RAN Intelligent Controller (RIC), or an O-RAN non-real-time RIC or RAN Data Analysis Function (DAF), or a core network data analysis function, such as a network DAF (NWDAF).

[0065] At 220, in response to the possibility of a failure, the active gNB-CU 112 may send a standby CU activation request to the standby gNB-CU 116 to trigger activation of the standby gNB-CU 116. Figure 3 Not shown, the standby gNB-CU 116 may respond to the active gNB-CU 112 with a confirmation message confirming receipt and acceptance of the activation request.

[0066] At 222, the active gNB-CU 112 may notify the gNB-DU 114 that the standby gNB-CU 116 will be activated to replace the active gNB-CU 112 by sending a standby CU activation indication to the gNB-DU 114. The standby CU activation indication may include information (e.g., IDs or addresses) of the active gNB-CU 112 and the standby gNB-CU 116, and information of the duration for which the standby gNB-CU 116 will become active and take over the role of the gNB-CU 112. The duration may be based on a recovery time estimate, or a previous failure recovery time. In an example embodiment, the duration may have a predefined value preconfigured at the gNB-DU 114 and may be omitted in the standby CU activation indication. Based on the standby CU activation indication, the gNB-DU 114 may determine that the active gNB-CU 112 will fail soon, and the gNB-DU 114 may start buffering uplink RRC messages received from the UE to avoid RRC message loss due to the failure of the active gNB-CU 112.

[0067] In an example embodiment, the standby CU activation indication may also include an indication for extending a timer for a UE-associated procedure, and / or an indication for preventing initiation of a new procedure (e.g., a RAN3 (RAN Working Group 3) procedure) or a retry of an existing procedure during the duration. In response to these indications, the gNB-DU 114 may extend the timer for the UE-associated procedure by adding a duration to the timer or restarting the timer. The duration added to the timer may depend on the duration of the failure indicated in the standby CU activation indication. The gNB-DU 114 may also prevent initiation of a new procedure (e.g., a RAN3 procedure) or a retry of an existing procedure until the standby gNB-CU 116 is activated.

[0068] In an example embodiment, the standby CU activation indication may also include a list of RRC messages received at the active gNB-CU 112. In another example embodiment, the gNB-CU 112 may send the list of RRC messages received at the active gNB-CU 112 to the gNB-DU 114 via a separate RRC confirmation message (other than the standby CU activation indication). From the list of received RRC messages, the gNB-DU 114 may realize which RRC messages have been successfully received at the active gNB-CU 112 and which RRC messages have not been received at the active gNB-CU 112. This may help the gNB-DU 114 to check whether an uplink RRC message is not delivered to the active gNB-CU 112. If an uplink RRC message is lost, the gNB-DU 114 may instruct the UE that has sent the lost RRC message to resend the RRC message.

[0069] In an example embodiment, the active gNB-CU 112 may also send a standby CU activation indication to an access and mobility management function (AMF), a neighboring RAN node (e.g., a neighboring base station), a CU user plane associated with the gNB-DU 114, and other network nodes or functions that have a direct interface with the active gNB-CU 112. For example, if the active gNB-CU 112 sends a handover request to a target gNB (not shown) during a handover procedure, and then the gNB-CU fails before the gNB-CU 112 receives a handover confirmation message from the target gNB, the target gNB will continue to retry at the Stream Control Transmission Protocol (SCTP) level to send a handover confirmation message to the failed gNB-CU 112, even without an Xn level retry. In an example embodiment, the gNB-CU 112 may also send a standby CU activation indication to the target gNB before the gNB-CU 112 fails, and the target gNB will not initiate transmission or retransmission of the handover confirmation message until the standby gNB-CU 116 is activated and replaces the active gNB-CU 112. The target gNB may restart the timers associated with the gNB-CU 112 and not initiate any RAN3 procedures associated with the gNB-CU 112 during the standby CU activation. When the standby gNB-CU 116 is activated, the target gNB may send a handover confirmation message to the newly activated gNB-CU 116.

[0070] In an example embodiment, operation 222 may be omitted and the standby gNB-CU 116 will send a standby CU activation indication to the gNB-DU 114 after it receives the standby CU activation request from the active gNB-CU 112, which will be discussed in detail below.

[0071] At 224, the active gNB-CU 112 may fail and synchronization with the standby gNB-CU 116 may be interrupted. Two scenarios may be considered here. In the first scenario, the gNB-CU 112 may be aware of the impending failure. For example, downtime may be scheduled for maintenance or upgrades of the network. Then, before the failure occurs, the gNB-CU 112 may send a standby CU activation request to the standby gNB-CU 116 at 220 and a standby CU activation indication to the gNB-DU 114 at 222. In the second scenario, the active gNB-CU 112 may not be aware of the impending failure. When the gNB-CU 112 fails, it may not have yet notified the standby gNB-CU 116 and the gNB-DU 114 of the failure at 220, 222. Then, there will be a longer downtime before the standby gNB-CU 116 is activated because the standby gNB-CU 116 cannot be immediately aware of the failure of the active gNB-CU 112.

[0072] In the scenario of unexpected CU failure, at 222, the gNB-DU 114 may not receive a standby CU activation indication from the active gNB-CU 112. The gNB-DU 114 may detect whether the active gNB-CU 112 has failed at 226. If the gNB-DU 114 resends an F1 Application Protocol (F1AP) message to the active gNB-CU 112 within a maximum retransmission threshold time but does not receive any response from the active gNB-CU 112, the gNB-DU 114 may determine that the active gNB-CU 112 has failed and start buffering RRC messages received from the UE.

[0073] Similarly, if the standby gNB-CU 116 does not receive a standby CU activation request from the active gNB-CU 112 at 220, such as in an unexpected CU failure scenario, the standby gNB-CU 116 may detect whether the active gNB-CU 112 has failed at 228. For example, if the standby gNB-CU 116 resends an Xn Application Protocol (XnAP) message to the active gNB-CU 112 within a maximum retransmission threshold time but does not receive any response from the active gNB-CU 112, the standby gNB-CU 116 may determine that the active gNB-CU 112 has failed.

[0074] If the standby gNB-CU 116 determines a failure of the active gNB-CU 112 based on the standby CU activation request received at 220 or the failure detection performed at 228, the standby gNB-CU 116 may send a standby CU activation indication to the gNB-DU 114 associated with the failed active gNB-CU 112 at 230. In another example embodiment, the standby gNB-CU 116 may send a standby CU activation indication to the gNB-DU 114 only if the standby gNB-CU 116 determines a failure of the active gNB-CU 112 based on the failure detection performed at 228. When the standby gNB-CU 116 receives the standby CU activation request from the active gNB-CU 112 at 220, the standby gNB-CU 116 may assume that the active gNB-CU 112 will send a standby CU activation indication to the gNB-DU 114 before the active gNB-CU 112 fails, and then the standby gNB-CU 116 does not need to send a standby CU activation indication to the gNB-DU 114 at 230.

[0075] As discussed above with respect to operation 222, in addition to information (e.g., an ID or address) of the active gNB-CU 112 and the standby gNB-CU 116, the standby CU activation indication sent at 230 may also include at least one of the following: a duration before the standby gNB-CU 116 is activated, an indication of a timer for extending a UE-associated procedure, an indication to prevent initiation of a new procedure (e.g., a RAN3 procedure) or a retry of an existing procedure during the indicated duration, and a list of radio resource control messages received by the standby gNB-CU 116 from the gNB-DU 114 through data synchronization with the active gNB-CU 112.

[0076] In some example embodiments, the standby gNB-CU 116 may also send a standby CU activation indication to an access and mobility management function (AMF), neighboring RAN nodes such as base stations, CU-UPs associated with the gNB-DU 114, and other network nodes or functions that have a direct interface with the active gNB-CU 112. The network nodes that receive the standby CU activation indication may restart the timers associated with the gNB-CU 112 and not initiate any RAN3 procedures related to the gNB-CU 112 until the standby gNB-CU 116 is activated.

[0077] As described above, the gNB-DU 114 may determine the failure of the active gNB-CU 112 based on the standby CU activation indication received from the active gNB-CU 112 at 222, the failure detection performed at 226, or the standby CU activation indication received from the standby gNB-CU 116 at 230. After determining the failure of the active gNB-CU 112, the gNB-DU 114 may immediately begin buffering RRC messages received from the UE(s) 120 at 232. The gNB-DU 114 does not send the RRC messages received from the UE(s) 120 to the failed active gNB-CU 112. For example, if the gNB-DU 114 receives an RRC message (e.g., RRC message 2) from the UE 120 at 234, the gNB-DU 114 will buffer the received RRC message 2 at 236 but will not forward the RRC message 2 to the failed active gNB-CU 112. Conversely, when the standby gNB-CU 116 is activated and associated with the gNB-DU 114, the gNB-DU 114 will send the buffered RRC messages to the newly activated gNB-CU 116, which will be described in detail later.

[0078] At 238, the gNB-DU 114 may also send a CU failure indication to the UE(s) 120. The CU failure indication may include information (e.g., ID or address) of the failed gNB-CU 112, the duration of the failure, and the cause of the failure. The duration of the failure may be indicated to the gNB-DU 114 from the network, such as estimated by the gNB-DU 114 based on previous CU failures in operations 222, 230, or pre-configured at the gNB-DU 114. Using the received duration, the UE 120 may start a timer to monitor the CU failure period. The cause of the failure may include, for example, expected / planned downtime or an unexpected failure, which may be determined at the gNB-DU 114 or indicated in a standby CU activation indication sent to the gNB-DU 114. For example, if the gNB-DU 114 determines that the gNB-CU 112 is failed based on the failure detection performed at 226, the gNB-DU 114 may infer that the cause of the failure is an unexpected failure. In another example, the active gNB-CU 112 or the standby gNB-CU 116 may indicate the cause of the failure to the gNB-DU 114 in a standby CU activation indication sent to the gNB-DU 114.

[0079] In an example embodiment, the CU failure indication may also indicate whether the UE 120 may initiate a new RRC procedure or a retry of an existing RRC procedure in the uplink during the failure of the active gNB-CU 112. Since the gNB-DU 114 has a limited buffer size to buffer RRC messages received from the served UE, the gNB-DU 114 may instruct the served UE not to initiate any new RRC procedure or a retry of any existing RRC procedure during the failure of the active gNB-CU 112.

[0080] In an example embodiment, the CU failure indication may also include a list of RRC messages received from UE 120 and buffered at gNB-DU 114, from which UE 120 may know that the buffered RRC messages have not been sent to the active gNB-CU and it may extend the timer associated with the buffered RRC messages.

[0081] In an example embodiment, the CU failure indication may be sent via an RRC message that is pre-encoded by the active gNB-CU 112 or an OAM function and pre-sent to the gNB-DU 114 at 212. In another example embodiment, if the gNB-DU 114 has the capability to encode the RRC message, the RRC message carrying the CU failure indication may be encoded by the gNB-DU. The RRC message may be specifically encoded for reception by the UE. In one example, a dedicated Packet Data Convergence Protocol (PDCP) sequence number (SN) may be used to identify the RRC message carrying the CU failure indication. Alternatively or additionally, when sent over a logical common control channel (CCCH), a tag may be used to identify the RRC message carrying the CU failure indication. The RRC message may be encrypted with a cell-specific public security key, such as a message authentication code integrity (MAC-i), which remains unchanged for UEs in the cell. It should be understood that the CU failure indication may also be sent via a media access control (MAC) control element (MAC CE) or a physical layer (PHY) message.

[0082] In the above discussion, UE 120 may be in RRC connected mode, and gNB-DU 114 may proactively send a CU failure indication to connected UEs including UE 120. Figure 4 Another scenario is illustrated in which UE 120 is already in RRC idle mode. Figure 4, after the gNB-DU 114 begins buffering the RRC message received from the UE at 232, the UE 120 may attempt to establish an RRC connection with the network through a random access procedure, and send an RRC setup request message (as RRC message 2) to the gNB-DU 114 at 234. The gNB-DU 114 may buffer the RRC setup request message at 236, and send a precoded RRC response message including a CU failure indication back to the UE 120 at 238. As described above, the precoded RRC response message may be precoded by the active gNB-CU 112 or the OAM function, and pre-sent to the gNB-DU 114 at 212. The CU failure indication carried in the precoded RRC response message may indicate to the UE 120, among other things, the cause and duration of the CU failure, and instruct the UE 120 not to retry transmission of the RRC setup request message before the indicated duration has elapsed.

[0083] Reference again Figure 3 At 240, UE 120 may, in response to the CU failure indication received at 238, prevent itself from transitioning to RRC idle mode during the failure of the active gNB-CU 112. If UE 120 is as described above with reference to Figure 4 If the UE 120 is already in the RRC idle mode, the UE 120 may remain in the random access procedure and refrain from returning to / transitioning to the RRC idle mode and initiating the random access procedure again.

[0084] Figure 5 Some example operations that may be performed at UE 120 to prevent transitioning to RRC idle mode are illustrated. Figure 5At 310, the UE 120 may suspend one or more transmissions to the gNB-CU 112 via a signaling radio bearer (SRB) (i.e., RRC messages). At 320, the UE 120 may extend one or more timers if the timers are running or active. An active timer refers to a timer that has been registered and is scheduled to tick later. For example, when the UE 120 receives an RRC connection reconfiguration message with mobility control information during a handover procedure, the UE 120 may start a timer T304. If the UE 120 fails to connect to the target cell and the timer T304 expires, the UE 120 declares a radio link failure (RLF) and enters an RRC idle mode. In an example embodiment, the UE 120 may extend the timer T304 to prevent the radio link failure from being declared and transition to the RRC idle mode. The UE 120 may extend the timer T304 by restarting or pausing the timer, or by adding a duration to the timer. UE 120 may also extend other timers running before declaring radio link failure or performing transmission or retransmission over a signaling radio bearer, i.e., expiration of the timer will cause UE 120 to declare radio link failure or send / retransmit an uplink RRC message. It should be understood that operations 310, 320 are described as examples, and other operations may also be performed at UE 120 to prevent UE 120 from transitioning to RRC idle mode.

[0085] Reference again Figure 3 , at 242, the standby gNB-CU 116 may be successfully activated and associated with the gNB-DU 114. From then on, the newly activated gNB-CU 116 takes over the role of the original active gNB-CU 112, and the F1 interface between the gNB-CU 116 and the gNB-DU 114 becomes operational to serve the UE.

[0086] At 244, gNB-CU 116 may send a standby CU activation complete message to gNB-DU 114, from which gNB-DU 114 knows that gNB-CU 116 has been activated. In an example embodiment, a resilient status indication message and related information elements (IEs) may be designed for a standby CU activation indication and a standby CU activation complete message. The resilient status indication message may be defined as follows:

[0087] Elasticity status indication message

[0088] ● Direction: From gNB-CU to gNB-DU

[0089] UE related messages

[0090] ●IE:

[0091] ○CU takeover (enumeration (in progress, completed...) optional

[0092] ○UL SRB buffer commands (enumeration (start, stop...) mandatory

[0093] ○RRC confirmation list (RRC message list) optional

[0094] RRC Message 1

[0095] ■……

[0096] ○……

[0097] The IE "CU Takeover" indicates whether activation of the standby gNB-CU 116 is in progress or has been completed. The IE "UL SRB Buffering Command" instructs the gNB-DU 114 to start or stop buffering RRC messages received from the served UE. The IE "RRC Confirmation List" includes indices of uplink RRC messages that have been received at the active gNB-CU 112 or the standby gNB-CU 116. For example, in the standby CU activation indication sent in 222 or 230, the resilience status indication message may be encoded as follows:

[0098] Elastic state indicator {

[0099] CU Takeover: In Progress;

[0100] UL SRB buffer command: start;

[0101] RRC confirmation list (RRC message 1, ...)

[0102] }

[0103] In the standby CU activation complete message sent in 244, the elastic state indication message may be encoded as follows:

[0104] Elastic state indicator {

[0105] CU takeover: completed;

[0106] UL SRB buffer command: stop;

[0107] RRC confirmation list (RRC message 1, ...)

[0108] }

[0109] At 246, the gNB-DU 114 may send the buffered RRC message to the newly activated gNB-CU 116. The gNB-DU 114 may also perform other operations with the newly activated gNB-CU 116.

[0110] At 248, the gNB-DU 114 may send a CU recovery indication to the UE 120 in response to the standby CU activation complete message received from the newly activated gNB-CU 116. The CU recovery indication may include information of the newly activated gNB-CU 116. From the receipt of the CU recovery indication, the UE 120 may operate normally with the newly activated gNB-CU 116. Optionally, the CU recovery indication may also include information of one or more uplink RRC messages lost at the gNB-DU 114.

[0111] At 250, UE 120 may resume the suspended transmissions over the signaling radio bearer to the newly activated gNB-CU 116. UE 120 may also resend the lost RRC message indicated in the CU resume indication to the newly activated gNB-CU 116.

[0112] In the above process 200, the UE is configured to prevent transitioning to RRC idle mode during failure of an active gNB-CU. This can reduce ineffective operations at the UE during gNB-CU failure and save power consumption of the UE. In addition, a burst of multiple UEs simultaneously performing random access procedures after entering RRC idle mode can be avoided. The gNB-DU can buffer RRC messages received from the UE during the failure of the active gNB-CU and send the buffered RRC messages to the newly activated gNB-CU after the CU failure duration. This can prevent uplink RRC message loss due to gNB-CU failure.

[0113] Figure 6 4 is a schematic functional block diagram illustrating an apparatus 400 according to an exemplary embodiment of the present disclosure. The apparatus 400 may be implemented at a terminal device such as UE 120 to perform operations related to UE 120, as described above. Figure 3-Figure 5 The operations related to the UE 120 are discussed in detail, so the blocks of the apparatus 400 will be briefly described here, and the details thereof may refer to the above description.

[0114] refer to Figure 6 , the apparatus 400 may include a first component 410 and a second component 420, the first component being used to receive a central unit (CU) failure indication from a gNB-DU 114, the central unit (CU) failure indication indicating a failure of a first gNB-CU 112 configured in an active mode and associated with the gNB-DU 114, the second component being used to prevent the UE 120 from transitioning to a radio resource control (RRC) idle mode during the failure of the first gNB-CU 112.

[0115] In an example embodiment, the CU failure indication may include at least one of: a cause of the failure of the first gNB-CU 112, a duration of the failure, an indicator indicating whether new RRC procedures in the uplink and / or retry of existing RRC procedures in the uplink are allowed at the UE 120 during the failure of the first gNB-CU 112, an identifier or address of the first gNB-CU 112, and a list of RRC messages sent from the UE 120 that are buffered at the gNB-DU 114.

[0116] In an example embodiment, the CU failure indication may be received in an RRC message, a medium access control (MAC) control element (MACCE), or a physical layer message.

[0117] In an example embodiment, the RRC message carrying the CU failure indication may be encrypted with a public security key that remains the same for UEs in a cell.

[0118] In an example embodiment, the RRC message carrying the CU failure indication may have a dedicated Packet Data Convergence Protocol (PDCP) Sequence Number (SN).

[0119] In an example embodiment, the RRC message carrying the CU failure indication may be sent through a common control channel together with a flag.

[0120] In an example embodiment, the second component 420 may optionally include: a first subcomponent 422 for suspending transmission to the first gNB-CU 112 via a signaling radio bearer (SRB), and a second subcomponent 424 for extending the timer while the timer is running or active.

[0121] In an example embodiment, the apparatus 400 may optionally include a third component 430 for receiving a CU recovery indication from the gNB-DU 114. The CU recovery indication may indicate that a second gNB-CU 116 configured in a standby mode is activated and associated with the gNB-DU 114. The second component 420 may be configured to prevent the UE 120 from transitioning to the RRC idle mode until the CU recovery indication is received from the gNB-DU 114. In another example embodiment, the second component 420 may be configured to prevent the UE 120 from transitioning to the RRC idle mode for a predetermined duration or for a duration indicated in a CU failure indication received from the gNB-DU 114.

[0122] In an example embodiment, the apparatus 400 may optionally include a fourth component 440 for resuming suspended transmission to the newly activated gNB-CU 116 via a signaling radio bearer in response to a CU resumption indication.

[0123] Figure 7 5 is a schematic functional block diagram illustrating an apparatus 500 according to an example embodiment of the present disclosure. The apparatus 500 may be implemented at a network node such as a gNB-DU 114 to perform operations related to the gNB-DU 114, as described above. Figure 3-Figure 5 The operations related to the gNB-DU 114 are discussed in detail, so the blocks of the apparatus 500 will be briefly described here, and the details thereof may refer to the above description.

[0124] refer to Figure 7 , the apparatus 500 may include a first component 510 and a second component 520, wherein the first component is used to start buffering radio resource control (RRC) messages received from one or more UEs 120 when the gNB-DU 114 determines a failure of a first gNB-CU 112 that is configured in an active mode and associated with the gNB-DU 114, and the second component is used to send a CU failure indication indicating the failure of the first gNB-CU 112 to the UE 120.

[0125] In an example embodiment, the gNB-DU 114 may determine a failure of the first gNB-CU 112 based on a standby CU activation indication received from the first gNB-CU 112 or a second gNB-CU 116 configured in a standby mode, or based on a failure detection performed at the gNB-DU 114 for the first gNB-CU 112. The standby CU activation indication may indicate that the second gNB-CU 116 is to be activated and associated with the gNB-DU 114.

[0126] In an example embodiment, the standby CU activation indication may include at least one of: a duration before the second gNB-CU 116 is activated, a first indication for extending a timer for a process associated with the UE 120, a second indication for preventing initiation of a new process or a retry of an existing process during the duration, and a list of RRC messages that have been received at the first gNB-CU 112 or the second gNB-CU 116.

[0127] In an example embodiment, the CU failure indication may be sent via an RRC message, a MAC CE, or a physical layer message.

[0128] In an example embodiment, the RRC message carrying the CU failure indication may be encrypted with a common security key that remains constant for UEs in a cell.

[0129] In an example embodiment, the RRC message carrying the CU failure indication may have a dedicated Packet Data Convergence Protocol (PDCP) Sequence Number (SN).

[0130] In an example embodiment, the RRC message carrying the CU failure indication may be sent through a common control channel together with a flag.

[0131] In an example embodiment, the CU failure indication may include at least one of: a cause of the failure of the first gNB-CU 112, a duration of the failure, an indicator indicating whether new RRC procedures in the uplink and / or retry of existing RRC procedures in the uplink are allowed at the UE 120 during the failure of the first gNB-CU 112, an identifier or address of the first gNB-CU 112, and a list of RRC messages received from the UE 120 that are buffered at the gNB-DU 114.

[0132] In an example embodiment, the apparatus 500 may optionally include a third component 530 for receiving an encoded RRC message including a CU failure indication from the first gNB-CU 112 or an operations administration and maintenance (OAM) function prior to a failure of the first gNB-CU 112.

[0133] In an example embodiment, the CU failure indication may be encoded as an RRC message at the gNB-DU 114 before the CU failure indication is sent to the UE 120.

[0134] In an example embodiment, the apparatus 500 may optionally include a fourth component 540 for receiving a standby CU activation complete message from the second gNB-CU 116. The standby CU activation complete message may indicate that the second gNB-CU 116 configured in the standby mode is activated and associated with the gNB-DU 114.

[0135] In an example embodiment, the apparatus 500 may optionally include a fifth component 550 for sending the buffered RRC message to the second gNB-CU 116 in response to the standby CU activation complete message.

[0136] In an example embodiment, the apparatus 500 may optionally include a sixth component 560 for sending a CU recovery indication to the UE 120 in response to the standby CU activation complete message.

[0137] Figure 8 6 is a schematic functional block diagram illustrating an apparatus 600 according to an example embodiment of the present disclosure. The apparatus 600 may be implemented at a network node such as a standby gNB-CU 116 to perform operations related to the standby gNB-CU 116, as described above. Figure 3-Figure 5 The operations related to the standby gNB-CU 116 are discussed in detail, so the blocks of the apparatus 600 will be briefly described here, and the details thereof may refer to the above description.

[0138] refer to Figure 8 , the apparatus 600 may include: a first component 610 for sending a standby central unit (CU) activation indication to the gNB-DU 114, the activation indication indicating that the standby gNB-CU 116 is to be activated to replace the active gNB-CU 112 associated with the gNB-DU 114. For ease of description, the active gNB-CU 112 may be referred to as a first gNB-CU, and the standby gNB-CU 116 may also be referred to as a second gNB-CU.

[0139] In an example embodiment, the standby CU activation indication may include at least one of: a duration before the second gNB-CU 116 is activated, a first indication for extending a timer for a procedure associated with a UE served by the gNB-DU 114, a second indication for preventing initiation of a new procedure or a retry of an existing procedure at the gNB-DU 114 during the duration, and a list of RRC messages that have been received from the gNB-DU 114 at the second gNB-CU 116.

[0140] In an example embodiment, the standby CU activation indication may also be sent to an access and mobility management function (AMF), neighboring radio access network (RAN) nodes, a CU user plane associated with the gNB-DU 114, and other network nodes or functions having a direct interface with the first gNB-CU 112.

[0141] In an example embodiment, the apparatus 600 may optionally include: a second component 620 for receiving a standby CU activation request from the first gNB-CU 112 or an operations administration and maintenance (OAM) function before the standby CU activation indication is sent to the gNB-DU 114.

[0142] In an example embodiment, the apparatus 600 may optionally include a third component 630 for sending a standby CU activation complete message to the gNB-DU 114 when the second gNB-CU 116 is activated and associated with the gNB-DU 114.

[0143] In an example embodiment, the apparatus 600 may optionally include a fourth component 640 for receiving one or more uplink RRC messages buffered at the gNB-DU 114 from the gNB-DU 114 before the second gNB-CU 116 is activated.

[0144] Fig. 9 7 is a schematic block diagram illustrating a device in a communication system 700 in which an example embodiment of the present disclosure may be implemented. Fig. 9As shown, the communication system 700 may include: a terminal device 710 that can be implemented as the above-mentioned UE 120, a first network device 720 that can be implemented as the above-mentioned gNB-DU 114, and a second network device 730 that can be implemented as the above-mentioned active gNB-CU 112 and / or the standby gNB-CU 116.

[0145] refer to Fig. 9 , the terminal device 710 may include: one or more processors 711, one or more memories 712, and one or more transceivers 713 interconnected by one or more buses 714. The one or more buses 714 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, optical fiber, optics, or other optical communication devices, etc. Each of the one or more transceivers 713 may include: a receiver and a transmitter connected to one or more antennas 716. The terminal device 710 may wirelessly communicate with the first network device 720 via one or more antennas 716. The one or more memories 712 may include computer program code 715. The one or more memories 712 and the computer program code 715 may be configured to: when executed by the one or more processors 711, cause the terminal device 710 to perform the operations and processes related to the UE 120 as described above.

[0146] The first network device 720 may include: one or more processors 721, one or more memories 722, one or more transceivers 723, and one or more network interfaces 727 interconnected by one or more buses 724. One or more buses 724 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, optical fiber, optics, or other optical communication devices, etc. Each of the one or more transceivers 723 may include a receiver and a transmitter connected to one or more antennas 726. The first network device 720 may operate as a distributed unit of a split base station and wirelessly communicate with the terminal device 710 through one or more antennas 726. One or more network interfaces 727 may provide a wired and / or wireless communication link, through which the first network device 720 may communicate with other network devices, entities, elements, or functions. The first network device 720 may communicate with the second network device 730 via a link 728. One or more memories 722 may include a computer program code 725. The one or more memories 722 and the computer program code 725 may be configured to, when executed by the one or more processors 721, cause the first network device 720 to perform operations and processes related to the gNB-DU 114 as described above.

[0147] The second network device 730 may include one or more processors 731, one or more memories 732, and one or more network interfaces 737 interconnected by one or more buses 734. The one or more buses 734 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, optical fiber, optical or other optical communication devices, etc. The second network device 730 may operate as a central unit of a split base station and communicate with the first network device 720 in wired or wireless communication via one or more links. The one or more network interfaces 737 may provide a wired or wireless communication link through which the second network device 730 may communicate with other network devices, entities, elements, or functions. The one or more memories 732 may include computer program code 735. The one or more memories 732 and computer program code 735 may be configured to, when executed by the one or more processors 731, cause the second network device 730 to perform operations and processes related to the gNB-CU 112 and / or gNB-CU 116 as described above.

[0148] The one or more processors 711, 721, and 731 may be any suitable type suitable for the local technical network, and may include one or more of the following: a general-purpose processor, a special-purpose processor, a microprocessor, a digital signal processor (DSP), a processor based on a multi-core processor architecture, and a special-purpose processor, such as a processor developed based on a field programmable gate array (FPGA) and an application-specific integrated circuit (ASIC). The one or more processors 711, 721, and 731 may be configured to control other elements of the network device and operate in conjunction with them to implement the above process.

[0149] The one or more memories 712, 722, and 732 may include at least one storage medium in various forms, such as volatile memory and / or non-volatile memory. Volatile memory may include, but is not limited to, for example, random access memory (RAM) or cache memory. Non-volatile memory may include, but is not limited to, for example, read-only memory (ROM), hard disk, flash memory, etc. In addition, the one or more memories 712, 722, and 732 may include, but are not limited to, electrical, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or devices, or any combination thereof.

[0150] It should be understood that the blocks in the drawings can be implemented in various ways, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more blocks can be implemented using software and / or firmware, such as machine executable instructions stored in a storage medium. In addition to or in place of machine executable instructions, some or all of the blocks in the drawings can be implemented at least in part by one or more hardware logic components. For example, but not limited to, illustrative types of hardware logic components that can be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), etc.

[0151] Some example embodiments also provide computer program codes or instructions, which, when executed by one or more processors, can cause a device or apparatus to perform the above-described processes. The computer program code for executing the processes of the example embodiments can be written in any combination of one or more programming languages. The computer program code can be provided to one or more processors or controllers of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that the program code, when executed by the processor or controller, enables the functions / operations specified in the flow chart and / or block diagram to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the computer and partially on a remote machine, or entirely on a remote machine or server.

[0152] Some example embodiments also provide a computer program product or computer readable medium in which computer program code or instructions are stored. A computer readable medium may be any tangible medium that may contain or store a program for use by or in combination with an instruction execution system, device, or apparatus. A machine readable medium may be a machine readable signal medium or a machine readable storage medium. A machine readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any suitable combination thereof. A more specific example of a machine readable storage medium would include an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0153] In addition, although the operations are described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in sequence or requiring all the operations shown to be performed to achieve the desired result. In some cases, multitasking and parallel processing can be advantageous. Similarly, although several specific implementation details are included in the above discussion, these details should not be interpreted as limitations on the scope of the present disclosure, but rather descriptions of features that may be peculiar to a particular embodiment. Certain features described in the context of a separate embodiment may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple embodiments individually or in any suitable sub-combination.

[0154] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as examples of implementing the claims.

Claims

1. A user equipment in a radio access network, comprising: at least one processor; as well as at least one memory including computer program code, the at least one memory and the computer program code being configured to, together with the at least one processor, cause the user equipment to at least: receiving a central unit failure indication from a distributed unit in the radio access network, the central unit failure indication indicating: a failure of a first central unit in the radio access network associated with the distributed unit; as well as The user equipment is prevented from transitioning to a radio resource control idle mode during the failure of the first central unit.

2. The user equipment according to claim 1, wherein preventing the user equipment from transitioning to the radio resource control idle mode comprises at least one of the following: suspending transmission to the first central unit over a signalling radio bearer; and If the timer is running or active, the timer is extended.

3. The user equipment of claim 1 , wherein the user equipment is prevented from transitioning to the radio resource control idle mode for a predetermined duration, for a duration indicated in the central unit failure indication, or until a central unit recovery indication is received at the user equipment, and The central unit recovery indication indicates that a second central unit configured in a standby mode is activated and associated with the distributed unit.

4. The user equipment according to claim 3, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, cause the user equipment to at least: In response to the central unit resumption indication, the suspended transmission to the second central unit is resumed over the signaling radio bearer.

5. The user equipment according to claim 1, wherein the central unit failure indication is carried in a radio resource control message, a medium access control control element, or a physical layer message.

6. The user equipment according to claim 5, wherein the radio resource control message carrying the central unit failure indication is encrypted with a public security key, The radio resource control message carrying the central unit failure indication has a dedicated packet data convergence protocol sequence number, and / or The radio resource control message carrying the central unit failure indication is sent together with a flag through a common control channel.

7. The user equipment according to claim 1, wherein the central unit failure indication comprises at least one of the following: a cause of said failure of said first central unit; the duration of the failure; an indicator specifying whether a new radio resource control procedure in uplink, and / or a retry of an existing radio resource control procedure in uplink is allowed during said failure of said first central unit; an identifier or address of the first central unit; as well as A list of radio resource control messages sent from the user equipment that are buffered at the distributed unit.

8. A distributed unit in a radio access network, comprising: at least one processor; as well as at least one memory including computer program code, the at least one memory and the computer program code being configured to, together with the at least one processor, cause the distributed unit to at least: when the distributed unit determines a failure of a first central unit in the radio access network, the first central unit being active and associated with the distributed unit, starting buffering of radio resource control messages received from one or more user equipment in the radio access network; as well as A central unit failure indication is sent to the one or more user equipments indicating the failure of the first central unit.

9. The distributed unit of claim 8, wherein the distributed unit determines the failure of the first central unit based on: a backup central unit activation indication received from the first central unit, or a second central unit in the radio access network, the backup central unit activation indication indicating that the second central unit is to be activated and associated with the distributed unit; or Fault detection is performed at the distributed units on the first central unit.

10. The distributed unit according to claim 9, wherein the backup central unit activation indication received from the first central unit or the second central unit comprises at least one of the following: the duration before said second central unit is activated; a first indication for extending a timer for a process associated with the one or more user equipments; a second indication for preventing initiation of a new process or a retry of an existing process during the duration; as well as A list of radio resource control messages that have been received at the first central unit or the second central unit.

11. The distributed unit of claim 8, wherein the central unit failure indication is sent via a radio resource control message, a media access control control element, or a physical layer message.

12. The distributed unit according to claim 11, wherein the radio resource control message carrying the central unit failure indication is encrypted with a public security key, The radio resource control message carrying the central unit failure indication has a dedicated packet data convergence protocol sequence number, and / or The radio resource control message carrying the central unit failure indication is sent together with a flag through a common control channel.

13. The distributed unit of claim 8, wherein the central unit failure indication comprises at least one of the following: a cause of said failure of said first central unit; the duration of the failure; an indicator specifying whether a new radio resource control procedure in uplink, and / or a retry of an existing radio resource control procedure in uplink is allowed during said failure of said first central unit; an identifier or address of the first central unit; as well as A list of radio resource control messages received from the user equipment that are buffered at the distributed unit.

14. The distributed unit of claim 8, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, cause the distributed unit to at least: Prior to the distributed unit determining the failure of the first central unit, a coded radio resource control message including an indication of a failure of the central unit is received from the first central unit, or an operations administration and maintenance function.

15. The distributed unit of claim 8, wherein the central unit failure indication is encoded as a radio resource control message at the distributed unit before the central unit failure indication is sent to the one or more user equipments.

16. The distributed unit of claim 8, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, cause the distributed unit to at least: receiving a backup central unit activation complete message from a second central unit in the radio access network, the backup central unit activation complete message indicating that the second central unit is activated and associated with the distributed unit; and The buffered radio resource control message is sent to the second central unit.

17. The distributed unit of claim 16, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, cause the distributed unit to at least: In response to receiving the backup central unit activation complete message from the second central unit, a central unit restoration indication is sent to the one or more user equipments.

18. A second central unit in a radio access network, comprising: at least one processor; as well as at least one memory including computer program code, the at least one memory and the computer program code being configured to, together with the at least one processor, cause the second central unit to at least: A backup central unit activation indication is sent to a distributed unit in the radio access network, the backup central unit activation indication indicating that the second central unit is to be activated to replace a first central unit in the radio access network, the first central unit being active and associated with the distributed unit.

19. The second central unit according to claim 18, wherein the backup central unit activation indication comprises at least one of the following: the duration before said second central unit is activated; a first indication for extending a timer of a process associated with a user equipment served by the distributed unit; a second indication for preventing initiation of a new process or a retry of an existing process at the distributed unit during the duration; as well as A list of radio resource control messages that have been received at the second central unit from the distributed units.

20. The second central unit of claim 18, wherein the standby central unit activation indication is also sent to: access and mobility management functions, neighboring radio access network nodes, central unit user planes associated with the distributed units, and other network nodes or functions having a direct interface with the first central unit.

21. The second central unit according to claim 18, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, cause the second central unit to at least: receiving a backup central unit activation request from the first central unit, or an operations management and maintenance function, before sending the backup central unit activation indication to the distributed unit; When the second central unit is activated and associated with the distributed unit, sending a backup central unit activation completion message to the distributed unit; and Receiving from the distributed unit: one or more uplink radio resource control messages buffered at the distributed unit before the second central unit is activated and associated with the distributed unit.

22. A method implemented at a user equipment in a radio access network, comprising: receiving a central unit failure indication from a distributed unit in the radio access network, the central unit failure indication indicating: a failure of a first central unit in the radio access network associated with the distributed unit; as well as The user equipment is prevented from transitioning to a radio resource control idle mode during the failure of the first central unit.

23. The method of claim 22, wherein preventing the user equipment from transitioning to the radio resource control idle mode comprises at least one of: suspending transmission to the first central unit over a signalling radio bearer; and If the timer is running or active, the timer is extended.

24. The method of claim 22, wherein the user equipment is prevented from transitioning to the radio resource control idle mode for a predetermined duration, for a duration indicated in the central unit failure indication, or until a central unit recovery indication is received at the user equipment, and The central unit recovery indication indicates that a second central unit configured in a standby mode is activated and associated with the distributed unit.

25. The method according to claim 24, further comprising: In response to the central unit resumption indication, the suspended transmission to the second central unit is resumed over the signaling radio bearer.

26. The method of claim 22, wherein the central unit failure indication is carried in a radio resource control message, a medium access control control element, or a physical layer message.

27. The method according to claim 26, wherein the radio resource control message carrying the central unit failure indication is encrypted with a public security key, The radio resource control message carrying the central unit failure indication has a dedicated packet data convergence protocol sequence number, and / or The radio resource control message carrying the central unit failure indication is sent together with a flag through a common control channel.

28. The method of claim 22, wherein the central unit failure indication comprises at least one of: a cause of said failure of said first central unit; the duration of the failure; an indicator specifying whether a new radio resource control procedure in uplink, and / or a retry of an existing radio resource control procedure in uplink is allowed during said failure of said first central unit; an identifier or address of the first central unit; as well as A list of radio resource control messages sent from the user equipment that are buffered at the distributed unit.

29. A method implemented at a distributed unit in a radio access network, comprising: when the distributed unit determines a failure of a first central unit in the radio access network, the first central unit being active and associated with the distributed unit, starting buffering of radio resource control messages received from one or more user equipment in the radio access network; as well as A central unit failure indication is sent to the one or more user equipments indicating the failure of the first central unit.

30. The method of claim 29, wherein the distributed units determine the failure of the first central unit based on: a backup central unit activation indication received from the first central unit, or a second central unit in the radio access network, the backup central unit activation indication indicating that the second central unit is to be activated and associated with the distributed unit; or Fault detection is performed at the distributed units on the first central unit.

31. The method of claim 30, wherein the backup central unit activation indication received from the first central unit or the second central unit comprises at least one of the following: the duration before said second central unit is activated; a first indication for extending a timer for a process associated with the one or more user equipments; a second indication for preventing initiation of a new process or a retry of an existing process during the duration; as well as A list of radio resource control messages that have been received at the first central unit or the second central unit.

32. The method of claim 29, wherein the central unit failure indication is sent via a radio resource control message, a medium access control control element, or a physical layer message.

33. The method of claim 32, wherein the radio resource control message carrying the central unit failure indication is encrypted with a public security key, The radio resource control message carrying the central unit failure indication has a dedicated packet data convergence protocol sequence number, and / or The radio resource control message carrying the central unit failure indication is sent together with a flag through a common control channel.

34. The method of claim 29, wherein the central unit failure indication comprises at least one of: a cause of said failure of said first central unit; the duration of the failure; an indicator specifying whether a new radio resource control procedure in uplink, and / or a retry of an existing radio resource control procedure in uplink is allowed during said failure of said first central unit; an identifier or address of the first central unit; as well as A list of radio resource control messages received from the user equipment that are buffered at the distributed unit.

35. The method of claim 29, further comprising: Prior to the distributed unit determining the failure of the first central unit, a coded radio resource control message including an indication of a failure of the central unit is received from the first central unit, or an operations administration and maintenance function.

36. The method of claim 29, wherein the central unit failure indication is encoded as a radio resource control message at the distributed unit before the central unit failure indication is sent to the one or more user equipments.

37. The method of claim 29, further comprising: receiving a backup central unit activation complete message from a second central unit in the radio access network, the backup central unit activation complete message indicating that the second central unit is activated and associated with the distributed unit; as well as The buffered radio resource control message is sent to the second central unit.

38. The method of claim 37, further comprising: In response to receiving the backup central unit activation complete message from the second central unit, a central unit restoration indication is sent to the one or more user equipments.

39. A method implemented at a second central unit in a radio access network, comprising: A backup central unit activation indication is sent to a distributed unit in the radio access network, the backup central unit activation indication indicating that the second central unit is to be activated to replace a first central unit in the radio access network, the first central unit being active and associated with the distributed unit.

40. The method of claim 39, wherein the backup central unit activation indication comprises at least one of the following: the duration before said second central unit is activated; a first indication for extending a timer of a process associated with a user equipment served by the distributed unit; a second indication for preventing initiation of a new process or a retry of an existing process at the distributed unit during the duration; as well as A list of radio resource control messages that have been received at the second central unit from the distributed units.

41. The method of claim 39, wherein the standby central unit activation indication is also sent to: access and mobility management functions, neighboring radio access network nodes, central unit user planes associated with the distributed units, and other network nodes or functions having a direct interface with the first central unit.

42. The method of claim 39, further comprising: receiving a backup central unit activation request from the first central unit, or an operations management and maintenance function, before sending the backup central unit activation indication to the distributed unit; When the second central unit is activated and associated with the distributed unit, sending a standby central unit activation completion message to the distributed unit; as well as Receiving from the distributed unit: one or more uplink radio resource control messages buffered at the distributed unit before the second central unit is activated and associated with the distributed unit.

43. An apparatus implemented at a user equipment in a radio access network, comprising: means for receiving a central unit failure indication from a distributed unit in the radio access network, the central unit failure indication indicating: a failure of a first central unit in the radio access network associated with the distributed unit; as well as Means for preventing said user equipment from transitioning to a radio resource control idle mode during said failure of said first central unit.

44. An apparatus implemented at a distributed unit in a radio access network, comprising: means for starting buffering radio resource control messages received from one or more user equipment in the radio access network when the distributed unit determines a failure of a first central unit in the radio access network, the first central unit being active and associated with the distributed unit; as well as Means for sending a central unit failure indication indicating said failure of said first central unit to said one or more user equipments.

45. An apparatus implemented at a second central unit in a radio access network, comprising: Means for sending a backup central unit activation indication to a distributed unit in the radio access network, the backup central unit activation indication indicating that the second central unit is to be activated to replace a first central unit in the radio access network, the first central unit being active and associated with the distributed unit.

46. ​​A computer program product, embodied in at least one computer readable medium, and comprising instructions which, when executed by at least one processor of a user equipment in a radio access network, cause the user equipment to at least: receiving a central unit failure indication from a distributed unit in the radio access network, the central unit failure indication indicating: a failure of a first central unit in the radio access network associated with the distributed unit; and The user equipment is prevented from transitioning to a radio resource control idle mode during the failure of the first central unit.

47. A computer program product, embodied in at least one computer readable medium, and comprising instructions which, when executed by at least one processor of a distributed unit in a radio access network, cause the distributed unit to at least: When the distributed unit determines a failure of a first central unit in the radio access network, the first central unit being active and associated with the distributed unit, starting buffering of radio resource control messages received from one or more user equipment in the radio access network; and A central unit failure indication is sent to the one or more user equipments indicating the failure of the first central unit.

48. A computer program product, embodied in at least one computer readable medium, and comprising instructions which, when executed by at least one processor of a central unit in a radio access network, cause the central unit to at least: A backup central unit activation indication is sent to a distributed unit in the radio access network, the backup central unit activation indication indicating that the second central unit is to be activated to replace a first central unit in the radio access network, the first central unit being active and associated with the distributed unit.

Images