Control device and RU device

Abstract

A first control device transmits, to an RU device, a first request message based on an NETCONF protocol and indicating a specified editing. The first request message includes the address information of a second control device that controls (monitors) the RU device as a substitute for the first control device. The first control device transmits, to the RU device, a Session Close message used for closing the session between the RU device and the first control device. In response to the receipt of the Session Close message, the RU device cuts the session between the RU device and the first control device. The RU device starts, together with the second control device, a procedure for establishing a session between the RU device and the second control device on the basis of the address information of the second control device.

Description

Control device, RU device, system, and method

[0001] The present disclosure relates to a control device, a RU device, a system, and a method.

[0002] In recent years, radio access networks have been adopted that separate the baseband and radio sections of base stations and connect them via a fronthaul. The O-RAN (Open-Radio Access Network) fronthaul specifications established by the O-RAN Alliance define the fronthaul specifications between the O-RU (O-RAN Radio Unit), which corresponds to the radio section, and the O-DU (O-RAN Distributed Unit), which corresponds to the baseband section. One of the goals of the O-RAN fronthaul specifications is to facilitate the connection of O-RUs from different vendors to O-DUs, thereby realizing multi-vendor radio access networks. Note that the O-DU may also be simply referred to as the DU. The O-RU may also be simply referred to as the RU.

[0003] Non-Patent Document 1 defines specifications for the M (Management) Plane, which is defined to transmit management data between the O-RU and the O-DU. The M-Plane provides management functions for the O-RU. In the M-Plane, the O-DU or the SMO (Service Management and Orchestration) is defined as the device that manages the O-RU. The O-RU to be managed corresponds to the NETCONF server, and the device that manages (controls) the O-RU (RU control device) corresponds to the NETCONF client. The M-Plane supports protocol stacks that transmit signals used in NETCONF (NETwork CONFiguration protocol) using Ethernet / IP / TCP (Transmission Control Protocol) / SSH (Secure SHell) and, optionally, Ethernet / IP / TCP (Transmission Control Protocol) / TLS (Transport Layer Security) (see, for example, Sections 9.1.2 and 9.1.3 of Non-Patent Document 1).

[0004] For example, Non-Patent Document 1 describes changing the power state of an O-RU. When the power state is AWAKE, the O-RU performs normal operation (not in energy saving mode), and when the power state is SLEEPING, the O-RU operates in energy saving mode. The power state of the O-RU is changed by the RU control device sending an RPC (Remote Procedure Call) message indicating configuration edit (edit-config) to the O-RU.

[0005] O-RAN-WG4.MP.0-v09.00,“O-RAN Working Group 4 (Open Fronthaul Interfaces WG) Management Plane Specification”

[0006] The inventors have studied the O-RAN fronthaul specifications and found various problems. For example, Non-Patent Document 1 does not sufficiently consider the circumstances in which it is desirable to switch the entity that manages (controls) the O-RU, or the processing that should be performed in those circumstances. For example, even if the mode of the RU device transitions to ES (Energy Saving) mode, the M-plane of the RU device may still be operating (alive). This allows the O-RU to be placed in a normal mode other than ES mode at any time. If the control device of the O-DU device controls the RU device and the RU device transitions to ES mode with the M-plane operating (i.e., the M-plane is alive), the control device of the O-DU device must monitor the alive status of the RU device via the M-plane. For this reason, even if the mode of the RU device transitions to ES mode, the resources of the O-DU device cannot be released. For this reason, there is a need to switch the entity that monitors the O-DU device from the control device of the O-DU device to another device.

[0007] One of the objectives to be achieved by the embodiments disclosed in this specification is to provide a control device and an RU device that contribute to solving at least one of the problems, including the problems described above. It should be noted that this objective is only one of the objectives to be achieved by the embodiments disclosed in this specification. Other objectives or objectives and novel features will become apparent from the description of this specification or the accompanying drawings.

[0008] In one aspect, a first control device that controls a Radio Unit (RU) device comprises: at least one memory; and at least one processor coupled to the at least one memory, wherein, when switching the control entity that controls the RU device, the at least one processor sends to the RU device a Remote Procedure Call (RPC) message that is based on the Network Configuration Protocol (NETCONF) and indicates a configuration edit (edit-config), the RPC message including destination information of a second control device that controls the RU device instead of the first control device; and sends to the RU device a Session Close message to close the session between the RU device and the first control device.

[0009] In another aspect, a Radio Unit (RU) device comprises: at least one memory; and at least one processor coupled to the at least one memory, wherein the at least one processor, when switching a control entity controlling the RU device, receives from the first control device a Remote Procedure Call (RPC) message based on the Network Configuration Protocol (NETCONF) and indicating a configuration edit (edit-config), the RPC message including destination information of a second control device that controls the RU device instead of a first control device; receives from the first control device a Session Close message for closing the session between the RU device and the first control device; in response to receiving the Session Close message, disconnects the session between the RU device and the first control device; and initiates a procedure (Call home procedure) with the second control device to establish a session between the second control device and the RU device based on the destination information.

[0010] In another aspect, a second control device that controls an RU (Radio Unit) device comprises: at least one memory; and at least one processor coupled to the at least one memory, wherein when the entity that controls the RU device is switched from a first control device to the second control device, the at least one processor initiates a procedure for establishing a session between the RU device and the second control device with the RU device, and switches the account of the second control device to an account of a type that allows session monitoring.

