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

Technical Field

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

Background Art

[0002] In recent years, a radio access network that separates the baseband unit and the radio unit of a base station and connects the baseband unit and the radio unit via a fronthaul has been used. The O-RAN (Open-Radio Access Network) fronthaul specification defined by the O-RAN Alliance defines the fronthaul specification between an O-RU (O-RAN Radio Unit) corresponding to the radio unit and an O-DU (O-RAN Distributed Unit) corresponding to the baseband unit. One purpose of the O-RAN fronthaul specification is to facilitate the connection between an O-RU of a vendor different from the O-DU vendor and to realize multi-vendorization of the radio access network. Note that the O-DU may also be simply called a DU. Also, the O-RU may also be simply called a RU.

[0003] Non-Patent Document 1 specifies the M(Management)-Plane, which is defined for transmitting management data between O-RUs and O-DUs. The M-Plane provides management functions for O-RUs. In the M-Plane, the O-DU or SMO (Service Management and Orchestration) is defined as the device that manages the O-RUs. The O-RUs under management correspond to NETCONF servers, and the device that manages (controls) the O-RUs (RU control device) corresponds to a 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 how to change the Power State of an O-RU. When the Power State is AWAKE, the O-RU operates normally (not in Energy saving mode), and when the Power State is SLEEPING, the O-RU operates in Energy saving mode. The Power State of an O-RU is changed when the RU control device sends an RPC (Remote Procedure Call) message to the O-RU indicating a configuration edit (edit-config). [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] O-RAN-WG4.MP.0-v09.00,“O-RAN Working Group 4 (Open Fronthaul Interfaces WG) Management Plane Specification” [Overview of the Initiative] [Problems that the invention aims to solve]

[0006] The inventors have examined the O-RAN fronthaul specification and identified various issues. For example, Non-Patent Document 1 does not adequately consider situations in which it is desirable to switch the entity managing (controlling) the O-RU, or what processing should be performed in such situations. For instance, even if the RU device's mode shifts to ES (Energy Saving) mode, the RU device's M-plane may still be operating (alive). This allows the O-RU to be switched to a normal mode other than ES mode at any time. If the RU device's mode shifts to ES mode while the O-DU device's control unit is controlling the RU device and the M-plane is operating (i.e., the M-plane is alive), the O-DU device's control unit needs to monitor the RU device's status through the M-plane. Therefore, even if the RU device's mode shifts to ES mode, the O-DU device's resources cannot be released. For this reason, there is a need to switch the entity monitoring the O-DU device from the O-DU device's control unit to another device.

[0007] One of the objectives that the embodiments disclosed herein seek to achieve is to provide a control device and RU device that contribute to solving at least one of several problems, including the problems described above. It should be noted that this objective is only one of several objectives that the embodiments disclosed herein seek to achieve. Other objectives or problems and novel features will be revealed in the description herein or in the accompanying drawings. [Means for solving the problem]

[0008] In one embodiment, the first control device that controls the RU (Radio Unit) device is: At least one memory, At least one processor coupled to the at least one memory, Equipped with, The aforementioned at least one processor is When switching the control entity that controls the RU device, an RPC (Remote Procedure Call) message is sent to the RU device, which is based on the NETCONF (Network Configuration Protocol) protocol and indicates configuration editing (edit-config), and includes destination information of the second control device that controls the RU device instead of the first control device. A Session Close message is sent to the RU device to close the session between the RU device and the first control device.

[0009] In other embodiments, the RU (Radio Unit) device is At least one memory, At least one processor coupled to the at least one memory, Equipped with, The aforementioned at least one processor is When switching the control entity that controls the RU device, the first control unit receives an RPC (Remote Procedure Call) message from the first control unit that is based on the NETCONF (Network Configuration Protocol) protocol and indicates configuration editing (edit-config), and includes destination information for the second control unit that controls the RU device instead of the first control unit. A Session Close message for closing the session between the RU device and the first control device is received from the first control device. Upon receiving the Session Close message, the session between the RU device and the first control device is disconnected. A procedure for establishing a session between the second control unit and the RU device (Call home procedure) is initiated with the second control unit based on the destination information.

