Method and device for energy saving in mobile communication system using split ran

Abstract

According to an embodiment of the present disclosure, a method performed by a serving distributed unit (DU) in a communication system may comprise the steps of: receiving a message for switching-off indication from a serving central unit (CU); transmitting a setup request message to a target CU on the basis of the message for the switching-off indication; in response to the setup request message, receiving a setup response message from the target CU; in response to the message for the switching-off indication, transmitting an approval message including information related to the target CU to the serving CU; and on the basis of the switching-off indication, performing a connection to the target CU for continuous service support.

Description

Method and device for energy saving in a mobile communication system using a split RAN

[0001] The present disclosure relates to the operation of a terminal and a base station in a mobile communication system. More specifically, the present disclosure relates to a method and device for energy conservation in a mobile communication system using a split RAN.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in the sub-6GHz frequency band such as 3.5 gigahertz (3.5GHz), but also in the ultra-high frequency band called millimeter wave (mmWave) such as 28GHz and 39GHz ('Above 6GHz'). In addition, for 6G mobile communication technology, which is called the system after 5G communication (Beyond 5G), implementation in the terahertz band (for example, the 3 terahertz (3THz) band at 95GHz) is being considered to achieve a transmission speed that is 50 times faster than 5G mobile communication technology and an ultra-low latency time that is reduced to one-tenth.

[0003] In the early stages of 5G mobile communication technology, the goal is to support services and satisfy performance requirements for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC). These include beamforming and massive MIMO to mitigate path loss of radio waves in ultra-high frequency bands and increase the transmission distance of radio waves, support for various numerologies (such as operation of multiple subcarrier intervals) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial access technology to support multi-beam transmission and wideband, definition and operation of BWP (Bidth Part), new channel coding methods such as LDPC (Low Density Parity Check) codes for large-capacity data transmission and Polar Code for reliable transmission of control information, and L2 pre-processing (L2). Standardization has been made for network slicing, which provides dedicated networks specialized for specific services, and pre-processing.

[0004] Currently, discussions are underway to improve and enhance the initial 5G mobile communication technology in consideration of the services that 5G mobile communication technology was intended to support, and physical layer standardization is in progress for technologies such as V2X (Vehicle-to-Everything) to help autonomous vehicles make driving decisions and increase user convenience based on their own location and status information transmitted by vehicles, NR-U (New Radio Unlicensed) for the purpose of system operation that complies with various regulatory requirements in unlicensed bands, NR terminal low power consumption technology (UE Power Saving), Non-Terrestrial Network (NTN), which is direct terminal-satellite communication to secure coverage in areas where communication with terrestrial networks is impossible, and Positioning.

[0005] In addition, standardization of wireless interface architecture / protocols is in progress for technologies such as intelligent factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) that provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement technology including Conditional Handover and Dual Active Protocol Stack (DAPS) handover, and 2-step random access (2-step RACH for NR) that simplifies random access procedures. Standardization is also in progress for system architecture / services such as 5G baseline architecture (e.g., Service-based Architecture, Service-based Interface) for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) that provides services based on the location of the terminal.

[0006] Once these 5G mobile communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, necessitating enhanced functionality and performance of 5G mobile communication systems and integrated operation of these connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity, supporting AI services, supporting metaverse services, and drone communications by utilizing eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] In addition, the development of these 5G mobile communication systems includes new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), Array Antenna, and Large Scale Antenna, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), Reconfigurable Intelligent Surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, satellite, AI (Artificial Intelligence) from the design stage and AI-based communication technology that realizes system optimization by internalizing end-to-end AI support functions, and ultra-high-performance communication and computing resources to provide services with complexity that exceeds the limits of terminal computing capabilities. It could serve as a basis for the development of next-generation distributed computing technologies that can be realized by utilizing this technology.

[0008] The disclosed embodiment seeks to provide a method and device capable of effectively providing a service in a mobile communication system.

[0009] The present invention aims to provide a method and device for effectively supporting energy saving and operation error recovery of a Central Unit (CU) in a structure in which base station functions are separated.

[0010] The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned can be clearly understood by a person having ordinary skill in the technical field to which the present invention belongs from the description below.

[0011] Based on the discussion described above, the present disclosure provides a method for processing a control signal in a mobile communication system, which may include: receiving a first control signal transmitted from a base station; processing the received first control signal; and transmitting a second control signal generated based on the processing to the base station.

[0012] In order to solve the above problems, the present disclosure discloses a method performed by a serving distributed unit (DU) in a communication system, the method comprising: receiving a message for a switching-off instruction from a serving central unit (CU); transmitting a setup request message to a target CU based on the message for the switching-off instruction; receiving a setup response message from the target CU in response to the setup request message; transmitting an acknowledgment message including information related to the target CU to the serving CU in response to the message for the switching-off instruction; and performing a connection to the target CU for continuous service support based on the switching-off instruction.

[0013] In order to solve the above problems, the present disclosure discloses a method performed by a serving central unit (CU) in a communication system, the method comprising: a step of transmitting a message for a switching-off instruction to a serving distributed unit (DU); a step of receiving an acknowledgment message including information related to a target CU from the serving DU in response to the message for the switching-off instruction; and a step of performing an interface connection deletion with the serving DU based on a connection to the target CU for continuous service support.

[0014] In order to solve the above problems, the present disclosure discloses a serving distributed unit (DU) in a communication system, comprising: a transceiver; and a control unit connected to the transceiver; wherein the control unit receives a message for a switching-off instruction from a serving central unit (CU), transmits a setup request message to a target CU based on the message for the switching-off instruction, receives a setup response message from the target CU in response to the setup request message, transmits an acknowledgment message including information related to the target CU to the serving CU in response to the message for the switching-off instruction, and performs a connection to the target CU for continuous service support based on the switching-off instruction.

[0015] In order to solve the above problems, the present disclosure discloses a serving central unit (CU) in a communication system, comprising: a transceiver; and a control unit connected to the transceiver; wherein the control unit: transmits a message for a switching-off instruction to a serving distributed unit (DU), receives an acknowledgment message including information related to a target CU from the serving DU in response to the message for the switching-off instruction, and performs interface connection deletion with the serving DU based on a connection to the target CU for continuous service support.

[0016] According to one embodiment, a device and method for effectively providing a service in a mobile communication system are provided.

[0017] In connection with one embodiment, a method and device are provided for effectively supporting energy saving and operation error recovery of a Central Unit (CU) in a structure in which base station functions are separated (split RAN).

[0018] The effects that can be obtained from the present invention are not limited to the effects mentioned above, and other effects not mentioned can be clearly understood by a person having ordinary skill in the art to which the present disclosure pertains from the description below.

[0019] FIG. 1 is a diagram illustrating the structure of a separate mobile communication base station system according to one embodiment of the present disclosure.

[0020] FIG. 2A is a diagram illustrating a connection state between entities in a separate mobile communication base station according to one embodiment of the present disclosure.

[0021] FIG. 2b is a diagram illustrating a connection state between entities in a separate mobile communication base station according to an embodiment of the present disclosure.

[0022] FIG. 3A is a diagram illustrating a process for energy saving of a mobile communication base station or error recovery in a central unit (CU) according to one embodiment of the present disclosure.

[0023] FIG. 3b is a diagram illustrating a process for energy saving of a mobile communication base station or error recovery in a central unit (CU) according to one embodiment of the present disclosure.

[0024] FIG. 4 is a diagram illustrating a switching off process in a serving CU according to one embodiment of the present disclosure.

[0025] FIG. 5A is a diagram illustrating the configuration of a message used to transmit an indication that a CU switching off procedure can be initiated according to one embodiment of the present disclosure.

[0026] FIG. 5b is a diagram illustrating the configuration of a message for transmitting a response to a CU switching off process according to one embodiment of the present disclosure.

[0027] FIG. 5c is a diagram illustrating the configuration of a CU Name Information Element (IE) according to one embodiment of the present disclosure.

[0028] FIG. 5d is a diagram illustrating the configuration of a Transport Layer Information IE according to one embodiment of the present disclosure.

[0029] FIG. 5e is a diagram illustrating a configuration of information for indicating a cell identifier according to one embodiment of the present disclosure.

[0030] FIG. 6a is a diagram illustrating the configuration of an interface setup request message between a central unit and a distributed unit (DU) according to one embodiment of the present disclosure.

[0031] FIG. 6b is a diagram illustrating the configuration of an interface setup request response message between a central unit and a distribution unit according to one embodiment of the present disclosure.

[0032] FIG. 7 is a diagram illustrating the configuration of a handover request message between base stations according to one embodiment of the present disclosure.

[0033] FIG. 8 is a diagram illustrating the configuration of a message related to a terminal context setting request according to an embodiment of the present disclosure.

[0034] FIG. 9A is a diagram illustrating a process for energy saving of a mobile communication base station or error recovery in a central unit according to one embodiment of the present disclosure.

[0035] FIG. 9b is a diagram illustrating a process for energy saving of a mobile communication base station or error recovery in a central unit according to one embodiment of the present disclosure.

[0036] FIG. 10 is a diagram illustrating a process for switching off a serving CU according to one embodiment of the present disclosure.

[0037] FIG. 11a is a diagram illustrating the configuration of a GNB SWITCHING OFF INDICATION message according to one embodiment of the present disclosure.

[0038] FIG. 11b is a diagram illustrating the configuration of a GNB SWITCHING OFF INDICATION ACKNOWLEDGE message according to one embodiment of the present disclosure.

[0039] FIG. 12a is a diagram illustrating the configuration of a message related to UE context transfer according to one embodiment of the present disclosure.

[0040] FIG. 12b is a diagram illustrating the configuration of a message related to a UE context transfer acknowledge according to one embodiment of the present disclosure.

[0041] FIG. 13a is a diagram illustrating the configuration of a UE CONTEXT SWITCH REQUEST message according to one embodiment of the present disclosure.

[0042] FIG. 13b is a diagram illustrating the configuration of a UE CONTEXT SWITCH RESPONSE message according to one embodiment of the present disclosure.

[0043] FIG. 14 is a diagram illustrating a process for energy saving of a mobile communication base station or error recovery in a CU according to one embodiment of the present disclosure.

[0044] FIG. 15a is a diagram illustrating a process for energy saving of a mobile communication base station or error recovery in a CU according to one embodiment of the present disclosure.

[0045] FIG. 15b is a diagram illustrating a process for energy saving of a mobile communication base station or error recovery in a CU according to one embodiment of the present disclosure.

[0046] FIG. 16 is a diagram illustrating a process for switching off a serving CU according to one embodiment of the present disclosure.

[0047] FIG. 17a is a diagram illustrating the configuration of a CU switching request message according to one embodiment of the present disclosure.

[0048] FIG. 17b is a diagram illustrating the configuration of a CU switching response message according to one embodiment of the present disclosure.

[0049] FIG. 18a is a diagram illustrating the configuration of a CU context transfer message according to one embodiment of the present disclosure.

[0050] FIG. 18b is a diagram illustrating the configuration of a CU context transfer acknowledge message according to an embodiment of the present disclosure.

[0051] FIG. 19 is a diagram illustrating the configuration of a RAN Node according to one embodiment of the present invention.