[0011] In another aspect, a method executed by a first control device controlling a Radio Unit (RU) device includes: when switching a control entity controlling the RU device, transmitting to the RU device a Remote Procedure Call (RPC) message based on the Network Configuration Protocol (NETCONF) protocol and indicating a configuration edit (edit-config), the RPC message including destination information of a second control device that controls the RU device instead of the first control device; and transmitting to the RU device a Session Close message for closing a session between the RU device and the first control device.

[0012] In another aspect, a method performed by a Radio Unit (RU) device includes, when switching a control entity controlling the RU device, receiving from the first control device a Remote Procedure Call (RPC) message based on the Network Configuration Protocol (NETCONF) and indicating a configuration edit (edit-config), the RPC message including destination information of a second control device that controls the RU device instead of a first control device; receiving from the first control device a Session Close message for closing the session between the RU device and the first control device; in response to receiving the Session Close message, disconnecting the session between the RU device and the first control device; and initiating a procedure (Call home procedure) with the second control device to establish a session between the second control device and the RU device based on the destination information.

[0013] In another aspect, a method executed by a second control device that controls a Radio Unit (RU) device includes: when switching the entity that controls the RU device from a first control device to the second control device, initiating a procedure for establishing a session between the RU device and the second control device with the RU device; and switching the account of the second control device to an account of a type that allows session monitoring.

[0014] In another aspect, a system includes: a RU (Radio Unit) device; a first control device that controls the RU device; and a second control device that controls the RU device instead of the first control device, wherein the first control device is configured to: when switching a control entity that controls the RU device, send to the RU device a Remote Procedure Call (RPC) message that is based on the Network Configuration Protocol (NETCONF) and indicates a configuration edit (edit-config), the message including destination information of the second control device; and send to the RU device a Session Close message for closing the session between the RU device and the first control device; and the RU device is configured to: receive from the first control device the RPC message indicating the configuration edit; receive the Session Close message from the first control device; and, in response to receiving the Session Close message, disconnect the session between the RU device and the first control device; and initiate a procedure (Call Home procedure) with the second control device to establish a session between the second control device and the RU device based on the destination information.

[0015] The present disclosure can provide a control device, an RU device, a system, and a method that contribute to solving at least one of multiple problems, including the problems described above.

[0016] FIG. 1 is a diagram showing an example of a procedure for acquiring the state of an RU. FIG. 2 is a diagram showing an example of a procedure for changing the state of an RU. FIG. 3 is a diagram explaining the power state of an RU. FIG. 4 is a diagram showing possible transitions and combinations of the "active" parameter and the "state" parameter. FIG. 5 is a block diagram showing an example of a system of the present disclosure. FIG. 6 is a diagram showing an example of processing operations of the system of the present disclosure. FIG. 7 is a diagram showing a first modified example of processing operations of the system of the present disclosure. FIG. 8 is a diagram showing a second modified example of processing operations of the system of the present disclosure. FIG. 9 is a diagram showing an example of the configuration of a control device. FIG. 10 is a diagram showing an example of the configuration of a DU device. FIG. 11 is a diagram showing an example of the configuration of an RU device. FIG. 12 is a diagram showing an example of the configuration of an SMO device.

[0017] Hereinafter, embodiments will be described with reference to the drawings. In this disclosure, the drawings may relate to one or more embodiments. Furthermore, each element in the drawings may apply to one or more embodiments. Furthermore, in the embodiments, identical or equivalent elements are given the same reference numerals, and redundant description will be omitted.

[0018] The multiple embodiments described below can be implemented independently or in appropriate combination. These multiple embodiments have different novel features. Therefore, these multiple embodiments contribute to solving different purposes or problems and to achieving different effects.

[0019] The following embodiments are described primarily for RU devices and controllers that comply with O-RAN technical specifications, but may also be applied to other systems that support similar technologies to these RU devices and controllers.

[0020] As used herein, depending on the context, "if" may be interpreted to mean "when," "at or around the time," "after," "upon," "in response to determining," "in accordance with a determination," or "in response to detecting." These expressions may be interpreted to have the same meaning, depending on the context.

[0021] First, related art will be described, and the respective embodiments are based on these arts. In other words, these arts can be incorporated into the respective embodiments.

[0022] (Protocols) C (Control)-Plane is a protocol for transferring control signals. U (User)-Plane is a protocol for transferring user data. C / U-Plane supports a protocol stack that transmits signals used in eCPRI or RoE (Radio over Ethernet) directly over Ethernet, and an optional protocol stack that transmits via UDP (User Datagram Protocol) / IP. S (Synchronization)-Plane is a protocol for achieving synchronization between devices. S-Plane supports a protocol stack that transmits signals used in PTP (Precision Time Protocol) and SyncE (Synchronous Ethernet) over Ethernet. M (Management)-Plane is a protocol that handles maintenance and monitoring signals. M-Plane supports protocol stacks that transmit signals used in NETCONF (NETwork CONFiguration protocol) via Ethernet / IP / TCP (Transmission Control Protocol) / SSH (Secure SHell), and optionally Ethernet / IP / TCP (Transmission Control Protocol) / TLS (Transport Layer Security).

