Control method and apparatus in open radio access network

Abstract

A control method and apparatus in an open wireless access network are provided. A change of a first distributed unit (DU) connected to a radio unit (RU) through a first fronthaul interface is determined, and when the change of the first distributed unit is determined, a second distributed unit connected to the radio unit through a second fronthaul interface is selected. Then, to control the radio unit, the method includes the step of changing from the first distributed unit to the selected second distributed unit.

Description

Technology Field

[0001] This specification describes a technology for controlling a Distributed Unit (DU) that constitutes a base station in an Open RAN (Radio Access Network), that is, an open radio access network structure. Specifically, it relates to a method and apparatus for controlling a Distributed Unit connected to a Radio Unit (RU) through a Fronthaul interface. Background Technology

[0003] As the times change and more communication devices require larger communication traffic, there is a demand for next-generation 5G systems, which are wireless broadband communication systems that are improved over existing LTE systems. In these next-generation 5G systems, referred to as NewRAT (Radio Access Technology), communication scenarios are classified into Enhanced Mobile BroadBand (eMBB), Ultra-reliability and low-latency communication (URLLC), and Massive Machine-Type Communications (mMTC).

[0004] Here, eMBB is a next-generation mobile communication scenario characterized by High Spectrum Efficiency, High User Experienced Data Rate, and High Peak Data Rate; URLLC is a next-generation mobile communication scenario characterized by Ultra-Reliable, Ultra-Low Latency, and Ultra-High Availability (e.g., V2X, Emergency Service, Remote Control); and mMTC is a next-generation mobile communication scenario characterized by Low Cost, Low Energy, Short Packet, and Massive Connectivity (e.g., IoT).

[0005] In 5G wireless access networks within 5G systems, base stations are separated into Central Units (CU) and Distributed Units (DU). In open wireless access networks, to build various software required for network equipment operation in an open manner, necessary software and hardware are separated, allowing mobile operators to select customized solutions to meet their needs, thereby increasing operational efficiency and reducing costs. The Open-Radio Access Network (O-RAN) Alliance is developing related standard technologies in conjunction with the 3GPP (3rd Generation Partnership Project). The problem to be solved

[0007] The disclosure of this specification aims to provide a method and apparatus for controlling a distributed unit that constitutes a base station in an open wireless access network structure in a 5G system. means of solving the problem

[0009] An embodiment of the present specification provides a method comprising the steps of determining a change in a first distributed unit (DU) connected to a radio unit (RU) through a first fronthaul interface in an open wireless access network, selecting a second distributed unit connected to the radio unit through a second fronthaul interface when the change in the first distributed unit is determined, and changing from the first distributed unit to the selected second distributed unit to control the radio unit.

[0010] The second distribution unit can be selected based on at least one of availability status, load status, and delay status.

[0011] The above availability status can be classified into no-failure, partial-failure, and total-failure states, the above load status can be classified into low-load, normal-load, and high-load states, and the above delay status can be classified into low-delay, normal-delay, and high-delay states.

[0012] The step of monitoring the status of the first distribution unit may be further included.

[0013] The decision to change the first distribution unit may be based on at least one of a fault notification, a load notification, and a delay notification from the first distribution unit.

[0014] After the change of the first distribution unit is determined, the method may further include the step of transmitting a distribution unit change request to at least one of the first distribution unit, the second distribution unit, and the wireless unit.

[0015] The method may further include the step of receiving confirmation of change from at least one of the first distributed unit, the second distributed unit, and the wireless unit in response to a request to change the distributed unit.

[0016] In addition, an embodiment of the present invention provides a device comprising a control unit that determines a change in a first distributed unit (DU) connected to a radio unit (RU) through a first fronthaul interface, and when the change in the first distributed unit is determined, selects a second distributed unit connected to the radio unit through a second fronthaul interface, and changes from the first distributed unit to the selected second distributed unit to control the radio unit. Effects of the invention

[0018] According to the disclosure of this specification, when a failure occurs in a distributed unit constituting a base station in an open wireless access network or when optimization of the entire system is required, changing the distributed unit can increase the stability of the open wireless network and provide the effect of expecting energy savings. Brief explanation of the drawing

[0020] Figure 1 is a diagram illustrating the structure of a wireless communication system. Figure 2 is a diagram illustrating a 5G-based Open-RAN (O-RAN) structure. Figure 3 is a diagram illustrating the structure of a 5G-based Open-RAN (O-RAN) base station. FIG. 4 is a diagram illustrating the connection structure between the front hall management plane (M-Plane) and the management interface (O1) of the distributed unit. FIG. 5 illustrates a control method operating in an open wireless access network according to one embodiment of the present specification. FIG. 6 illustrates a control method operating in an open wireless access network according to another embodiment of the present specification. FIG. 7 illustrates a multiplexed connection between devices and a distributed unit failure recovery scenario in an open wireless access network according to one embodiment of the present specification. FIG. 8 illustrates a status notification procedure of a distributed unit according to one embodiment of the present specification. FIG. 9 illustrates a distribution unit change procedure according to one embodiment of the present specification. FIG. 10 illustrates a front-hall reset procedure for a wireless unit and a distribution unit according to one embodiment of the present specification. FIG. 11 shows a flowchart of a change procedure for a distribution unit according to one embodiment of the present specification. FIG. 12 shows a flowchart of the selection procedure for a distribution unit according to one embodiment of the present specification. FIG. 13 illustrates a failure recovery scenario in which the distributed units in a shared network are different mobile carriers according to one embodiment of the present specification. FIG. 14 shows a state diagram of a dispersion unit according to one embodiment of the present specification. FIG. 15 illustrates a procedure for changing a distributed unit in a common network according to one embodiment of the present specification. FIG. 16 shows open wireless access network devices according to one embodiment of the present specification. Specific details for implementing the invention