[0052] Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the attached drawings. It should be noted that, where possible, identical components are represented by identical reference numerals throughout the attached drawings. Furthermore, detailed descriptions of well-known functions and configurations that may obscure the gist of the present invention will be omitted.

[0053] In describing the embodiments herein, descriptions of technical details that are well known in the technical field to which the present disclosure pertains and are not directly related to the present invention will be omitted. This is to avoid obscuring the gist of the present disclosure by omitting unnecessary explanations and to convey the gist more clearly.

[0054] For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically depicted. Furthermore, the dimensions of each component do not entirely reflect its actual size. Identical or corresponding components in each drawing are assigned the same reference numbers.

[0055] The advantages and features of the present disclosure, and methods for achieving them, will become clearer with reference to the embodiments described below in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided only to ensure that the disclosure of the present disclosure is complete and to fully inform those skilled in the art of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

[0056] At this time, it will be understood that each block of the processing flow diagrams and combinations of the flow diagrams can be performed by computer program instructions. These computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flow diagram block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can direct a computer or other programmable data processing equipment to implement the functions in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured item that includes an instruction means for performing the functions described in the flow diagram block(s). Since the computer program instructions may be installed on a computer or other programmable data processing device, a series of operational steps may be performed on the computer or other programmable data processing device to create a computer-executable process, and the instructions that cause the computer or other programmable data processing device to perform the steps for performing the functions described in the flowchart block(s) may also provide steps for performing the functions described in the flowchart block(s).

[0057] Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a specific logical function(s). It should also be noted that in some alternative implementation examples, the functions described in the blocks may occur out of order. For example, two blocks depicted in succession may actually be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on their respective functions.

[0058] Here, the term '~ unit' used in the present embodiment means a software or hardware component such as an FPGA or ASIC, and the '~ unit' performs certain roles. However, the '~ unit' is not limited to software or hardware. The '~ unit' may be configured to be on an addressable storage medium and may be configured to play one or more processors. Accordingly, as an example, the '~ unit' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and '~ units' may be combined into a smaller number of components and '~ units' or further separated into additional components and '~ units'. Additionally, components and '~parts' may be implemented to regenerate one or more CPUs within a device or secure multimedia card.

[0059] Hereinafter, a base station is an entity that performs resource allocation of a terminal, and may be at least one of a Node B, a BS (Base Station), an eNB (eNode B), a gNB (gNode B), a wireless access unit, a base station controller, or a node on a network. The terminal may include a UE (User Equipment), an MS (Mobile Station), a cellular phone, a smartphone, a computer, or a multimedia system capable of performing a communication function. In addition, the embodiments of the present disclosure may be applied to other communication systems having a similar technical background or channel type to the embodiments of the present disclosure described below. In addition, the embodiments of the present disclosure may be applied to other communication systems through some modifications without significantly departing from the scope of the present disclosure at the discretion of a person having skilled technical knowledge.

[0060] In the following description, terms used to identify connection nodes, terms referring to network entities or network functions (NFs), terms referring to messages, terms referring to interfaces between network objects, terms referring to various identification information, etc. are provided as examples for convenience of explanation. Therefore, the present disclosure is not limited to the terms described below, and other terms referring to objects having equivalent technical meanings may be used.

[0061] For convenience of explanation, some terms and names defined in the 3rd generation partnership project long-term evolution (3GPP) standards may be used. However, the present disclosure is not limited to these terms and names, and can be equally applied to systems conforming to other standards.

[0062] In the following description of the present invention, detailed descriptions of known functions or configurations will be omitted if they are deemed to unnecessarily obscure the gist of the present invention. Hereinafter, embodiments of the present invention will be described with reference to the attached drawings.

[0063] Figure 1 illustrates the structure of a separate mobile communication base station system.