[0010] In other embodiments, a second control device that controls the RU (Radio Unit) device is: At least one memory, At least one processor coupled to the at least one memory, Equipped with, The aforementioned at least one processor is When switching the entity controlling the RU device from the first control device to the second control device, a procedure for establishing a session between the RU device and the second control device is initiated with the RU device, Switch the account of the second control device to an account of a type that allows session monitoring.

[0011] In other embodiments, a method performed by a first control unit that controls a Radio Unit (RU) device is: When switching the control entity that controls the RU device, an RPC (Remote Procedure Call) message is sent to the RU device, which is based on the NETCONF (Network Configuration Protocol) protocol and indicates configuration editing (edit-config), and includes destination information of the second control device that controls the RU device instead of the first control device. Sending a Session Close message to the RU device to close the session between the RU device and the first control device, Includes.

[0012] In other embodiments, the method performed by the RU (Radio Unit) device is: When switching the control entity that controls the RU device, receiving, from the first control device, an RPC (Remote Procedure Call) message that is based on the NETCONF (Network Configuration Protocol) protocol and indicates an edit-config (configuration editing) message and includes destination information for a second control device that controls the RU device instead of the 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; Starting, with the second control device, a call home procedure for establishing a session between the second control device and the RU device based on the destination information; Including.

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

[0014] In another aspect, a system includes: a RU (Radio Unit) device a first control device that controls the RU device, a second control device that controls the RU device instead of the first control device, and includes: The first control device When switching the control entity that controls the RU device, an RPC (Remote Procedure Call) message based on the NETCONF (Network Configuration Protocol) protocol and indicating configuration editing (edit-config), including the destination information of the second control device, is transmitted to the RU device. A Session Close message for closing the session between the RU device and the first control device is transmitted to the RU device. It is configured as follows. The RU device receives the RPC message indicating the configuration editing from the first control device. receives the Session Close message from the first control device. In response to receiving the Session Close message, the session between the RU device and the first control device is disconnected. A procedure (Call home procedure) for establishing a session between the second control device and the RU device based on the destination information is started with the second control device. It is configured as follows.

Advantages of the Invention

[0015] According to the present disclosure, it is possible to provide a control device, an RU device, a system, and a method that contribute to solving at least one of a plurality of problems including the above-described problems.

Brief Description of the Drawings

[0016] [Figure 1] It is a diagram showing an example of a procedure for acquiring the state of the RU. [Figure 2] It is a diagram showing an example of a procedure for changing the state of the RU. [Figure 3] It is a diagram for explaining the power state of the RU. [Figure 4]This diagram shows the possible transitions and the combinations of the "active" and "state" parameters. [Figure 5] Block diagram showing an example of the system in this disclosure. [Figure 6] This figure shows an example of the processing operation of the system disclosed herein. [Figure 7] This figure shows a modified example 1 of the processing operation of the system disclosed herein. [Figure 8] This figure shows a modified example 2 of the processing operation of the system disclosed herein. [Figure 9] This is a diagram showing an example of the configuration of a control device. [Figure 10] This figure shows an example of the configuration of a DU device. [Figure 11] This is a diagram showing an example configuration of an RU device. [Figure 12] This figure shows an example of the configuration of an SMO (Scaling Modulation) device. [Modes for carrying out the invention]

[0017] The embodiments will be described below with reference to the drawings. In this disclosure, the drawings may be associated with one or more embodiments. Also, each element in the drawings may correspond to one or more embodiments. Furthermore, in the embodiments, the same or equivalent elements are denoted by the same reference numerals, and redundant descriptions are omitted.

[0018] The multiple embodiments described below can be implemented independently or in combination as appropriate. These multiple embodiments have novel features that differ from each other. Therefore, these multiple embodiments contribute to solving different objectives or problems and contribute to producing different effects.

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