[0021] The inventors recognized that various problems may occur during the process of controlling distributed units constituting a base station in an open wireless access network structure in a 5G system, and based on this recognition of problems, they conducted research and development on the distributed unit control method and apparatus described below.

[0022] Although the present specification describes embodiments using a 5G wireless communication system, that is, an NR (New Radio) wireless communication system, these embodiments may be applied to various wireless communication systems. For example, they may be applied to 3GPP (3rd Generation Partnership Project)-based WCDMA (Wideband Code Division Multiple Access) systems, LTE (Long-Term Evolution) systems, and LTE-A (Long-Term Evolution-Advanced) systems and LTE-A Pro systems, which are advanced versions of LTE systems.

[0023] For terms and technologies not specifically described in this specification, reference may be made to wireless communication standard documents published prior to this specification. Examples of wireless communication standard documents include standard documents published by 3GPP and standard documents published by the Open-Radio Access Network Alliance.

[0024] The technical features described in one drawing of this specification may be implemented individually in separate steps or devices, or simultaneously.

[0025] The various descriptions, structures, procedures, methods, and diagrams disclosed in this specification can be applied to various fields requiring communication and connection between devices.

[0026] A slash ( / ) or a comma used in this specification may mean "and / or". For example, "A / B" may mean "A and / or B".

[0027] Furthermore, the methods provided in this specification may be applied independently or combined and operated in any form. Additionally, for new terms used in this specification, arbitrary names that facilitate understanding of their meaning have been used, and this specification may be applied even if other terms having the same meaning are actually used.

[0028] Hereinafter, the present specification will be described in more detail with reference to the drawings.

[0029] Figure 1 is a diagram illustrating the structure of a wireless communication system.

[0030] Referring to FIG. 1, the wireless communication system of the present specification includes a radio access network (RAN; 100), a 5G core (5GC) network (120), and various wireless devices (110a to 110c). The radio access network (100) is responsible for multiple access and efficient distribution of wireless resources through wireless interfaces with the wireless devices (110a to 110c), and the 5GC network (120) can perform roles such as data transmission, traffic routing, and user access and connection control. The wireless devices (110a to 110c) represent devices that perform communication using, for example, 5G NR radio access technology, and may include portable devices (110a and 110b) such as smartphones and smartwatches, and vehicles (110c).

[0031] A 5G base station (gNB) may be configured as an example of a wireless access network (100), and the 5G base station may be described as including a Central Unit (CU; 103), a Distributed Unit (DU; 102), and a Radio Unit (RU; 101). Depending on the efficiency of network construction and service requirements, the base station may be configured in various forms, such as having each function separated into the CU (103), DU (102), and RU (101), or having some or all of the functions integrated.

[0032] Additionally, the term Fronthaul interface is used to refer to the interface connecting the RU (101) and the DU (102), and can be understood as distinct from the Midhaul interface connecting the DU (102) and the CU (103), and the Backhaul interface connecting the CU (103) and the 5GC network (120).

[0033] Figure 2 is a diagram illustrating a 5G-based Open-RAN (O-RAN) structure.

[0034] Referring to FIG. 2, a 5G open radio access network, i.e., an Open-RAN (O-RAN), may be configured to include an O-RU (Open-Radio Unit; 201), an O-DU (Open-Distributed Unit; 202), an O-CU (Open-Central Unit; 203), a Near-Real Time Radio Intelligent Controller (Near-RT RIC; 204), a Service Management and Orchestration (SMO; 231), a Non-Real Time Radio Intelligent Controller (Non-Real Time RIC; 232), and an O-Cloud (240) device, and the connections between each device are defined by interfaces defined in the standard. For example, F1, Xn, and NG interfaces are defined by the 3GPP standard specifications, and FH(M), FH(CUSM), O1, O2, A1, and E2 interfaces are defined by the O-RAN standard specifications.

[0035] FIG. 3 is a diagram illustrating the functional separation structure of a 5G-based Open-RAN (O-RAN) base station, and FIG. 4 is a diagram illustrating the connection structure between the fronthole M-Plane and the O-DU (Open-Distributed Unit) management interface (O1).

[0036] Referring to Figure 3, the 3GPP-based protocol stack can be divided into Layer 1 (i.e., Physical, PHY layer), Layer 2, and Layer 3 (i.e., Radio Resource Control, RRC layer). Layer 2 is divided into MAC (Medium Access Control), RLC (Radio Link Control), PDCP (Packet Data Convergence Protocol), and SDAP (Service Data Adaptation Protocol) sublayers. The protocol stack can be divided into a user plane and a control plane, and for example, the PDCP sublayer can be divided into PDCP-C (PDCP-Control Plane) and PDCP-U (PDCP-User Plane) of the control plane.

[0037] Referring again to FIG. 3, the functions of the physical layer (PHY) of the 5G Open RAN base station are divided and separated into O-RU (301) and O-DU (302), employing a Lower Layer Split (LLS) structure. Here, O-DU (302) and O-CU (303) can also be represented as 'E2 Nodes'. The C (Control) / U (User) / S (Synchronization)-Planes of the O-RAN fronthall interface are responsible for the control plane, user plane, and synchronization plane, respectively, while the NETCONF / YANG-based M (Management)-Plane is responsible for the management plane, handling initialization, configuration, and management to support the separation of these functions.