[0064] According to one embodiment, a RAN (radio access network) Node (20) may include a Central Unit (CU) (22) and a Distributed Unit (DU) (24). The CU (22) may include a CU-CP (Central Unit - Control Plane) for processing an RRC (radio resource control) layer and a CU-UP (Central Unit - User Plane) for processing data packets of a terminal. In one embodiment, the RAN Node (20), which is a base station, may be composed of one CU (22) and one or more DUs (24) connected thereto, or may be composed of a combination other than the present combination. The RAN Node (20) may be a 5G (5 th 4G (4 generation) base station (e.g. gNodeB: gNB) or LTE (long term evolution) supporting 4G (4 th It can be a 6G base station (e.g., eNodeB: eNB) and a later 6G base station.

[0065] The CU (22) and DU (24) can support the functions of each base station (e.g., base station or gNB) separately. For example, the CU (22) can support the RRC layer that processes control signals to be transmitted to the terminal and the PDCP (packet data convergence protocol) layer that processes data packets of the terminal. The DU (24) can support the RLC (radio link control) layer, the MAC (medium access control) layer, and the PHY (physical) layer, and can be in charge of communication with the terminal (10) in the wireless section.

[0066] Depending on the base station function supported by the RAN Node, at least one of the functions supported by the CU (22) and DU (24) constituting the RAN Node, and the names of each function or entity constituting the RAN Node may be different.

[0067] The CU (22) and DU (24) within the RAN Node may be connected through interfaces between internal functions of the base station, such as the F1 or W1 interface. The interface of F1 or W1 may be composed of F1-C and W1-C of the control plane for transmitting control information and F1-U and W1-U of the user plane for transmitting user data information and PDCP status packets of the terminal.

[0068] The RAN Node (20) can be connected to other RAN Nodes using an interface between base stations, such as an X2 or Xn interface. The RAN Node (20) can be connected to a CN (Core Network) (30) using an interface between base stations and a Core Network, such as an S1 or NG interface. The Core Network can be composed of multiple functions or entities, and the functions or entities supported by the Core Network can be different depending on the type of system.

[0069] For example, in a 5G system, an NR base station (e.g., gNB) is connected to a 5G core network, the 5G Core Network (5GC), and can be connected to an Access and Mobility Management Function (AMF) within the 5GC. In a 4G system, an LTE base station (e.g., eNB) is connected to an Evolved Packet Core (EPC), the 4G core network, and can be connected to a Mobility Management Entity (MME) within the EPC.

[0070] Figures 2a and 2b illustrate connection states between entities in a separate mobile communication base station.

[0071] According to one embodiment, the connection status between entities in a mobile communication base station may include the functions of each entity before and after a process for energy saving or error recovery in the CU.

[0072] Figure 2a illustrates the connection state of CU 1 (22-a) in a separate mobile communication base station.

[0073] According to one embodiment, CU 1 (22-a) of a separate mobile communication base station may be connected to a core network (CN) (30). In addition, CU 1 (22-a) may be connected to DU 1 (24-a) and DU 2 (24-b), and may provide mobile communication services to a terminal (10) through DU 2 (24-b).

[0074] CU 2 (22-b) may be connected to CN (30). In addition, CU 2 (22-b) may be connected to DU 3 (24-c) and DU 4 (24-d), and may provide mobile communication services to other terminals through DU 3 (24-c) and DU 4 (24-d).

[0075] In the connection state illustrated in FIG. 2a, the operation of CU 1 (22-a) may be stopped or the use of the CU 1 (22-a) processor may be stopped in order to save energy of the mobile communication base station or to recover from an operation error in the CU. When it is decided to stop the operation of CU 1 (22-a), to stop the use of the CU 1 (22-a) processor, or to turn off part or all of the power of the device supporting CU 1 (22-a), a procedure may be performed to enable information related to the mobile communication service supported by CU 1 (22-a) to be supported through another CU.

[0076] Fig. 2b illustrates the connection state of CU 2 (22-b) in a separate mobile communication base station.

[0077] According to one embodiment, the CN can continuously provide mobile communication services to a terminal (10) that was providing mobile communication services through CU 1 (22-a) through CU 2 (22-b).

[0078] For example, DU 1 (24-a) and DU 2 (24-b), which were providing mobile communication services through CU 1 (22-a), newly establish a connection with CU 2 (22-b), and a terminal (10) connected to DU 2 (24-b) can receive mobile communication services through DU 2 (24-b) and CU 2 (22-b).

[0079] The processor of CU 1(22-a) for CU 1(22-a) may be in a stopped state, or part or all of the power of the device supporting CU 1(22-a) may be turned off, thereby reducing energy usage of the entire mobile communication base station.

[0080] Figures 3a and 3b illustrate a process for energy saving in a mobile communication base station or error recovery in a CU.

[0081] According to one embodiment, FIGS. 3A and 3B disclose a series of procedures for suspending the functions of some CUs (Central Units), suspending the use of a processor supporting the CUs, or powering off part or all of the power of a device supporting the CUs, in order to save energy in a mobile communication base station or recover from errors in the CUs. To save energy or recover from errors in the CUs, a terminal connected to a CU and receiving mobile communication services can be connected to another operating CU through a handover procedure without losing connection with the CU. Accordingly, the terminal can continuously receive mobile communication services.

[0082] Although only one DU and one terminal (UE: User Equipment) are disclosed in FIGS. 3a and 3b, the procedures of FIGS. 3a and 3b may be performed similarly for all DUs connected to a CU and all terminals connected to the CU. Furthermore, the same procedures for other DUs and other terminals may be omitted in FIGS. 3a and 3b.

[0083] Referring to FIGS. 3a and 3b, in step 100, the terminal(s) (10) can receive mobile communication services by connecting to the CN (30) through the connected serving DU (24) and serving CU (22-a).

[0084] In step 200, a serving CU (22-a) supporting a mobile communication service connection of a terminal (10) may decide to stop its function for energy saving, stop using a processor to support the serving CU (22-a), or switch off part or all of the power of the supporting device. Switching off in the CU (22-a) may be determined or performed by considering at least one of the following factors.

[0085] - Number of terminals connected to and supported by the CU (or number of RRC connections)

[0086] - The level of load supported by the CU (load status)

[0087] - Request by OAM (triggered by OAM)

[0088] -> OAM can decide to switch off a CU based on CU management, the number of terminals connected to the CU, the load level of the CU, an upgrade of the CU, a partial failure of the CU, or other reasons, and can request switching off to the CU.

[0089] -> CU switching-off request information in OAM may include at least one of a switching-off indication (instant indicator), CU switching-off scheduled time or schedule information, parameter information for determining switching-off in the CU, the number of terminals in a connection state, and the load level of the CU.

[0090] - Error detection and other internal reasons and algorithms within the CU

[0091] If the serving CU (22-a) decides to initiate a switching off procedure, at step 210, the serving CU (22-a) may transmit or forward an indication (e.g., a CU switching off indication) to the serving DU (24) indicating that the CU can initiate a switching off procedure.

[0092] The CU switching off indication can be used by defining a new message to be passed from the CU to the DU, or by adding relevant information to a management message passed from the CU to the DU (e.g., the GNB-CU CONFIGURATION UPDATE message in F1AP).

[0093] The CU switching off indication message may include at least one of the following: information related to a target CU to which the serving DU (24) must newly connect; information on an existing cell identifier (e.g., NCGI (NR Cell Global Identifier)) in each serving cell supported by the serving DU (24) when connecting to a new target CU; and a new cell identifier.

[0094] When the serving DU (24) receives a CU switching off indication from the serving CU (22-a), the serving DU (24) can determine a new CU to connect to in step 215. When the serving DU (24) determines a new CU to connect to, at least one of the following information can be used.

[0095] - CU information to be used when changing the CU configured in OAM and new cell identifier information for each serving cell

[0096] - New CU information received from the currently connected CU and new cell identifier information from each serving cell.

[0097] When the serving DU (24) determines a new CU to connect to, the serving DU can transmit a setup request message (e.g., an F1 SETUP REQUEST message) for connection with the target CU (22-b) in step 220.

[0098] The CU switching off indication message may include a transport layer connection procedure for transmitting control messages between CUs and DUs (e.g., procedures such as SCTP (Stream Control Transmission Protocol) connection establishment).

[0099] The setup request message may include information that the CU to which the serving DU (24) was connected is switching off and requesting a connection to a new CU.

[0100] After performing processing according to the CU-DU connection setup message, the target CU (22-b) can transmit a response message (e.g., an F1 SETUP RESPONSE message) to the setup request message to the serving DU (24) in step 230.

[0101] After the serving DU (24) establishes a connection with a new target CU (22-b), in step 240, the serving DU (24) can transmit a response message (e.g., CU switching off indication acknowledge) for CU switching off to the serving CU (22-a).

[0102] The CU switching off indication acknowledge can be used by defining a new message to be passed from the DU to the CU, or by adding relevant information to a management message passed from the DU to the CU (e.g., the GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE message in F1AP).

[0103] The CU switching off indication acknowledge message may include at least one of information related to a target CU to which the serving CU is newly connected, information on existing cell identifiers (e.g., NCGI (NR Cell Global Identifier)) in each serving cell supported by the serving DU (24) when connecting to a new target CU from the serving DU (24), and a new cell identifier.

[0104] At step 250, the serving DU (24) can perform setting changes and operations in the serving DU (24) based on connection information with the newly connected target CU.

[0105] When the serving CU (22-a) receives or transmits a CU switching off indication acknowledgement from the serving DU (24), it performs a handover procedure for all terminals connected to the serving DU (24). To this end, in step 300, the serving CU (22-a) may transmit a handover request message (e.g., a HANDOVER REQUEST message) to the target CU (24-b).

[0106] In step 300, the serving CU (22-a) may determine a CU to which to transmit a handover request message using at least one of the information transmitted or received from the serving DU (24) in step 240. In addition, information about the target cell (e.g., target NCGI) may be determined, and the information may be included in the handover request message.

[0107] The handover request message may include at least one of information that the handover request was initiated due to switching off of the serving CU, an identifier used as a terminal identifier or identifier in the connection between the serving CU (22-a) and the serving DU (24) (e.g., gNB-CU UE F1AP ID used in the F1 interface), and a gNB-DU UE F1AP ID.

[0108] The target CU (22-b) that has received the handover request message can transmit a UE context setup request message (e.g., a UE CONTEXT SETUP REQUEST message) to the serving DU (24) in step 310.

[0109] The UE context setup request message may include at least one of an indicator that it is transmitted due to switching off of the serving CU, an identifier used as a terminal identifier in the connection between the serving CU (22-a) and the serving DU (24) received from the serving CU in step 300 (e.g., gNB-CU UE F1AP ID used in the F1 interface), and a gNB-DU UE F1AP ID.

[0110] The serving DU (24) that has received the UE context setup request message can perform an operation related to UE context setup and then transmit a UE context setup response message (e.g., a UE CONTEXT SETUP RESPONSE message) to the target CU (22-b) in step 320.

[0111] The target CU (22-b), which has received a UE context setup response message from the serving DU (24), can transmit a handover request response message (e.g., a HANDOVER REQUEST ACKNOWLEDGE message) to the serving CU (22-a) in step 330.

[0112] The source CU (22-a) that receives a handover request response message from the target CU (22-b) can generate an RRC message (e.g., an RRCReconfiguration message) including handover-related information to be transmitted to the terminal (10), and then transmit a UE context change (or modification) request message (e.g., a UE CONTEXT MODIFICATION REQUEST message) to the serving DU (24) in step 340.

[0113] In step 350, the serving DU (24) can transmit an RRC message (e.g., an RRCReconfiguration message) received from the serving CU to the terminal (10).

[0114] At step 360, the serving DU (24) may transmit a UE context change response message (e.g., a UE CONTEXT MODIFICATION RESPONSE message) to the serving CU (22-a).

[0115] At step 400, the serving CU (22-a) may transmit a message (e.g., an SN STATUS TRANSFER message) containing PDCP SN (Sequence Number) related information to the target CU (22-b).

[0116] In step 410, the serving CU (22-a) can transfer the user data stored in the serving CU (22-a) to the target CU (22-b).

[0117] A terminal (10) that has received an RRC reset message (e.g., an RRCReconfiguration message) from a base station can perform a random access procedure with a serving DU (24-b) in step 500.

[0118] In step 510, the terminal (10) can transmit an RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to the base station.

[0119] The serving DU (24) that has received the RRC reconfiguration completion message from the terminal (10) can transmit an uplink RRC message transfer message (e.g., UL RRC MESSAGE TRANSFER message) including the RRC message transmitted by the terminal in step 520 to the target CU (22-b).

[0120] The target CU (22-b) that has received the RRC reset completion message from the terminal (10) can transmit a request message (e.g., a PATH SWITCH REQUEST message) to the CN (30) to change the path information for transmitting the terminal's user data in step 600.

[0121] CN (30) may transmit a response message (e.g., PATH SWITCH REQUEST ACKNOWLEDGE message) to change path information in response to the request message to change path information to target CN (22-b) in step 610.

[0122] In step 620, the target CU (22-b) may transmit a message (e.g., a UE CONTEXT RELEASE message) indicating that handover of the terminal to the serving CU (22-a) is complete and that deletion (or release) of the terminal context information stored in the serving CU (22-a) is possible.

[0123] In step 700, the serving CU (22-a) can confirm that all connected terminals that it was serving have completed handover to one or more other CUs through the procedures from step 210 to step 620.

[0124] The serving CU (22-a) can perform an interface removal procedure (e.g., F1 removal procedure with all connected DUs) with the serving DU (24) connected to the serving CU (22-a) in step 710.

[0125] The serving CU (22-a) may perform an interface connection deletion procedure (e.g., NG removal procedure with all connected AMFs (CN functions)) with the CN (30) connected to the serving CU (22-a) at step 720.

[0126] The serving CU (22-a) may perform an interface connection deletion procedure (e.g., Xn removal procedure with all neighbor gNBs (gNB-CUs)) with the target CU (22-b) connected to the serving CU (22-a) at step 730.

[0127] At step 800, the serving CU (22-a) may perform other procedures for switching off to complete the switching off procedure of the serving CU (22-a).

[0128] Figure 4 illustrates the switching off process in a serving CU.

[0129] Referring to FIG. 4, the switching off procedure of the CU may be initiated at step 100.

[0130] In step 200, the serving CU may transmit a CU switching off indication message to all connected DUs indicating that the CU is switching off, and may receive a CU switching off indication acknowledge message from the DUs in response to the CU switching off indication message.

[0131] The CU switching off indication message may contain information regarding the target CU to which the DU needs to newly connect.

[0132] For all terminals in a connected state, the DU connected to each terminal can perform a handover procedure to another CU that is newly connected to the terminal in step 300.

[0133] After completing the handover procedure for all terminals that were connected, the serving CU can perform a procedure of deleting (interface removal) the network interface connection with all currently connected DUs and neighboring base stations (or CUs of neighboring base stations) and CNs in step 400.

[0134] After all other procedures for CU switching off have been completed, the serving CU can perform switching off at step 500.

[0135] FIGS. 5A to 5E are diagrams illustrating the configuration of messages for performing CU switching off.

[0136] The messages of FIGS. 5a to 5e are examples of cases where new messages are defined and used, and related information can be added to and used in messages for management purposes transmitted from an existing CU to a DU (e.g., a GNB-CU CONFIGURATION UPDATE message or a GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE message in F1AP).

[0137] The message names or IE names used in FIGS. 5A to 5E are one embodiment and may be configured with other names or other forms of configuration or values ​​for the same purpose.

[0138] Figure 5a illustrates the structure of a message (e.g., a GNB-CU SWITCHING OFF INDICATION message) used to transmit an indication (e.g., a CU switching off indication) that a CU can initiate a switching off procedure.

[0139] The GNB-CU SWITCHING OFF INDICATION message may include a Message Type IE used to distinguish the message type, a Transaction ID IE used to distinguish the message transmission (transaction), and at least one of the following information may be included separately: Service State IE information for conveying the current state of the CU (e.g., information such as 'in-Service' or 'out-of-Service'), and a Switching Off Ongoing IE indicating that the CU will switch off.

[0140] The GNB-CU SWITCHING OFF INDICATION message may include a Candidate Migration CU List IE, which is information on the CUs to which the DU should newly connect. The Candidate Migration CU information may be zero, may contain information on only one CU, or may contain information on more than one CU.

[0141] The Candidate Migration CU List IE may contain information per CU, and may include a gNB-CU Name IE indicating the name of the information CU for each CU. The specific configuration of the gNB-CU Name IE is described in Fig. 5c.

[0142] Figure 5c is a diagram illustrating an example configuration of a gNB-CU Name IE.

[0143] Figure 5c shows that the gNB-CU Name IE can be displayed in various forms that can be displayed in a human-readable form, such as Printable String form, Visible String form, UTF8 String form, etc.

[0144] Additionally, the Candidate Migration CU information may include at least one of the gNB-CU ID IE, which includes the identifier information of the CU, and the TNL Association Layer Information IE, which is the TNL (Transport Network Layer) related information of the CU that can be used for connection with the CU. The specific configuration of the TNL Association Layer Information IE is described in Fig. 5d.

[0145] Figure 5d illustrates an example of configuring a TNL Association Layer Information IE.

[0146] Referring to Fig. 5d, it may include information such as an IP address and port number for establishing a connection with the CU.

[0147] Additionally, the Candidate Migration CU information may include at least one of the current cell identifier information (e.g., Current NCGI IE) for each serving cell of the DU and a new cell identifier (e.g., New NCGI IE information) to be used by the newly connected CU. The specific configuration of the cell identifier is described in FIG. 5e.

[0148] Figure 5e illustrates an example of the configuration of information for indicating a cell identifier. The cell identifier may include a PLMN identity IE indicating operator information and an NR Cell Identity IE for cell differentiation.

[0149] Figure 5b illustrates the configuration of a message (e.g., CU switching off indication acknowledge) used to transmit a response to a CU switching off proceeding.

[0150] The GNB-CU SWITCHING OFF INDICATION ACKNOWLEDGE message can be used to transmit a CU switching off indication acknowledge.

[0151] The GNB-CU SWITCHING OFF INDICATION ACKNOWLEDGE message may include a Message Type IE used to distinguish the message type and a Transaction ID IE used to distinguish the message transmission (transaction). The GNB-CU SWITCHING OFF INDICATION ACKNOWLEDGE message may include a Target CU Info IE, which is information about a CU newly connected by the DU.

[0152] The Target CU Info IE may include gNB-CU Name IE that indicates the name of the CU as target CU information, gNB-CU ID IE that includes identifier information of the CU, and TNL Association Layer Information IE that is information related to the TNL (Transport Network Layer) of the CU that can be used for connection with the CU. In addition, the Target CU Info IE may include current cell identifier information for each serving cell of the DU (e.g., Current NCGI IE and new cell identifier to be used by the newly connected CU, or New NCGI IE information).

[0153] Figures 6a and 6b illustrate the configuration of an interface setup message between a DU and a CU. The messages in Figures 6a and 6b are examples of messages related to the F1 setup procedure of the F1 interface, which is an interface between a gNB-DU and a gNB-CU. The IE names used in Figures 6a and 6b are examples, and other names or other configurations or values ​​for the same purpose may be used.

[0154] FIG. 6a is a diagram illustrating the configuration of an interface setup request message (e.g., F1 SETUP REQUEST message) between a CU and a DU.

[0155] The F1 SETUP REQUEST message may include a Message Type IE used to distinguish the message type and a Transaction ID IE used to distinguish the message transmission (transaction). In addition, the F1 SETUP REQUEST message may include other information related to the gNB-DU along with a gNB-DU ID IE containing the identifier information of the DU. In addition, the F1 SETUP REQUEST message may include a Triggering Cause IE, which is information on the cause of the DU requesting the F1 setup, and the Triggering Cause IE may include information that the DU is transmitted due to the switching off of the CU to which it was previously connected. The information that the F1 setup procedure is initiated due to the switching off of the CU may be included in the existing Cause IE information, not the Triggering Cause IE.

[0156] Additionally, the F1 SETUP REQUEST message may include Old CU Info IE, which is CU information to which the DU (Distributed Unit) was connected. The Old CU Info IE may include at least one of gNB-CU Name IE indicating the name of the CU, gNB-CU ID IE including identifier information of the CU, and TNL Association Layer Information IE information, which is TNL (Transport Network Layer) related information of the CU that can be used for connection with the CU. The gNB-CU Name IE included in the Old CU Info IE may be as in the configuration example of FIG. 5c, and the TNL Association Layer Information IE may be as in the configuration example of FIG. 5d.

[0157] Figure 6b illustrates the configuration of an interface setup request response message (e.g., F1 SETUP RESPONSE message) between a CU and a DU.

[0158] The F1 SETUP RESPONSE message may include a Message Type IE used to distinguish the message type and a Transaction ID IE used to distinguish the message transmission (transaction). In addition, the F1 SETUP RESPONSE message may include a gNB-CU Name IE indicating the name of the CU, along with other information related to the gNB-CU. The gNB-CU Name IE may have the same configuration as in FIG. 5c. In addition, the F1 SETUP RESPONSE message may include at least one of the gNB-CU ID IE information including the identifier information of the CU.

[0159] Figure 7 illustrates the configuration of a handover request message between base stations.

[0160] The handover request message is an example of a message configuration related to a handover request on the Xn interface, which is an interface between a gNB or a gNB-CU. The IE name used in FIG. 7 is an example, and the message can be configured with a different name or a different form or value for the same purpose.

[0161] The handover request message includes a Message Type IE used to distinguish the message type, a Source NG-RAN node UE XnAP ID reference IE which is a terminal identifier on the Xn interface used by the source NG-RAN node, and may include other information related to the handover request. In addition, the HANDOVER REQUEST message may include a Triggering Cause IE which is information on the cause of the handover request from the source NG-RAN node.

[0162] The Triggering Cause IE may contain information that the CU of the source base station is being transmitted as switching off.

[0163] Information that a handover request procedure is initiated due to the switching off of the CU can be transmitted by including it in the existing Cause IE information.

[0164] The HANDOVER REQUEST message may include a Source NG-RAN node UE F1AP ID reference IE containing information related to the identifier of the UE used on the F1 interface between the CU and DU within the source NG-RAN node.

[0165] The Source NG-RAN node UE F1AP ID reference IE may include at least one of a gNB-CU Name IE indicating the name of the CU of the source base station (source NG-RAN node), a gNB-CU ID IE including identifier information of the CU, a TNL Association Layer Information IE information which is information related to the TNL (Transport Network Layer) of the CU that can be used for connection with the CU, and a gNB-CU UE F1AP ID IE and a gNB-DU UE F1AP ID which are terminal identifiers in the CU and DU, respectively, on the F1 interface. The gNB-CU Name IE included in the Source NG-RAN node UE F1AP ID reference IE may be as in the configuration example of FIG. 5c, and the TNL Association Layer Information IE may be as in the configuration example of FIG. 5d.

[0166] Figure 8 illustrates the structure of a message related to a terminal context setup (or configuration) request (e.g., a UE CONTET SETUP REQUEST message).

[0167] The message related to the UE context setup request is an example of a message configuration related to the UE context setup request on the F1 interface, which is the interface between the gNB-CU and the gNB-DU. The IE name used in FIG. 8 is an example, and the message may be configured with a different name or a different form or value for the same purpose.

[0168] The UE CONTEXT SETUP REQUEST message may include a Message Type IE used to distinguish the message type, gNB-CU UE F1AP ID IE and gNB-DU UE F1AP ID which are terminal identifiers in the CU and DU respectively in the F1 interface, and other information related to UE context setup. In addition, the UE CONTEXT SETUP REQUEST message may include a Triggering Cause IE which is information on the cause of requesting UE context setup, and the Triggering Cause IE may include information that the CU of the old NG-RAN node is being switched off.

[0169] Information that a handover request procedure is initiated due to the switching off of the CU can be transmitted by including it in the existing Cause IE information.

[0170] The UE CONTEXT SETUP REQUEST message may include an Old NG-RAN node UE F1AP ID reference IE containing information related to an identifier of a terminal used in the F1 interface between a CU and a DU within an old NG-RAN node. The Old NG-RAN node UE F1AP ID reference IE may include at least one of a gNB-CU Name IE indicating a name of a CU of the old NG-RAN node, a gNB-CU ID IE containing identifier information of the CU, a TNL Association Layer Information IE information related to a TNL (Transport Network Layer) of the CU that can be used for connection with the CU, and a gNB-CU UE F1AP ID IE and a gNB-DU UE F1AP ID which are terminal identifiers in the CU and the DU, respectively, in the F1 interface.

[0171] Figures 9a and 9b illustrate a process for energy saving in a mobile communication base station or error recovery in a central unit.

[0172] According to one embodiment, FIGS. 9A and 9B disclose a series of procedures for stopping the functions of some CUs (Central Units) and stopping the use of a processor supporting the CU, or powering off part or all of a device supporting the CU, in order to save energy in a mobile communication base station or recover from an error in the CU. A terminal receiving a mobile communication service while connected to a CU for energy saving or error recovery in the CU can continuously receive the mobile communication service without losing connection with other operating CUs through a terminal context (UE context) transmission (or transfer) procedure.

[0173] Although only one DU (Distributed Unit) and one UE (User Equipment) are included in FIGS. 9A and 9B, the procedure in FIG. 9 can be performed similarly for all DUs connected to the CU and all UEs connected to the CU. Furthermore, the same procedure for other DUs and other UEs can be omitted in FIGS. 9A and 9B.

[0174] Referring to FIGS. 9a and 9b, in step 100, the terminal(s) (10) can receive mobile communication services by connecting to the CN (30) through the connected serving DU (24) and serving CU (22-a).

[0175] In step 200, a serving CU (22-a) supporting a mobile communication service connection of a terminal (10) may decide to stop its function for energy saving, stop using a processor to support the serving CU (22-a), or switch off part or all of the power of the supporting device. Switching off in the CU may be decided or performed by considering at least one of the following factors.

[0176] - Number of terminals connected to and supported by the CU (or number of RRC connections)

[0177] - The level of load supported by the CU (load status)

[0178] - Request by OAM (triggered by OAM)

[0179] -> As OAM manages the CU, it can decide to switch off the CU based on the number of terminals connected to the CU, the load level of the CU, an upgrade of the CU, a partial failure of the CU, or other reasons, and can request switching off to the CU.

[0180] -> CU switching-off request information in OAM may include at least one of a switching-off indication (instant indicator), CU switching-off scheduled time or schedule information, parameter information for determining switching-off in the CU, the number of terminals in a connection state, and the load level of the CU.

[0181] - Error detection and other internal reasons and algorithms within the CU

[0182] When the serving CU (22-a) decides to initiate a switching off procedure, at step 210, the serving CU (22-a) may transmit or transmit an indication (e.g., a CU switching off indication) to the surrounding CUs that the DUs connected to the serving CU (22-a) need to newly connect to initiate a switching off procedure.

[0183] When a DU (Distributed Unit) connected to a Serving CU (22-a) determines a new CU to connect to, at least one of the following information may be used.

[0184] - When changing the CU configured in OAM, the CU information to be used and the new cell identifier information for each serving cell

[0185] - New CU information received from the currently connected CU and new cell identifier information from each serving cell.

[0186] Step 210 only includes transmission to one target CU (22-b), but more than one target CU may be used. The CU switching off indication transmitted from the Serving CU (22-a) to the target CU (22-b) may be used by defining a new message transmitted between base stations, or by adding relevant information to a message for management purposes transmitted between base stations (e.g., an NG-RAN NODE CONFIGURATION UPDATE message in XnAP).

[0187] The CU switching off indication message may include information related to serving DUs that can change their connection to the target CU (22-b) among the serving DUs connected to the serving CU (22-a).

[0188] When the target CU (22-b) receives a CU switching off indication from the serving CU (22-a), the target CU (22-b) can transmit a response message (e.g., CU switching off indication acknowledge) regarding the CU switching off process to the serving CU (22-a) at step 220.

[0189] At step 230, the serving CU (22-a) may transmit an indication (e.g., a CU switching off indication) to the serving DU (24) indicating that the CU can initiate a switching off procedure. The CU switching off indication may be used by defining a new message transmitted from the CU to the DU, or by adding relevant information to a management message transmitted from the CU to the DU (e.g., a GNB-CU CONFIGURATION UPDATE message in F1AP).

[0190] The CU switching off indication message may include at least one of information related to a target CU to which the serving DU (24) must newly connect, information on an existing cell identifier (e.g., NCGI (NR Cell Global Identifier)) in each serving cell supported by the serving DU (24) when connecting to a new target CU from the serving DU (24), and a new cell identifier.

[0191] When a serving DU (24) receives a CU switching off indication from a serving CU (22-a) to which it is currently connected, the serving DU (24) can determine a new CU to connect to in step 235. When the DU determines a new CU to connect to, at least one of the following information may be used.

[0192] - CU information to be used when changing the CU configured in OAM and new cell identifier information for each serving cell

[0193] - New CU information received from the currently connected CU and new cell identifier information from each serving cell.

[0194] When the serving DU (24) determines a new CU to connect to, the CU may transmit a setup request message (e.g., an F1 SETUP REQUEST message) for connection with the target CU (22-b) in step 240. Step 240 may include a transport layer connection procedure (e.g., a procedure such as SCTP (Stream Control Transmission Protocol) connection setup) for transmitting control messages between CUs and DUs.

[0195] The setup request message may include information that the serving DU (24) is requesting a connection because the CU it was connected to is in the process of switching off.

[0196] After the target CU (22-b) performs processing according to the CU-DU connection setup message, in step 250, the target CU (22-b) can transmit a response message (e.g., an F1 SETUP RESPONSE message) to the setup request to the serving DU (24).

[0197] After the serving DU (24) establishes a connection with a new target CU (22-b), in step 260, the serving DU (24) can transmit a response message (e.g., a CU switching off indication acknowledge message) for CU switching off to the serving CU (22-a).

[0198] The CU switching off indication acknowledge can be used by defining a new message to be passed from the DU to the CU, or by adding relevant information to a management message passed from the DU to the CU (e.g., the GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE message in F1AP).

[0199] The CU switching off indication acknowledge message may include at least one of information related to a target CU to which the serving CU is newly connected, information on existing cell identifiers (e.g., NCGI (NR Cell Global Identifier)) in each serving cell supported by the serving DU (24) when connecting to a new target CU from the serving DU (24), and a new cell identifier.

[0200] In step 270, the serving DU (24) can perform setting changes and operations in the serving DU (24) based on connection information with the newly connected target CU.

[0201] The serving CU (22-a) that has received a CU switching off indication acknowledgement from the serving DU (24) can perform a UE context transfer procedure to target CUs for all terminals connected to the serving DU (24). To this end, in step 300, the serving CU (22-a) can transmit a UE transmission stop indication, which is an indication to stop data transmission of the corresponding terminal, to the serving DU (24).

[0202] The UE transmission stop indication can be conveyed by defining a new message on the interface between the CU and DU, or by using the Transmission Stop Indicator IE included in the existing UE CONTEXT MODIFCAITON REQUEST message.

[0203] The serving DU (24) that receives the UE transmission stop indication can stop transmission to the corresponding terminal and then send a response message with a UE transmission stop indication acknowledgment to the serving CU (22-a) at step 310. The existing UE CONTEXT MODIFCAITON RESPONSE message can also be used as the response message.

[0204] The serving CU (22-a) that has received a UE transmission stop indication acknowledge from the serving DU (24) can transmit a UE context transfer message (e.g., a UE CONTEXT TRANSFER message) to the target CU (24-b) in step 400.

[0205] The UE CONTEXT TRANSFER message may include at least one of context information of the corresponding terminal, serving DU information connected for the corresponding terminal service, and an identifier used as a terminal identifier in a connection between a serving CU (22-a) and a serving DU (24) (e.g., gNB-CU UE F1AP ID and gNB-DU UE F1AP ID used in the F1 interface).

[0206] The target CU (22-b) that has received the terminal context information can, after internal configuration, transmit a terminal context transfer response (UE context transfer acknowledge) message (e.g., a UE CONTEXT TRANSFER ACKNOWLEDGE message) to the serving CU (22-a) in response at step 410.

[0207] The UE CONTEXT TRANSFER ACKNOWLEDGE message may include at least one of information related to a PDU session, QoS flow, DRB that can be set up in the target CU (22-b), and address information for data forwarding from the source CU (22-a) to the target CU (22-b).

[0208] The source CU (22-a) that has received a UE context transfer acknowledgement from the target CU (22-b) can transmit an SN status transfer message to the target CU (22-b) in step 420.

[0209] The SN status transfer message may contain SN (sequence number) information related to data forwarding.

[0210] At step 430, the serving CU (22-a) can perform data forwarding of the terminal's user data to the target CU (22-b).

[0211] In step 500, the target CU (22-b) can transmit a UE context switching request (e.g., UE CONTEXT SWITCH REQUEST) message to the source DU (24) to change the connection interface between CUs to support the terminal being serviced.

[0212] The UE CONTEXT SWITCH REQUEST message may include information about the current serving CU serving the terminal, or an identifier used as a terminal identifier in a connection between the serving CU (22-a) and the serving DU (24) (e.g., gNB-CU UE F1AP ID and gNB-DU UE F1AP ID used in the F1 interface).

[0213] The serving DU (22-a) that has received a UE context switching request from the target CU (22-b) can change the internal configuration of the serving DU (22-a) so that it can transmit a UE associated signaling message for supporting the corresponding terminal from the serving CU (22-a) to the target CU (22-b) while maintaining the context and other configuration information configured for the corresponding terminal in step 500.

[0214] The serving DU (24) may transmit a UE context switching response (e.g., UE CONTEXT SWITCH RESPONSE) message to the target CU (22-b) in step 510.

[0215] The UE CONTEXT SWITCH RESPONSE message may include a new terminal identifier (or identifier) ​​(e.g., gNB-DU UE F1AP ID) set in the serving DU (24). Additionally, the UE CONTEXT SWITCH RESPONSE message may include RRC information that needs to be reset to the terminal (e.g., DU to CU RRC Information IE including CellGroupConfig IE, etc.).

[0216] The target CU (22-b) may generate an RRC reconfiguration message (e.g., an RRCReconfiguration message) to be transmitted to the terminal (10) in step 600, and then transmit or forward the message to the serving DU (24) through a downlink RRC message transfer message (e.g., a DL RRC MESSAGE TRANSFER message).

[0217] The serving DU (24) that has received an RRC message to be transmitted to the terminal from the target CU (22-b) can transmit an RRC reset message to the terminal (10) in step 610.

[0218] The terminal (10) that has received an RRC reset message (e.g., an RRCReconfiguration message) from the base station can perform a random access procedure with the serving DU (24-b) or another DU in step 620.

[0219] The terminal (10) can transmit an RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to the base station to the serving DU (24) at step 630.

[0220] The serving DU (24) that has received the RRC reset completion message from the terminal (10) can transmit the RRC message transmitted by the terminal in step 640 to the target CU (22-b) using an uplink RRC message transfer message (e.g., UL RRC MESSAGE TRANSFER message).

[0221] In step 700, the Target CU (22-b) can transmit a request message (e.g., a PATH SWITCH REQUEST message) to the CN (30) to change the path information for transferring user data between the CN (30) and the terminal.

[0222] The CN (30) that has received a request message for changing the path information from the target CU (22-b) can transmit a response message (e.g., a PATH SWITCH REQUEST ACKNOWLEDGE message) for changing the path information to the target CU (22-b) in response to the request message for changing the path information in step 710.

[0223] In step 720, the target CU (22-b) can transmit a message (e.g., a UE CONTEXT RELEASE message) to the serving CU (22-a) indicating that the UE context transfer procedure is completed and that the UE context information stored in the serving CU (22-a) can be deleted.

[0224] In step 800, the serving CU (22-a) can confirm that the context transfer of all connected terminals that it was serving through the procedures from step 210 to step 720 has been completed to one or more other CUs.

[0225] The serving CU (22-a), which has confirmed that context transfer to another CU has been completed, can perform an interface removal procedure (e.g., F1 removal procedure with all connected DUs) with the serving DU (24) connected to the serving CU (22-a) at step 810.

[0226] The serving CU (22-a), which has confirmed that context transfer to another CU has been completed, can perform an interface connection deletion procedure (e.g., NG removal procedure with all connected AMFs (CN functions)) with the CN (30) connected to the serving CU (22-a) at step 820.

[0227] The serving CU (22-a), which has confirmed that context transfer to another CU has been completed, can perform an interface connection deletion procedure (e.g., Xn removal procedure with all neighbor gNBs (gNB-CUs)) with the target CU (22-b) connected to the serving CU (22-a) at step 830.

[0228] At step 900, the serving CU (22-a) may perform other procedures for switching off to complete the switching off procedure of the serving CU (22-a).

[0229] Figure 10 illustrates a process for switching off a serving CU.

[0230] Referring to FIG. 10, the CU switching off procedure may be initiated at step 100.

[0231] In step 200, the serving CU can select target CUs to which the UE context will be transferred or transmitted.

[0232] In step 300, the serving CU may transmit a CU switching off indication message to target CUs indicating that the CU will perform switching off, and may receive a CU switching off indication acknowledge message from the target CU in response to the CU switching off indication message.

[0233] The CU switching off indication message may include information about DUs that can be connected to target CUs among the DUs currently connected to the CU.

[0234] In step 400, the serving CU may transmit a CU switching off indication to all connected Distributed Units (DUs) indicating that the CU will perform switching off. In addition, a CU switching off indication acknowledge message may be received from the DUs in response to the CU switching off indication message.

[0235] The CU switching off indication message may contain information about the target CU to which the DU needs to connect.

[0236] For all connected terminals, after each terminal transmits an indication to the DU to which it is connected to stop data transmission and reception of the terminal, in step 500, the serving CU can perform a procedure (UE context transfer) and data forwarding to transfer the context of the terminal to the target CU to which the DU is newly connected.

[0237] After completing the UE context transfer procedure for all connected terminals, the serving CU can perform an interface removal procedure for all currently connected DUs, neighboring base stations (or CUs of neighboring base stations), and network interface connections with the CN at step 600.

[0238] After all other procedures for CU switching off are completed, the serving CU can perform switching off at step 700.

[0239] Figure 11a illustrates the configuration of a CU switching off indication message that is transmitted from a serving CU (22-a) to surrounding CUs that require new connection by DUs connected to the serving CU (22-a).

[0240] A CU switching off indication message (e.g., a GNB SWTICHING OFF INDICATION message) may include indicator information indicating that a switching off procedure has begun. The message in FIG. 11a is an example of a message configuration related to the transmission of switching off information on the Xn interface, which is an interface between a gNB or a gNB-CU. The message name or IE name used in FIG. 11a is an example, and the message may be configured with a different name or a different form of configuration or value for the same purpose.

[0241] The GNB SWITCHING OFF INDICATION message may include a Message Type IE used to distinguish the message type and a Transaction ID IE used to distinguish the message transmission (transaction). Additionally, the GNB SWITCHING OFF INDICATION message may include a Service State IE used to convey the current status of the CU.

[0242] Service State IE may contain 'in-Service' and 'out-of-Service' information.

[0243] Additionally, a separate Switching Off Ongoing IE can be included to indicate that the CU is to proceed with switching off.

[0244] Additionally, the GNB SWITCHING OFF INDICATION message may include a Migration DU List IE containing information about one or more DUs that can perform a new connection to the CU receiving the GNB SWITCHING OFF INDICATION message.

[0245] The Migration DU List IE may include at least one of the following: information per DU included, a gNB-DU Name IE indicating the name of the DU with each DU information, a gNB-DU ID IE including identifier information of the DU, TNL Association Layer Information IE information which is information related to the TNL (Transport Network Layer) of the DU that can be used for connection with the DU, current cell identifier information per serving cell of the DU (e.g., Current NCGI IE), or a new cell identifier to be used by a newly connected CU (e.g., New NCGI IE information).

[0246] The gNB-DU Name IE may follow the configuration example of FIG. 5c, the TNL Association Layer Information IE may follow the configuration example of FIG. 5d, and the cell identifier may follow the configuration example of FIG. 5e.

[0247] Figure 11b illustrates the configuration of a CU switching off indication acknowledge message, which is a response to a CU switching off indication message transmitted by DUs connected to the serving CU (22-a) to surrounding CUs that require new connection.

[0248] A CU switching off indication acknowledge message (e.g., a GNB SWTICHING OFF INDICATION acknowledge message) may include indicator information indicating that a switching off procedure has begun. The message in FIG. 11b is an example of a message configuration related to transferring switching off information on the Xn interface, which is an interface between a gNB or a gNB-CU. The message name or IE name used in FIG. 11b is an example, and the message may be configured with a different name or a different form of configuration or value for the same purpose.

[0249] The GNB SWITCHING OFF INDICATION ACKNOWLEDGE message may include a Message Type IE used to distinguish the message type and a Transaction ID IE used to distinguish the message transmission (transaction). In addition, the GNB SWITCHING OFF INDICATION ACKNOWLEDGE message may include an Admitted DU List IE containing information on DUs that can connect to the target CU, and a Non-admitted DU List IE containing information on DUs that cannot connect to the target CU.

[0250] The Admitted DU List IE may include information about each DU, a gNB-DU Name IE that indicates the name of the DU with each DU information, and a gNB-DU ID IE that includes identifier information of the DU. In addition, the Admitted DU List IE may include TNL Association Layer Information IE information, which is information related to the TNL (Transport Network Layer) of the target CU that the DU can use to connect to the target CU.

[0251] The Non-admitted DU List IE may include information for each DU, a gNB-DU Name IE indicating the name of the DU with each DU information, and a gNB-DU ID IE containing identifier information of the DU.

[0252] The gNB-DU Name IE may follow the configuration example of Fig. 5c, and the TNL Association Layer Information IE may follow the configuration example of Fig. 5d.

[0253] Figure 12a illustrates the configuration of a terminal context transfer message (e.g., a UE CONTEXT TRANSFER message) between base stations.

[0254] The message in FIG. 12a is an example of a message configuration related to UE context transfer on the Xn interface, which is an interface between a gNB or a gNB-CU. The message name or IE name used in FIG. 12a is an example, and the message may be configured with a different name or a different form of configuration or value for the same purpose.

[0255] The UE CONTEX TRANSFER message may include a Message Type IE used to distinguish the message type, a Source NG-RAN node UE XnAP ID reference IE containing information related to the terminal identifier on the Xn interface used by the source base station (source NG-RAN node), and a UE Context Information IE containing terminal context information.

[0256] UE context information may include information necessary for terminal services at the base station, such as information that can identify the core network connected to the terminal (e.g., GUAMI (Globally Unique AMF Identifier)), terminal authentication information, terminal bearer information, and RRC configuration information configured for the terminal. In addition, the UE CONTEX TRANSFER message may include at least one of information about a DU within a source NG-RAN node, or a Source NG-RAN node UE F1AP ID reference IE that includes information related to an identifier of the terminal used in the F1 interface between the CU and the DU.

[0257] The Source NG-RAN node UE F1AP ID reference IE may include at least one of the gNB-DU Name IE indicating the name of the DU of the source NG-RAN node, the gNB-DU ID IE including identifier information of the DU, the TNL Association Layer Information IE information which is information related to the TNL (Transport Network Layer) of the DU that can be used for connection with the CU, and the gNB-CU UE F1AP ID IE and the gNB-DU UE F1AP ID which are terminal identifiers in the CU and DU, respectively, on the F1 interface.

[0258] The gNB-CU Name IE included in the Source NG-RAN node UE F1AP ID reference IE may be as in the configuration example of Fig. 5c, and the TNL Association Layer Information IE may be as in the configuration example of Fig. 5d.

[0259] Figure 12b illustrates the configuration of a response (UE context transfer acknowledge) message for UE context transfer between base stations.

[0260] The message in FIG. 12b is an example of a message configuration related to UE context transfer on the Xn interface, which is an interface between a gNB or a gNB-CU. The message name or IE name used in FIG. 12b is an example, and the message may be configured with a different name or a different form of configuration or value for the same purpose.

[0261] The UE CONTEX TRANSFER ACKNOWLEDGE message may include at least one of a Message Type IE used to distinguish the message type, a Source NG-RAN node UE XnAP ID reference IE which is a terminal identifier on the Xn interface used by the source NG-RAN node, a Target NG-RAN node UE XnAP ID reference IE which is a terminal identifier on the Xn interface used by the target NG-RAN node, an Xn-U Address Information per PDU Session Resource List IE which includes information for user data forwarding of the terminal, or a Criticality Diagnostics IE for procedure error management, etc.

[0262] The Xn-U Address Information per PDU Session Resource List IE may include at least one of the PDU Session ID IE, which is a PDU session identifier for each PDU session, QoS flow mapping information related to data forwarding, and Data Forwarding Info from target NG-RAN node IE, which includes data forwarding address information.

[0263] Figure 13a illustrates the configuration of a terminal context switch request (e.g., UE CONTEXT SWITCH REQUSET) transmitted from a CU of a base station to a DU.

[0264] The message in FIG. 13a is an example of the configuration of messages related to a UE context switch request on the F1 interface, which is the interface between the gNB-CU and the gNB-DU. The message names and IE names used in FIG. 13a are examples, and other names or other configurations or values ​​for the same purpose may be configured.

[0265] The UE CONTEXT SWITCH REQUEST message may include at least one of the Message Type IE used to distinguish the message type, the gNB-CU UE F1AP ID IE which is a terminal identifier in the CU on the F1 interface, the Triggering Cause IE which is information on the cause of requesting UE context setup, and the Old NG-RAN node UE F1AP ID reference IE which includes information related to the terminal identifier on the F1 interface used between the previous CU.

[0266] The Triggering Cause IE may contain information that the CU of the old NG-RAN node is being switched off.

[0267] The Old NG-RAN node UE F1AP ID reference IE may include at least one of the gNB-CU Name IE indicating the name of the CU of the old base station (old NG-RAN node), the gNB-CU ID IE including identifier information of the CU, the TNL Association Layer Information IE information which is information related to the TNL (Transport Network Layer) of the CU that can be used for connection with the CU, and the gNB-CU UE F1AP ID IE and the gNB-DU UE F1AP ID which are terminal identifiers in the CU and DU, respectively, on the F1 interface.

[0268] The gNB-CU Name IE included in the Old NG-RAN node UE F1AP ID reference IE may be as in the configuration example of Fig. 5c, and the TNL Association Layer Information IE may be as in the configuration example of Fig. 5d.

[0269] FIG. 13b illustrates the configuration of a UE context switch response message (e.g., a UE CONTEXT SWITCH RESPONSE message) that is a response to a UE context switch request message transmitted from a CU of a base station to a DU.

[0270] The message in FIG. 13b is an example of the configuration of messages related to a UE context switch request on the F1 interface, which is the interface between the gNB-CU and the gNB-DU. The message names and IE names used in FIG. 13b are examples, and other names or other configurations or values ​​for the same purpose may be used.

[0271] The UE CONTEX SWITCH RESPONSE message may include at least one of the Message Type IE used to distinguish the message type, the gNB-CU UE F1AP ID IE which is a terminal identifier in the CU and DU on the F1 interface, the gNB-DU UE F1AP ID IE, the DU to CU RRC Information IE which includes RRC information that needs to be transmitted from the DU to the terminal, and the Criticality Diagnostics IE for procedure error management.

[0272] Figure 14 illustrates a process for energy saving in a mobile communication base station or error recovery in a CU.

[0273] According to the present embodiment, in order to save energy of a mobile communication base station or recover from an error in the CU, a series of procedures are disclosed for stopping the functions of some CUs (Central Units) and stopping the use of a processor supporting the CU, or turning off part or all of the power of a device supporting the CU. In order to save energy or recover from an error in the CU, a terminal receiving a mobile communication service by being connected to a CU (Central Unit) can continuously receive the mobile communication service by temporarily changing the connected base station (e.g., performing a handover procedure to another base station). In addition, the DU of the base station to which the terminal was previously connected can apply new settings through OAM (Operation and Management), etc., and then provide the mobile communication service by newly connecting to a CU of another base station. Although only one terminal (UE: User Equipment) is included in FIG. 14, similar procedures can be performed for all DUs connected to the CU and all terminals in a connected state, and in FIG. 9, the same procedures for other DUs and other terminals can be omitted.

[0274] Referring to FIG. 14, in step 100, the terminal (10) can receive mobile communication services by connecting to the CN (30) through the connected serving DU (24-a) and serving CU (22-a).

[0275] At step 200, a serving CU (22-a) supporting a mobile communication service connection of a terminal (10) may decide to stop its function for energy conservation, stop using a processor to support the serving CU (22-a), or perform a switching-off to partially or completely power off the supporting device. The switching-off in the CU may be determined or performed by considering at least one of the following factors.

[0276] - Number of terminals connected to and supported by the CU (or number of RRC connections)

[0277] - The level of load supported by the CU (load status)

[0278] - Request by OAM (triggered by OAM)

[0279] -> As OAM manages the CU, it can decide to switch off the CU based on the number of terminals connected to the CU, the load level of the CU, an upgrade of the CU, a partial failure of the CU, or other reasons, and can request switching off to the CU.

[0280] -> CU switching-off request information in OAM may include at least one of a switching-off indication (instant indicator), CU switching-off scheduled time or schedule information, parameter information for determining switching-off in the CU, for example, the number of connected terminals, and the load level of the CU.

[0281] - Error detection and other internal reasons and algorithms within the CU

[0282] When the serving CU (22-a) decides to start a switching off procedure, the serving CU (22-a) can perform a handover of all terminals connected to the serving CU (22-a) to other DUs and CUs through a handover procedure at step 300.

[0283] At step 400, the serving CU (22-a) can confirm that all connected terminals that the serving CU (22-a) was serving have completed handover to one or more other DUs and CUs.

[0284] The serving CU (22-a), which has confirmed that the handover to another CU has been completed, can perform an interface removal procedure (e.g., an F1 removal procedure with all connected DUs) with the serving DU (24) connected to the serving CU (22-a) at step 410.

[0285] The serving CU (22-a), which has confirmed that the handover to another CU has been completed, can perform an interface connection deletion procedure (e.g., NG removal procedure with all connected AMFs (CN functions)) with the CN (30) connected to the serving CU (22-a) at step 420.

[0286] The serving CU (22-a), which has confirmed that the handover to another CU has been completed, can perform an interface connection deletion procedure (e.g., Xn removal procedure with all neighbor gNBs (gNB-CUs)) with the target CU (22-b) connected to the serving CU (22-a) at step 430.

[0287] When the interface connection removal with the serving CU (22-a) is completed, the serving DU (24-a) can stop all transmission and reception. When the interface connection removal with the DUs connected to the serving CU (22-a) and the surrounding base station or the CU of the base station, CN (30) is completed, the serving CU (22-a) can perform other procedures for switching off the serving CU (22-a) in step 500 to complete the switching off procedure of the serving CU (22-a).

[0288] After completing interface removal with the serving CU (22-a) in steps 410 to 415, the serving DU (24-a) can determine a new CU to connect to in step 600. When the DU determines a new CU to connect to, at least one of the following information can be used.

[0289] - When changing the CU configured in OAM, the CU information to be used and the new cell identifier information for each serving cell

[0290] Information set in OAM may have been previously received and stored, and may be received by DU by connecting to the OAM server before step 600.

[0291] Once a new CU to be connected is determined, the serving DU (24-a) may perform an F1 connection procedure (e.g., an F1 setup procedure) for connection with the corresponding CU (e.g., a target CU (22-b)) at step 610. Step 610 may include procedures such as a transport layer connection procedure (e.g., SCTP (Stream Control Transmission Protocol)) connection setup for transmitting control messages between CUs and DUs.

[0292] Upon completion of the F1 connection procedure with the target CU (22-b), the serving DU (24-b) can perform setup and operation in the serving DU (24-b) based on the connection information with the newly connected target CU in step 615.

[0293] The target CU (22-b), which has completed the F1 connection procedure with the serving DU (24-a), can perform a RAN configuration update procedure for the CN (30) to transmit information including additional cell information supported by the target CU (22-b) to the CN (30) at step 620.

[0294] Based on the wireless section signal measurement information at the terminal, the target CU (22-b) can perform a handover of the terminal from the cell of the target DU (24-b) to the cell of the serving DU (24-a) at step 700.

[0295] Figures 15a and 15b illustrate a process for energy saving in a mobile communication base station or error recovery in a CU.

[0296] According to one embodiment, FIGS. 15A and 15B disclose a series of procedures for stopping the functions of some CUs (Central Units) and stopping the use of a processor supporting the CU, or powering off part or all of a device supporting the CU, in order to save energy in a mobile communication base station or recover from an error in the CU. In order to save energy or recover from an error in the CU, a terminal connected to the CU and receiving a mobile communication service can be connected to another operating CU through a CU context transfer procedure without losing connection with the CU, and can continuously receive the mobile communication service.

[0297] In FIGS. 15a and 15b, only one DU (Distributed Unit) and one UE (User Equipment) are included, but the procedures in FIGS. 15a and 15b can be performed similarly for all DUs connected to the CU and all UEs in a connected state, and in FIG. 15, the same procedures for other DUs and other UEs can be omitted.

[0298] Referring to FIG. 15, in step 100, the terminal (10) can receive mobile communication services by connecting to the CN (30) through the connected serving DU (24) and serving CU (22-a).

[0299] In step 200, a serving CU (22-a) supporting a mobile communication service connection of terminal(s) (10) may decide to stop its function for energy saving, stop using a processor to support the serving CU (22-a), or perform a switching-off to turn off part or all of the power of the supporting device. The switching-off in the CU may be determined or performed by considering at least one of the following factors.

[0300] - Number of terminals connected to and supported by the CU (or number of RRC connections)

[0301] - The level of load supported by the CU (load status)

[0302] - Request by OAM (triggered by OAM)

[0303] -> As OAM manages the CU, it can decide to switch off the CU based on the number of terminals connected to the CU, the load level of the CU, an upgrade of the CU, a partial failure of the CU, or other reasons, and can request switching off to the CU.

[0304] -> CU switching-off request information in OAM may include at least one of a switching-off indication (instant indicator), CU switching-off scheduled time or schedule information, parameter information for determining switching-off in the CU, for example, the number of connected terminals, and the load level of the CU.

[0305] - Error detection and other internal reasons and algorithms within the CU

[0306] If the serving CU (22-a) decides to start the switching off procedure, at step 210, the serving CU (22-a) may indicate a UE transmission stop indication, which is an indication to stop data transmission of the terminal, to the DUs connected to the serving CU (22-a).

[0307] The UE transmission stop indication can be conveyed by defining a new message on the interface between the CU and DU, or by using the Transmission Stop Indicator IE included in the existing UE CONTEXT MODIFCAITON REQUEST message.

[0308] The serving DU (24) that receives the transmission stop indication stops transmission to the corresponding terminal, and then in step 220, the existing UE CONTEXT MODIFCAITON RESPONSE message can be used for UE transmission to the serving CU (22-a).

[0309] When transmission of all terminals connected to the serving CU (22-a) is stopped, the serving CU (22-a) can transmit a request message (e.g., a CU switching request message) to the backup CU (22-c) at step 310, indicating that the serving CU is initiating a switching-off procedure.

[0310] The CU switching request message may include information about DUs connected to the serving CU (22-a).

[0311] At step 320, the backup CU (22-c) may transmit a response message (e.g., a CU switching response message) to the CU switching request message to the serving CU (22-a).

[0312] The serving CU (22-a) that receives the CU switching response message from the backup CU (22-c) can transmit a message (e.g., a CU context transfer message) that transfers the context information of the CU to the backup CU (22-c) at step 330. The context information of the CU can include all data information used by the serving CU (22-a), and the data information of the serving CU can include context information of all terminals being serviced by the serving CU (22-a).

[0313] The backup CU (22-c), which has received CU context information from the serving CU (22-a), can transmit a response message (e.g., a CU context transfer acknowledge message) to the CU context transfer message after internal configuration at step 340.

[0314] The CU context transfer message may include at least one of address information related to the Transport Network Layer (TNL) for use in the control plane from the backup CU (22-c) to each interface (e.g., each NG, Xn, F1, E1 interface), and information for forwarding user data of each terminal.

[0315] The serving CU (22-a) can perform user data forwarding of the terminal to the backup CU (22-c) at step 350 based on the received data forwarding information.

[0316] The serving CU (22-a) can perform an F1 multiple TLNA association addition or change procedure to enable each of the DUs (e.g., the serving DU (24-a)) connected to the serving CU (22-a) to communicate with the backup CU (22-c) in the interface connection based on the TNL-related address information received from the backup CU (22-c) at step 400.

[0317] The serving CU (22-a) can perform an NG multiple TLNA association addition or change procedure to enable each of the CNs (30) connected to the serving CU (22-a) to communicate with the backup CU (22-c) in the interface connection at step 410 based on the TNL-related address information received from the backup CU (22-c).

[0318] The serving CU (22-a) may perform an Xn multiple TLNA association addition or change procedure to enable each of the CUs (e.g., backup CU (22-c)) of the surrounding base stations or base stations connected to the serving CU (22-a) to communicate with the backup CU (22-c) in the interface connection based on the TNL-related address information received from the backup CU (22-c) at step 420. Thereafter, a node-level signaling (non-UE associated signaling) transmission procedure may be performed in the connection interface with the backup CU (22-c).

[0319] When the procedure for adding or changing multiple TLNA associations for each interface is completed in the serving CU (22-a), the serving CU (22-a) can transmit a message indicating that the CU will be switched off (e.g., a CU switching off indication message) to the backup CU (22-c) in step 500.

[0320] The backup CU (22-c), which has received an indication that the serving CU (22-a) is to switch off, may perform an F1 TLNA association change procedure to remove TLNA information that allowed each of the DUs (e.g., the serving DU (24-a)) connected to the backup CU (22-c) to communicate with the serving CU (22-a) in the interface connection at step 510.

[0321] The backup CU (22-c), which has received an indication that the serving CU (22-a) is to switch off, can perform an NG TLNA association change procedure to remove TLNA information that allowed each of the CNs (30) connected to the backup CU (22-c) to communicate with the serving CU (22-a) in the interface connection at step 520.

[0322] The backup CU (22-c), which has received an indication that the serving CU (22-a) is to switch off, may perform an Xn TLNA association change procedure to remove TLNA information that allowed each of the CUs (e.g., the backup CU (22-c)) of the surrounding base stations or base stations connected to the backup CU (22-c) to communicate with the serving CU (22-a) in the interface connection at step 530.

[0323] If necessary, either a procedure for changing path information for transferring user data of a terminal between the backup CU (22-c) and the core network (30) (e.g., a path switch update procedure) or a UE context modification required procedure may be performed at step 540.

[0324] At step 550, the backup CU (22-C) may transmit a response message (e.g., a CU switching off indication acknowledge message) to the serving CU (22-a) indicating that the serving CU (22-a) may switch off.

[0325] Upon receiving a CU switching off indication acknowledge message from the backup CU (22-c), the serving CU (22-a) can perform other procedures for switching off at step 600 to complete the switching off procedure of the serving CU (22-a).

[0326] Figure 16 illustrates a process for switching off a serving CU.

[0327] Referring to FIG. 16, the serving CU may initiate the CU switching off procedure at step 100.

[0328] In step 200, the serving CU may transmit an indication message to all terminals connected to DUs connected to the CU, indicating that data transmission and reception of the corresponding terminal is to be stopped with respect to the DU to which the respective terminal is connected. In addition, a response message may be received from the DUs in response to the transmission and reception stop indication message.

[0329] In step 300, the serving CU may transmit a message containing CU switching request (e.g., CU switching request) information to the backup CU. A response message to the CU switching request may then be received.

[0330] At step 400, the serving CU can transfer CU context information to the backup CU. If necessary, data forwarding of the terminal's user data can be performed to the backup CU.

[0331] In step 500, the serving CU may perform multiple TLNA association addition and change procedures to establish connections with the backup CU on the network interfaces with all DUs currently connected to the CU, the surrounding base stations (or CUs of the surrounding base stations), the CU-UP, and the core network.

[0332] After all procedures related to multiple TLNA association are completed, the serving CU may transmit a message including a CU switching off indicator to the backup CU at step 600. A response message to the message including the switching off indicator may then be received.

[0333] At step 700, the serving CU can perform the switching off after completing all other procedures for CU switching off.

[0334] Figure 17a illustrates the configuration of a CU switching request message transmitted from a serving CU (22-a) to a backup CU (22-c).

[0335] The CU switching request message may include switching off request information.

[0336] The message in Fig. 17a may be transmitted or sent through the Xn interface, which is an interface between the gNB or gNB-CU, or a separate interface used for connection with the backup CU. The message name or IE name used in Fig. 17a is an example, and may be configured with a different name or a different form or value for the same purpose.

[0337] The GNB-CU SWITCHING REQUEST message may include a Message Type IE used to distinguish the message type and a Transaction ID IE used to distinguish the message transmission (transaction). In addition, the GNB-CU SWITCHING REQUEST message may separately include a Switching Off Ongoing IE to indicate that the CU is about to switch off. In addition, the GNB-CU SWITCHING REQUEST message may include a Migration DU List IE containing information on one or more DUs connected to the serving CU.

[0338] The Migration DU List IE may include information for each DU, and may include at least one of a gNB-DU Name IE indicating the name of the DU with each DU information, a gNB-DU ID IE including identifier information of the DU, TNL Association Layer Information IE information which is information related to the TNL (Transport Network Layer) of the DU that can be used for connection with the DU, current cell identifier information for each serving cell of the DU (e.g., Current NCGI IE), and a new cell identifier to be used by a newly connected CU (e.g., New NCGI IE information). The gNB-DU Name IE may follow the configuration example of FIG. 5c, the TNL Association Layer Information IE may follow the configuration example of FIG. 5d, and the cell identifier may follow the configuration example of FIG. 5e.

[0339] Figure 17b illustrates the configuration of a CU switching response message, which is a response to a CU switching request message transmitted from a serving CU (22-a) to a backup CU (22-c).

[0340] The CU switching response message may include switching off request information.

[0341] The message in Fig. 17b can be transmitted by creating an Xn interface, which is an interface between gNB or gNB-CU, or a separate interface used for connection with a backup CU. The message name or IE name used in Fig. 17b is an example, and it can be configured with a different name or a different form or value for the same purpose.

[0342] The GNB-CU SWITCHING RESPONSE message may include at least one of the Message Type IE used to distinguish the message type, the Transaction ID IE used to distinguish the message transmission (transaction), and the Criticality Diagnostics IE used for procedure error management.

[0343] Figure 18a illustrates the configuration of a CU context transfer message that includes a transmission from a serving CU (22-a) to a backup CU (22-c).

[0344] The CU context transfer message may include CU context information. The message in Fig. 18a may be transmitted by creating an Xn interface, which is an interface between the gNB or the gNB-CU, or a separate interface used for connection with the backup CU. The message name or IE name used in Fig. 18a is an example, and it may be configured with a different name or a different form or value for the same purpose.

[0345] The GNB-CU CONTEXT TRANSFER message may include a Message Type IE used to distinguish the message type, a Transaction ID IE used to distinguish the message transmission (transaction), and a CU Context IE containing CU context information.

[0346] The CU Context IE can be transmitted by including a CU context having an OCTET value in the form of a container as shown in Fig. 18a, or all individual data of the CU context can be transmitted by configuring them in a separate IE form, or can be transmitted in a mixed form of the IE form and the container form.

[0347] Figure 18b illustrates the configuration of a CU context transfer acknowledge message, which is a response to a CU context transfer message that includes forwarding from a serving CU (22-a) to a backup CU (22-c).

[0348] The CU context transfer acknowledge message may include CU context information. The message in FIG. 18b may be transmitted through the Xn interface, which is an interface between the gNB or the gNB-CU, or a separate interface used for connection with the backup CU. The message name or IE name used in FIG. 18b is an example, and may be configured with different names or different forms or values ​​for the same purpose.

[0349] The GNB-CU CONTEXT TRANSFER ACKNOWLEDGE message may include at least one of the Message Type IE used to distinguish the message type, the Transaction ID IE used to distinguish the message transmission (transaction), the TNL Association Layer Information List IE information which is information related to the TNL (Transport Network Layer) of the backup CU for connecting to the backup CU from the network interface with all DUs and peripheral base stations (or CUs of peripheral base stations), CU-UP, and the core network, the Xn-U Address Information per PDU Session Resource List IE which includes information for user data forwarding of the terminal, and the Criticality Diagnostics IE for procedure error management.

[0350] The TNL Association Layer Information List IE may include Interface IE and TNL Association Layer Information IE information indicating interfaces where TNL-related information is used. The TNL Association Layer Information IE may follow the configuration example of Fig. 5d.

[0351] The Xn-U Address Information per PDU Session Resource List IE may include at least one of the PDU Session ID IE, which is a PDU session identifier for each PDU session, QoS flow mapping information related to data forwarding, and Data Forwarding Info from target NG-RAN node IE, which includes data forwarding address information.

[0352] FIG. 19 is a diagram illustrating the configuration of a RAN Node according to one embodiment of the present invention.

[0353] In this embodiment, the RAN Node may be configured to include an RF processing unit (10), a baseband processing unit (20), a backhaul communication unit (30), a storage unit (40), and a control unit (50).

[0354] If the RAN Node is divided into a CU (Central Unit) and a DU (Distributed Unit), blocks other than those included in Fig. 19 can also be configured. For example, the RF processing unit (10) and the baseband processing unit (20) can be configured to include a control unit, a storage unit, and a backhaul communication unit for communication with the CU in the DU, and the backhaul communication unit (30) can be configured to include a control unit, a storage unit, a DU, and a backhaul communication unit for communication with the core network in the CU. The CU is responsible for the functions of CU-CP and CU-UP.

[0355] The RF processing unit (10) can perform functions for transmitting and receiving signals through a wireless channel, such as signal band conversion and amplification. The RF processing unit (10) can up-convert the baseband signal provided from the baseband processing unit (20) into an RF band signal and then transmit it through an antenna, and down-convert the RF band signal received through the antenna into a baseband signal. For example, the RF processing unit (10) can include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, etc.

[0356] In the above drawing, only one antenna is shown, but the first access node may be equipped with multiple antennas. In addition, the RF processing unit (10) may include multiple RF chains. Furthermore, the RF processing unit (10) may perform beamforming. For the beamforming, the RF processing unit (10) may adjust the phase and magnitude of each signal transmitted and received through multiple antennas or antenna elements. The RF processing unit may perform a downlink MIMO operation by transmitting one or more layers.

[0357] The baseband processing unit (20) above can perform a conversion function between a baseband signal and a bit stream according to the physical layer standard of the first wireless access technology. For example, when transmitting data, the baseband processing unit (20) can generate complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the baseband processing unit (20) can restore a reception bit stream by demodulating and decoding a baseband signal provided from the RF processing unit (10). For example, in the case of following the OFDM method, when transmitting data, the baseband processing unit (20) can generate complex symbols by encoding and modulating a transmission bit stream, map the complex symbols to subcarriers, and then configure OFDM symbols through an IFFT operation and CP insertion. In addition, when receiving data, the baseband processing unit (20) can divide the baseband signal provided from the RF processing unit (10) into OFDM symbol units, restore signals mapped to subcarriers through FFT operation, and then restore the received bit string through demodulation and decoding. The baseband processing unit (20) and the RF processing unit (10) can transmit and receive signals as described above. Accordingly, the baseband processing unit (20) and the RF processing unit (10) can be referred to as a transmitter, a receiver, a transceiver, a communication unit, or a wireless communication unit.

[0358] The backhaul communication unit (30) may provide an interface for communicating with other nodes within the network. The backhaul communication unit (30) may convert a bit string transmitted from the primary RAN Node to another node, such as an auxiliary base station or core network, into a physical signal, and may convert a physical signal received from the other node into a bit string.

[0359] The storage unit (40) stores data such as basic programs, application programs, and configuration information for the operation of the primary RAN Node. In particular, the storage unit (40) can store information on bearers assigned to connected terminals, measurement results reported from connected terminals, and the like. In addition, the storage unit (40) can store information that serves as a judgment criterion for whether to provide or terminate multiple connections to a terminal. In addition, the storage unit (40) can provide stored data at the request of the control unit (50).

[0360] The control unit (50) can control the overall operations of the RAN Node. For example, the control unit (50) transmits and receives signals through the baseband processing unit (20) and the RF processing unit (10) or through the backhaul communication unit (30). In addition, the control unit (50) can record and read data in the storage unit (40). For this purpose, the control unit (50) can include at least one processor.

Claims

1. A method performed by a serving distribution unit (DU) in a communication system, A step of receiving a message for a switching off instruction from a serving central unit (CU); A step of transmitting a setup request message to a target CU based on the message for the switching off instruction; In response to the setup request message, a step of receiving a setup response message from the target CU; In response to the message for the switching off instruction, transmitting an acknowledgement message including information related to the target CU to the serving CU; and A method characterized by comprising: a step of performing a connection to the target CU for continuous service support based on the switching off instruction.

2. In paragraph 1, The message for the switching off indication includes information related to at least one of a list for candidate CUs, a message type, a transmission identifier (ID), a service status, an ID of a serving cell supported by the serving DU, a new cell ID, or an indication related to the switching off. The above approval message further includes information related to at least one of the message type, the transmitting ID, the ID of the serving cell supported by the serving DU, or the new cell ID, and A method characterized in that the target CU is determined as one of the lists for the candidate CUs.

3. In paragraph 1, Further comprising a step of updating the settings based on the information related to the target CU; A method characterized in that the information related to the target CU includes at least one of a name of the target CU, an identifier (ID) of the target CU, transmission layer information, or a new radio cell global ID (NCGI).

4. In paragraph 1, A method characterized in that the switching off instruction is determined based on at least one of the number of user equipment (UE) connected to the serving CU, the load degree of the serving CU, or a request triggered by orbital angular momentum (OAM).

5. In a method performed by a serving central unit (CU) in a communication system, A step of transmitting a message for a switching off instruction to a serving distribution unit (DU); In response to the message for the switching off instruction, receiving an acknowledgement message including information related to the target CU from the serving DU; and A method characterized by comprising: a step of performing interface connection deletion with the serving DU based on a connection to the target CU for continuous service support.

6. In paragraph 5, The message for the switching off indication includes information related to at least one of a list for candidate CUs, a message type, a transmission identifier (ID), a service status, an ID of a serving cell supported by the serving DU, a new cell ID, or an indication related to the switching off. The above approval message further includes information related to at least one of the message type, the transmitting ID, the ID of the serving cell supported by the serving DU, or the new cell ID, and A method characterized in that the target CU is determined as one of the lists for the candidate CUs.

7. In paragraph 5, The above information related to the above target CU is used to update the settings of the above serving DU, A method characterized in that the information related to the target CU includes at least one of a name of the target CU, an identifier (ID) of the target CU, transmission layer information, or a new radio cell global ID (NCGI).

8. In paragraph 5, A method characterized in that the switching off instruction is determined based on at least one of the number of user equipment (UE) connected to the serving CU, the load degree of the serving CU, or a request triggered by orbital angular momentum (OAM).

9. In a serving distribution unit (DU) in a communication system, Transmitter and receiver; and A control unit connected to the above transceiver; wherein the control unit: Receive a message for switching off instruction from the serving central unit (CU), To the target CU, a setup request message is transmitted based on the message for the switching off instruction, In response to the above setup request message, a setup response message is received from the target CU, In response to the message for the switching off instruction, transmit an acknowledgement message including information related to the target CU to the serving CU, and A serving DU characterized by performing a connection to the target CU for continuous service support based on the above switching off instruction.

10. In paragraph 9, The message for the switching off indication includes information related to at least one of a list for candidate CUs, a message type, a transmission identifier (ID), a service status, an ID of a serving cell supported by the serving DU, a new cell ID, or an indication related to the switching off. The above approval message further includes information related to at least one of the message type, the transmitting ID, the ID of the serving cell supported by the serving DU, or the new cell ID, and A serving DU, characterized in that the target CU is determined as one of the lists for the candidate CUs.

11. In paragraph 9, the control unit: Update the settings based on the above information related to the above target CU, A serving DU, characterized in that the information related to the target CU includes at least one of a name of the target CU, an identifier (ID) of the target CU, transmission layer information, or a new radio cell global ID (NCGI).

12. In paragraph 9, A serving DU, characterized in that the switching off instruction is determined based on at least one of the number of user equipment (UE) connected to the serving CU, the load degree of the serving CU, or a request triggered by orbital angular momentum (OAM).

13. In a serving central unit (CU) in a communication system, Transmitter and receiver; and A control unit connected to the above transceiver; wherein the control unit: To the serving distribution unit (DU), a message for switching off instruction is transmitted, In response to the message for the switching off instruction, receiving an acknowledgement message containing information related to the target CU from the serving DU, and A serving CU characterized by performing interface connection deletion with the serving DU based on a connection to the target CU for continuous service support.

14. In paragraph 13, The message for the switching off indication includes information related to at least one of a list for candidate CUs, a message type, a transmission identifier (ID), a service status, an ID of a serving cell supported by the serving DU, a new cell ID, or an indication related to the switching off. The above approval message further includes information related to at least one of the message type, the transmitting ID, the ID of the serving cell supported by the serving DU, or the new cell ID, and A serving CU, characterized in that the target CU is determined as one of the lists for the candidate CUs.

15. In paragraph 13, The above information related to the above target CU is used to update the settings of the above serving DU, The information related to the target CU includes at least one of a name of the target CU, an identifier (ID) of the target CU, transmission layer information, or a new radio cell global ID (NCGI). A serving CU, characterized in that the switching off instruction is determined based on at least one of the number of user equipment (UE) connected to the serving CU, the load degree of the serving CU, or a request triggered by orbital angular momentum (OAM).

Images