[0020] As used herein, depending on the context, “(if)” may be interpreted as meaning “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 as having the same meaning depending on the context.

[0021] First, the related technologies will be described. Each embodiment is based on these technologies. In other words, these technologies can be incorporated into each embodiment.

[0022] (protocol) 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 directly transmits signals used in eCPRI or RoE (Radio over Ethernet) over Ethernet, and optionally a protocol stack that transmits signals via UDP (User Datagram Protocol) / IP. S-Plane is a protocol for achieving synchronization between devices. S-Plane supports protocol stacks that transmit signals used in PTP (Precision Time Protocol) and SyncE (Synchronous Ethernet) over Ethernet. M(Management)-Plane is a protocol for handling 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 via Ethernet / IP / TCP (Transmission Control Protocol) / TLS (Transport Layer Security).

[0023] (Logical architecture) The O-RAN (Open-Radio Access Network) Alliance adopts a configuration that separates the RAN's communication processing functions into three components: RU (Radio Unit), DU (Distributed Unit), and CU (Central Unit). Furthermore, it defines "RIC (RAN Intelligent Controller)," a platform that optimizes wireless resource management and automates operations, and "SMO (Service Management and Orchestration)," a framework for RAN maintenance and orchestration. The RU and DU are connected by an open fronthaul. CUS / M-Plane signals are transmitted through this open fronthaul between the RU and DU. Alternatively, the RU and SMO may be connected by an open fronthaul, and M-Plane signals may be transmitted through this open fronthaul. In this case as well, CUS-Plane signals are transmitted through the open fronthaul between the RU and DU. Furthermore, the DU and SMO are connected via the O1 interface. The CU and SMO are also connected via the O1 interface. The managed RUs correspond to the NETCONF server, and the device that manages (controls) the RUs (RU control device) corresponds to the NETCONF client. The NETCONF client may be installed in the DU or in the SMO.

[0024] (Retrieving the State of the RU) Figure 1 shows an example of the procedure for obtaining the State of an RU. In Figure 1, the RU controller is NETCONF <get>Use the procedure to obtain the state of the RU.

[0025] Specifically, the RU control unit sends an RPC (Remote Procedure Call) message to the RU indicating a get. The RU responds to the RPC message by sending an RPC reply message to the RU control unit. This RPC reply message contains information indicating the RU's state. In other words, the RU control unit, <get>The State of the RU can be retrieved via request.

[0026] (Modifying the State of the RU) The RU controller can change the configurable state of a RU for RUs that support optional hardware-state features defined in the RU's hardware. The RU controller can change the NETCONF without resetting. <edit-config>The configurable State of a RU can be changed using the provided procedure.

[0027] Figure 2 shows an example of the procedure for changing the State of the RU. The RU control unit performs NETCONF without resetting. <edit-config>Use the procedure to change the configurable State of the RU.

[0028] Specifically, the RU control unit sends an RPC message to the RU indicating a configuration edit (edit-config). The RU changes its state based on this RPC message. Then, if the change is successful, <ok>Send an RPC response message indicating this to the RU control unit.

[0029] [power-state] The configurable state of an RU is, for example, power-state. As shown in Figure 3, the RU's Power State can be "AWAKE" or "SLEEPING". Figure 3 is a diagram illustrating the RU's Power State. The RU control unit controls the RU's Power State by editing the RU's "energy-saving-enabled" parameter by sending an RPC message to the RU indicating configuration editing (edit-config). 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 Power-state transitions to AWAKE or SLEEPING. -AWAKE: This Power State indicates that the RU is operating normally, i.e., not in energy saving mode. -SLEEPING: This Power State indicates that the RU is in Energy saving mode.

[0030] (RU Carrier settings) The RU control unit is NETCONF <edit-config>The parameters of the RU can be set (updated) using the procedure. 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". A tx-array-carrier(s) element (and / or 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 the possible transitions and the combinations of the "active" parameter and the "state" parameter.