[0038] Meanwhile, the M-Plane structure can be implemented as a hierarchical or hybrid structure depending on the method of interoperability between the O-RU (301), O-DU (302), and SMO (330) devices.

[0039] FIG. 4 is a diagram illustrating the connection structure between the front hall management plane (M-Plane) and the management interface (O1) of the distributed unit.

[0040] More specifically, FIG. 4(a) is an example showing a hierarchical structure, and FIG. 4(b) is an example showing a hybrid structure. In the hybrid (430) structure, unlike the hierarchical (400) structure, the SMO can be directly connected to the O-RU. In other words, in the hybrid (430) structure, the SMO can be directly connected to the O-RU without needing to go through the O-DU. Here, the O-RU acts as a NETCONF server, and the O-DU and SMO act as NETCONF clients. For reference, the NETCONF client can also be described as an O-RU controller, which is a relative concept to the O-RU.

[0041] In addition, the connection between the OAM of SMO and the ME (Managed Element) of O-DU is performed through the NETCONF / YANG-based O1 interface (O1 I / F).

[0042] FIG. 5 illustrates a control method operating in an open wireless access network according to one embodiment of the present specification.

[0043] Referring to FIG. 5, a change in a first distributed unit (DU) connected to a radio unit (RU) through a first fronthaul interface can be determined (S510). For example, in an SMO of an open radio access network, a change in the first distributed unit can be determined based on at least one of the fault status, load status, and delay status of the first distributed unit. Here, the fault status, load status, and delay status of the first distributed unit may be based on a notification received from the first distributed unit.

[0044] When a change to the first distribution unit is determined, a second distribution unit connected to the wireless unit through the second front-haul interface can be selected (S520). Here, the second distribution unit may be selected based on at least one of the availability state, load state, and delay state of the second distribution unit. i) the availability state, which is the basis for the selection of the second distribution unit, may be classified into a no-failure state, a partial failure state, and a total failure state; ii) the load state may be classified into a low-load state, a normal-load state, and a high-load state; and iii) the delay state may be classified into a low-delay state, a normal-delay state, and a high-delay state.

[0045] In addition, a change can be made from a first distributed unit to a selected second distributed unit (DU) to control a wireless unit. For example, to control a wireless unit in an SMO of an open wireless access network, a change can be made from a first distributed unit connected to the wireless unit via a first fronthall interface to a second distributed unit connected to the wireless unit via a second fronthall interface.

[0046] In open wireless access networks, when a failure occurs in a distributed unit constituting a base station or when optimization of the entire system is required, technologies such as Artificial Intelligence (AI) and Machine Learning (ML) can be utilized to determine more quickly and accurately whether a failure has occurred or to identify the method and timing for overall system optimization.

[0047] FIG. 6 illustrates a control method operating in an open wireless access network according to another embodiment of the present specification.

[0048] Referring to FIG. 6, the status of the first distributed unit is monitored (S600). For example, the status of the first distributed unit connected to the wireless unit through the first fronthall interface in the SMO of an open wireless access network is monitored. Here, the status of the first distributed unit to be monitored may include at least one of a fault state, a load state, and a delay state.

[0049] After monitoring the status of the first distributed unit, a change to the first distributed unit (Distributed Unit, DU) connected through the wireless unit and the first fronthall interface can be determined (S610). For example, in an SMO of an open wireless access network, a change to the first distributed unit can be determined based on at least one of the failure status, load status, and latency status of the first distributed unit. Here, the failure status, load status, and latency status of the first distributed unit may be based on notifications received from the first distributed unit.

[0050] When a change to the first distribution unit is determined, a second distribution unit connected to the wireless unit through the second front-haul interface can be selected (S620). Here, the second distribution unit may be selected based on at least one of the availability state, load state, and delay state of the second distribution unit. i) the availability state, which is the basis for the selection of the second distribution unit, may be classified into a no-failure state, a partial failure state, and a total failure state; ii) the load state may be classified into a low-load state, a normal-load state, and a high-load state; and iii) the delay state may be classified into a low-delay state, a normal-delay state, and a high-delay state.

[0051] When the second distributed unit is selected, a change can be performed from the first distributed unit to the selected second distributed unit to control the wireless unit. For example, in order to control the wireless unit in an SMO of an open wireless access network, a change can be performed from a first distributed unit connected to the wireless unit via a first fronthall interface to a second distributed unit connected to the wireless unit via a second fronthall interface. To change from the first distributed unit to the second distributed unit, a distributed unit change request can be transmitted (S630). For example, in an SMO of an open wireless access network, a distributed unit change request can be transmitted to at least one of the first distributed unit, the second distributed unit, and the wireless unit.

[0052] After transmitting a distributed unit change request, a change acknowledgment may be received in response thereto (S640). For example, in an SMO of an open wireless access network, to change from a first distributed unit to a second distributed unit, a distributed unit change request may be transmitted to at least one of the first distributed unit, the second distributed unit, and the wireless unit, and a change acknowledgment may be received in response thereto.

[0053] When a change to the first distribution unit is determined, a second distribution unit connected to the wireless unit through the second fronthole interface can be selected (S520). Here, the second distribution unit can be selected based on at least one of an availability state, a load state, and a delay state.