[0023] (Logical Architecture) The O-RAN (Open-Radio Access Network) Alliance adopts a configuration in which the RAN's communication processing functions can be separated into three components: the Radio Unit (RU), the Distributed Unit (DU), and the Central Unit (CU). It also defines the RAN Intelligent Controller (RIC), a platform that optimizes radio resource management and automates operations, and the Service Management and Orchestration (SMO), a framework for RAN maintenance and orchestration. The RU and DU are connected via an open fronthaul. CUS / M-Plane signals are transmitted over this open fronthaul between the RU and DU. Alternatively, the RU and SMO may be connected via an open fronthaul, and M-Plane signals may be transmitted over this open fronthaul. Even in this case, CUS-Plane signals are transmitted over the open fronthaul between the RU and DU. The DU and SMO are connected via an O1 interface. The CU and SMO are also connected via an O1 interface. The RU to be managed corresponds to a NETCONF server, and the device that manages (controls) the RU (RU control device) corresponds to a NETCONF client. The NETCONF client may be located in a DU or an SMO.

[0024] (Retrieve state of RU) FIG. 1 is a diagram showing an example of a procedure for retrieving the state of an RU. In FIG. 1, the RU controller uses NETCONF <get>Use the procedure to get the State of the RU.

[0025] Specifically, the RU control device sends an RPC (Remote Procedure Call) message indicating acquisition (get) to the RU. In response to the RPC message, the RU sends an RPC reply (rpc-reply) message to the RU control device. This RPC reply message includes information indicating the state of the RU. In other words, the RU control device: <get>The state of the RU can be obtained by request.

[0026] (Modify state of RU) The RU control unit can change the configurable state of an RU that supports optional hardware-state features defined in the RU hardware. The RU control unit can change the configurable state of an RU by sending a NETCONF <edit-config>Procedures can be used to change the configurable State of an RU.

[0027] 2 is a diagram showing an example of a procedure for changing the state of an RU. The RU control device changes the NETCONF <edit-config>The procedure is used to change the configurable State of an RU.

[0028] Specifically, the RU control device sends an RPC message indicating configuration edit (edit-config) to the RU. The RU changes its own state based on this RPC message. If the change is successful, the RU: <ok>The RU controller sends an RPC response message indicating

[0029] [power-state] An example of a configurable state of an RU is the power-state. As shown in Figure 3, the power states of an RU are "AWAKE" and "SLEEPING." Figure 3 is a diagram used to explain the power states of an RU. The RU control device controls the power state of the RU by sending an RPC message indicating configuration edit (edit-config) to the RU and editing the RU's "energy-saving-enabled" parameter. That is, by setting the value of the configurable parameter "energy-saving-enabled" to TRUE or FALSE, the value of the non-configurable parameter of the power-state transitions to AWAKE or SLEEPING. - AWAKE: This power state indicates that the RU is operating normally, that is, not in energy saving mode. - SLEEPING: This power state indicates that the RU is in energy saving mode.

[0030] (RU Carrier configuration) The RU control device uses NETCONF <edit-config>The procedure can be used to configure (update) RU parameters. For example, the RU control unit performs activation by setting the value of the "active" parameter for the tx-array-carrier(s) element (and / or rx-array-carrier(s) element) to "ACTIVE." The RU control unit also performs deactivation by setting the value of the "active" parameter for the tx-array-carrier(s) element (and / or rx-array-carrier(s) element) to "INACTIVE." The RU control unit also puts the tx-array-carrier(s) element (and / or rx-array-carrier(s) element) to sleep by setting the value of the "active" parameter for the tx-array-carrier(s) element (and / or rx-array-carrier(s) element) to "SLEEP." The tx-array-carrier(s) element (and / or the rx-array-carrier(s) element) is in sleep mode when the value of the "active" parameter is "SLEEP" and the value of the "State" parameter is "READY". Figure 4 shows possible transitions and combinations of the "active" and "state" parameters.

[0031] Here, tx-array-carrier(s) is a data node generated by the RU controller containing carrier configuration parameters and associated with the RU's transmit array (tx-array) information. rx-array-carrier(s) is a data node generated by the RU controller containing carrier configuration parameters and associated with the RU's receive array (rx-array) information. tx-array-carrier(s) and rx-array-carrier(s) are generated for each carrier and each transmit / receive array, and the carrier's center frequency, bandwidth, transmit power, etc. are configured for the RU.

[0032] First Embodiment Example of System Configuration Fig. 5 is a block diagram showing an example of a system according to the present disclosure. In Fig. 5, a system 1 includes a DU device 10, an RU device 20, and a control device 30.

[0033] The DU device 10 may be a logical node that performs functions in the Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, and Media Access Control (MAC) layer, as well as functions higher than the physical layer, or may be a physical device that incorporates these logical nodes. The functions higher than the physical layer may be, for example, encoding and modulation processing, and decoding and demodulation processing. The functions in the PDCP layer may be executed in a logical node called a Central Unit (CU) (not shown).

[0034] The RU device 20 may be a logical node that performs PHY-Low (lower level) functions and RF (Radio Frequency) processing, or may be a physical device that includes this logical node. The lower level functions of the physical layer may be, for example, Fast Fourier Transform (FFT) / Inverse FFT (IFFT) processing, Beam Forming (BF) processing, etc.