[0031] Here, tx-array-carrier(s) is a data node generated by the RU control unit that includes carrier configuration parameters and is associated with the RU's transmit array (tx-array) information. Similarly, rx-array-carrier(s) is a data node generated by the RU control unit that includes carrier configuration parameters and is 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 set for the RU.

[0032] <First Embodiment> <Example of system configuration> Figure 5 is a block diagram showing an example of the system of this disclosure. In Figure 5, 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 PDCP (Packet Data Convergence Protocol) layer, the RLC (Radio Link Control) layer, and the MAC (Media Access Control) layer, as well as higher-level functions of the physical layer, or it may be a physical device that houses this logical node. The higher-level functions of the physical layer may include, for example, encoding and modulation processing, as well as decoding and demodulation processing. The functions in the PDCP layer may be performed in a logical node called a CU (Central Unit) (not shown).

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

[0035] In Figure 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 the "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 signals from the CUS-Plane and signals from the M-Plane.

[0036] Here, there is a need to switch the control entity that controls (monitors) the RU device 20 from control device 11 to control device 30. Hereafter, control device 30 may also be called the "second control device". As described above, for example, when control device 11 of DU device 10 is controlling the RU device 20, the mode of the RU device 20 may transition to ES mode while in M-plane operation state (i.e., M-plane is alive). If the control entity that controls the RU device 20 is not switched at this time, control device 11 of DU device 10 will need to monitor the status of the RU device 20 through the M-plane. For this reason, even if the mode of the RU device 20 transitions to ES mode, the resources of DU device 10 cannot be released. Therefore, by switching the control entity that controls the RU device 20 from control device 11 to control device 30, it becomes possible to release the resources of DU device 10.

[0037] The control device 30 may be, for example, the control unit (RU control device) of the SMO device. The control unit (RU control device) of the SMO device may support NETCONF clients. 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 the optimization of wireless resource management and the automation of operations. In this case, the RU device 20 and the SMO device may also be connected by an open fronthaul. In addition, the DU device 10 and the SMO device may be connected via the O1 interface.

[0038] Furthermore, the control device 30 may be, for example, the 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 support NETCONF clients. The RU device 20 and the other DU device may also be connected by an open fronthaul. Note that the other DU device may be connected to the RU device 20 as well as to another RU device. The mode of this other RU device may be normal mode or ES mode.

[0039] Furthermore, the control device 30 may 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 ES (Energy Saving) mode of the RU device 20, the power-state of the RU device 20 is SLEEPING, or 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> Figure 6 shows an example of the processing operation of the system of this disclosure. The processing operation of system 1 shown in Figure 6 is initiated when the control entity that controls (monitors) the RU device 20 is switched from control device 11 to control device 30.

[0043] The control device 11 sends a message indicating configuration editing (edit-config) (hereinafter sometimes referred to as the "first request message") to the RU device 20 (step S101). The first request message may be based on the NETCONF (Network Configuration Protocol) protocol. The first request message includes destination information for the control device 30, which 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 information elements related to the destination held by the RU device 20.

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

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

[0046] Based on the destination information of the control device 30, the RU device 20 initiates a procedure with the control device 30 to establish a session between the RU device 20 and the control device 30 (step S105). This procedure may be, for example, a 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 switches the control entity that controls (monitors) the RU device 20 to the control device 30.

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

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

[0049] For example, if the control device 30 supports a NETCONF client and the RU device 20 supports a NETCONF server, the notification signal that the RU device 20 sends to the control device 30 may be a Supervision-notification. Also, the notification signal that the control device 30 sends to the RU device 20 may be: <supervision-watchdog-reset>This may also be an RPC message indicating this. 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 sends a Supervision-notification to the control device 30. In response to receiving the Supervision-notification, the control device 30 <supervision-watchdog-reset>The RU device 20 sends an RPC message indicating this. The RU device 20 resets the Notification timer and the Supervision timer. Note that the control device 30 is compatible with NETCONF clients, as described above, for example, when the control device 30 is the control unit (RU control device) of the SMO device, or when the control device 30 is the control unit (control device) of another DU device other than the DU device 10.