[0054] i) availability conditions based on the selection of the second distributed unit can be classified into no-failure, partial-failure, and total-failure conditions, ii) load conditions can be classified into low-load, normal-load, and high-load conditions, and iii) latency conditions can be classified into low-latency, normal-latency, and high-latency conditions.

[0055] FIG. 7 illustrates a multiplexed connection between devices and a distributed unit failure recovery scenario in an open wireless access network according to one embodiment of the present specification.

[0056] Referring to FIG. 7, a single O-RU (701) may be physically connected to two or more O-DUs (702) either directly or via a switch. Specifically, the O-RU (701) may be connected to two or more O-DUs (702) through fronthall interfaces. Here, the fronthall interface may be an M-Plane interface. Additionally, an SMO (703) including OAM functions is connected to the O-DUs (702). Specifically, the SMO (703) may be connected to two or more O-DUs (702) through O1 interfaces. Although FIG. 7 shows only one SMO (703) connected to the O-DUs (702), a situation in which multiple SMOs are connected to multiple O-DUs (702) may also be included within the scope of this embodiment.

[0057] A single O-RU (701) can be managed by one or more O-DUs (702), and in the case of a hybrid structure (or model) that allows direct connection between SMO (703) and O-RU (701), it is also possible to directly interact with the O-RU (701), unlike a hierarchical structure (or model).

[0058] Referring again to FIG. 7, FIG. 7(a) shows a state in which an SMO (703) and a plurality of O-DUs (702) are connected, and the plurality of O-DUs (702) are connected to an O-RU (701). Here, control of the O-RU (701) may be performed through the plurality of O-DUs (702), or through one or more of the plurality of O-DUs (702). FIG. 7(b) shows a situation in FIG. 7(a) where a failure occurs in O-DU #1 while the plurality of O-DUs (702) are connected to a single O-RU (701) and are in service. The SMO (703) monitors the O-DUs (702) connected to the O-RU (701) and detects that a failure has occurred in O-DU #1. Afterward, SMO (703) selects (or determines) the best O-DU #2 among the O-DUs (702) connected to O-RU (701). Once SMO (703) selects (or determines) O-DU #2, it can perform an 0-DU change procedure. As part of the 0-DU change procedure, SMO (703) can send an 0-DU change request to at least one of O-RU (701), O-DU #1, and O-DU #2, and O-RU (701) can change the connection settings to O-DU #2 to continue providing service.

[0059] Meanwhile, situations requiring changes to O-DU #1 can be divided into details as described below.

[0060] (1) This may occur when some hardware (H / W) and / or software (S / W) functions within O-DU #1 fail. If some H / W modules (e.g., cooling fans, processors and / or storage devices, etc.) and / or some S / W functions (e.g., Virtual Machines (VMs), Pods / Containers and / or PNFs / VNFs / CNFs, etc.) within O-DU #1 fail, the system performance of O-DU #1 may deteriorate, potentially leading to future problems, so the connection may be changed to another normal O-DU. Here, PNF (Physical Network Function), VNF (Virtualized Network Function), and CNF (Cloud-native Network Function) refer to physical network equipment, VM-based virtualized network equipment, and container-based network equipment, respectively.

[0061] (2) This may occur when a failure occurs in the entire Hardware (H / W) and / or entire Software (S / W) functions within O-DU #1. If a system crash occurs due to a failure in the entire Hardware (H / W) and / or entire Software (S / W) functions within O-DU #1, the connection may be immediately switched to another normal O-DU. In this case, the failure notification may not be transmitted to other devices.

[0062] (3) O-DU #1 may be operating normally, but the system load and / or latency may exceed a threshold. This may be for system stabilization. The processing load and latency of the O-DU #1 system are important indicators for judging processing performance. Therefore, if O-DU #1 is operating normally but the processing load exceeds a threshold (e.g., exceeding 70%) or the system latency exceeds a threshold (e.g., exceeding 10 msec), SMO (701) may change the connection to another O-DU with a load margin to distribute the entire OpenRAN load as a type of O-DU or RAN Orchestrator. Here, the load rate may be based on the O-DU's PRB (Physical Resource Block) usage rate, CPU usage rate, or workload share, and the number of active connections and users may also be used additionally or as a supplement. The present invention can be applied not only to dedicated hardware-based O-DU equipment but also to general-purpose hardware-based virtualization (cloud-native) O-DU equipment.

[0063] (4) O-DU #1 may be operating normally, but the system load may be below a threshold. This may be for energy saving purposes. For example, the system load of O-DU #1 may be very low during nighttime hours, so in this case, traffic processing may be transferred to another O-DU or processed together to reduce overall energy consumption. Therefore, if the O-DU is operating normally but the load being processed is below a threshold for a considerable period of time (e.g., 10% or less), SMO (701) may change the connection to another available O-DU to save energy.

[0064] FIG. 8 illustrates a status notification procedure of a distributed unit according to one embodiment of the present specification.

[0065] By utilizing the management functions of the fronthaul M-Plane interface and the O1 interface between the O-DU and OAM, O-DU failures can be monitored, and a switch to another available O-DU may be possible. Basically, a series of procedures based on the hybrid M-Plane structure are described, and the differences in the case of a hierarchical structure are described separately.