[0035] In FIG. 5, the DU device 10 has a control unit (control device) 11. This control unit (control device) 11 may correspond to a NETCONF client. Hereinafter, the control unit (control device) 11 may be referred to as a "first control device." The RU device 20 has a control unit 21. The RU device 20 itself or the control unit 21 may correspond to a NETCONF server. The DU device 10 and the RU device 20 are connected via an open fronthaul. This open fronthaul can transmit CUS-Plane signals and M-Plane signals.

[0036] Here, there is a need to switch the control entity that controls (monitors) the RU device 20 from the control device 11 to the control device 30. Hereinafter, the control device 30 may be referred to as the "second control device." As described above, for example, when the control device 11 of the DU device 10 is controlling the RU device 20, the mode of the RU device 20 may transition to ES mode while the M-plane is operating (i.e., the M-plane is alive). In this case, if the control entity that controls the RU device 20 is not switched, the control device 11 of the DU device 10 needs to monitor the alive status of the RU device 20 via the M-plane. Therefore, even if the mode of the RU device 20 transitions to ES mode, the resources of the DU device 10 cannot be released. Therefore, by switching the control entity that controls the RU device 20 from the control device 11 to the control device 30, the resources of the DU device 10 can be released.

[0037] The control device 30 may be, for example, a control unit (RU control device) of the SMO device. The control unit (RU control device) of the SMO device may correspond to a NETCONF client. The SMO device performs maintenance and orchestration of the RAN (Radio Access Network) and the RIC (RAN Intelligent Controller), which is a platform that realizes optimization of radio resource management and automation of operations. In this case, the RU device 20 and the SMO device may also be connected via an open fronthaul. Furthermore, the DU device 10 and the SMO device may be connected via an O1 interface.

[0038] Furthermore, the control device 30 may be, for example, a control unit (control device) of another DU device other than the DU device 10. The control unit (control device) of the other DU device may correspond to a NETCONF client. The RU device 20 and the other DU device may also be connected via an open fronthaul. Note that the other DU device may be connected to the RU device 20 and also to another RU device. The mode of this other RU device may be normal mode or ES mode.

[0039] The control device 30 may also be, for example, an event collector as described in Non-Patent Document 1.

[0040] Furthermore, the control device 30 may be, for example, a dedicated device for controlling (monitoring) the RU device.

[0041] In addition, in the ES (Energy Saving) mode of the RU device 20, the power-state of the RU device 20 is SLEEPING, the value of the active parameter of the tx / rx-array-carriers of the RU device 20 is SLEEP or INACTIVE, or both (i.e., the power-state of the RU device 20 is SLEEPING and the value of the active parameter of the tx / rx-array-carriers of the U device 20 is SLEEP or INACTIVE).

[0042] <Example of System Operation> Fig. 6 is a diagram showing an example of the processing operation of the system of the present disclosure. The processing operation of the system 1 shown in Fig. 6 is started when the control entity that controls (monitors) the RU device 20 is switched from the control device 11 to the control device 30.

[0043] The control device 11 transmits a message indicating a setting edit (edit-config) (hereinafter, sometimes referred to as a "first request message") to the RU device 20 (step S101). The first request message may be based on the Network Configuration Protocol (NETCONF). The first request message includes destination information of the control device 30 that controls (monitors) the RU device 20 on behalf of the control device 11. This allows the destination of the control device 30 to be added to the destination-related information elements held by the RU device 20.

[0044] The control device 11 sends a Session Close message (e.g., a close-session command) to close the session between the RU device 20 and the control device 11. <close-session>The control device 11 transmits an RPC message including the operation to the RU device 20 (step S102). Then, the control device 11 transitions the DU device 10 to a sleep state (step S103). This enables power saving of the DU device 10. In addition, as described above, power saving of the RU device 20 is also achieved by the ES mode. Therefore, when a base station (e.g., gNB (next generation NodeB)) is configured by the RU device 20 and the DU device 10, power saving of the base station can be achieved.

[0045] In response to receiving the Session Close message, the RU device 20 disconnects the session between the RU device 20 and the control device 11 (step S104).

[0046] The RU device 20 starts a procedure with the control device 30 to establish a session between the RU device 20 and the control device 30 based on the destination information of the control device 30 (step S105). This procedure may be, for example, the Call Home procedure defined in O-RAN (see, for example, Section 6.3 of Non-Patent Document 1). This procedure establishes an M-plane between the RU device 20 and the control device 30 and enables the control entity that controls (monitors) the RU device 20 to be switched to the control device 30.

[0047] The control device 30 switches the account of the control device 30 to an account of a type that allows session monitoring (step S106). The account of a type that allows session monitoring may be, for example, a root account or an O-DU account, or may be an account dedicated to session monitoring (supervision account).

[0048] The control device 30 and the RU device 20 mutually monitor the session via the M-plane (step S107). For example, the RU device 20 may transmit a notification signal indicating that the RU device 20 is alive to the control device 30. Furthermore, the control device 30 may transmit a notification signal indicating that the control device 30 is alive to the RU device 20. This allows bidirectional session monitoring by the control device 30 and the RU device 20. These notification signals may be called, for example, heartbeats. Furthermore, such session monitoring may be based on Monitoring NETCONF Connectivity defined in O-RAN (for example, see Section 6.7 of Non-Patent Document 1).