[0050] Alternatively, the control entity that controls (monitors) the RU device 20 may be returned from the control device 30 to the control device 11 using a procedure similar to that shown in Figure 6. Specifically, the control device 30 sends a first request message to the RU device 20 containing destination information for the control device 11, which controls (monitors) the RU device 20 on behalf of the control device 30. The control device 30 also sends a Session Close message to the RU device 20 to close the session between the RU device 20 and the control device 30. Upon receiving the Session Close message, the RU device 20 disconnects the session between the RU device 20 and the control device 30. Based on the destination information from the control device 30, the RU device 20 initiates a procedure with the control device 11 to establish a session between the RU device 20 and the control device 11.

[0051] <Variation> The following modifications may be made to the processing operation of the system in the first embodiment.

[0052] <1> Figure 7 shows a modified example 1 of the processing operation of the system of this disclosure. As shown in Figure 7, the RU device 20 periodically sends a notification signal (e.g., Supervision notification, heartbeat, etc.) to the control device 30 indicating that the RU device 20 is alive (step S201). In contrast, the control device 30 does not send a notification signal (e.g., Supervision notification, heartbeat, etc.) to the RU device 20 indicating that the control device 30 is alive. That is, the control device 30 does not send a notification signal to the RU device 20 indicating that the control device 30 is alive, and instead receives a notification signal from the RU device 20 indicating that the RU device 20 is alive. As a result, instead of bidirectional session monitoring, the control device 30 monitors the status of the RU device 20 (e.g., whether the RU device 20 is alive or dead) in one direction. This simplifies the monitoring method. In particular, if the control device 30 is an event collector, the notification signal that the control device 30 receives from the RU device 20 may be a Heartbeat Notification.

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

[0054] <2> Figure 8 shows a modified example 2 of the processing operation of the system of this disclosure. As shown in Figure 8, the control device 30 sends a message containing information to the RU device 20 to change the period (transmission interval) in which the RU device 20 transmits notification signals (e.g., Supervision notification, heartbeat, etc.) indicating that the RU device 20 is alive (step S301). The control device 30 may also send this message containing information to change the period immediately after establishing the M-plane between the RU device 20 and the control device 30. Alternatively, the control device 30 may change the transmission period of the RU device 20 to a period corresponding to the load of the control device 30. For example, the larger the load on the control device 30 (i.e., the less processing capacity the control device 30 has), the longer the transmission period of the RU device 20 may be. Note that the message containing information to change the transmission period (transmission interval) of the RU device 20 may also be sent from the control device 30 to the RU device 20 in the sequence shown in Figure 7.