[0066] Referring to FIG. 8(a), the SMO (830) periodically monitors the system and fault status of the O-DU (800). For example, if a fault occurs in the O-DU, the O-DU (800) sends an O-DU Fault Notification message to the SMO (830) (S810). The O-DU Fault Notification message may include information such as the O-DU identifier, cause, the module or VM / Pod / Container where the fault occurred, the H / W or S / W identifier, the PNF, VNF or CNF identifier, the severity, and / or the reporting period. If the O-DU suddenly goes down and fails to notify of the fault, the SMO may detect the fault status of the O-DU through a periodic verification procedure.

[0067] Additionally, referring to FIG. 8(b), as another example in which the SMO (830) periodically monitors the system and status of the O-DU (800), if the load rate or latency of the O-DU exceeds a preset threshold, the O-DU (800) sends an O-DU Load / Latency Notification message to the SMO (830) (S820). Here, the O-DU Load Notification message and the O-DU Latency Notification message may be messages defined separately, or they may be a single message. The O-DU Load / Latency Notification message may include information such as the O-DU identifier, load rate, latency, severity, and calculation cycle.

[0068] The procedure of FIGS. 8(a) and FIGS. 8(b) is performed through the O1 interface (O1 I / F) for OAM between O-DU (800) and SMO (830).

[0069] FIG. 9 illustrates a distribution unit change procedure according to one embodiment of the present specification.

[0070] Referring to FIG. 9, the SMO (930) determines whether a change to another O-DU is necessary based on notifications and / or status information received from the O-DU (920-a) through the O1 interface (O1 I / F) (S900). Here, the SMO (930) is described as a single device that includes both a Non-RT RIC device and an OAM device. If the Non-RT RIC device is distinct from the OAM device, the Non-RT RIC device may perform the function of determining the change, and the Non-RT RIC and OAM may interact to share necessary information. For example, data / information request and lookup procedures, RAN policy / control decision request and transmission procedures, etc., fall under this category. If a change to the O-DU (920-a) is required, the SMO (930) selects the O-DU to be changed from within the O-DU group (920) and transmits an O-DU Change Request message to the current O-DU (920-a) and the O-DU to be changed (920-b), respectively, indicating that a change is required (S910, S930). Here, the O-DU group (920) is defined as a set of O-DUs connected to a specific O-RU. The O-DU Change Request message includes and transmits at least one of the following: O-DU Group ID, selected O-DU ID, reason for change, urgency of change, cell configuration information, linked O-CU information, and linked SMO information. Meanwhile, the SMO (930) collects information such as the availability, failure information, load rate, and system latency of the O-DUs within the O-DU group (920) and makes a decision on the change based on this information. That is, the most available O-DU within the O-DU group (920) is selected as the top priority to request a change.

[0071] The current / existing O-DU (920-a) and the new / changed O-DU (920-b) that have received an O-DU Change Request message from the SMO (930) may reply to the SMO (930) with an O-DU Change Acknowledgement message (S920, S940). The O-DU Change Acknowledgement message is transmitted including at least one of whether the change was successful or failed and the corresponding reason in case of failure. If the O-DU change fails, the SMO (930) may inform the existing O-DU (920-a) that there are no available O-DUs. The above-described series of procedures is performed through the O1 interface for OAM.

[0072] In addition, the procedure for changing traffic bearers between O-DUs can be processed using 3GPP’s F1 and Xn interfaces and protocols.

[0073] FIG. 10 illustrates a front-hall reset procedure for a wireless unit and a distribution unit according to one embodiment of the present specification.

[0074] The following describes the procedure following the completion of the O-DU change procedure. Referring to FIG. 10, the newly connected O-DU (1020) performs cell configuration (S1000). Subsequently, Configuration Management (S1010) and O-RU to O-DU Interface Management (S1020) are performed through the fronthall M-Plane interface. Here, configuration information for changing the fronthall connection is transmitted to the O-RU (1010) through the O-RU to O-DU Interface Management procedure, and the O-RU (1010) completes the configuration change and connection based on the received configuration information. Here, a service availability procedure is performed between the O-RU (1010) and the O-DU (1020) (S1030), and an O-RU Restart procedure is performed between the O-RU (1010) and the SMO (1030) (S1040). The O-RU Restart procedure includes the transmission of a Restart request from the SMO (1030) to the O-RU (1010). Although the previously described O-RU Restart procedure was explained using a hybrid structure as an example, in the case of a hierarchical structure, the SMO (1030) transmits the O-RU Restart request through the modified O-DU (1020). An O-DU Restart procedure may be performed between the SMO (1030) and the O-DU (1020) (S1050). The O-RU Restart procedure and the O-DU Restart procedure may be performed independently of each other, or the O-DU Restart procedure may be performed after the O-RU Restart procedure is completed.

[0075] As another method of the fronthaul reset procedure for the O-RU (1010) and O-DU (1020), the SMO (1030) may attempt to recover from a failure by restarting the existing O-DU or replace it by powering it off, using some or all of the fronthaul reset procedures described above.

[0076] FIG. 11 shows a flowchart of a change procedure for a distribution unit according to one embodiment of the present specification.

[0077] Referring to FIG. 11, the status of the O-DU is monitored (S1100). For example, the status of the O-DU connected to the O-RU in the SMO is monitored. Here, the status of the O-DU to be monitored may include at least one of a fault state, a load state, and a delay state.

