Network performing distributed unit scaling and method of operation thereof
The method addresses the challenge of dynamic resource allocation in radio access networks by scaling DUs based on traffic demand, optimizing resource use and reducing operational costs through seamless service migration between DUs and RUs.
Patent Information
- Application Number
- JP2024534630
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2022-03-14
- Filing Date
- 2022-12-09
- Publication Date
- 2025-09-09
- Estimated Expiration
- 2042-12-09
AI Technical Summary
Conventional radio access networks lack a method for dynamically allocating resources to distributed units (DUs) without disconnecting user equipment (UE), leading to inefficient resource utilization and increased operational costs.
A method for scaling DUs by dynamically allocating server resources based on traffic demand, utilizing a scaling controller to migrate services between DUs and RUs, ensuring seamless data flow transfer without disrupting UE communications.
Enables efficient use of server resources, reduces overall server requirements, and minimizes power consumption by allocating only the necessary resources to DUs, while maintaining uninterrupted UE connectivity.
Smart Images

Figure 0007736930000001 
Figure 0007736930000002 
Figure 0007736930000003
Abstract
Description
[Technical Field]
[0001] The present invention relates to a method for scaling distributed units that are independent functions of a radio access network and / or allocation of radio resources. [Background technology]
[0002] Conventional base stations are implemented by integrating a data processing unit (distributed unit, DU) and a radio transceiver unit (radio unit or remote unit, RU) into a cell site. However, such an integrated implementation has physical limitations. For example, when the number of service subscribers or traffic increases, operators need to establish new cell sites within the base station. To address this issue, the centralized RAN (radio access network) or cloud RAN (cloud RAN) architecture has been implemented. In a C-RAN, the DU is located in one physical location, and the RU is located at a cell site that actually transmits and receives radio signals to and from the user equipment (UE). The DU and RU may be connected via optical or coaxial cables. When the RU and DU are separated, an interface standard for communication between them is required, and standards such as the Common Public Radio Interface (CPRI) are used between the RU and DU. The 3GPP (registered trademark) is standardizing base station architectures and is currently discussing the Open Radio Access Network (O-RAN), an open network standard that can be applied to 5G systems.
[0003] In O-RAN, the RU, DU, CU-CP (central unit-control plane), and CU-UP (central unit-user plane), which may be conventional 3GPP NEs, may be O-RU, O-DU, O-CU-CP, and O-CU-UP, respectively (these may be collectively referred to as O-RAN base stations), and the RIC (RAN Intelligent Controller) and NRT-RIC (non-real-time RAN Intelligent Controller) have also been proposed.
[0004] In next-generation communication systems, a new radio access network (RAN) structure is being considered, including a centralized unit (CU), distributed units (DUs), and remote units (RUs). The radio protocol stack or functions for communication can be split between the CU, DU, and RU in various ways. This is called function splitting in the standard. Splitting the RAN functions enables various operational modes tailored to each mobile operator's environment. For example, installing only the RU equipment at the cell site and distributing the CU and DU to a central office or cloud data center and connecting them via fronthaul can reduce overall operational costs. At least one DU can exist under one CU. The radio protocol stack or functions for communication can be split between the CU and DU in various ways. For example, the PDCP layer / functions can be located in the CU, and the RLC / MAC / PHY functions / layers can be located in the DU. In another option, the PDCP / RLC layer / functions may be located in the CU, and the MAC / PHY layer / functions may be located in the DU. Similarly, there may be other options for dividing functions among the CU, DU, and RU. In a radio access network architecture, user equipment (UE) mobility allows a UE to move from one DU to another within the same CU, or from one DU to another within a different CU. Alternatively, the UE may detect a radio link failure (RLF) on a source DU and then switch to a target DU within the same or a different CU. The traditional H / W-based operation of CUs and DUs is evolving to operate CUs and DUs in software-implemented cloud environments based on virtual machine (VM) or container technologies. Summary of the Invention [Problem to be solved by the invention]
[0005] The introduction of cloud environments has enabled efficient utilization of internal resources in service provision and application development, and has led to the emergence of container-based services that enable high-speed application distribution and management within a few seconds. However, container-based microservices must be able to handle rapidly increasing user traffic. Conventional services often lack the ability to switch services between container platforms or flexibly expand resources. Therefore, scale-out / in methods that enable balanced utilization of resources within containers in cloud environments are attracting attention.
[0006] If server resources equivalent to those required for processing RU data are dynamically allocated to the DU, the overall server resources may be reduced as needed. However, the current NR standard lacks a method for dynamically allocating resources to the DU without disconnecting the UE.
[0007] A DU is assigned server resources with the capacity required for the average data processing of the RU, and when the data volume of the RU increases, traffic is forwarded so that the additional DU is run by another server, and some of the multiple RUs that the DU was responsible for are processed by the newly distributed DU. When server resources are dynamically assigned to DUs, the overall resource usage (CPU, memory, accelerators, etc.) can be reduced. A method is needed to seamlessly transfer the existing (source) DU-RU-UE (terminal) data flow to the new (target) DU-RU-UE.
[0008] Various embodiments describe a method for scaling a DU without disrupting UE communications. [Means for solving the problem]
[0009] According to various embodiments, a radio access network device is provided that includes a distributed unit (DU). The device includes: a first DU configured to communicate with at least one first remote unit (RU); a scaling controller (including control circuitry) configured to control a scaling process according to a resource status of a first server; and a second DU selected by the scaling controller based on resource usage information regarding the first DU. The scaling controller may be configured to select a second RU to migrate to the second DU from among the first RUs currently processing a service of the first DU. The first DU may be configured to transmit information regarding the second RU as a migration target to the second DU. The remaining RUs of the first RUs, excluding the second RU, may be configured to process the service of the first DU. Each DU, RU, CU, UE, and server herein may include circuitry, such as processing circuitry.
[0010] According to various embodiments, a communication method for a radio access network device including a distributed unit (DU) may be provided, the method including: acquiring, by a scaling controller, information regarding resource usage of a first DU executed via a first server; selecting, by the scaling controller, a second DU based on the information regarding resource usage of the first DU; selecting, by the scaling controller, a second RU to be transferred to the second DU from among first remote units (RUs) processing a service of the first DU; and transmitting, by the first DU, information regarding the second RU to the second DU, wherein the remaining RUs among the first RUs, excluding the second RU, may be configured to process the service of the first DU. [Effects of the Invention]
[0011] According to various embodiments, dynamic scaling of software-implemented virtual DUs in the RAN that supports UE terminals to connect and communicate can be enabled, allowing efficient use of server resources required by all DUs.
[0012] According to one embodiment, instead of allocating a dedicated DU to an RU, the server resource pooling effect of the cloud platform is utilized so that only the required amount of server resources is allocated to the DU according to the traffic volume of the RU, thereby reducing the required server resources and, by reducing the number of servers, also reducing power consumption.
[0013] According to various embodiments, the scheduler responsible for radio resource allocation within the DU can seamlessly control the radio bearer from the resource DU allocated to the UE to the target DU. [Brief explanation of the drawings]
[0014] [Figure 1a] FIG. 1 is a block diagram illustrating a RAN and a core network (CN) in accordance with various embodiments. [Figure 1b] FIG. 2 is a block diagram illustrating a hardware configuration of a RAN device according to various embodiments. [Figure 2a] FIG. 1 illustrates a cell site and a central office in a RAN system in accordance with various embodiments. [Figure 2b] FIG. 1 illustrates servers and resource pools in a cloud environment, according to various embodiments. [Figure 3a] FIG. 1 is a block diagram illustrating network components according to various embodiments. [Figure 3b] 1 is a block diagram illustrating a network including multiple DUs, according to various embodiments. [Figure 3c] FIG. 10 is a diagram illustrating the data flow of a DU and the transfer of the data flow. [Figure 4]FIG. 10 illustrates operations by a scaling controller, according to various embodiments. [Figure 5a] FIG. 1 illustrates a scale-out process by a scaling controller in a cloud environment according to resource usage of a DU. [Figure 5b] FIG. 1 illustrates a scale-in process by a scaling controller in a cloud environment according to resource usage of a DU. DETAILED DESCRIPTION OF THE INVENTION
[0015] FIG. 1a is a block diagram illustrating a RAN and a core network (CN) according to various embodiments.
[0016] According to various embodiments, the RAN 150 includes at least one of at least one distributed unit (DU) 151, at least one central unit-control plane (CU-CP) 152, or at least one central unit-user plane (CU-UP) 153. While the RAN 150 is shown connected to at least one remote unit (RU) 161, this is exemplary and at least one RU 161 is configured to be connected to or included in the RAN 150. The RAN 150 may be an O-RAN, in which case the DU 151 may be an O-DU, the CU-CP 152 may be an O-CU-CP, the CU-UP 153 may be an O-CU-UP, and the RU 161 may be an O-RU. Each "unit" herein includes a circuit.
[0017] According to various embodiments, the RU 161 communicates with the user equipment (UE) 160. The RU 161 is a logical node that provides lower physical layer (low-PHY) functions and RF processing. The DU 151 is a logical node that provides RLC, MAC, and higher physical layer (high-PHY) functions, and is connected to the RU 161, for example. The CUs 152 and 153 are logical nodes that provide radio resource control (RRC), service data adaptation protocol (SDAP), and packet data convergence protocol (PDCP) protocol functions. The CU-CP 152 is a logical node that provides the control plane functions of the RRC and PDCP. The CU-UP 153 is a logical node that provides the user plane functions of the SDAP and PDCP.
[0018] According to various embodiments, the core network (e.g., 5GC 5th generation core) 154 includes at least one of an access and mobility management function (AMF) 155, a user plane function (UPF) 156, or a session management function (SMF) 157. The AMF 155 provides functionality for access and mobility management in the unit of the UE 160. The SMF 157 provides session management functionality. The UPF 156 forwards downlink data received from a data network to the UE 160, or forwards uplink data received from the UE 160 to the data network. As an example, the CU-CP 152 is directly or indirectly connected to the AMF 155 via an N2 interface (or an NGAP interface). The AMF 155 is directly or indirectly connected to the SMF 157 via an N11 interface. The CU-UP 153 is directly or indirectly connected to the UPF 156 via an N3 interface.
[0019] FIG. 1b is a block diagram illustrating a hardware configuration of a network device according to various embodiments.
[0020] According to various embodiments, the RAN device includes at least one of a processor 120 including processing circuitry, a memory device 130, or a communication module 190 including processing circuitry.
[0021] According to various embodiments, processor 120 executes software (e.g., a program) to control at least one other component (e.g., a hardware or software component) of RIC 101 (or an electronic device configured to perform the functions of RIC 101) connected to processor 120 and perform various data processing or calculations. Software may include, but is not limited to, xAPP. According to one embodiment, as at least part of the data processing or calculations, processor 120 (including processing circuitry) stores commands or data received from another component in storage device 130, processes the commands or data stored in storage device 130, and saves the resulting data in storage device 130. According to one embodiment, processor 120 includes at least part of a central processing unit, an application processor, a neural network processing unit (NPU), or a communications processor, but the type of processor 120 is not limited. A neural network processing unit includes a hardware structure specialized for processing artificial intelligence models. The artificial intelligence model may include, but is not limited to, machine learning (e.g., reinforcement learning, supervised learning, unsupervised learning, or semi-supervised learning). The artificial intelligence model includes multiple artificial neural network layers. Examples of artificial neural networks include, but are not limited to, deep neural networks (DNNs), convolutional neural networks (CNNs), recurrent neural networks (RNNs), restricted Boltzmann machines (RBMs), deep belief networks (DBNs), bidirectional recurrent deep neural networks (BRDNNs), deep Q-networks, or combinations of two or more thereof. The artificial intelligence model may additionally or alternatively include software structures other than hardware structures.Those skilled in the art will understand that the storage device 130 is not limited to a device capable of storing data, such as a disk (eg, HDD).
[0022] According to various embodiments, storage device 130 stores various data used by processor 120 or communications module 190. Data may include, for example, input or output data for software and its associated commands.
[0023] According to various embodiments, the communication module 190 establishes a direct (e.g., wired) or wireless communication channel between the RAN device and an external electronic device, or supports communication via the established communication channel. The type of communication module 190 is not limited, as long as it supports, for example, an E2 interface. On the other hand, if the RAN 150 is implemented as a single device, the communication module 190, including the processing circuitry, is and / or represents an interface for both entities.
[0024] In communication systems, a new radio access network (RAN) structure including a centralized unit (CU), distributed units (DUs), and remote units (RUs) is being considered. The radio protocol stack or functions for communication can be split between the CU and DU in various ways. This is called function split in the standard. Splitting the RAN functions enables various operations tailored to each mobile operator's environment. In one example, only the RU equipment is installed at the cell site, while the CU and DU are distributed in a central office or cloud data center and connected via fronthaul, thereby reducing overall operational costs. One or more DUs may exist under one CU. The radio protocol stack or functions for communication can be split between the CU and DU in various ways. For example, in one option, the PDCP layer / functions are located in the CU, and the RLC / MAC / PHY functions / layers are located in the DU. In another option, the PDCP / RLC layer / functions may be located in the CU and the MAC / PHY layer / functions may be located in the DU. Similarly, there are other options for splitting functions between the CU and the DU. In a radio access network architecture, user equipment (UE) mobility allows a UE to move from one DU to another within the same CU or from one DU to another within a different CU. Alternatively, the UE can detect a radio link failure (RLF) on a serving DU and then switch to a target DU in the same or a different CU.
[0025] FIG. 2a is a diagram illustrating cell sites and a central office in a RAN system, in accordance with various embodiments.
[0026] In a next-generation communication system, the division of RAN functions enables various operations depending on the environment of each mobile communication operator. For example, only one RU 211 device is installed in a cell site 210, and a CU 222 (or virtual CU) and at least one DU 221 (or virtual DU) are distributed to a central office 220 or a cloud environment (e.g., a cloud data center) and connected via a fronthaul (FH) 223, thereby reducing overall operational costs. At least one DU 221 corresponds to (or is connected to) one CU 222. In contrast to the conventional hardware-based CU and DU operation methods, the CU and / or DU are implemented in software. For example, the CU and / or DU operate in a cloud environment based on virtual machine (VM) or container technology.
[0027] FIG. 2b is a diagram illustrating servers and resource pools in a cloud environment, according to various embodiments.
[0028] Referring to the embodiment shown on the left side of FIG. 2b , at least one DU 231 is configured to be connected to at least one cell site 210. For example, one or more RUs 211 correspond to (or are connected to) one cell site 210. According to the embodiment shown on the left side, as an example, one DU 231 is fixedly associated with (or connected to) one cell site 210. In this case, a dedicated DU is configured for the cell site 210 (or an entity constituting the cell site 210 (e.g., one or more RUs 211)), and the DU 231 may be referred to as a dedicated DU, as an example. Configuring a dedicated DU for one cell site 210 may also be interpreted as configuring a dedicated DU for one or more RUs 211 constituting the cell site 210. To execute each dedicated DU, the network device needs to allocate (or execute) a server (such as a VM or a container) for each dedicated DU, and the execution of the server requires allocating resources of at least a specified size. The resources equal to or larger than the specified size may be preset or variable. Meanwhile, referring to the left side of FIG. 2b, a bar-shaped indicator 231a is displayed on each of at least one DU 320a and 320b. Each indicator 231a indicates the ratio of the resources currently used by the at least one DU 231 to the maximum resources available to the at least one DU 231. The maximum available resources are, for example, the maximum available resources allocated to a server (e.g., a VM or a container) for running the dedicated DU. Similar to the embodiment shown on the left side of FIG. 2b, when a dedicated DU corresponds to (or connects to) a cell site, the entire resources available to one DU (e.g., DU 231) may not be used, resulting in idle resources and wasted resources in the network device. As an example, the available resources are determined under the assumption that a maximum number of UEs are connected to one or more RUs 211. Therefore, idle resources may occur if fewer than the maximum number of UEs are connected to the RU 211.However, one or more RUs 211 are assigned fixed resources and cannot use idle resources.
[0029] Referring to the embodiment on the right side of FIG. 2b, instead of allocating a dedicated DU 231 to an RU 211, a server pool 232 is deployed in a cloud environment and a resource pooling function is used. In contrast to the embodiment on the left side of FIG. 2b, instead of allocating a dedicated DU to one cell site, one server (e.g., server 232b) performs functions corresponding to RUs included in multiple cell sites. For example, server 232b performs functions corresponding to RUs included in one cell site while also performing functions corresponding to RUs included in other cell sites. The network device determines the server that will perform the corresponding function on a RU-by-RU (or UE-by-UE basis). Thus, as shown on the right side of FIG. 2b, one server (e.g., server 232a) allocates resources 233a for performing functions corresponding to RUs included in a first cell site 210a and resources 233b for performing functions corresponding to RUs included in a second cell site 210b. Thus, server 232a allocates any idle resources remaining after allocating resources 233a to serve first cell site 210a to resources 233b to serve at least one RU included in second cell site 210b, thereby minimizing or reducing idle resources. Server 232c with no allocated resources is unused.
[0030] Referring to FIG. 2b, the remaining portion 232b of at least one server and the server 232c shown by the dashed line represent surplus servers that are not allocated to perform the functions of the DU, i.e., unallocated server resources, and the network device does not operate the surplus servers or allocate resources to them, thereby preventing or reducing resource waste.
[0031] 2b, one or more RUs 211 constituting one cell site 210 are assigned to each dedicated DU 231, but when a server pool 232 is used, resources of any server in the server pool 232 are allocated according to resource pooling only to the amount of traffic required by the RU 211. Therefore, in the central office 220, the number of servers operated to execute the functions of the DU 221 is reduced through the server pool 232.
[0032] 3a is a block diagram including network components according to various embodiments. Each embodiment herein can be used in combination with any other embodiment described herein.
[0033] According to various embodiments, the radio protocol stack or functions for communication can be divided between the CU 310 and the DU 320 in various ways. As an example, the packet data convergence protocol (PDCP) 314 / RRC 312 / SDAP 313 layers / functions are located in the CU 310, and the RLC 325 / MAC 327 / PHY 239 functions / layers are located in the DU 320. In another option, the PDCP 314 / RRC 312 / SDAP 313 layers / functions are located in the CU 310, and the RLC 325 / MAC 327 layers / functions are located in the DU 320. Similarly, other options exist for dividing functions between the CU 310 and the DU 320. In a radio access network architecture, due to user equipment (UE) mobility, a UE 340 may move between RUs 330a, 330b, and 330c within the same DU 320, or may move directly or indirectly to an RU connected to a DU other than one DU 320. Alternatively, the UE 340 may detect a radio link failure (RLF) on the same DU 320 and then switch to a DU other than the DU 320 in the same CU 310 or a different CU.
[0034] According to various embodiments, the three-tier structure of the RAN, CU310, DU320, and RU330, constitutes a 5G base station (gNB) for flexibly building a 5G RAN for various 5G applications (eMBB, URLLC, mMTC, etc.).
[0035] 3a, the base station separates RRC, SDAP, and PDCP into a three-layer structure, with RRC, SDAP, and PDCP as CU, RLC, and MAC, an upper PHY as DU, and a lower PHY as RU. Specifically, a midhaul channel may be located between the CU 310 and the DU 320, and a fronthaul channel may be located between the DU 320 and the RU 330. The separation points of functions are not limited to those shown in the figure.
[0036] FIG. 3b is a block diagram illustrating a network including multiple DUs, according to various embodiments.
[0037] According to various embodiments, the network device includes a CU 310, at least one DU (e.g., a source DU 320a and a target DU 320b in FIG. 3b), a scaling controller 312, an F1 splitter 311 that decouples the CU 310 and at least one DU 320a, 320b, a scaling controller 312 that controls the scaling process, F1 handlers 321a, 321b included in each of the at least one DU, scale agents 322a, 322b, RLCs 325a, 325b, MACs 327a, 327b, PHY-Hs 329a, 329b, schedulers 324a, 324b, and fronthaul handlers. The system may include and implement a fronthaul splitter 331 that decouples at least one DU 320a, 320b and at least one RU 330a, 330b, 330c, and at least one UE 340 that corresponds to each of the at least one RU 330a, 330b, 330c.
[0038] According to various embodiments, the CU 310 transfers downlink data to the UE 340 and transfers uplink data received from the UE 340 to the network in the data flow of the UE on the U-plane. The description of the CU 310 can be applied mutatis mutandis to the descriptions of FIGS. 1a to 3a.
[0039] According to various embodiments, referring to the 3GPP F1 interface standard, the F1 splitter 311 provides a decoupling function between the CU 310 and the DUs 320a and 320b. The F1 splitter 311 may also be configured to allow the CU 310 to recognize the source DU 320a and the target DU 320b as a single DU. It also controls the data flow path (IP address translation) between the CU 310 and the source DU 320a and the target DU 320b. The F1 splitter 311 may be a standalone component or a component included in the CU 310.
[0040] According to various embodiments, a scaling controller 312 including a control circuit controls the overall scaling. Referring to FIG. 3b, the scaling controller 312 communicates with the source DU 320a, the target DU 320b, the F1 splitter 311, and the fronthaul splitter 331. According to various embodiments, the scaling controller 312 receives a report on resource usage from the source DU 320a to determine whether scaling out is necessary for the source DU 320a. If the scaling controller 312 determines that scaling out is necessary, it requests a cloud platform, such as Kubernetes, to create a new target DU 320b. The scaling controller 312 sends information about the target DU 320b to the F1 splitter 311 and the fronthaul splitter 331 so that the target DU 320b is registered with the F1 splitter 311 and the fronthaul splitter 331. Alternatively, the scaling controller 312 sends information about the target DU 320b to the F1 splitter 311 and the fronthaul splitter 331 to instruct the scale agent 322a or 322b to register the target DU 320b with the F1 splitter 311 and the fronthaul splitter 331. In this specification, each RU, each CU, each UE, and each DU includes a processing circuit.
[0041] According to various embodiments, the descriptions in Figures 1a to 3a apply to the DU 320a or 320b. Referring to Figure 3b, the source DU 320a includes an F1 handler 321a, a scale agent 322a, a fronthaul handler 323a, a scheduler 324a, an RLC 325a, a MAC 327a, and a PHY-H 329a. According to various embodiments, the source DU 320a reports resource usage to the scaling controller 312 via the scale agent 322a periodically or according to certain conditions. According to one embodiment, the target DU 320b, to which traffic processing is migrated from the source DU 320a, includes an F1 handler 321b, a scale agent 322b, a fronthaul handler 323b, a scheduler 324b, an RLC 325b, a MAC 327b, and a PHY-H 329b. The scale agent 322b of the target DU 320b receives information for context synchronization from the scale agent 322a of the source DU 320a.
[0042] According to various embodiments, the F1 handlers 321a, 321b are configured to communicate with the CU 310 in the DUs 320a, 320b and comply with the 3GPP F1 interface standard.
[0043] According to various embodiments, the fronthaul handlers 323a, 323b are the parts in the DU 320 that communicate with the RU 330, and may be compliant with the ORAN fronthaul standard (7.2x) or the Small Cell Forum's nFAPI.
[0044] According to various embodiments, in accordance with the ORAN fronthaul standard, the fronthaul (FH) splitter 331 provides a decoupling function between the DUs 320a, 320b and the RUs 330a, 330b, 330c. The RUs 330a, 330b, 330c may be configured to recognize the source DU 320a and the target DU 320b as a single DU. The data flow path (MAC Address Translation) between the RUs 330a, 330b, 330c and the source DU 320a and the target DU 320b is controlled. According to various embodiments, the fronthaul splitter 331 may be standalone or included in the RU 330.
[0045] According to various embodiments, the RU 330 communicates with the UE 340. The RU 330 is a logical node that provides lower physical layer (PHY-low) functions and RF processing. The RU 330 is configured to be connected to the RAN or included in the RAN. The descriptions of Figures 1a to 3a can be applied to the description of the RU 330. Figure 3c illustrates the data flow of the DU and the transfer of the data flow.
[0046] According to various embodiments, a user equipment (UE) 340 moves from one DU (e.g., source DU 320a in FIG. 3b) to another DU (e.g., target DU 320b in FIG. 3b) within the same CU 310 due to UE mobility in a radio access network architecture. Alternatively, the UE 340 moves from one DU (e.g., source DU 320a in FIG. 3b) to another DU (e.g., target DU 320b in FIG. 3b) within a different CU. As an example, the UE 340 detects a radio link failure (RLF) on one DU (e.g., source DU 320a in FIG. 3b) and then switches to another DU (e.g., target DU 320b in FIG. 3b) within the same CU 310 or a different CU.
[0047] 3c, those skilled in the art will understand that the target DU 320b may be a DU generated by the scaling controller 312 (301) for scale-out, or the generation process by the target DU 320b may replace an existing generated DU by designating it for scale-out. The scaling controller 312 sends information about the target DU 320b to the F1 splitter 311 including a circuit, and the F1 splitter 311 registers the new DU (302). As an example, at least one event for scale-out is detected in the source DU 320a, and the target DU 320b for scale-out is generated (or designated) in response to the detected event. Here, as an example, the event indicates that the ratio of the size of resources currently in use by the source DU 320a (or the server driving the source DU 320a) to the total resources available to the source DU 320a is equal to or greater than a threshold ratio. However, this is merely an example, and those skilled in the art will understand that the condition is not limited to this, as long as it indicates that the resources used by the source DU 320a are relatively excessive and scale-out is necessary. The scaling controller 312 is configured to send information about the new DU to the fronthaul splitter 331 to register the information about the new DU (303). The current source DU 320a sends the context to the target DU 320b to synchronize the context with the target DU 320b (304).For example, the context may include at least one of system information (including synchronization, system information block, random access, and reference signal), scheduling context (including channel state, power management, HARQ, and DRX), control information (including information on MAC-CE and paging), frequency resources (including information on carrier aggregation, BWP, and SUL), spatial resources (including information on beam management and MINO), UE context (including information on RNTI, SRB, DRB, and RAT), or RU context. Here, the context may be associated with, but not limited to, an RU (or at least one UE connected to the RU) for which migration is requested among at least one RU 330 corresponding to (or connected to) the source DU 320a. The target DU 320b receives the above-mentioned context and thereby identifies information on the RU (or at least one UE connected to the RU) to be migrated. The F1 splitter 311 prepares data to be transmitted or received (305) according to the downlink / uplink resource allocation information for the target DU 320b. The fronthaul splitter 311 is configured to receive or transmit the prepared transmission data to the target DU 320b according to the downlink / uplink resource information allocated to the target DU 320b (306). For operations 301-306 in FIG. 3c above, the operations are repeatedly performed for at least one UE connected via a data radio bearer with the RU (e.g., 330c) serving the target DU 320b, so that the data flow is transferred to the target DU 320b (307).Thus, information about at least one UE connected to the RU 330c to be scaled out to the target DU 320b is provided, and the transmission and / or reception procedures of downlink data and / or uplink data associated with the at least one UE can be managed.
[0048] FIG. 4 is a diagram illustrating operations by a scaling controller according to various embodiments.
[0049] According to various embodiments, in a radio access network device, a scaling controller (312 in FIG. 3b) operates to obtain, from a first DU 320a, information about resource usage of the first DU (source DU, 320a in FIG. 3b) executed via a first server (401). The scaling controller 312 selects, based on the information about resource usage of the first DU 320a obtained by 312 in FIG. 3b, a second DU (target DU, 320b in FIG. 3b) (403). The scaling controller 312 selects, from among the first RUs (e.g., 330a, 330b, 330c in FIG. 3b) processing the service of the first DU 320a, a second RU (e.g., 330b and / or 330c in FIG. 3b) to be migrated to the second DU (e.g., 320b in FIG. 3b) (405). The scaling controller 312 requests the first DU 320a to establish a communication session so that information about the second RU (e.g., 330c in FIG. 3b) is transmitted from the first DU 320a to the second DU 320b (407). The specific operation of the scaling controller will be described below.
[0050] 5a and 5b are diagrams illustrating the scale-out and scale-in process by a scaling controller in a cloud environment according to the resource usage of a DU.
[0051] According to various embodiments, container-based scaling-out or scaling-in is performed when an application or workload running on the cloud runs on a virtual machine (VM) or logical partition that causes memory shortages or performance degradation.
[0052] Referring to FIG. 5a, the source DU 320a reports its resource status to the scaling controller 312 (501). Based on the reported resource status, the scaling controller 312 determines whether to scale out (503). The scaling controller 312 generates a target DU 320b to be scaled out. The scaling controller 312 registers information about the target DU 320b with the F1 splitter and the fronthaul splitter (505). The scaling controller 312 selects a migration target RU (e.g., 330c in FIG. 3b) to be migrated to the target DU 320b from among the RUs (e.g., 330a, 330b, and 330c in FIG. 3b) currently processing the services of the source DU 320a (507). The scaling controller 312 selects a server (e.g., 232b or 232c in FIG. 2b) to be scaled out (509). The scaling controller 312 switches (511) the data flow for the migration target UE 340 connected to the migration target RU (e.g., 330c in FIG. 3b) from the source DU 320a to the target DU 320b. The previous switching operation is repeatedly performed (513) for each UE until all UEs 340 connected to the migration target RU (e.g., 330c in FIG. 3b) have been migrated to the target DU 320b. As used herein, "based on" includes at least based on.
[0053] Referring to FIG. 5b, the target DU 320b reports its resource status to the scaling controller 312 (521). Based on the reported resource status, the scaling controller 312 determines whether to scale in, and selects the target DU 320b to scale in (523). The scaling controller 312 selects a migration target RU (e.g., 330c in FIG. 3b) to be migrated to the source DU 320a from among the RUs (e.g., 330a, 330b, and 330c in FIG. 3b) currently processing the services of the target DU 320b (525). The scaling controller 312 selects a server (e.g., 232b in FIG. 2b) to scale in (527). The scaling controller 312 switches the data flow for the migration target UE 340 connected to the migration target RU (e.g., 330c in FIG. 3b) from the target DU 320b to the source DU 320a (529). The previous switching operation is repeated for each UE (531) until all UEs 340 connected to the transition target RU (eg, 330c in FIG. 3b) have been transitioned to the source DU 320a.
[0054] The specific process is as follows:
[0055] 1) Scale-out process
[0056] a) The scale agent 322 periodically reports resource status such as CPU usage, memory usage, network throughput, power consumption, and accelerator usage (FPGA / GPU / smart NIC, etc.) of the DU320 server including the processing circuit to the scaling controller 312. According to various embodiments, the scale agent 322 does not report periodically, but reports the resource status when a resource usage condition preset by the scaling controller 312 is met.
[0057] b) The scaling controller 312 selects the DU 320 to be scaled out (scaling decision) based on the resource usage information of the DU 320, and selects the RU 330 to be migrated to another server for processing from among the RUs 330a, 330b, and 330c currently processing DU services. According to various embodiments, the selection of the source DU 320a for scaling can be performed using various policies. For example, if the server resources allocated to the source DU 320a are allocated to process 30% of the peak throughput per RU and three RUs, the corresponding DU starts to be scaled out when the overall throughput reaches or exceeds 60% of the peak (30% x 2). Alternatively, the DU optimal for scaling can be selected through artificial intelligence / machine learning techniques. According to various embodiments, the scaling controller 312 generates a new DU, the target DU 320b, to be scaled out, and registers the target DU 320b with the F1 splitter 311. The scaling controller 312 registers the target DU 320b with the fronthaul splitter. According to various embodiments, the selection of the RU 330 is performed according to various policies. As an example, among the RUs 330 processing the service of the source DU 320a in the current server (e.g., 232a in FIG. 2b), an RU with a smaller throughput than the average may be selected to execute the service of the target DU 320b in another server (e.g., 232b in FIG. 2b) and be transferred to be processed by the RU corresponding to the target DU 320b. Alternatively, an RU with the largest throughput may be selected, and the target DU 320b may be executed in a server with the capacity to process the peak rate, and the RU corresponding to the target DU 320b may be processed. Each DU herein includes a processing circuit.
[0058] c) The scaling controller 312 selects a server (e.g., 232b in FIG. 2b) within the target DU 320b that has sufficient processing capacity for the new service (scale-out server selection) and runs the service on that server. According to various embodiments, the selection of a server for running the target DU 320b service is performed according to various policies. For example, a server capable of processing the maximum amount of data for one RU 330 may be selected, or a server capable of average processing may be selected. The selection of a server for scaling out is related to the policy for selecting the target RU 330 for scale-out. If the scale-out target RU 330, for example, the RU whose processing is migrated to the target DU 320b service, must process a peak rate, the service of the target DU 320b is run on a server with the resource capacity to handle the corresponding traffic. Running the target DU 320b service on a server with the required resources is performed via a cloud platform such as Kubernetes. The scaling controller 312 provides the resource information required for the cloud platform to select a server for running the service of the DU.
[0059] d) The scaling controller 312 registers the service of the target DU 320b with the F1 splitter 311. For example, the F1 splitter 311 uses the registered information to prepare to forward (switch) data transmitted to the source DU 320a to the target DU 320b. If necessary, the F1 splitter 311 creates a new SCTP (stream control transmission protocol) communication session with the target DU 320b. (Transport network layer connection)
[0060] e) The scaling controller 312 causes the service of the target DU 320b to be registered with the FH splitter 331 (including the transport network layer connection).
[0061] For example, the FH splitter 331 uses the registered information to prepare to switch data transmitted to the source DU 320a to the target DU 320b.
[0062] f) The scaling controller 312 directs the creation of a communication session between the scale agents 322 of the source DU 320a and the target DU 320b to synchronize the context.
[0063] g) The scale agent 322a of the source DU 320a starts transmitting the context of the RU 330 that is the migration target to the scale agent 322b of the target DU 320b, and keeps updating the context change. The transmitted context may be information about the UE context, channel state, radio resource scheduling information, and system information.
[0064] h) The scale agent 322a may select UEs to be processed by the target DU 320b from among UEs directly or indirectly connected to the RU 330 to be migrated. According to various embodiments, the selection of UEs is performed according to various policies. For example, the selection may be performed by starting with UEs in an inactive state and selecting UEs in a connected state from UEs with the least amount of data transmission to UEs with the most amount of data transmission. The reverse order is also possible. Alternatively, the DRB QoS values of each UE may be compared and the UEs may be selected in descending order of priority.
[0065] i) The scale agent 322a of the source DU 320a sends information about the UEs to be migrated to the scale agent 322b of the target DU 320b. For example, the information about the UEs to be sent includes a signaling radio bearer (SRB) list, a data radio bearer (DRB) list, etc.
[0066] j) The scale agent 322a of the source DU 320a requests the F1 splitter 311 to send data intended for the migration target UE to the target DU 320b. According to various embodiments, the F1 splitter 312 sends all data destined for the migration target UE to the target DU 320b (switching the data path from the source DU 320a to the target DU 320b).
[0067] k) The scale agent 322a of the source DU 320a requests the scheduler of the source DU 320a to stop uplink / downlink resource allocation for the transition target UE.
[0068] l) The scale agent 322a of the source DU 320a sends the currently remaining uplink / downlink data to the scale agent 322b of the target DU 320b.
[0069] m) The target DU 320b resets its buffer with the data received from the source DU 320a and the F1 splitter 311, and prepares to send and receive data to and from the UE.
[0070] n) The scaling agent 322b of the target DU 320b notifies the scaling agent 322a of the source DU 320a that it is ready to send and receive data to and from the UE.
[0071] o) The scale agent 322a of the source DU 320a requests the scheduler to resume uplink / downlink resource allocation for the migration target UE.
[0072] p) The scaling agent 322a of the source DU 320a requests the scheduler to forward uplink / downlink resource allocation information for the migration target UE to the scaling agent 322b of the target DU 320b. According to various embodiments, the scheduling information is continuously forwarded until the migration of the RU 330 is completed.
[0073] q) The scale agent 322a of the source DU 320a sends the source DU address and / or target DU address information to the FH splitter 331.
[0074] r) The target DU prepares transmission data according to the uplink / downlink resource allocation information and sends it to or receives it from the FH splitter 331.
[0075] s) Upon receiving a C-plane message (ORAN fronthaul 7.2x standard) from the target DU 320b, the FH splitter 331 processes it as follows: According to various embodiments, since the RU 330 cannot know the new target DU 320b, the FH splitter 331 changes the MAC address to that of the source DU 320a before transmitting it to the RU 330. The FH splitter 331 stores at least one of the Frame ID, Subframe ID, Slot ID, Symbol ID, and Section ID of the C-plane packet. As an example, in the case of the uplink, upon receiving a packet from the RU 330 that uses the MAC address of the source DU 320a as the destination address, the FH splitter 331 identifies at least one of the Frame ID, Subframe ID, Slot ID, Symbol ID, and Section ID, and if it matches the stored one, changes the destination address to the MAC address of the target DU 320b. For example, in the case of downlink, when receiving a U-plane packet from the target DU 320b, the RU 330 cannot know the changed target DU 320b, so it changes the MAC address to that of the source DU 320a and then transmits it to the RU 330.
[0076] t) In the above steps h to s, a series of steps from the step in which the control agent 322a of the source DU 320a selects UEs to be processed by the target DU 320b from among the UEs directly or indirectly connected to the migration target RU 330, to the step in which the FH splitter 331 receives a C-plane message from the target DU and sends the MAC address of the source DU 320a to the migration target RU, are repeatedly executed until all UEs connected to the migration target RU are migrated to the target DU 320b.
[0077] u) The scale agent 322a of the source DU 320a requests the scale agent 322b of the target DU 320b to handle the scheduling of the migration RU.
[0078] v) The scale agent 322a of the source DU 320a notifies the scaling controller 312 that the transition to the transitioned RU is complete and deletes information about the RU for which the transition has been completed. According to various embodiments, the scale agent 322a of the source DU 320a maintains information about the RU for which the transition has been completed and receives information about the RU from the scale agent 322b of the target DU 320b to proceed with synchronization.
[0079] w) The scaling controller 312 notifies the F1 splitter 311 and the FH splitter 331 that the migration of the RU 330 is complete. As an example, the F1 splitter 311 performs IP address-based Network Address Translation (NAT) to switch data destined for the RU 330 for which migration has been completed. The FH splitter 331 performs MAC address-based Network Address Translation (NAT) to switch data destined for the target DU 320b from the RU 330 for which migration has been completed.
[0080] 2) Scale-in process
[0081] a) The scale agent 322a of the source DU 320a periodically reports resource status such as CPU usage, memory usage, network throughput, power consumption, and accelerator usage (FPGA / GPU / Smart NIC) of the DU server to the scaling controller 312. According to various embodiments, instead of periodically reporting to the scaling controller 312, the scale agent 322 reports the resource status when a resource usage condition preset by the scaling controller 312 is met.
[0082] b) The scaling controller 312 selects (makes a scaling decision for) a DU to be scaled in (target DU) based on the resource usage information of the DU 320. The scaling controller 312 switches the target DU service from the first server (e.g., 232c in FIG. 2) to another server (e.g., 232b in FIG. 2b) among the RUs 330 currently processing the target DU service, and selects an RU (e.g., 330c) to process the service. According to various embodiments, the selection of the scale-in target DU (target DU 320b) can be based on various policies. For example, if the resources allocated to the target DU 320b are allocated to process three RUs (e.g., 330a, 330b, and 330c in FIG. 3b) based on 30% of the RU's peak throughput, and one RU (e.g., 330a in FIG. 3b) is currently connected, and 20% of the processing capacity (90% in total) is being used, the scaling controller 312 initiates scaling. Alternatively, the scaling controller 312 selects the DU optimal for scaling through artificial intelligence / machine learning techniques. The scaling controller 312 selects the RU 330 according to various policies. As an example, among the RUs (e.g., 330a, 330b, and 330c in FIG. 3b) processing the service of the target DU 320b on a server (e.g., 232c in FIG. 2b), the RU (e.g., 330c in FIG. 3b) with a smaller-than-average throughput is selected, and the target DU 320b service is executed on another server (e.g., 232b in FIG. 2b) so that the corresponding RU 330c can process it. Alternatively, the scaling controller 312 selects the RU with the largest throughput and has the source DU 320a, which processes the corresponding capacity, process the migration target RU.
[0083] c) The scaling controller 312 selects a server (e.g., 232b in FIG. 2b) with spare processing capacity (scale-in server selection) to execute the target DU 320b service on that server. According to various embodiments, the selection of a server to execute the target DU 320b service is performed according to various policies. As an example, the scaling controller 312 selects a server that can process a peak data rate among several RUs, or a server that can process average data rates. The selection of the scale-in target server is related to the policy for selecting the scale-in target RU. If the scale-in target RU (the RU whose processing is migrated to the target DU service) has 20% of its peak throughput, the scaling controller 312 migrates the RU to a DU (e.g., source DU 320a) among the target DU 320b that uses 20% or less of resources than the scale-out reference value. According to various embodiments, reclaiming resources used by the DU (e.g., target DU 320b) service from the server is generally performed via a cloud environment such as Kubernetes. The server from which resources have been reclaimed (e.g., 232c in FIG. 2b) may be deleted from the cloud environment. Alternatively, the target DU 320b using fewer resources may be deleted by migrating the RUs to the source DU 320a. The scaling controller 312 provides information that allows the DU (e.g., target DU 320b) service to be deleted in the cloud environment.
[0084] d) The scaling controller 312 may change (if the target DU320b is scaled in on a server different from the source DU320a) or delete (if the target DU320b is scaled in on the same server as the source DU320a) information about the scale-in target DU320b registered in the F1 splitter 311.
[0085] e) The scaling controller 312 may change (if the target DU320b is scaled in on a different server than the source DU320a) or delete (if the target DU320b is scaled in on the same server as the source DU320a) information about the scale-in target DU320b registered in the fronthaul splitter 331.
[0086] f) The scaling controller 312 directs the creation of a communication session to synchronize the context between the scale agents 322a, 322b in the source DU 320a and the target DU 320b.
[0087] g) The scale agent 322b of the target DU 320b starts sending the context of the migration target RU (e.g., 330c) to the scale agent 322a of the source DU 320a and keeps updating the context changes. According to various embodiments, the context includes at least one of UE context, channel conditions, radio resource scheduling information, and system information.
[0088] h) The scaling agent 322b of the target DU 320b selects a UE to be processed by the source DU 320a from at least one UE directly or indirectly connected to the migration target RU (e.g., 330c in FIG. 3b). According to various embodiments, the scaling agent 322b selects the migration target RU (e.g., 330c in FIG. 3b) according to various policies. For example, the scaling agent 322b selects the UE from the inactive UEs, sequentially selecting the UE with the least amount of data transmission among the RRC connected UEs, starting with the UE with the most data transmission. Alternatively, the DRB QoS values of each UE may be compared and the UE with the lowest priority may be selected.
[0089] i) The scaling agent 322b of the target DU 320b sends information about the migration target UE to the scaling agent 322a of the source DU 320a. According to various embodiments, the scaling agent 322b of the target DU 320b sends information about the RU to the scaling agent 322a of the source DU 320a before sending information about the UE. According to various embodiments, the information about the UE includes a signaling radio bearer (SRB) list and a data radio bearer (DRB) list.
[0090] j) The scale agent 322b of the target DU 320b requests the F1 splitter 311 to send data destined for the migration target UE to the source DU 320b. According to various embodiments, the F1 splitter 312 sends all data destined for the migration target UE to the source DU 320b. In other words, the data flow is switched from the target DU 320b to the source DU 320a.
[0091] k) The scale agent 322b of the target DU 320b requests the scheduler 324b to stop uplink / downlink resource allocation for the migration target UE.
[0092] l) The scale agent 322b of the target DU 320b sends the currently remaining uplink / downlink data to the scale agent 322a of the source DU 320a.
[0093] m) The source DU 320a resets its buffer with the data received from the F1 splitter 311 and target DU 320b with circuitry, preparing to send and receive UE data.
[0094] n) The scaling agent 322a of the source DU 320a notifies the scaling agent 322a of the target DU 320b that it is ready to send and receive data to and from the UE.
[0095] o) The scale agent 322b of the target DU 320b requests the scheduler 324b to resume uplink / downlink resource allocation for the migration target UE.
[0096] p) The scaling agent 322b of the target DU 320b communicates the uplink / downlink resource allocation information for the migration target UE to the scheduler 324b to forward to the scaling agent 322b of the source DU 320a. According to various embodiments, the scaling agent 322b of the target DU 320b continues to forward the scheduling information until the migration of the migration target RU is completed.
[0097] q) The scale agent 322b of the target DU 320b sends the source DU address and target DU address information to the FH splitter 331.
[0098] r) The source DU 320a prepares transmission data according to the uplink / downlink resource allocation information and sends it to or receives it from the fronthaul splitter 331.
[0099] s) When the fronthaul splitter 331 receives a C-plane message (ORAN fronthaul 7.2x standard) from the source DU 320a, it modifies the MAC address of the target DU 320b, then sends it to the RU, and stores at least one of the Frame ID, Subframe ID, Slot ID, Symbol ID, and Section ID of the C-plane packet. According to various embodiments, in the case of uplink transmission, when a packet using the MAC address of the target DU 320b as the destination address is received from the RU 330, the fronthaul splitter 331 identifies at least one of the Frame ID, Subframe ID, Slot ID, Symbol ID, and Section ID, and then modifies the destination address to the MAC address of the source DU 320a if it matches the stored one. According to various embodiments, in the case of downlink transmission, when a U-plane packet is received from the target DU 320b, the fronthaul splitter 331 including the circuitry modifies the MAC address of the source DU 320a and sends the modified address to the RU.
[0100] t) Repeat the above steps h to s on each UE until all UEs connected to the transfer target RU are transferred to the source DU 320a.
[0101] u) The scale agent 322a of the target DU 320b requests the scale agent 322a of the source DU 320a to handle the scheduling of the migration target RU (eg, 330c).
[0102] v) The scale agent 322b of the target DU 320b notifies the scaling controller 312 that the migration of the migration target RU (e.g., 330c in FIG. 3b) is complete, and deletes information about the RU (e.g., 330c in FIG. 3b) whose migration has been completed.
[0103] w) The scaling controller 312 notifies the F1 splitter 311 and / or the fronthaul splitter 331 that the transition of the RU (e.g., 330c) is complete.
[0104] x) If there are no RUs 330 processed by the target DU 320b, the scaling controller 312 deletes the instance of the target DU 320b.
[0105] According to various embodiments of the present invention, in a 5G RAN system consisting of a CU, a DU, and an RU, software and devices are proposed that include an F1 splitter that decouples the CU and DU, a fronthaul splitter that decouples the DU and RU, a scaling controller that controls a scaling process according to the state of server resources, and a scaling agent that communicates with the scaling controller, controls the data flow required for scaling within the DU, and handles context synchronization between the DUs.
[0106] According to various embodiments, a scheduler responsible for resource allocation within a DU is used to seamlessly control radio bearers as resources allocated to a UE are transitioned from a source DU to a target DU.
[0107] According to various embodiments, in the data flow between the source DU and the UE, the data flow between the RU and the target DU is changed based on FrameID, SubframeID, SlotID, SymbolID, and SectionID information to switch the data flow between the target DU and the UE.
[0108] According to various embodiments, instead of allocating a dedicated DU to the RU 330, server resources required according to the traffic of the RU are allocated to the DU 320 through server resource pooling of the cloud platform. As a result, server resources are secured, which allows the number of servers to be reduced, thereby reducing power consumption.
[0109] According to various embodiments, a resource pool represents a state in which at least one resource, such as a server or storage, is reserved and can be provided in response to a user's request, and is implemented in a virtual space. In a cloud environment, resources are provided in response to a user's request via a pre-reserved resource pool, either immediately or through minimal or reduced processing.
[0110] The electronic device according to various embodiments may be of various types, including, for example, a base station system of a telecommunications carrier, a private network device (Private 5G system), etc. According to one embodiment, the electronic device is not limited to the above.
[0111] The various embodiments of the present invention and the terms used therein are not intended to limit the technical features described herein to a specific embodiment, but rather encompass various modifications, equivalents, or alternatives of the embodiment. In describing the drawings, like reference numerals are used for similar or related components. The singular form of a noun corresponding to an item includes one or more of the item unless the relevant context clearly dictates otherwise. In this specification, each of phrases such as "A or B," "at least one of A and B," "at least one of A or B," "A, B, or C," "at least one of A, B, and C," and "at least one of A, B, or C" includes any of the items listed together in the corresponding phrase, or all possible combinations thereof. Terms such as "first," "second," "first," or "second" are used merely to distinguish a component from other corresponding components and do not limit the component in other aspects (e.g., importance or order). When a (e.g., first) component is referred to as being "coupled" or "connected" to another (e.g., second) component, either in combination with or without the terms "functionally" or "communicatively," it means that the component is connected to the other component directly (e.g., by wire), wirelessly, or through at least a third component.
[0112] The term "module" as used in various embodiments herein includes a unit implemented in hardware, software, or firmware, and is used interchangeably with terms such as logic, logic block, component, or circuit. A module may be an integrated component, or the smallest unit or portion of such components that performs one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC). Here, each module includes a circuit.
[0113] Various embodiments of the present invention may be implemented as software (e.g., program 140) including one or more instructions stored in a storage medium (e.g., internal memory 136 or external memory 138) readable by a machine (e.g., electronic device 101). For example, a processor (e.g., processor 120) of the machine (e.g., electronic device 101) retrieves and executes at least one instruction from the one or more instructions stored in the storage medium. This causes the machine to perform at least one function according to the retrieved at least one instruction. The one or more instructions may include code generated by a compiler or code executed by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, the term "non-transitory" simply means that the storage medium is a tangible device and does not include signals (e.g., electromagnetic waves). This term does not distinguish between data being stored semi-permanently and data being stored temporarily on the storage medium.
[0114] According to one embodiment, the methods according to various embodiments may be provided in a computer program product. The computer program product may be traded as a commodity between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., a compact disc read-only memory (CD-ROM)) or may be distributed online (e.g., downloaded or uploaded) through an application store (e.g., the Play Store) or through a mobile carrier's distribution system. In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily generated in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store server, or an intermediary server, where each server includes processing circuitry.
[0115] According to various embodiments, each of the above components (e.g., modules or programs) may include one or more entities, and some of the entities may be located separately in different components. According to various embodiments, one or more of the above-described components or operations may be omitted, or one or more other components or operations may be added. Alternatively or additionally, multiple components (e.g., modules or programs) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each of the multiple components in the same or similar manner as performed by the corresponding component of the multiple components before integration. According to various embodiments, the operations performed by a module, program, or other component may be performed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be performed in a different order, omitted, or one or more other operations may be added. [Explanation of symbols]
[0116] 120 processors 130 Storage device 150 Radio Access Network (RAN) 151 Distributed Unit (DU) 154 Core Network 160 User Equipment (UE) 161 Remote Unit (RU) 190 Communication Module
Claims
1. A radio access network device including a distributed unit (DU), a first DU in communication with a plurality of remote units (RUs); a scaling controller that obtains resource usage information for the first DU; a second DU selected by the scaling controller based on resource usage information for the first DU; The scaling controller selects at least one RU to migrate to the second DU from among the plurality of RUs processing the service of the first DU; The first DU transmits information about the selected at least one RU to the second DU; At least one remaining RU, excluding the selected at least one RU, processes the service of the first DU; The information about the selected at least one RU includes at least one of a signaling radio bearer (SRB) list and / or a data radio bearer (DRB) list for a migration target UE.
2. The apparatus of claim 1 , wherein the scaling controller is configured to select a server having capacity to service the second DU.
3. The device of claim 1, wherein the second DU is selected as the second DU to process at least a portion of the service of the first DU using a second server different from the first server based on the resource usage of the first DU satisfying a condition related to the available resources of the first server executing the service of the first DU.
4. 2. The apparatus of claim 1, wherein the information about the selected at least one RU further includes at least one of information about a UE associated with the selected at least one RU, information about a channel condition, radio resource scheduling information, or system information.
5. 2. The apparatus of claim 1, wherein the first DU is configured to create a communication session to synchronize information regarding the selected at least one RU with the second DU.
6. 2. The apparatus of claim 1, wherein the second DU is configured to select a UE to be processed by the second DU from among at least one UE connected to the selected at least one RU.
7. 2. The apparatus of claim 1, wherein the first DU is configured to transmit information about a migration target UE to the second DU, and the migration target UE is configured to process services for the second DU.
8. 2. The apparatus of claim 1, wherein the radio access network device further includes an F1 splitter that connects the first DU and the second DU to a central unit (CU), the F1 splitter being configured to switch a data flow from the first DU and transmit it to the second DU.
9. the radio access network device includes an F1 splitter that connects the first DU and the second DU to a central unit (CU); and a fronthaul (FH) splitter connecting the first DU and the second DU to the plurality of RUs; The apparatus of claim 1 , wherein the scaling controller is configured to register information about the service of the second DU with the F1 splitter and the FH splitter, respectively.
10. A communication method by a radio access network device including a first distributed unit (DU) and a second DU, comprising: obtaining resource usage information for the first DU; selecting the second DU based on resource usage information for the first DU; selecting at least one remote unit (RU) to migrate to the second DU from among a plurality of RUs currently processing the service of the first DU; transmitting information about the selected at least one RU from the first DU to the second DU; At least one remaining RU among the plurality of RUs, excluding the selected at least one RU, is configured to process a service of the first DU; The method, wherein the information about the selected at least one RU includes at least one of a signaling radio bearer (SRB) list and / or a data radio bearer (DRB) list for a migration target UE.
11. The method of claim 10, further comprising the step of selecting a server having the capacity to perform the service of the second DU.
12. The method of claim 10, characterized in that the process of selecting the second DU comprises selecting the second DU to process at least a portion of the service of the first DU using a second server different from the first server based on the resource usage of the first DU satisfying a condition related to the available resources of the first server executing the service of the first DU.
13. 11. The method of claim 10, wherein the information about the selected at least one RU further includes at least one of information about a UE associated with the selected at least one RU, information about a channel condition, radio resource scheduling information, or system information.
Citation Information
Patent Citations
Apparatus, system, and method for transferring control of a remote radio head between baseband unit (BBU) processing pools
JP2017526235A
Radio communication system, controller, and control method
JP2021158602A
Optical Transport Network
US20170163342A1