[0049] For example, if the control device 30 corresponds to a NETCONF client and the RU device 20 corresponds to a NETCONF server, the notification signal transmitted from the RU device 20 to the control device 30 may be a Supervision-notification. Alternatively, the notification signal transmitted from the control device 30 to the RU device 20 may be an RPC message indicating <Supervision-Watchdog-reset>. In this case, the RU device 20 may use two timers called Watchdog timers (Notification timer, Supervision timer). The Notification timer is set to Notification-timer-interval. The Supervision timer is set to Notification-timer-interval + guard-timer-overhead. When the Notification timer expires, the RU device 20 transmits a Supervision-notification to the control device 30. In response to receiving the Supervision-notification, the control device 30 transmits an RPC message indicating <Supervision-Watchdog-reset> to the RU device 20. The RU device 20 resets the Notification timer and Supervision timer. In addition, the control device 30 corresponds to a NETCONF client when, as described above, for example, the control device 30 is a control unit (RU control device) of an SMO device, or when the control device 30 is a control unit (control device) of a DU device other than the DU device 10.

[0050] 6 , the control entity that controls (monitors) the RU device 20 may be returned from the control device 30 to the control device 11. Specifically, the control device 30 transmits a first request message to the RU device 20, including destination information of the control device 11 that controls (monitors) the RU device 20 instead of the control device 30. The control device 30 also transmits a Session Close message to the RU device 20 to close the session between the RU device 20 and the control device 30. In response to receiving the Session Close message, the RU device 20 disconnects the session between the RU device 20 and the control device 30. The RU device 20 starts a procedure with the control device 11 to establish a session between the RU device 20 and the control device 11 based on the destination information of the control device 30.

[0051] <Modifications> The processing operations of the system in the first embodiment may be modified as follows.

[0052] <1> FIG. 7 is a diagram illustrating a first variation of the processing operation of the system of the present disclosure. As shown in FIG. 7, the RU device 20 periodically transmits a notification signal (e.g., Supervision Notification, heartbeat, etc.) indicating that the RU device 20 is alive to the control device 30 (step S201). In response, the control device 30 does not transmit a notification signal (e.g., Supervision Notification, heartbeat, etc.) indicating that the control device 30 is alive to the RU device 20. That is, the control device 30 does not transmit a notification signal indicating that the control device 30 is alive to the RU device 20, but receives a notification signal indicating that the RU device 20 is alive from the RU device 20. As a result, instead of bidirectional session monitoring, the control device 30 unidirectionally monitors the status of the RU device 20 (e.g., whether the RU device 20 is alive or dead). This simplifies the monitoring method. Note that, particularly when the control device 30 is an event collector, the notification signal the control device 30 receives from the RU device 20 may be Heartbeat Notification.

[0053] As described above, if the control device 30 is a control unit (control device) of another DU device other than the DU device 10, the control device 30 may be connected to the RU device 20 and may also be connected to another RU device. The mode of this other RU device may be normal mode or ES mode. If the mode of this other RU device is normal mode, the control device 30 may be performing bidirectional session monitoring with this other RU device.

[0054] <2> FIG. 8 is a diagram illustrating a second variation of the processing operation of the system of the present disclosure. As shown in FIG. 8 , the control device 30 transmits to the RU device 20 a message including information for changing the period (transmission interval) at which the RU device 20 transmits a notification signal (e.g., a Supervision notification, a heartbeat, etc.) indicating that the RU device 20 is alive (step S301). The control device 30 may transmit a message including information for changing this period immediately after establishing an M-plane between the RU device 20 and the control device 30. The control device 30 may also change the transmission period of the RU device 20 to a period depending on the load of the control device 30. For example, the control device 30 may lengthen the transmission period of the RU device 20 as the load on the control device 30 increases (i.e., as the control device 30 has less processing capacity). Note that the message including information for changing the period (transmission interval) at which the RU device 20 transmits may also be transmitted from the control device 30 to the RU device 20 in the sequence of FIG. 7 .

[0055] <Other Embodiments> <1> FIG. 9 is a diagram illustrating an example configuration of a control device. In FIG. 9, the control device 100 includes a processor 101 and a memory 102. The control devices 11 and 30 may have the configuration illustrated in FIG. 9. The processor 101 may be, for example, a microprocessor, a microprocessing unit (MPU), or a central processing unit (CPU). The processor 101 may include multiple processors. The memory 102 is configured by a combination of volatile memory and nonvolatile memory. The memory 102 may include multiple physically independent memory devices. The volatile memory may be, for example, static random access memory (SRAM), dynamic RAM (DRAM), or a combination thereof. The nonvolatile memory may be, for example, mask read only memory (MROM), electrically erasable programmable ROM (EEPROM), flash memory, a hard disk drive, or any combination thereof. The memory 102 may include storage located remotely from the processor 101. In this case, the processor 101 may access the memory 102 via an I (Input) / O (Output) interface (not shown).

[0056] The memory 102 may store one or more software modules (computer programs) including instructions and data for performing the processes of the control devices 11 and 30 described in the above-described embodiments. In some implementations, the processor 101 may be configured to read and execute the software modules from the memory 102 to perform the processes of the control devices 11 and 30 described in the above-described embodiments.