[0078] By monitoring the status of the O-DU, it is determined whether a change is necessary for the O-DU connected to the O-RU (S1110). The SMO may determine a change to the O-DU based on at least one of the O-DU's fault status, load status, and latency status. Here, the O-DU's fault status, load status, and latency status may be based on notifications received from the O-DU.

[0079] When a change to the O-DU is determined, a new O-DU connected to the O-RU is selected or chosen as an O-DU change procedure, and the SMO transmits an O-DU change request message to the selected or chosen O-DU and receives an O-DU change request confirmation message in response (S1120). Additionally, it includes procedures performed according to the distributed unit change procedure described in FIG. 9.

[0080] A determination is made as to whether the previously performed O-DU change procedure was successful, that is, whether the O-DU change was successful (S1130); if the O-DU change failed, a termination procedure is performed (S1150); and if the O-DU change was successful, an O-DU and O-RU setting change procedure is performed (S1140). Additionally, the procedure includes procedures performed according to the front-haul reset procedure of the wireless unit and the distributed unit described in FIG. 10.

[0081] When the procedure for changing the new O-DU and O-RU settings is completed, the O-DU change recovery is finally completed (S1160).

[0082] FIG. 12 shows a flowchart of the selection procedure for a distribution unit according to one embodiment of the present specification.

[0083] Referring to Fig. 12, for O-DU change, SMO needs to select the best O-DU from the available O-DUs within the target O-DU group. First, to identify the available O-DUs within the O-DU group, system status information necessary for judgment is monitored and collected (S1200).

[0084] First, determine if the reason for changing the O-DU is a system failure (S1210). If the reason for changing the O-DU is determined to be a system failure, select the O-DU with the lowest load rate among the available O-DUs in the O-DU group (S1220).

[0085] Secondly, it is determined whether the reason for changing the O-DU is that performance optimization is required due to high load and / or latency (S1230). If it is determined that performance optimization is required due to high load and / or latency, the O-DU with the lowest load and / or latency among the available O-DUs in the O-DU group is selected (S1240).

[0086] Third, it is determined whether the reason for changing the O-DU is energy saving because the load is too low (S1250). If it is determined that the reason for changing the O-DU is energy saving, an O-DU with a normal load rate is selected from among the available O-DUs in the O-DU group (S1260). If there are two or more candidates for an O-DU with a normal load rate, it is desirable to select the O-DU that is closest to the average load rate of the O-DU group. As an example of distinguishing load rate states, they can be classified into three states: Low, Normal, and High. Specifically, a low load rate state can be defined as less than 20%, a normal state as 20–60%, and a high state as more than 60%, and these values ​​can be managed and changed by the SMO. Here, instead of or together with the load rate, data on the power consumption rate of individual O-DUs (calculated as the current operating power consumption compared to the maximum power consumption) may be measured, collected, and used.

[0087] FIG. 13 illustrates a failure recovery scenario in which the distributed units in a shared network are different mobile carriers according to one embodiment of the present specification.

[0088] Referring to FIG. 13, one O-RU (1301) can be physically connected directly or via a switch to two or more O-DUs (1302). Specifically, the O-RU (1301) can be connected to two or more O-DUs (1302) through fronthall interfaces. The SMO (1303) connected to two or more O-DUs (1302) may be one or multiple.

[0089] When a wireless network is jointly constructed through RAN sharing among multiple Mobile Service Providers (MSPs), wide wireless coverage can be provided in a short period with minimal investment. In a shared network base station with an Open RAN structure, a method can be considered where the base station shares equipment from other companies and the core network uses equipment from a specific mobile carrier by transmitting Multi-PLMN identifiers. That is, an example is when subscriber terminals of the shared network carriers initially connect to the core network of an individual carrier through the corresponding host O-RU and host O-DU. Additionally, the O-RU equipment within the shared network can also be interconnected with the guest carrier's O-DU equipment. Figure 13(a) illustrates a case where a specific mobile carrier's SMO is not interconnected with the other mobile carrier's O-DUs according to the SMO interconnection structure between mobile carriers in the shared network, and Figure 13(b) illustrates a case where a specific mobile carrier's SMO is interconnected with the other carrier's O-DUs. The failure recovery procedure in the case of Fig. 13(b) can be processed similarly to the case of a single carrier described earlier.

[0090] Referring to FIG. 13(a), in order to switch to O-DU #2 of mobile carrier B due to a failure of O-DU #1 of mobile carrier A, SMO #1 of mobile carrier A (host mobile carrier) performs this by interlocking with O-DUs (1302) of another mobile carrier (guest mobile carrier) through O-RU (1301). In this case, the use of a hybrid M-Plane model is required. Here, the terms host and guest are used to distinguish between the mobile carrier providing the shared network and the mobile carrier using the shared network, respectively.

[0091] A set of host O-DUs and guest O-DUs connected to a specific O-RU (1301) within the shared network is defined and managed as a Shared O-DU Group. In addition to the existing O-DU group information, all or part of the mobile carrier identification information, host and guest identification information, and information on whether the O-DU is shared between carriers are included. While the host SMO can directly collect the failure or system status of the host O-DU through the O1 interface, this is not possible between the host SMO and the guest O-DU as there is no O1 interface connection. Therefore, the system and failure status of the guest O-DUs within the Shared O-DU Group collected by the host O-RU is transmitted to the host SMO through the fronthaul M-Plane interface connection between the host SMO and the host O-RU. To this end, individual O-DUs transmit their system and failure status to the host O-RU periodically or on an event basis. Here, the performance of the O-DU system is transmitted to the host SMO using the Performance Management procedure, and the system status of the O-DU is transmitted using the Configuration Management procedure. Meanwhile, fault information collected from the O-DU system is transmitted to the host SMO in the form of an alarm notification using a Fault Management procedure. At this time, detailed information regarding the O-DU fault may also be notified.