[0055] <Other Embodiments> <1> Figure 9 shows an example of the configuration of a control device. In Figure 9, the control device 100 has a processor 101 and a memory 102. Control devices 11 and 30 may have the configuration shown in Figure 9. The processor 101 may be, for example, a microprocessor, an MPU (Micro Processing Unit), or a CPU (Central Processing Unit). The processor 101 may include multiple processors. The memory 102 is composed of a combination of volatile memory and non-volatile memory. The memory 102 may include multiple physically independent memory devices. Volatile memory is, for example, Static Random Access Memory (SRAM) or Dynamic RAM (DRAM), or a combination thereof. Non-volatile memory is Mask Read Only Memory (MROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, or a hard disk drive, or any combination thereof. The memory 102 may include storage located away from the processor 101. In this case, the processor 101 may access memory 102 via an I(Input) / O(Output) interface, which is not shown.

[0056] Memory 102 may store one or more software modules (computer programs) containing instruction sets and data for processing by the control devices 11 and 30 described in the above embodiments. In some implementations, the processor 101 may be configured to read and execute the software modules from memory 102 to perform the processing of the control devices 11 and 30 described in the above embodiments.

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

[0058] Network interface 201 is used, for example, to communicate with network elements (e.g., SMO device 30, other RAN nodes). Network interface 1201 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] Memory 203 consists of volatile memory and non-volatile memory. Memory 203 may include multiple physically independent memory devices. Volatile memory is, for example, Static Random Access Memory (SRAM) or Dynamic RAM (DRAM), or a combination thereof. Non-volatile memory is Mask Read Only Memory (MROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, or hard disk drive, or any combination thereof. Memory 203 may include storage located away from the processor 202. In this case, the processor 202 may access memory 203 via a network interface 201 or an I / O interface.

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

[0062] Furthermore, a dedicated device for controlling (monitoring) the above-mentioned event collector and RU device may also have the configuration shown in Figure 10.

[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 memory 305. The RU device 20 may have the configuration shown in Figure 11. The RF transceiver 302 performs analog RF signal processing to communicate with UEs. The RF transceiver 302 may include multiple transceivers. The RF transceiver 302 is coupled with 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 supplies the transmit RF signal to the antenna array 301. The RF transceiver 302 also generates a baseband receive signal based on the received RF signal received by the antenna array 301 and supplies it to the processor 304. The RF transceiver 302 may include an analog beamformer circuit for beamforming. The analog beamformer circuit includes, for example, multiple phase shifters and multiple power amplifiers.

[0064] The network interface 303 is used to communicate with network nodes (e.g., DU10, SMO30). The network interface 303 may include, for example, a network interface card (NIC) compliant with the IEEE 802.3 series.

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

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

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

[0068] The memory 305 may store one or more software modules (computer programs) containing instruction sets and data for performing processing by the RU device 20 as described in the above embodiments. In some implementations, the processor 304 may be configured to perform the processing of the RU device 20 as described in the above embodiments by reading and executing the software modules from the memory 305.

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

[0070] <4> Figure 12 shows an example configuration of an SMO device. In the example in 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 or a network adapter, or any combination thereof.

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

[0072] Furthermore, a dedicated device for controlling (monitoring) the above-mentioned event collector and RU device may also have the configuration shown in Figure 12.

[0073] While the present disclosure has been described above with reference to embodiments, the disclosure is not limited thereto. Various modifications to the structure and details of the present disclosure are possible, as can be understood by those skilled in the art 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 also be described as follows, but are not limited to the following: (Note 1) A first control device for controlling a Radio Unit (RU) device, At least one memory, At least one processor coupled to the at least one memory, Equipped with, The aforementioned at least one processor is When switching the control entity that controls the RU device, an RPC (Remote Procedure Call) message is sent to the RU device, which is based on the NETCONF (Network Configuration Protocol) protocol and indicates configuration editing (edit-config), and includes destination information of the second control device that controls the RU device instead of the first control device. A Session Close message is sent to the RU device to close the session between the RU device and the first control device. First control device. (Note 2) When switching the control entity that controls the RU device, this includes cases where the mode of the RU device transitions to ES (Energy Saving) mode. The first control device as described in Appendix 1. (Note 3) In the ES mode of the RU device, the M(Management)-plane of the RU device is operating. The first control device as described in Appendix 2. (Note 4) In the ES mode of the RU device, Is the power state of the RU device SLEEPING? The value of the active parameter of the tx / rx-array-carriers in the RU device is either SLEEP or INACTIVE, or It is both. The first control device as described in Appendix 2 or 3. (Note 5) RU (Radio Unit) device, At least one memory, At least one processor coupled to the at least one memory, Equipped with, The aforementioned at least one processor is When switching the control entity that controls the RU device, the first control unit receives an RPC (Remote Procedure Call) message from the first control unit that is based on the NETCONF (Network Configuration Protocol) protocol and indicates configuration editing (edit-config), and includes destination information for the second control unit that controls the RU device instead of the first control unit. A Session Close message for closing the session between the RU device and the first control device is received from the first control device. Upon receiving the Session Close message, the session between the RU device and the first control device is disconnected. A procedure for establishing a session between the second control unit and the RU device (Call home procedure) is initiated with the second control unit based on the destination information. RU equipment. (Note 6) When switching the control entity that controls the RU device, this includes cases where the mode of the RU device transitions to ES (Energy Saving) mode. The RU device described in Appendix 5. (Note 7) In the ES (Energy Saving) mode of the RU device, at least one processor operates the M (Management)-plane of the RU device. The RU device described in Appendix 6. (Note 8) In the ES (Energy Saving) mode of the aforementioned 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, It is both. The RU device described in Appendix 6 or 7. (Note 9) After establishing a session between the RU device and the second control unit, the at least one processor transmits a notification signal to the second control unit indicating that the RU device is alive. An RU device as described in any one of the items 5 to 7 of the appendix. (Note 10) A second control device for controlling a Radio Unit (RU) device, At least one memory, At least one processor coupled to the at least one memory, Equipped with, The aforementioned at least one processor is When switching the entity controlling the RU device from the first control device to the second control device, a procedure for establishing a session between the RU device and the second control device is initiated with the RU device, Switch the account of the second control device to an account of a type that allows session monitoring. Second control device. (Note 11) When switching the main entity controlling the RU device from the first control unit to the second control unit, this includes cases where the mode of the RU device transitions to ES (Energy Saving) mode. The second control device as described in Appendix 10. (Note 12) In the ES mode of the RU device, the M(Management)-plane of the RU device is operating. The second control device as described in Appendix 11. (Note 13) In the ES mode of the RU device, Is the power state of the RU device SLEEPING? The value of the active parameter of the tx / rx-array-carriers in the RU device is either SLEEP or INACTIVE, or It is both. The second control device as described in Appendix 11 or 12. (Note 14) The at least one processor sends a message to the RU device containing information to change the transmission interval at which the RU device transmits a notification signal indicating that the RU device is alive to the second control unit. The second control device described in any one of the appendices 10 to 12. (Note 15) The at least one processor does not send a notification signal to the RU device indicating that the second control device is alive, and receives a notification signal from the RU device indicating that the RU device is alive. The second control device described in any one of the appendices 10 to 12. (Note 16) The second control device is a DU (Distributed Unit) node, an SMO (Service Management and Orchestration) node, or an event collector. The second control device described in any one of the appendices 10 to 12. (Note 17) A method performed by a first control device that controls a Radio Unit (RU) device, When switching the control entity that controls the RU device, an RPC (Remote Procedure Call) message is sent to the RU device, which is based on the NETCONF (Network Configuration Protocol) protocol and indicates configuration editing (edit-config), and includes destination information of the second control device that controls the RU device instead of the first control device. Sending a Session Close message to the RU device to close the session between the RU device and the first control device, including, method. (Note 18) When switching the control entity that controls the RU device, this includes cases where the mode of the RU device transitions to ES (Energy Saving) mode. The method described in Appendix 17. (Note 19) A method performed by a Radio Unit (RU) device, When switching the control entity that controls the RU device, the first control unit receives an RPC (Remote Procedure Call) message from the first control unit that is based on the NETCONF (Network Configuration Protocol) protocol and indicates configuration editing (edit-config), and includes destination information for the second control unit that controls the RU device instead of the first control unit. The RU device receives a Session Close message from the first control device to close the session between the RU device and the first control device, Upon receiving the Session Close message, the session between the RU device and the first control device is disconnected. A procedure for establishing a session between the second control unit and the RU device based on the destination information (Call home procedure) is initiated with the second control unit, including, method. (Note 20) When switching the control entity that controls the RU device, this includes cases where the mode of the RU device transitions to ES (Energy Saving) mode. The method described in Appendix 19. (Note 21) A method performed by a second control device that controls a Radio Unit (RU) device, When switching the entity controlling the RU device from the first control device to the second control device, the procedure for establishing a session between the RU device and the second control device is initiated with the RU device, Switching the account of the second control device to an account of a type that allows session monitoring, including, method. (Note 22) When switching the main entity controlling the RU device from the first control unit to the second control unit, this includes cases where the mode of the RU device transitions to ES (Energy Saving) mode. The method described in Appendix 21. (Note 23) RU (Radio Unit) device and A first control device that controls the RU device, A second control device that controls the RU device instead of the first control device, Equipped with, The first control device is When switching the control entity that controls the RU device, an RPC (Remote Procedure Call) message, which is based on the NETCONF (Network Configuration Protocol) protocol and indicates configuration editing (edit-config), and which includes destination information of the second control device, is sent to the RU device. A Session Close message is sent to the RU device to close the session between the RU device and the first control device. It is configured in such a way, The RU device is The RPC message indicating the aforementioned setting edit is received from the first control unit, The Session Close message is received from the first control unit, Upon receiving the Session Close message, the session between the RU device and the first control device is disconnected. A procedure for establishing a session between the second control unit and the RU device (Call home procedure) is initiated with the second control unit based on the destination information. It is configured in such a way. system. (Note 24) The second control device is The procedure for establishing the aforementioned session is initiated with the RU, Switch the account of the second control device to an account of a type that allows session monitoring. It is configured in such a way. The system described in Appendix 23.

[0075] This application claims priority based on Japanese Patent Application No. 2022-151205, filed on 22 September 2022, and incorporates all of its disclosures herein. [Explanation of Symbols]

[0076] 10 DU equipment 11 Control Unit (First Control Unit) 20RU equipment 21 Control Unit 30 Control device (second control device) < / ok> < / get> < / get>

Claims

1. A first control device for controlling a Radio Unit (RU) device, At least one memory, At least one processor coupled to the at least one memory, Equipped with, The aforementioned at least one processor is When switching the control entity that controls the RU device, a Remote Procedure Call (RPC) message is sent to the RU device, which is based on the Network Configuration Protocol (NETCONF) protocol and indicates configuration editing (edit-config), and includes destination information of the second control device that controls the RU device instead of the first control device. A Session Close message for closing the session between the RU device and the first control device is sent to the RU device. First control device.

2. When switching the control entity that controls the RU device, this includes cases where the mode of the RU device transitions to ES (Energy Saving) mode. The first control device according to claim 1.

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, Is the power state of the RU device SLEEPING? The value of the active parameter of the tx / rx-array-carriers in the RU device is either SLEEP or INACTIVE, or It is both. The first control device according to claim 2 or 3.

5. A Radio Unit (RU) device, At least one memory, At least one processor coupled to the at least one memory, Equipped with, The aforementioned at least one processor is When switching the control entity that controls the RU device, the first control unit receives an RPC (Remote Procedure Call) message from the first control unit that is based on the NETCONF (Network Configuration Protocol) protocol and indicates configuration editing (edit-config), and includes destination information for the second control unit that controls the RU device instead of the first control unit. A Session Close message for closing the session between the RU device and the first control device is received from the first control device. Upon receiving the Session Close message, the session between the RU device and the first control device is disconnected. A procedure (Call home procedure) for establishing a session between the second control unit and the RU device based on the destination information is initiated with the second control unit. RU equipment.

6. When switching the control entity that controls the RU device, this includes cases where the mode of the RU device transitions to ES (Energy Saving) mode. The RU device according to claim 5.

7. In the Energy Saving (ES) mode of the RU device, the at least one processor operates the Management (M)-plane of the RU device. The RU device according to claim 6.

8. In the ES (Energy Saving) mode of the aforementioned 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, It is both. The RU device according to claim 6 or 7.

9. After establishing a session between the RU device and the second control unit, the at least one processor transmits a notification signal to the second control unit indicating that the RU device is alive. The RU device according to any one of claims 5 to 7.

10. A second control device for controlling a Radio Unit (RU) device, At least one memory, At least one processor coupled to the at least one memory, Equipped with, The aforementioned at least one processor is When switching the entity controlling the RU device from the first control device to the second control device, a procedure for establishing a session between the RU device and the second control device is initiated with the RU device, Switch the account of the second control device to an account of a type that allows session monitoring. Second control device.

Images