[0057] <2> Fig. 10 is a diagram showing an example of the configuration of a DU device. In Fig. 10, a device 200 includes a network interface 201, a processor 202, and a memory 203. The DU device 10 and the other DU devices described above may have the configuration shown in Fig. 10.

[0058] The network interface 201 is used to communicate with, for example, network elements (e.g., the SMO device 30, other RAN nodes), and may include, for example, a network interface card (NIC) compliant with the IEEE 802.3 series.

[0059] The processor 202 may be, for example, a microprocessor, an MPU, or a CPU. The processor 202 may include multiple processors.

[0060] The memory 203 is composed of volatile memory and nonvolatile memory. The memory 203 may include multiple physically independent memory devices. The volatile memory is, for example, Static Random Access Memory (SRAM), Dynamic RAM (DRAM), or a combination thereof. The nonvolatile memory is, for example, Mask Read Only Memory (MROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, or a hard disk drive, or any combination thereof. The memory 203 may include storage located remotely from the processor 202. In this case, the processor 202 may access the memory 203 via the network interface 201 or an I / O interface.

[0061] The memory 203 may store one or more software modules (computer programs) including instructions and data for performing processing by the DU device 10 described in the above-described embodiments and the other DU devices. In some implementations, the processor 202 may be configured to read and execute the software modules from the memory 203 to perform processing by the DU device 10 described in the above-described embodiments and the other DU devices.

[0062] The event collector and the dedicated device for controlling (monitoring) the RU device may also have the configuration shown in FIG.

[0063] <3> Figure 11 shows an example configuration of an RU device. In Figure 11, the device 300 includes an antenna array 301, a radio frequency transceiver 302, a network interface 303, a processor 304, and a memory 305. The RU device 20 may have the configuration shown in Figure 11. The RF transceiver 302 performs analog RF signal processing for communication with UEs. The RF transceiver 302 may include multiple transceivers. The RF transceiver 302 is coupled to the antenna array 301 and the processor 304. The RF transceiver 302 receives modulation symbol data from the processor 304, generates a transmit RF signal, and provides the transmit RF signal to the antenna array 301. The RF transceiver 302 also generates a baseband receive signal based on the receive RF signal received by the antenna array 301 and provides the baseband receive signal to the processor 304. The RF transceiver 302 may include an analog beamformer circuit for beamforming. The analog beamformer circuitry includes, for example, multiple phase shifters and multiple power amplifiers.

[0064] The network interface 303 is used to communicate with network nodes (eg, the DU 10 and the SMO 30). The network interface 303 may include, for example, a network interface card (NIC) that complies with the IEEE 802.3 series.

[0065] The processor 304 performs digital baseband signal processing (data plane processing) and control plane processing for wireless communication. The processor 304 may include multiple processors. For example, the processor 304 may include a modem processor (e.g., a Digital Signal Processor (DSP)) that performs digital baseband signal processing and a protocol stack processor (e.g., a Central Processing Unit (CPU) or a Micro Processing Unit (MPU)) that performs control plane processing.

[0066] The processor 304 may include a digital beamformer module for beamforming, which may include a Multiple Input Multiple Output (MIMO) encoder and precoder.

[0067] The memory 305 is configured by a combination of volatile memory and non-volatile memory. The volatile memory is, for example, Static Random Access Memory (SRAM), Dynamic RAM (DRAM), or a combination thereof. The non-volatile memory is, for example, Mask Read Only Memory (MROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, or a hard disk drive, or any combination thereof. The memory 305 may include storage located remotely from the processor 304. In this case, the processor 304 may access the memory 305 via the network interface 303 or an I / O interface (not shown).

[0068] The memory 305 may store one or more software modules (computer programs) including instructions and data for performing the processes of the RU device 20 described in the above-described embodiments. In some implementations, the processor 304 may be configured to read and execute the software modules from the memory 305 to perform the processes of the RU device 20 described in the above-described embodiments.

[0069] The antenna array 301 may correspond to the tx-array and rx-array described above.

[0070] <4> Figure 12 is a diagram showing an example configuration of an SMO device. In the example of Figure 12, the SMO device 400 is implemented as a computer system. The computer system 400 includes one or more processors 401, memory 402, and mass storage 403, which communicate with each other via a bus 407. The one or more processors 401 may include, for example, a central processing unit (CPU) or a graphics processing unit (GPU), or both. The computer system 400 may also include other devices such as one or more output devices 404, one or more input devices 405, and one or more peripherals 406. The one or more peripherals 406 may include a modem, a network adapter, or any combination thereof.

[0071] One or both of the memory 402 and the mass storage 403 may include a computer-readable medium having stored thereon one or more sets of instructions, which may be located partially or completely in memory within one or more processors 401. These instructions, when executed in one or more processors 401, cause the one or more processors 401 to provide the functionality of the SMO device 30 described in the above embodiments.

[0072] The event collector and the dedicated device for controlling (monitoring) the RU device may also have the configuration shown in FIG.

[0073] Although the present disclosure has been described above with reference to the embodiments, the present disclosure is not limited to the above. Various modifications that can be understood by those skilled in the art can be made to the configuration and details of the present disclosure within the scope of the disclosure. Furthermore, each embodiment can be combined with other embodiments as appropriate.

[0074] Some or all of the above embodiments may be described as, but are not limited to, the following supplementary notes. (Supplementary Note 1) A first control device controlling an RU (Radio Unit) device, comprising: at least one memory; and at least one processor coupled to the at least one memory, wherein the at least one processor, when switching a control entity controlling the RU device, transmits to the RU device a Remote Procedure Call (RPC) message based on the Network Configuration Protocol (NETCONF) and indicating a configuration edit (edit-config), the RPC message including destination information of a second control device controlling the RU device instead of the first control device, and transmits to the RU device a Session Close message for closing the session between the RU device and the first control device. (Supplementary Note 2) The first control device according to Supplementary Note 1, wherein switching of a control entity controlling the RU device includes a case where the mode of the RU device transitions to an Energy Saving (ES) mode. (Supplementary Note 3) The first control device according to Supplementary Note 2, wherein, in the ES mode of the RU device, the Management (M)-plane of the RU device is operating. (Supplementary Note 4) The first control device described in Supplementary Note 2 or 3, wherein in the ES mode of the RU device, the power-state of the RU device is SLEEPING, or the value of the active parameter of the tx / rx-array-carriers of the RU device is SLEEP or INACTIVE, or both.(Supplementary Note 5) An RU (Radio Unit) device comprising: at least one memory; and at least one processor coupled to the at least one memory, wherein the at least one processor, when switching a controller controlling the RU device, receives from the first controller a Remote Procedure Call (RPC) message based on the Network Configuration Protocol (NETCONF) and indicating a configuration edit (edit-config), the RPC message including destination information of a second controller controlling the RU device instead of a first controller, receives from the first controller a Session Close message for closing the session between the RU device and the first controller, disconnects the session between the RU device and the first controller in response to receiving the Session Close message, and starts a procedure (Call home procedure) with the second controller to establish a session between the second controller and the RU device based on the destination information. (Supplementary Note 6) The RU device according to Supplementary Note 5, wherein switching a controller controlling the RU device includes a case where the mode of the RU device transitions to an Energy Saving (ES) mode. (Supplementary Note 7) The RU apparatus according to Supplementary Note 6, wherein in the ES (Energy Saving) mode of the RU apparatus, the at least one processor operates the M (Management)-plane of the RU apparatus. (Supplementary Note 8) The RU apparatus according to Supplementary Note 6 or 7, wherein in the ES (Energy Saving) mode of the RU apparatus: the power-state of the RU apparatus is SLEEPING, the value of the active parameter of tx / rx-array-carriers of the RU apparatus is SLEEP or INACTIVE, or both. (Supplementary Note 9) The RU apparatus according to any one of Supplements 5 to 7, wherein after establishing a session between the RU apparatus and the second control apparatus, the at least one processor transmits a notification signal to the second control apparatus indicating that the RU apparatus is alive.(Supplementary Note 10) A second control device that controls an RU (Radio Unit) device, comprising: at least one memory; and at least one processor coupled to the at least one memory, wherein the at least one processor, when switching the entity that controls the RU device from a first control device to the second control device, initiates a procedure for establishing a session between the RU device and the second control device with the RU device, and switches the account of the second control device to an account of a type that allows session monitoring. (Supplementary Note 11) The second control device according to Supplementary Note 10, wherein switching the entity that controls the RU device from the first control device to the second control device includes a case where the mode of the RU device transitions to an ES (Energy Saving) mode. (Supplementary Note 12) The second control device according to Supplementary Note 11, wherein, in the ES mode of the RU device, the M (Management)-plane of the RU device is operating. (Supplementary Note 13) The second control device according to Supplementary Note 11 or 12, wherein, in the ES mode of the RU device, the power-state of the RU device is SLEEPING, or the value of the active parameter of tx / rx-array-carriers of the RU device is SLEEP or INACTIVE, or both. (Supplementary Note 14) The second control device according to any one of Supplements 10 to 12, wherein the at least one processor transmits to the RU device a message including information for changing the transmission interval at which the RU device transmits to the second control device a notification signal indicating that the RU device is alive. (Supplementary Note 15) The second control device according to any one of Supplements 10 to 12, wherein the at least one processor does not transmit to the RU device a notification signal indicating that the second control device is alive, and receives from the RU device a notification signal indicating that the RU device is alive.(Supplementary Note 16) The second control device according to any one of Supplements 10 to 12, wherein the second control device is a DU (Distributed Unit) node, an SMO (Service Management and Orchestration) node, or an event collector. (Supplementary Note 17) A method executed by a first control device controlling an RU (Radio Unit) device, the method including, when switching a control entity controlling the RU device, sending to the RU device a Remote Procedure Call (RPC) message that is based on the Network Configuration Protocol (NETCONF) and indicates a configuration edit (edit-config), the RPC message including destination information of a second control device that controls the RU device instead of the first control device, and sending to the RU device a Session Close message for closing the session between the RU device and the first control device. (Supplementary Note 18) The method according to Supplementary Note 17, wherein switching the control entity controlling the RU device includes a case where the mode of the RU device transitions to an Energy Saving (ES) mode.(Supplementary Note 19) A method executed by a RU (Radio Unit) device, the method including, when switching a controller controlling the RU device, receiving from the first controller a Remote Procedure Call (RPC) message based on the Network Configuration Protocol (NETCONF) and indicating a configuration edit (edit-config), the RPC message including destination information of a second controller controlling the RU device instead of a first controller, receiving from the first controller a Session Close message for closing the session between the RU device and the first controller, disconnecting the session between the RU device and the first controller in response to receiving the Session Close message, and initiating a procedure (Call home procedure) for establishing a session between the second controller and the RU device based on the destination information. (Supplementary Note 20) The method according to Supplementary Note 19, wherein switching a controller controlling the RU device includes a case where the mode of the RU device transitions to an Energy Saving (ES) mode. (Supplementary Note 21) A method executed by a second control device that controls an RU (Radio Unit) device, the method including: when switching an entity that controls the RU device from a first control device to the second control device, initiating a procedure for establishing a session between the RU device and the second control device, and switching an account of the second control device to an account of a type that allows session monitoring. (Supplementary Note 22) The method according to Supplementary Note 21, wherein switching an entity that controls the RU device from the first control device to the second control device includes a case where the mode of the RU device transitions to an ES (Energy Saving) mode.(Supplementary Note 23) A system comprising: an RU (Radio Unit) device; a first control device that controls the RU device; and a second control device that controls the RU device instead of the first control device, wherein the first control device is configured to: when switching a control entity that controls the RU device, send to the RU device an RPC (Remote Procedure Call) message that is based on the NETCONF (Network Configuration Protocol) protocol and indicates configuration editing (edit-config), the RPC message including destination information of the second control device; and send to the RU device a Session Close message for closing the session between the RU device and the first control device; and the RU device is configured to: receive from the first control device the RPC message indicating configuration editing, receive the Session Close message from the first control device, and in response to receiving the Session Close message, disconnect the session between the RU device and the first control device, and start a procedure (Call home procedure) with the second control device to establish a session between the second control device and the RU device based on the destination information. (Supplementary Note 24) The system according to Supplementary Note 23, wherein the second control device is configured to: initiate the procedure for establishing the session with the RU; and switch the account of the second control device to an account type that allows session monitoring.

[0075] This application claims priority based on Japanese Patent Application No. 2022-151205, filed September 22, 2022, the disclosure of which is incorporated herein in its entirety.

[0076] 10 DU device 11 control unit (first control device) 20 RU device 21 control unit 30 control device (second control device) < / ok> < / get> < / get>

Claims

1. A first control device for controlling a RU (Radio Unit) device, comprising: at least one memory; at least one processor coupled to the at least one memory; wherein, when switching the control entity for controlling the RU device, the at least one processor transmits an RPC (Remote Procedure Call) message, which is a message based on the NETCONF (Network Configuration Protocol) protocol and indicates edit-config and includes destination information of a second control device that controls the RU device instead of the first control device, to the RU device; and transmits a Session Close message for closing a session between the RU device and the first control device to the RU device. A first control device.

2. The first control device according to claim 1, wherein when switching the control entity for controlling the RU device, it includes the case where the mode of the RU device shifts to the ES (Energy Saving) mode.

3. In the ES mode of the RU device, the M (Management)-plane of the RU device is operating. The first control device according to claim 2.

4. In the ES mode of the RU device, either the power-state of the RU device is SLEEPING, or the value of the active parameter of the tx / rx-array-carriers of the RU device is SLEEP or INACTIVE, or both. The first control device according to claim 2 or 3.

5. A RU (Radio Unit) device, comprising: at least one memory; at least one processor coupled to the at least one memory; wherein, when switching the control entity for controlling the RU device, the at least one processor receives, from the first control device, an RPC (Remote Procedure Call) message, which is a message based on the NETCONF (Network Configuration Protocol) protocol and indicates edit-config and includes destination information of a second control device that controls the RU device instead of the first control device. ​ ​ ​ Receive a Session Close message from the first control device to close the session between the RU device and the first control device, In response to the reception of the Session Close message, disconnect the session between the RU device and the first control device, Start a procedure (Call home procedure) to establish a session between the second control device and the RU device based on the destination information with the second control device, RU device. **Claim 6** When switching the control entity that controls the RU device, it includes the case where the mode of the RU device shifts to the ES (Energy Saving) mode, The RU device according to claim 5. **Claim 7** In the ES (Energy Saving) mode of the RU device, the at least one processor operates the M (Management)-plane of the RU device, The RU device according to claim 6. **Claim 8** In the ES (Energy Saving) mode of the RU device, If the power-state of the RU device is SLEEPING, If the value of the active parameter of the tx / rx-array-carriers of the RU device is SLEEP or INACTIVE, or Both of them, The RU device according to claim 6 or 7. **Claim 9** After the at least one processor establishes a session between the RU device and the second control device, the at least one processor transmits a notification signal indicating that the RU device is alive to the second control device, The RU device according to any one of claims 5 to 7. **Claim 10** A second control device for controlling a RU (Radio Unit) device, comprising: At least one memory, At least one processor coupled to the at least one memory, And comprising, The at least one processor: When switching the entity that controls the RU device from the first control device to the second control device, start a procedure to establish a session between the RU device and the second control device with the RU device, Switch the account of the second control device to an account of a type for which session monitoring is permitted, Second control device.