[0092] FIG. 14 shows a state diagram of a dispersion unit according to one embodiment of the present specification.

[0093] Referring to FIG. 14, as a diagram for the classification and definition of the states of an O-DU system (or device), FIG. 14(a) shows the availability state of the O-DU, FIG. 14(b) shows the load state of the O-DU, and FIG. 14(c) shows the latency state of the O-DU. The availability state of the O-DU is classified into a normal state (1401), a degraded state (1402), and a faulty state (1403) depending on the degree of failure of the system. The load state of the O-DU is classified into a low load state (1411), a normal load state (1412), and a high load state (1413) depending on the magnitude of the load rate of the system. The latency status of the O-DU is classified into low latency status (1421), normal latency status (1422), and high latency status (1423) depending on the magnitude of the system's latency.

[0094] FIG. 15 illustrates a procedure for changing a distributed unit in a common network according to one embodiment of the present specification.

[0095] Referring to FIG. 15, when the host SMO (1530) determines that a change to the host O-DU (1520a) is necessary (e.g., a failure occurs), it selects an available guest O-DU (1525b) from the shared O-DU group (1520).

[0096] To do this, first, the O-RU (1510) collects the system and fault status of the host O-DU (1520a) within the shared O-DU group (1520) through the O-DU Performance / Fault Collection procedure (S1500). Subsequently, the O-DU Performance / Fault Status Request and Report procedure between the O-RU (1510) and the host SMO (1530) is performed (S1510). According to the O-DU Performance / Fault Status Request and Report procedure, the host SMO (1530) may request the system and fault status of the host O-DU (1520a) from the O-RU (1510), and in response, the O-RU (1510) may report the system and fault status of the host O-DU (1520a) collected through the O-DU Performance / Fault Collection procedure to the host SMO (1530).

[0097] The host SMO (1530) can determine that a change to the host O-DU (1520a) is necessary based on the information reported through the O-DU Performance / Fault Status Request and Report procedure (S1520). Subsequently, the host SMO (1530) can transmit the O-DU change request to the O-RU (1510) (S1530). That is, the host SMO (1530) can transmit the change request from the host O-DU (1520a) to the guest O-DU (1520b) to the O-RU (1510) through the O-DU Change Request message.

[0098] When the O-RU (1510) receives an O-DU change request from the host SMO (1530), it can proceed with the procedure to change the O-DU and fronthall. That is, the O-RU (1510) proceeds with the procedure to change the fronthall connection setting with the host O-DU (1520a) to the fronthall setting with the guest O-DU (1520b). Once the procedure to change the O-DU and fronthall is completed, the O-RU (1510) and the guest O-DU (1520b) perform a service availability procedure (S1550), thereby enabling service and / or data transmission and reception through the fronthall interface between the O-RU (1510) and the changed O-DU, i.e., the guest O-DU (1520b).

[0099] FIG. 16 shows open wireless access network devices according to one embodiment of the present specification.

[0100] Referring to FIG. 16, open wireless access network devices may include a first device (1600), a second device (1610), and a third device (1620). Each of the devices (1600, 1610, 1620) may transmit and receive signals, messages, and / or information through various wireless access technologies or interfaces.

[0101] In FIG. 16, for example, the first device (1600) may correspond to the SMO (230) of FIG. 2, the second device (1610) to the O-DU (202) of FIG. 2, and the third device (1620) to the O-RU (201) of FIG. 2.

[0102] In FIG. 16, as another example, the first device (1600) may be one of the wireless devices (110a to 110c) of FIG. 1. Wireless devices such as portable devices (110a and 110b), such as smartphones and smartwatches, and vehicles (110c) may be collectively referred to as User Equipment (UE). Additionally, the second device (1610) may correspond to the RU (101) of FIG. 1, and the third device (1620) may correspond to the DU (102) of FIG. 1.

[0103] With the features of the present specification described above, the user device may include a processor, a memory operably connected to the processor for storing instructions, and a transceiver that communicates with a radio unit (RU) of an open radio access network, and the radio unit (RU) may have its connection changed from a first distributed unit (DU) of the open radio access network connected through a first fronthaul interface to a second distributed unit connected through a second fronthaul interface, and the transceiver of the user device may communicate with the radio unit whose connection has been changed to the second distributed unit.

[0104] Meanwhile, the second distribution unit is selected based on at least one of the availability state, load state, and delay state, and the transceiver of the user device can communicate with the wireless unit whose connection has been changed to the second distribution unit.

[0105] Additionally, based on at least one of a fault notification, a load notification, and a delay notification from the first distribution unit, the transceiver of the user device can communicate with the wireless unit whose connection has been changed to the second distribution unit.

[0106] Each device (1600, 1610, 1620) may include a transceiver (1603, 1613, 1623), at least one processor (1601, 1611, 1621), and memory (1602, 1612, 1621). The memory (1602, 1612, 1622) of each device (1600, 1610, 1620) may be operably connected to the processor(s) (1601, 1611, 1621) to store various types of information and / or commands. Additionally, memory (1602, 1612, 1622) may store software code that implements instructions for performing descriptions, functions, procedures, proposals, methods, and / or operation flowcharts, etc., disclosed in this specification when executed by processor(s) (1601, 1611, 1621). For example, software code may implement instructions for performing descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification when executed by processor(s) (1601, 1611, 1621). Transceivers (1603, 1613, 1623) of each device (1600, 1610, 1620) may transmit data, information, signals, messages, etc., mentioned in descriptions, functions, procedures, proposals, methods, and / or operation flowcharts, etc., disclosed in this specification to one or more other devices.

[0107] Some or all of the various features of the exemplary method and / or apparatus of the present invention may be related to various technical standards. For example, there are standards related to Open Radio Access Networks (O-RAN), [1] O-RAN ALLIANCE O-RAN.WG1.O-RAN-Architecture-Description-v06.00: “O-RAN Architecture Description”; [2] O-RAN ALLIANCE O-RAN.WG4.CUS-v08.00: “Control, User and Synchronization Plane Specification”; [3] O-RAN ALLIANCE O-RAN.WG4.MP-v08.00: “Management Plane Specification”; [4] O-RAN ALLIANCE O-RAN.WG5.O-DU-O1.0-v03.00: “O1 Interface Specification for O-DU”; and [5] O-RAN ALLIANCE O-RAN.WG10.O1-Interface.0-v06.00: "O-RAN Operation and Management Interface Specification" may also be considered related.

[0108] The above description of this specification is an illustrative explanation of the technical concept of the present invention, and various modifications and variations are possible for those skilled in the art without departing from the essential characteristics of this specification. Accordingly, the embodiments disclosed in this specification are intended to explain the technical concept of the present invention, and the scope of the technical concept of the present invention is not limited by these embodiments.

[0109] Furthermore, the claims described in this specification may be combined in various ways. For example, the technical features of the method claims in this specification may be combined to be implemented as a device, and the technical features of the device claims in this specification may be combined to be implemented as a method. Additionally, the technical features of the method claims and the technical features of the device claims in this specification may be combined to be implemented as a device, and the technical features of the method claims and the technical features of the device claims in this specification may be combined to be implemented as a method.

Claims

Claim 1 A control method in an open wireless access network comprises: a step of determining a change in a first distributed unit (DU) connected to a radio unit (RU) through a first fronthaul interface; a step of selecting a second distributed unit connected to the radio unit through a second fronthaul interface when the change in the first distributed unit is determined; and a step of changing from the first distributed unit to the selected second distributed unit to control the radio unit, wherein the determination of the change in the first distributed unit is based on at least one of a fault notification, a load notification, and a latency notification from the first distributed unit, and the fault notification, load notification, and latency notification include a notification transmitted to a Service Management and Orchestration (SMO) device through a first interface as a result of determining at least one of a system fault state, a system load state, and a system latency state of the first distributed unit by a Managed Element performing a management function of the first distributed unit. Claim 2 A method according to claim 1, wherein the second distribution unit is selected based on at least one of an availability state, a load state, and a delay state. Claim 3 A method according to paragraph 2, wherein the availability state is classified into a fault-free state, a partial fault state, and a total fault state, the load state is classified into a low load state, a normal load state, and a high load state, and the delay state is classified into a low delay state, a normal delay state, and a high delay state. Claim 4 A method according to claim 1, further comprising the step of monitoring the state of the first distribution unit. Claim 5 delete Claim 6 A method according to claim 1, further comprising the step of transmitting a distribution unit change request to at least one of the first distribution unit, the second distribution unit, and the wireless unit after the change of the first distribution unit is determined. Claim 7 A method according to claim 6, further comprising the step of receiving a change confirmation from at least one of the first distributed unit, the second distributed unit, and the wireless unit in response to a request to change the distributed unit. Claim 8 A Service Management and Orchestration (SMO) device in an open wireless access network comprises a control unit that determines a change in a first Distributed Unit (DU) connected to a Radio Unit (RU) through a first Fronthaul interface, and when the change in the first Distributed Unit is determined, selects a second Distributed Unit connected to the Radio Unit through a second Fronthaul interface, and changes from the first Distributed Unit to the selected second Distributed Unit to control the Radio Unit, wherein the determination of the change in the first Distributed Unit is based on at least one of a fault notification, a load notification, and a latency notification from the first Distributed Unit, and the fault notification, load notification, and latency notification include a notification transmitted to the SMO device through a first interface as a result of determining at least one of a system fault state, a system load state, and a system latency state of the first Distributed Unit by a Managed Element performing a management function of the first Distributed Unit. Claim 9 A device according to claim 8, wherein the second distribution unit is selected based on at least one of an availability state, a load state, and a delay state. Claim 10 A device according to claim 9, characterized in that the availability state is classified into a fault-free state, a partial fault state, and a total fault state, the load state is classified into a low load state, a normal load state, and a high load state, and the delay state is classified into a low delay state, a normal delay state, and a high delay state. Claim 11 In claim 8, the device is characterized in that the control unit monitors the state of the first distribution unit. Claim 12 delete Claim 13 In claim 8, the device further comprises a transmitter that transmits a distribution unit change request to at least one of the first distribution unit, the second distribution unit, and the wireless unit after the change of the first distribution unit is determined. Claim 14 In paragraph 13, the device further comprises a receiver that receives a change confirmation from at least one of the first distributed unit, the second distributed unit, and the wireless unit in response to a request to change the distributed unit. Claim 15 delete Claim 16 delete Claim 17 delete

Images