5G Radio Access Network Live Migration and Sharing

Abstract

The Radio Access Network (RAN) of fifth-generation (5G) mobile networks is virtualized to operate on edge computing platforms in cloud computing environments, where Radio Units (RUs) and Radio Frequency (RF) spectrum are shared among Distributed Units (DUs) to support use cases including 1) live migration, where a DU moves from one computing server to another without interrupting network traffic, and 2) RAN sharing, where two DUs share the same RU and spectrum.

Description

[Background technology]

[0001] background Fifth-generation (5G) mobile networks offer the ability to connect tens of billions of intelligent devices that will be densely deployed and generate orders of magnitude more data to be processed by the network. Consumer expectations for 5G mobile networks are high, and mobile network operators will be under real pressure from their enterprise customers to act quickly and deliver 5G's low latency, high device density, and high-performance capabilities to enable near real-time management and control of critical business operations. Summary of the Invention [Means for solving the problem]

[0002] overview The 5G Radio Access Network (RAN) is virtualized for operation on edge computing platforms in cloud computing environments, where radio unit (RU) and radio frequency (RF) spectrum resources are shared among distributed units (DUs) to support use cases including: 1) live migration, where a DU moves from one computing server to another without disrupting network traffic, such as user equipment (UE) disconnection or loss of performance or network coverage, and 2) RAN sharing, where two DUs share the same RU and spectrum. RAN sharing allows, for example, different mobile operators (MOs) to share RAN resources and 5G network slicing in a multi-vendor scenario.

[0003] This Summary is presented to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. Moreover, the claimed subject matter is not limited to implementations that solve any or all of the disadvantages noted in any part of this disclosure. It will be understood that the foregoing subject matter may be implemented as a computer-controlled device, a computer process, a computing system, or as an article of manufacture, such as one or more computer-readable storage media. These and various other features will be apparent from reading the Detailed Description below and reviewing the associated drawings. [Brief explanation of the drawings]

[0004] DESCRIPTION OF THE DRAWINGS [Figure 1] 1 illustrates an exemplary RAN Live Migration use case facilitated by the present disclosure. [Figure 2] 1 illustrates an exemplary RAN sharing use case facilitated by the present disclosure. [Figure 3] 1 illustrates an exemplary intelligent controller configured for operation in a cloud computing infrastructure using IQ (in-phase and quadrature) multiplexers, each of which may be virtually and / or physically implemented. [Figure 4] 1 illustrates an exemplary 5G NR (New Radio) time / frequency resource grid. [Figure 5] 1 illustrates an exemplary 5G NR frame structure. [Figure 6] 1 shows an example table of OFDM symbols per slot, slots per subframe, and OFDM symbols per subframe for a standard cyclic prefix configuration. [Figure 7]1 illustrates an exemplary physical channel allocation within a 5G NR frame and associated scheduling of radio resources based on the allocated channels. [Figure 8] 1 illustrates an exemplary mapping of physical channels to physical antenna ports. [Figure 9] 1 illustrates an exemplary message exchange according to the xRAN7.2x protocol. [Figure 10] 1 shows an exemplary control plane (C-plane) frame format as defined in ETSI (European Telecommunications Standards Institute) TS 103 859. [Figure 11] An exemplary user plane (U-plane) frame format, as defined in ETSI TS 103 859, is shown. [Figure 12] An illustrative example of RAN Live Migration is presented. [Figure 13] An illustrative example of RAN Live Migration is presented. [Figure 14] An illustrative example of RAN Live Migration is presented. [Figure 15] An illustrative example of RAN Live Migration is presented. [Figure 16] An illustrative example of RAN Live Migration is presented. [Figure 17] An illustrative example of RAN sharing is provided. [Figure 18] 1 illustrates an example of an exemplary usage scenario for a 5G network. [Figure 19] A standardized exemplary 5G network slice is shown. [Figure 20] 1 illustrates an exemplary layered 5G network slicing framework. [Figure 21] 1 illustrates an exemplary physical infrastructure for a 5G network architecture. [Figure 22] An exemplary 5G radio access network (RAN) and radio unit (RU) are shown. [Figure 23] 1 illustrates an exemplary split RAN hierarchy in which a central unit (CU) may support multiple distributed units (DUs), which in turn may support multiple RUs. [Figure 24] 1 illustrates an exemplary Radio Resource Control (RRC) decomposed into mobile core-facing control plane components and a near real-time RAN Intelligent Controller (near-RT RIC). [Figure 25] 1 illustrates an exemplary RAN Operations and Maintenance (OAM) logical architecture as described by the O-RAN Alliance. [Figure 26] FIG. 1 is a block diagram of an example UE that may be used at least in part to implement this 5G RAN live migration and sharing. [Figure 27] FIG. 1 is a block diagram of an exemplary server or computing device that may be used at least in part to implement this 5G RAN live migration and sharing. [Figure 28] FIG. 1 is a block diagram of an exemplary data center that may be used at least in part to implement this 5G RAN live migration and sharing. [Figure 29] FIG. 1 is a simplified block diagram of an exemplary computer system that may be used at least in part to implement this 5G RAN live migration and sharing. DETAILED DESCRIPTION OF THE INVENTION

[0005] Detailed Description Like reference numbers refer to like elements in the various drawings, and unless otherwise specified, elements are not drawn to scale.

[0006] Acronyms used in this disclosure are defined along the text and are also listed in the acronym list in the Appendix.

[0007] RAN live migration and sharing use cases are facilitated by a virtualized RAN (Radio Access Network) approach using edge-based cloud computing, where 5G physical radio resources are virtualized to enable the common and efficient sharing of RUs (Radio Units) 102 among various DUs (Distributed Units), each appearing as a dedicated, separate RU. Figure 1 illustrates an exemplary live migration use case 100 in which a DU 105 moves from Server 1 (110) to Server 2 (115) in a cloud computing data center 120 without user disruption. Each server may be implemented physically or virtually to support a given application of the principles of the present invention. Figure 2 illustrates an exemplary RAN sharing use case 200 in which different DUs 205 and 210 are deployed in a data center 212 that shares the same RU 202 and radio spectrum. In the illustrative example, each of the DUs is associated with a different mobile operator (MO) 215 and 220. It will be understood that the exemplary principles disclosed herein use the context of a 5G mobile network, but are also applicable, with appropriate modifications, to a Fourth Generation Long Term Evolution (4G LTE) network.

[0008] RAN live migration and sharing is implemented in an exemplary use case 300 shown in FIG. 3, in which an intelligent controller 305 is configured to collect telemetry data 308 in real time from various RAN components 301, including source and destination DUs, designated by reference numerals 310 and 315, respectively, and a central unit (CU) 320. In some embodiments, the telemetry data may also include UE status. The intelligent controller submits fronthaul packet forwarding rules 320 to an IQ multiplexer 325, which is configured to multiplex IQ (in-phase and quadrature) samples 330 in a fronthaul network (not shown) between the RAN and the RU 302. The intelligent controller and IQ multiplexer can be implemented virtually and / or physically using cloud computing and other infrastructures. For example, depending on the intended use, these components may be instantiated on an edge cloud computing platform and / or a far edge cloud computing platform using appropriate software, general-purpose hardware, and / or specialized hardware such as application specific integrated circuits (ASICs).

[0009] In an illustrative example, the intelligent controller 305 may be implemented in a RAN intelligent controller (RIC) described below in the text accompanying Figures 24 and 25, which includes control hooks to the DUs 310 and 315. In various illustrative examples, the IQ multiplexer 325 may be implemented in various manners depending on the requirements of a particular application. Implementation options include a programmable switch, such as a physically embodied top-of-rack (TOR) switch, or a software switch implemented virtually on various computing infrastructures. Alternative IQ multiplexer architectures include switching solutions implemented alongside virtualized RAN components, including DUs and / or CUs, or other virtualized RAN components.

[0010] The intelligent controller operates according to the forwarding rules 320 presented to the IQ multiplexer 325 and based on real-time telemetry data 308 to dynamically allocate blocks of radio resources at the source and destination DUs to enable sharing of a common RU with minimal interference. In the live migration use case, the intelligent controller allocates radio resources so that traffic from the UE is handed over from the source DU to the destination DU with minimal UE disconnection and traffic disruption. In the RAN sharing use case, IQ samples are dynamically merged based on the network load and radio resource allocation (determined by telemetry data) at each DU, but handover of UE traffic is not necessarily implemented.

[0011] In an illustrative example, IQ samples to and from the RU are combined in IQ multiplexers at two DUs (e.g., source DU 310 on Server 1 (350) and destination DU 315 on Server 2 (355)) using forwarding rules 320 into the fronthaul network packet carrying the sample. The use of two DUs in this example is illustrative and not limiting, and the RAN live migration and sharing principles described herein are adaptable to use cases involving three or more DUs with appropriate modifications. Fronthaul network packets include xRAN packets described by the Open Fronthaul Specification published by the xRAN Forum and are collected using the 7.2 Split RAN protocol proposed by the O-RAN Alliance, which splits the physical (PHY) layer into a high PHY and a low PHY. The high PHY resides in the DU, and the low PHY resides in the RU. It is emphasized that the xRAN packets and 7.2 protocols used in this example are exemplary and not limiting, and that various other fronthaul network architectures, protocols, interfaces, and functional divisions can be used to meet the requirements of this specific application of RAN live migration and sharing.

[0012] IQ samples are defined in published 5G NR (New Radio) literature (see, for example, M. Viswanathan, Gaussianwaves.com (2022)) as using complex numbers, as exemplarily shown in graph 400 in Figure 4, where subcarriers in the frequency domain are plotted against symbol positions in the time domain. As shown, physical resource block 405 includes 12 subcarriers scheduled for transmission. Resource element 410 is the smallest time / frequency resource on one subcarrier of a single OFDM (Orthogonal Frequency Division Multiplexing) symbol.

[0013] As shown in FIG. 5 and described by Viswanathan, a 5G NR frame structure 500 from a time domain perspective includes a radio frame 505, subframes 510, and slots 515. A radio frame is 10 ms in duration and includes 10 subframes, each of 1 ms in duration. Each subframe may consist of one or more adjacent slots, each of which has 14 symbols. A viable means of transmitting over a portion of a slot is called a minislot. FIG. 6 shows an example table 600, as described by Viswanathan, of OFDM symbols per slot, slots per subframe, and OFDM symbols per subframe for a typical cyclic prefix configuration. The parameter μ is referred to as the numerology.

[0014] 7 illustrates an exemplary physical channel allocation 700 within a 5G NR frame 705 and the associated scheduling of radio resources based on the allocated channels. As explained by Fuentes et al. in "5G New Radio Evaluation Against IMT-2020 Key Performance Indicators (IEEE Access, 2020)," a physical channel is defined as an information flow transmitted between the physical (PHY) layer and the medium access control (MAC) layer. In comparison, a physical signal is an information flow transmitted only at the physical layer. In the DL (downlink), three physical channels are used: The Physical Downlink Control Channel (PDCCH) specifies the scheduling and allocation of data by means of Downlink Control Information (DCI) at every UE and configures other aspects such as Hybrid Automatic Repeat Request (HARQ) retransmissions, link adaptation, and Multiple Input Multiple Output (MIMO). Furthermore, there are four types of reference signals: The UL defines three physical channels: Primary and Secondary Synchronization Signals (PSS, SSS), which are required by the UE to access the network and, more specifically, to receive radio frame timing information and cell IDs; Demodulation Reference Signals (DMRS), which are used for channel estimation to retrieve data on the PBCH, PDCCH, and PDSCH; Phase Tracking Reference Signals (PT-RS), which are used to estimate the phase noise on the PDSCH (only used in Frequency Range 2 (FR2)); and Channel State Information Reference Signals (CSI-RS), which are used to provide the CSI needed for link adaptation.The Physical Uplink Control Channel (PUCCH) carries uplink control information (UCI) and contains various information such as CSI, HARQ, or scheduling requests, and the Physical Uplink Shared Channel (PUSCH) transmits data content to the gNB. For the UL (uplink), similar reference signals are used: DMRS, PT-RS, and Sounding Reference Signal (SRS), which are equivalent to CSI-RS in DL.

[0015] Figure 8 shows an example mapping 800 of physical channels 805 to physical antenna ports 810, as described in "Multiplexing Techniques for Applications Based on 5G Systems (2022)" by N.H. Trung. Recognizing that signals transmitted from various logical antenna ports may be subject to different radio conditions, this RAN live migration and sharing implements antenna port mapping. The mapping of DU data flows to antenna ports is performed using RU endpoint identifiers. For example, in the O-RAN 7.2 protocol, this mapping is performed using the eAxC identifier (eAxC_ID) placed in the xRAN packet header, as described in Section 5.1.3.2.7 of the O-RAN Technical Specification WG4.CUS.0-v10.00. Therefore, each eAxC_ID may correspond to one or more spatial streams of a DU and may be mapped to one or more RU antennas.

[0016] In this mapping scheme, SSB and PDCCH are always mapped to a single physical antenna port, while PDSCH may be mapped to many antenna ports. Furthermore, some signals, e.g., PDSCH and DMRS, must be transmitted from the same antenna.

[0017] The xRAN7.2x protocol is exemplarily shown in message flow 900 in Figure 9, where xRAN messages are exchanged between an O-RU 905 (an O-RAN Alliance-defined Open RU) and an O-DU 910 (an O-RAN Alliance-defined Open DU). Downlink (DL) messages in the control plane (C-plane) and user plane (U-plane) are shown on the left side of the figure. Uplink (UL) messages in the C-plane and U-plane are shown on the right side of the figure. C-plane frame format 1000 and U-plane frame format 1100, as defined in ETSI TS 103 859, are shown in Figures 10 and 11, respectively.

[0018] Referring again to Figure 3, the multiplexing performed in the IQ multiplexer 325 is informed by the observation that the source DU 310 and destination DU 315 have identical timing and slot alignment, derived for example using PTP (Precision Time Protocol). Furthermore, the source DU and destination DU are identically configured with respect to xRAN messaging, since C-plane and U-plane messages are generated simultaneously and in the same order. Furthermore, the C-plane messages at the source DU and destination DU are identical. The UL U-plane messages are also identical at the source DU and destination DU.

[0019] An illustrative and non-limiting example of an IQ multiplexing algorithm that applies the preceding observations and forwarding rules is provided below. It will be appreciated that appropriate modifications can be made to the algorithm to accommodate various alternative cell configurations, for example, utilizing beamforming and / or carrier aggregation.

[0020] 1. C-plane: Forwards C-plane packets from the source DU to the RU and discards C-plane packets from the destination DU. 2.UL U-Plane: Forwards UL U-Plane packets to both the source DU and destination DU. 3. DL U-Plane 1. At the source DU 1. If the xRAN packet is intended for the RU endpoint corresponding to the PDCCH / SSB symbol, forward it. 2. If the xRAN packet is intended for a RU endpoint corresponding to the PDSCH, forward it if it is intended for the slot allocated to this DU, otherwise discard it. 2. At the destination DU 1. If the xRAN packet is intended for an RU endpoint corresponding to the PDCCH / SSB symbol, remap and forward the packet to an available RU endpoint by modifying the header. Note: This means that the original RU endpoint has already been acquired by the source DU for its own PDCCH, and occurs because the cell configurations of both the source DU and destination DU are the same. 2. If the xRAN packet is intended for a RU endpoint corresponding to the PDSCH, forward it if it is intended for the slot allocated to this DU, otherwise discard it.

[0021] An illustrative example of RAN Live Migration is shown in Figures 12-16. In Figure 12, a UE (not shown) is connected to a source DU 1205 located at the far edge 1202 of a cloud computing infrastructure as part of an elastic server pool 1210. The UE may (or may not) transmit traffic over the network. As shown in Figure 13, UE status and other telemetry data (exemplary details are shown on the right side of the figure and representatively indicated by reference numeral 1305) is collected by an intelligent controller 305.

[0022] FIG. 14 illustrates how live migration may be triggered. For example, as shown in FIG. 15, a UE (not shown) may be handed over from a source DU 1205 to a destination DU for several reasons, such as energy conservation in a data center, software upgrades, or the implementation of elastic pooling of computer and / or other resources. In FIG. 15, an intelligent controller activates another DU (e.g., destination DU 1505). The destination DU has a cell configuration that differs from the cell configuration of the source DU. Such differences include, for example, MIBs / SIBs located at different locations on the radio resource grid. Furthermore, different cell identification information, including, for example, a physical cell identifier (PCI) and a scrambling ID, may be utilized between the source DU and the destination DU.

[0023] The intelligent controller 305 initially configures the IQ multiplexer (not shown) to block all xRAN packets to and from the destination DU 1505. The intelligent controller configures the source DU and destination DU to utilize non-overlapping radio resources (e.g., PDSCH / ULSCH channels) for both UL and DL user data. Typically, the intelligent controller ensures that only one DU is transmitting and / or receiving user data (PDSCH / ULSCH) in any given UL / DL slot. For example, assuming 10 slots, the source DU 1205 may transmit data in slots 0, 1, 2, 3, and 4, and the destination DU may transmit data in slots 5, 6, 7, 8, and 9. The intelligent controller can dynamically modify slot allocation based on traffic load (as indicated by telemetry data). Typically, radio resources are allocated proportionally based on the traffic load at each DU.

[0024] The intelligent controller 305 creates and / or updates forwarding rules that are presented to the IQ multiplexer so that xRAN traffic at both the source DU 1205 and destination DU 1505 is transported to and from the RU 1510. The creation and / or update of the rules takes into account the various cell configurations at each DU and the multiplexing algorithms described above.

[0025] The intelligent controller 305 performs handover of each UE from the source DU 1205 to the destination DU 1505. In an illustrative example, optimized handover is accomplished by the intelligent controller ordering UE handovers between the source DU and destination DU based on real-time telemetry data from the DU and CU (representatively designated by reference numeral 1515) indicating the traffic load of a given UE. UEs carrying traffic loads below a predetermined threshold are handed over from the source DU to the destination DU first, and the intelligent controller's selection of the next UE to handover is based on the current traffic load. For example, the UE with the lowest uplink (UL) and downlink (DL) queues is handed over next.

[0026] In situations where the telemetry data indicates that the UE is exceeding a predetermined traffic load threshold, a handover is not attempted. Instead, the intelligent controller 305 is configured to implement a predetermined waiting interval before again checking the traffic load on the UE. Once the traffic load falls below the predetermined threshold, a handover from the source DU to the destination DU is performed.

[0027] The intelligent controller 305 then updates the IQ multiplexer to block all xRAN traffic to and from the source DU 1205 and forward all traffic to and from the destination DU 1505. As shown in Figure 16, the intelligent controller configures all resource blocks for use by the destination DU for both UL and DL user data, and then stops the source DU.

[0028] FIG. 17 illustrates an exemplary use case 1700 of RAN sharing, in which multiple RANs 1705 and 1710, each with a DU and CU and associated with different MO core networks 1715 and 1720, utilize a single RU 1725. For example, such RAN sharing can be used in MORAN (Multi-Operator Radio Access Network) and MOCN (Multi-Operator Core Network) scenarios. Other use cases supported by RAN sharing include multi-vendor network slicing, in which different network slices use different capabilities from different vendors. For example, the RUs are provided by vendor A, the DUs are provided by vendor B, and the CUs are provided by vendor C; 5G network slicing is discussed below in the description accompanying FIGS. 19 and 20.

[0029] In RAN sharing, similar to RAN Live Migration, IQ multiplexers perform IQ sample multiplexing of traffic on each network with dynamic radio resource allocation implemented by forwarding rules from an intelligent controller based on traffic load determined from telemetry data. However, unlike RAN Live Migration, no handover is performed in the RAN sharing scenario.

[0030] The following discussion presents information about 5G mobile networks to provide context and background for this 5G RAN live migration and sharing. 5G mobile networks utilize a service-based architecture that supports deployments that enable data connectivity and services, using techniques such as network function virtualization (NFV), software-defined networking (SDN), and cloud computing. Some example features and concepts of 5G networking include separating user plane (UP) and control plane (CP) functions to enable independent scalability, evolution, and flexible deployment, for example, across centralized and / or distributed (i.e., remote) locations. The functional design of 5G networks is modularized to enable flexible and efficient network slicing. Dependencies between the radio access network (RAN) and the core network (CN) are also minimized. The 5G architecture is therefore defined by a converged core network with a common AN-CN interface that integrates different access types, for example 3GPP (3rd Generation Partnership Project) access and untrusted non-3GPP access such as WiMAX, cdma2000, WLAN or fixed networks.

[0031] The International Mobile Telecommunications (IMT) Recommendation for 2020 (ITU-R M.2083-0) from the International Telecommunications Union, Radiocommunication Sector, envisions usage scenarios for 5G networks including: Mobile Broadband (MBB), as shown by reference numeral 1805, Ultra-Reliable and Low Latency Communications (URLLC) 1810, and Massive Machine Type Communications (MMTC) 1815, as shown in the usage footprint 1800 in Figure 18.

[0032] MBB use cases 1805 address human-centric use cases for accessing multimedia content, services, and data. Demand for mobile broadband will continue to grow, leading to higher speeds and higher capacity mobile broadband. Enhanced MBB use cases will involve existing MBB applications as well as new application areas and requirements for improved performance and an increasingly seamless user experience. Enhanced MBB use cases may include wide area coverage and hotspots, targeting a range of use cases with different requirements.

[0033] In hotspot scenarios (i.e., areas with high user density), very high traffic capacity is required, mobility requirements are typically low, and user data rates are higher than in wide-area coverage scenarios. Wide-area coverage scenarios require seamless coverage, medium to high levels of mobility, and significantly improved user data rates compared to existing data rates, typically 20 Gbps download and 10 Gbps upload. However, these data rate requirements may be relaxed compared to hotspot scenarios.

[0034] URLLC use cases 1810 typically have relatively stringent requirements for capabilities such as latency and availability. For example, latency in the RAN can be expected to be less than 1 ms while maintaining high reliability. Some examples include wireless control of industrial manufacturing or production processes, remote medical surgery, power distribution automation in smart grids, and transportation safety.

[0035] MMTC usage scenarios 1815 may be characterized by very large numbers of connected devices, such as Internet of Things (IoT) devices, with hundreds of thousands of connected devices per square kilometer. MMTC is sometimes referred to as Massive IoT (MIoT) in some 5G literature. Such connected devices can be expected to transmit relatively small amounts of data that are not latency-sensitive. Devices are typically required to be low cost and have very long battery life.

[0036] An exemplary application in 5G networking is also shown in Figure 18. This application may be included in example usage scenarios 1800 in various locations depending on the given balance of the application's networking requirements. As shown, the exemplary applications may include three-dimensional and / or ultra-high definition (3D and UHD) 1820, augmented reality 1825, industrial automation 1830, autonomous vehicles 1835, mission-critical infrastructure 1840, smart cities 1845, voice 1850, smart homes 1855, and gigabytes per second 1860.

[0037] ITU emphasizes that it expects additional use cases and applications for 5G to emerge, and that 5G network operators may not necessarily be limited to or required to support any particular use case or predefined slice type. Similarly, application and service providers may be expected to take advantage of the high speeds and low latency of 5G to develop feature-rich capabilities for all types of connected devices (both fixed and mobile), deliver compelling user experiences across a range of computing devices and platforms, and further realize the potential of artificial intelligence (AI) and the Internet of Things (IoT) in ways that are prohibited by current connectivity.

[0038] With 5G, capabilities such as network slicing will be available to both operators and enterprises deploying 5G infrastructure, allowing for the optimization of mobile networks. A network slice is a logical (i.e., virtual) network customized to serve a defined purpose, service type / class, quality of service (QoS), or dedicated customer. 5G network slices may be dynamically created, consisting of the end-to-end composition of all the diverse network resources and infrastructure needed to meet the specific performance and requirements of a specific service class or application, while meeting any predefined service level agreement (SLA). Each part of the 5G network is sliced, such that the network can be considered to consist of a RAN slice, a mobile core slice, a cloud slice, and so on. 5G network slicing thus enables the creation of multiple logical, secure networks that are separate from each other but span the same common physical network infrastructure.

[0039] A 5G network slice may consist of resources configured into an end-to-end service delivery structure. These may include physical resources, such as shared or profiles assigned to the slice, or possibly dedicated physical resources. A slice also consists of logical entities, such as configured network functions, management functions, and VPNs (Virtual Private Networks). Resources (physical or logical) may be dedicated to a 5G network slice, i.e., a separate instance, or may be shared across multiple slices. These resources are not necessarily all generated within the mobile network provider; some may include services consumed by other providers, for example, facilitating aggregation, cloud infrastructure, roaming, etc.

[0040] 3GPP is the primary standardization organization developing the 5G architecture. Several iterations of the standard have established the current foundation for slice-specific definitions. The 3GPP R15 System Architecture (3GPP TS23.501) defines the currently standard service-based slice / service type (SST). As shown in Figure 19, the standardized 3GPP network slices for a 5G network 1905 include eMBB (eMb / B) (SST=1), URLLC (SST=2), and MIoT (SST=3), which correspond to the use cases described in ITU-R2083-0. Additional standardized SST values ​​for V2X (Vehicle-to-Everything) (SST=4) and HMTC (High-Performance Machine-Type Communication (SST=5)) are also defined by 3GPP. It is understood that slice service types beyond those with standardized SST values ​​may also be defined.

[0041] The five standardized or predefined service types in 5G network slices are shown in Figure 19 with reference numbers 1910, 1915, 1920, 1925, and 1930, respectively. IMT-2020 describes the concept of network slicing as supporting diverse requirements for UEs and application services using a network that can create multiple logical network instances tailored to the requirements. Network slicing enables 5G network operators to realize dedicated logical networks (i.e., network slices) with customer-specific functions. The 5G architecture allows for various network configurations in different network slices.

[0042] Network slices can be dedicated to different types of services and can span any area of ​​the underlying physical infrastructure 1935, such as transport networks supporting flexible location of functions, dedicated radio configurations, or specific radio access technologies (RATs), mobile core networks, etc. Network slices can also be deployed across multiple operators. Slices can share a common physical infrastructure or, in some cases, have dedicated resources and / or functions. Various types of network slices can consist of standardized network functions as well as intellectual property-based functions that may be provided by different operators or third parties.

[0043] Standardized SST values ​​and default slice types provide a method for establishing global interoperability for 5G network slicing, allowing operators to efficiently support important industry verticals, such as industrial automation, healthcare, entertainment, transportation, manufacturing, energy, agriculture, construction, and security, with the most commonly used default slice / service types. Additional customization and / or specialization for applications and services may be implemented for specific use cases. The UE may provide the network with parameters in the Network Slice Selection Assistance Information (NSSAI) to assist in selecting the RAN and core network portion of a slice instance for the device. Several slices may be selected by a single NSSAI. The NSSAI consists of a session management NSSAI (SM-NSSAI), each of which contains an SST and possibly a slice identifier (SD). The SST may refer to the expected network behavior, e.g., for broadband or IoT functionality, and the SD can help select among several slice instances of the same type. It should be noted that services supported in a standardized default slice may also be supported by other default slices with other (i.e., non-standard) SST values.

[0044] FIG. 19 illustrates UE 1900, which may represent a wide variety of device types that may utilize a 5G network, including, but not limited to, smartphones and computing devices, drones, robots, process automation equipment, sensors, controls, vehicles, transportation equipment, haptic interaction devices, virtual reality and augmented reality (VR and AR) devices, and industrial machinery. While standardized slices can be mapped to each of these UE types under normal usage conditions to optimize network utilization and user experience, 5G network slicing is designed for flexibility to meet demands across a wide range of device types and various applications and services. The softwarization of the network, brought about by SDN and NFV paradigms in 5G, enables the configuration of network slices—how various physical infrastructure and network resources are deployed and rapidly and dynamically adapted to ensure that performance targets for 5G applications are consistently met across a given population of UEs.

[0045] As shown, the eMBB slice 1910 configuration may be optimized for "broadband everywhere" use cases over a wide coverage area, such as consumer entertainment (e.g., video, gaming, streaming), remote office, and other applications where maximizing network and data rates is desirable and traffic volumes are typically high. The URLLC slice 1915 may be configured for low-latency use cases in mobile critical infrastructure, including applications such as remote control operations in medical and industrial environments, VR and AR, robotics, and automation.

[0046] The MIoT slice 1920 may be configured to optimally handle IoT, control, and sensor applications related to logistics, construction, and instrumentation in vertical industries such as construction and agriculture. The V2X slice 1925 may be optimized for automotive and transportation applications such as telemetry, infotainment, autonomous operation, and enhanced safety. The HMTC slice 1930 is typically configured to optimally handle non-mobile / fixed critical infrastructure applications such as smart factories and smart utilities.

[0047] FIG. 20 illustrates an exemplary layered 5G network slicing framework 2000, as described in the IMT-2020 recommendation. The framework includes a RAN 2005, a mobile packet core 2010, and cloud networking components 2015, which are logically represented in a network slice instance layer 2020 above a physical infrastructure layer 2025 within the framework. The physical infrastructure layer provides abstraction of radio, computing, network, and storage resources, which may include, for example, one or more RATs 2030, a mobile fronthaul (MFH) 2035, a mobile backhaul (MBH) 2040, a mobile core network 2045, transport 2050, and one or more data centers (DCs) 2055. In some cases, resources may be implemented as one or more UE instances.

[0048] In this illustrative example, the slice instance layer includes three 5G network slices: slice A 2060, slice B 2065, and slice C 2070; however, in any given implementation, more or fewer slices may be utilized at any given time. These slices may include one or more of the predefined slice types shown in FIG. 19 and described in the accompanying text, or may include different slice types. Slices may be separated by logical or physical separation of their underlying resources. Each slice may support instances of various applications and / or services (collectively, reference numeral 2075) in the service instance layer 2080, for example, using an application programming interface (API), as representatively indicated by reference numeral 2085. Each network slice may be viewed as an independent logical collection of resources whose per-slice configuration can be dynamically changed as needed to meet predefined technical characteristics (e.g., throughput, latency, reliability, etc.) and / or business characteristics required by the application / service instance.

[0049] The slice controller 2090, in conjunction with the slicing framework 2000, keeps aware of application requirements to responsively allocate and manage the virtualized network functions and resources within each slice. The service manager and orchestrator 2095 combines the required resources and functions to create a network slice instance. Its main tasks include creating slice instances on the underlying physical infrastructure, dynamically mapping network functions to slice instances to accommodate changing conditions, and maintaining communication between applications and services and the framework to manage the lifecycle of the slice.

[0050] As shown, a service level agreement (SLA) 2098 is generally applicable to each of slices 2060, 2065, and 2070. The applicable SLAs may vary in scope and configuration. A slice controller 2090 may be advantageously utilized to perform resource allocation among RAN slices in some cases to meet connectivity requirements while ensuring compliance with applicable SLA guarantees.

[0051] An SLA may be defined as a contract between a service provider and its internal or external end users or customers, which defines what services the provider will provide, the performance levels the provider must meet, and any remedies or penalties if the agreed-upon levels are not achieved. According to the ITU, an SLA is a formal agreement between two or more entities reached after negotiation activities designed to evaluate the service characteristics, responsibilities, and priorities of all parties. An SLA typically establishes customer expectations regarding the provider's performance and quality. Depending on the applicable environment and circumstances, this 5G RAN live migration and sharing typically can support various types of customers. For example, customers may include, but are not limited to, consumers, merchants, enterprises, organizations, service providers, and application developers. A 5G network operator may support its own services to customers as well as services from multiple different third-party providers. For example, one third-party provider may offer services to a customer on one network slice, while another third-party provider offers services on another network slice. Each individual service offering may have its own corresponding unique SLA.

[0052] The terms of an SLA may include metrics covering technical aspects of the service, such as describing the level and volume of communication services and measuring the performance characteristics of the provided services. Such technical metrics may include, but are not limited to, availability, throughput, latency, bit / packet error rate, and energy. The SLA may also include business, economic, and legal terms covering the agreement between the service provider and the customer. SLAs for various types of services and slices may vary. For example, some slice types may be more elastic with respect to RAN resource allocation, allowing resources to be easily adjusted according to resource demand. Other slice types may be less elastic. For example, a URLLC slice type may require strict resource allocation to guarantee reliability and low latency under the corresponding SLA, but enhanced MBS resources may be easily scaled down once edge cloud buffering is complete.

[0053] 21 illustrates an exemplary physical infrastructure in a 5G network 2100. Multiple instances of radio units (RUs) 2105 are configured to communicate over the air interface with a diverse population of UEs 1900. Each UE typically includes client-side software / firmware components configured to interface with one or more local applications 2110 or one or more remote application servers, service providers, or other resources (collectively designated by reference numeral 2115) and therefore require network connectivity with such remote facilities.

[0054] The RUs are coupled to the RAN 2120 via mobile fronthaul 2035. The RAN is coupled to one or more data centers (DCs) via mobile fronthaul 2040. In this illustrative example, the DCs comprise an edge DC 2125, a metro DC 2130, and a central DC 2135. In some networking literature, an edge DC may be referred to as a far-edge DC or an on-premises DC. A metro DC may be referred to as a near-edge DC, and a central DC may be referred to as a cloud. In some implementations, the edge DC may support a multi-access edge computing (MEC) function 2140. Application servers 2115 can be placed at various points in the network architecture 2100 to meet technical requirements and traffic demands. Typically, minimizing latency would result in the application servers being physically located closer to the UE 1900. However, an operator's application server location criteria may also take into account factors such as ease of management, scalability, and security, among others. Depending on the implementation, an operator may optionally deploy application servers and other resources in the RAN 2120 or RU 2105, as shown by the dashed circles in FIG.

[0055] Figure 22 shows functional blocks of the RAN 2120 and RU 2105. The RU comprises a radio transmission point, for example, a next-generation Node B (gNB 2205), which handles radio communications with the UE. The gNB is serially coupled to a radio frequency (RF) front end 2210, a digital-to-analog (D / A) conversion unit 2215, and a portion of the physical (PHY) layer 2220 functionality, as described in the OSI (Open Systems Interconnection) model.

[0056] Under 3GPP and the O-RAN (Open RAN) Alliance, the processing pipeline of the RAN 2120 is divided into a distributed unit (DU) 2225 and a central unit (CU) 2230. The DU is responsible for real-time Layer 1 and 2 (LI and L2) scheduling functions, while the CU is responsible for non-real-time higher L2 and L3 functions. Thus, the DU includes MAC (medium access control) layer components 2240, RLC (radio link control) layer components 2245, and a scheduler 2235 located above a portion of the PHY (physical) layer components 2220. The MAC layer components are responsible for buffering, multiplexing, and demultiplexing segments, including all real-time scheduling decisions regarding which segments are transmitted and when. Late transmission decisions (i.e., transmission decisions to alternate carrier frequencies, including Wi-Fi, for example) can also be made. The PHY layer components are responsible for coding and modulation.

[0057] The CU 2230 consists of PDCP (Packet Data Convergence Protocol) layer components 2250 and RRC (Radio Resource Control) layer components 2255. The PDCP layer components are responsible for IP (Internet Protocol) header compression and decompression, encryption and integrity protection, and early forwarding decisions (i.e., whether to send the packet down the pipeline to the UE or forward the packet to another base station). The RRC layer components are responsible for configuring the coarse-grained and policy-related aspects of the RAN processing pipeline. The RRC layer components interface with the control plane 2260, and the PDCP layer components interface with the user plane 2265, thereby implementing the 5G CUPS functionality (control plane and user plane separation).

[0058] The split RAN configuration shown in Figure 22 allows for the division of RAN functions between physical infrastructure elements at central and distributed locations. For example, as shown in Figure 23, a single CU 2230 may be configured to serve multiple DUs 2225, each of which in turn serves multiple RUs 2105.

[0059] Figure 24 shows that the RRC layer components 2255 may be decomposed into a mobile core-facing control plane forwarding component 2405 and a near real-time (RT) controller, the RAN Intelligent Controller (RIC) 2410. Thus, the RRC layer components are responsible only for near real-time configuration and control decisions, and the scheduler 2235 in the MAC component 2240 is responsible for real-time scheduling decisions.

[0060] Figure 25 illustrates an exemplary RAN Operations and Maintenance (OAM) logical architecture 2500 as described by the O-RAN Alliance. In this diagram, the O prefix indicates an O-RAN implementation for the functional elements of the architecture. The O-RAN Alliance defines and maintains the A1, E2, O1, O2, and Open Fronthaul interfaces described below. As shown, a non-RT RIC 2505 may be incorporated into the Service Manager and Orchestrator 2095. The non-RT RIC interoperates with the quasi-RT RIC 2410 via the A1 interface 2510.

[0061] The quasi-RT RIC 2410 is coupled to network functions for radio access control and optimization, including the O-CU-CP (O-RAN Central Unit Control Plane) 2520, the O-CU-UP (O-RAN Central Equipment User Plane) 2525, and the O-DU 2530, via an E2 interface 2515. As defined and maintained by 3GPP, the O-CU-CP and O-CU-UP are coupled to the O-DU via F1-c and F1-u interfaces 2540 and 2545, respectively. The O-CU-CP is coupled to the O-CU-UP via a 3GPP E1 interface 2550. The O-DU and O-RU 2535 are coupled using an open fronthaul interface 2555 (also known as the lower layer split (LLS) interface).

[0062] The O-Cloud 2560 is a cloud computing platform that includes a set of physical infrastructure nodes that meet O-RAN requirements for hosting relevant O-RAN functions (i.e., quasi-RT RIC, O-CU-CP, O-CU-UP, and O-DU), supporting software components (such as operating systems, virtual machine monitors, and container runtimes), and appropriate management and orchestration functions for creating virtual network instances and mapping network functions. The O-Cloud is coupled to the service manager and orchestrator 2095 via an O2 interface 2565. As shown in Figure 25, an O1 interface 2570 is provided for each of the quasi-RT RIC, O-CU-CP, O-CU-UP, O-DU, and O-RU.

[0063] Figure 26 is a block diagram of an example UE 1900 that may be used, at least in part, to implement this 5G RAN live migration and sharing. The embodiment of the UE 1900 shown in Figure 26 is for illustrative purposes only, and the UEs 1900 shown in the various figures and described in the preceding text may have the same or similar configurations. However, it should be noted that a UE may take on a wide variety of configurations, and Figure 26 does not limit the scope of the present disclosure to any particular implementation of a UE.

[0064] The UE 1900 includes an antenna 2610, a radio frequency (RF) transceiver 2615, transmit (TX) processing circuitry 2620, a microphone 2625, and receive (RX) processing circuitry 2630. The UE 1900 also includes a speaker 2635, a processor 2640, an input / output (I / O) interface 2645, an input device 2650, a display device 2655, and memory 2660. The memory includes an operating system (OS) program 2665 and one or more applications 2110.

[0065] The RF transceiver 2615 receives input RF signals transmitted by gNBs in the 5G network 2100 (FIG. 21) from the antenna 2610. The RF transceiver downconverts the input RF signals to generate intermediate frequency (IF) or baseband signals. The IF or baseband signals are transmitted to the RX processing circuitry 2630, which filters, decodes, and / or digitizes the baseband or IF signals to generate processed baseband signals. The RX processing circuitry transmits the processed baseband signals to a speaker 2635 (e.g., in the case of voice data) or to a processor 2640 for further processing (e.g., in the case of web browsing data).

[0066] The TX processing circuitry 2620 receives analog or digital voice data from a microphone 2625 or other outgoing baseband data (such as web data, email, or interactive video game data) from the processor 2640. The TX processing circuitry 2620 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate processed baseband or IF signals. The RF transceiver 2615 receives the processed outgoing baseband or IF signals from the TX processing circuitry and upconverts the baseband or IF signals to RF signals that are transmitted by the antenna.

[0067] The processor 2640 may comprise one or more processors or other processing devices and may execute an OS program 2665 stored in the memory 2660 to control the overall operation of the UE 1900. For example, the processor may control the reception of forward channel signals and the transmission of reverse channel signals by the RF transceiver 2615, the RX processing circuit 2630, and the TX processing circuit 2620 in accordance with well-known principles. In some embodiments, the processor 2640 comprises at least one microprocessor or microcontroller. The processor 2640 may be configured to execute other processes and programs resident in the memory 2660, such as operations for measuring and reporting CSI in systems described in embodiments of the present disclosure. The processor may transfer data to and from the memory as required by the executing processes. In some embodiments, the processor may be configured to execute the application 2110 based on the OS program 2665 or in response to signals received from the gNB or the operator. The processor is also coupled to an I / O interface 2645, which enables the UE 1900 to connect to other computing devices, such as laptop computers, handheld computers, etc. The I / O interface may thus serve as a communication pathway between such accessories and the processor.

[0068] The processor 2640 is also coupled to an input device 2650 (e.g., a keypad, touch screen, buttons, etc.) and a display device 2655. A user of the UE 1900 may typically utilize the input device to input data into the UE. For example, the display device may be a liquid crystal display or other display device capable of rendering text and / or graphics, video, etc. from websites, applications, and / or service providers. The memory 2660 is coupled to the processor 2640. A portion of the memory may include random access memory (RAM), and another portion of the memory may include flash memory or other read-only memory (ROM).

[0069] As described in more detail below, the UE 1900 can perform signaling and calculations for channel state information (CSI) reporting. While FIG. 26 illustrates one illustrative example of a UE 1900, it will be appreciated that various modifications to this diagram may be made. For example, various components may be combined, further subdivided, or omitted, and additional components may be added according to particular needs. As a specific example, the processor 2640 may be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). Similarly, although FIG. 26 illustrates the UE 1900 as configured as a mobile device such as a smartphone, the UE may be configured to operate as other types of portable or fixed devices.

[0070] Figure 27 illustrates an example architecture 2700 of a computing device, such as a server, capable of executing various components described herein for this 5G RAN live migration and sharing. The architecture 2700 illustrated in Figure 27 includes one or more processors 2702 (e.g., a central processing unit, a dedicated AI chip, a graphics processing unit, etc.), a system memory 2704 including RAM (random access memory) 2706 and ROM (read-only memory) 2708, and a system bus 2710 that operatively couples the components in the architecture 2700 for proper operation. A basic input / output system, containing basic routines that help transfer information between elements in the architecture 2700, such as during startup, is typically stored in ROM 2708. The architecture 2700 further includes mass storage 2712 for storing software code or other computer-executable code used to implement applications, a file system, and an operating system. Mass storage device 2712 is connected to processor 2702 via a mass storage controller (not shown) connected to bus 2710. Mass storage device 2712 and its associated computer-readable storage media provide non-volatile storage for architecture 2700. While descriptions of computer-readable storage media contained herein refer to mass storage devices such as hard disks or CD-ROM drives, those skilled in the art will appreciate that computer-readable storage media can be any available storage media that can be accessed by architecture 2700.

[0071] By way of example, and without limitation, computer-readable storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. For example, computer-readable storage media includes, but is not limited to, RAM, ROM, EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), Flash memory or other solid-state storage technology, CD-ROM, DVD, HD-DVD (High Definition DVD), Blu-ray or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices, or any other medium that can be used to store the required information and that can be accessed by architecture 2700.

[0072] According to various embodiments, architecture 2700 may operate in a networked environment using logical connections to remote computers over a network. Architecture 2700 may connect to the network via a network interface unit 2716 connected to bus 2710. It will be appreciated that network interface unit 2716 may also be used to connect to other types of networks and remote computer systems. Architecture 2700 may also include an input / output controller 2718 for receiving and processing input from several other devices, including a keyboard, a mouse, a touchpad, a touchscreen, controls such as buttons or switches, or an electronic stylus (not shown in FIG. 27 ). Similarly, input / output controller 2718 may provide output to a display screen, a user interface, a printer, or other type of output device (also not shown in FIG. 27 ).

[0073] It will be appreciated that the software components described herein, when loaded and executed on the processor 2702, may transform the processor 2702 and the overall architecture 2700 from a general-purpose computing system into a special-purpose computing system customized to facilitate the functions presented herein. The processor 2702 may be comprised of any number of transistors or other discrete circuit elements, which may individually or collectively assume any number of states. More specifically, the processor 2702 may operate as a finite state machine in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions may transform the processor 2702 by specifying how the processor 2702 transitions between states, thereby transforming the transistors or other discrete hardware elements that make up the processor 2702.

[0074] Encoding the software modules presented herein may also transform the physical structure of the computer-readable storage medium presented herein. The specific transformation of the physical structure may depend on various factors in various implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the computer-readable storage medium, whether the computer-readable storage medium is characterized as a primary storage device, a secondary storage device, or the like. For example, if the computer-readable storage medium is implemented as a semiconductor-based memory, the software disclosed herein may be encoded on the computer-readable storage medium by transforming the physical state of the semiconductor memory. For example, the software may transform the state of transistors, capacitors, or other discrete circuit elements that make up the semiconductor memory. The software may also transform the physical state of such components to store data therein.

[0075] As another example, the computer-readable storage media disclosed herein may be implemented using magnetic or optical technology. In such implementations, the software presented herein may transform the physical state of the magnetic or optical media when the software is encoded therein. These transformations may include altering the magnetic properties of specific locations within a given magnetic medium. These transformations may also include altering the physical features or characteristics of specific locations within a given optical medium to change the optical characteristics of those locations. Other transformations of physical media are possible without departing from the scope and spirit of this specification, and the foregoing examples are presented solely to facilitate this discussion.

[0076] In light of the above, it will be appreciated that numerous types of physical transformations occur in architecture 2700 to store and execute the software components presented herein. It will also be appreciated that architecture 2700 may comprise other types of computing devices, including wearable devices, handheld computers, embedded computer systems, smartphones, PDAs, and other types of computing devices known to those skilled in the art. It is also contemplated that architecture 2700 may not include all of the components shown in FIG. 27, may include other components not explicitly shown in FIG. 27, or may utilize an entirely different architecture than that shown in FIG. 27.

[0077] FIG. 28 is a high-level block diagram of an exemplary data center 2800 providing cloud or distributed computing services that may be used to implement this 5G RAN live migration and sharing. The data center 2800 may incorporate one or more of the features disclosed in the DC illustrated in the figures and described in the accompanying text. Multiple servers 2801 are managed by a data center management controller 2802. A load balancer 2803 distributes requests and computing workloads across the servers 2801 to avoid situations where a single server may become overloaded. The load balancer 2803 maximizes the available capacity and performance of resources in the data center 2800. Router / switch 2804 supports data traffic between each server 2801 and between data center 2800 and external resources and users (not shown) via external network 2805, which may be, for example, a local area network (LAN) or the Internet.

[0078] Servers 2801 may be standalone computing devices and / or configured as individual blades within a rack of one or more server devices. Servers 2801 have input / output (I / O) connectors 2806 that manage communication with other database entities. One or more host processors 2807 on each server 2801 execute a host operating system (O / S) 2808 that supports multiple virtual machines (VMs) 2809. Each VM 2809 may execute its own O / S; therefore, each VM O / S 2810 on a server may be different, the same, or a combination of both. VM O / S 2810 may, for example, be different versions of the same O / S (e.g., different VMs running various current and legacy versions of the Windows® operating system). Additionally or alternatively, the VM O / S 2810 may be provided by different manufacturers (e.g., some VMs may run the Windows® operating system, while others may run the Linux® operating system). Each VM 2809 may also run one or more applications (Apps) 2811. Each server 2801 also includes storage 2812 (e.g., a hard disk drive (HDD)) and memory 2813 (e.g., RAM) that the host processor 2807 and VMs 2809 can access and use to store software code, data, etc. In one embodiment, the VMs 2809 may utilize the data plane API disclosed herein.

[0079] Data center 2800 provides pooled resources that allow customers or tenants to dynamically provision and scale applications as needed without adding servers or additional networking. This allows tenants to get the computing resources they need without having to procure, provision, and manage infrastructure ad hoc for each application. Cloud computing data center 2800 allows tenants to dynamically scale resources up or down to meet the current demands of their business. Additionally, data center operators can offer usage-based services to tenants, so that tenants pay only for the resources they use, when they need them. For example, a tenant may initially use one VM 2809 on server 28011 to run its application 2811. As demand for application 2811 increases, data center 2800 can scale the resources on the same server 28011 and / or on new servers 2801 as needed. N Additional VMs 2809 may be activated at that time. Later, if demand for the application subsides, these additional VMs 2809 can be deactivated.

[0080] Data center 2800 may provide guaranteed availability, disaster recovery, and backup services. For example, the data center may designate one VM 2809 on server 28011 as the primary location for a tenant's applications, and if the first VM or server 28011 fails, a second VM 2809 on the same or another server may be activated as a standby or backup. Data center management controller 2802 automatically switches incoming user requests from the primary VM to the backup VM without requiring tenant intervention. While data center 2800 is shown as a single location, it will be understood that server 2801 may be distributed across multiple locations around the globe to provide additional redundancy and disaster recovery capabilities. Furthermore, data center 2800 may be an on-premise private system serving a single enterprise user, or a publicly accessible distributed system serving multiple unrelated customers and tenants, or a combination of both.

[0081] Domain Name System (DNS) server 2814 resolves domain names and host names to IP addresses for all roles, applications, and services in data center 2800. DNS log 2815 keeps a record of which domain names have been resolved for each role. It will be understood that DNS is used herein as an example, and other name resolution services and domain name logging services may be used to identify dependencies, such as IP or packet sniffing, code instrumentation, or code tracing in other embodiments.

[0082] Data center health monitoring 2816 monitors the health of the physical systems, software, and environment within data center 2800. Health monitoring 2816 provides feedback to data center administrators when problems are detected with servers, blades, processors, or applications within data center 2800, or when network bandwidth or communication issues occur.

[0083] Access control service 2817 determines whether a user may access specific connections and services offered at data center 2800. Directory and identity management service 2818 authenticates user credentials for tenants on data center 2800.

[0084] FIG. 29 is a simplified block diagram of an exemplary computer system 2900, such as a PC, client machine, or server, that may implement this 5G RAN live migration and sharing. The computer system 2900 includes a processor 2905, a system memory 2911, and a system bus 2914 that couples various system components, including the system memory 2911, to the processor 2905. The system bus 2914 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, or a local bus using any of a variety of bus architectures. The system memory 2911 includes a read-only memory (ROM) 2917 and a random access memory (RAM) 2921. A basic input / output system (BIOS) 2925, containing the basic routines that help to transfer information between elements within the computer system 2900, such as during start-up, is stored in the ROM 2917. Computer system 2900 may further include a hard disk drive 2928 for reading from and writing to an internally located hard disk (not shown), a magnetic disk drive 2930 for reading from and writing to a removable magnetic disk 2933 (e.g., a floppy disk), and an optical disk drive 2938 for reading from and writing to a removable optical disk 2943, such as a CD (compact disk), DVD (digital versatile disk), or other optical media. Hard disk drive 2928, magnetic disk drive 2930, and optical disk drive 2938 are connected to system bus 2914 by a hard disk drive interface 2946, a magnetic disk drive interface 2949, and an optical drive interface 2952, respectively. The drives and their associated computer-readable storage media provide nonvolatile storage of computer-readable instructions, data structures, program modules, and other data for computer system 2900 .Although this illustrative example includes a hard disk, a removable magnetic disk 2933, and a removable optical disk 2943, other types of computer-readable storage media capable of storing computer-accessible data, such as magnetic cassettes, flash memory cards, digital video disks, data cartridges, random access memory (RAM), read-only memory (ROM), etc., may also be used depending on the intended use of this 5G RAN live migration and sharing. Furthermore, as used herein, the term computer-readable storage medium includes one or more instances of a media type (e.g., one or more magnetic disks, one or more CDs, etc.). For purposes of this specification and claims, the phrase "computer-readable storage medium" and variations thereof are intended to cover persistent embodiments and do not include waves, signals, and / or other transitory and / or intangible communication media.

[0085] The hard disk, magnetic disk 2933, optical disk 2943, ROM 2917, or RAM 2921 may store a number of program modules, including an operating system 2955, one or more application programs 2957, other program modules 2960, and program data 2963. A user may enter commands and information into the computer system 2900 through input devices such as a keyboard 2966 and a pointing device 2968, such as a mouse. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, trackball, touchpad, touch screen, touch-sensitive device, voice command module or device, user motion or gesture capture device, etc. These other input devices are often connected to the processor 2905 through a serial port interface 2971 coupled to the system bus 2914, but may also be connected by other interfaces, such as a parallel port, game port, or universal serial bus (USB). A monitor 2973 or other type of display device is also connected to the system bus 2914 via an interface, such as a video adapter 2975. In addition to the monitor 2973, personal computers typically include other peripheral output devices (not shown), such as speakers and printers. The illustrative example shown in Figure 29 also includes a host adapter 2978, a small computer system interface (SCSI) bus 2983, and an external storage device 2976 connected to the SCSI bus 2983.

[0086] Computer system 2900 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer 2988. The remote computer 2988 may be selected as another personal computer, a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements previously described in connection with computer system 2900, although only a single representative remote memory / storage device 2990 is illustrated in FIG. 29. The logical connections depicted in FIG. 29 include a local area network (LAN) 2993 and a wide area network (WAN) 2995. Such networking environments are often found in, for example, offices, enterprise-wide computer networks, intranets, and the Internet. When used in a LAN networking environment, computer system 2900 is connected to the local area network 2993 through a network interface or adapter 2996. When used in a WAN networking environment, the computer system 2900 typically includes a broadband modem 2998, a network gateway, or other means for establishing communications over the wide area network 2995, such as the Internet. The broadband modem 2998, which may be internal or external, is connected to the system bus 2914 via a serial port interface 2971. In a networked environment, program modules associated with the computer system 2900, or portions thereof, may be stored in a remote memory storage device 2990. It should be noted that the network connections shown in FIG. 29 are exemplary, and other means of establishing a communications link between the computers may be used depending on the specific requirements of this 5G RAN live migration and sharing application.

[0087] Various exemplary embodiments of this 5G RAN live migration and sharing are presented below as examples and not as an exhaustive list of all embodiments. An example includes a computer-implemented method for live migration of a radio access network (RAN), comprising: hosting a virtual source distributed unit (DU) on a first server, the source DU communicating with traffic from a population of user equipments (UEs); hosting a virtual destination distributed unit (DU) on a second server; operating an intelligent controller operable to receive telemetry data describing traffic load on the source DU and to create fronthaul packet forwarding rules in response to the telemetry data; operating an IQ (in-phase and quadrature) multiplexer to receive the forwarding rules from the intelligent controller; and using the IQ multiplexer to multiplex IQ samples in fronthaul packets between the source DU and a radio unit (RU) based on the received forwarding rules to handover UE traffic from the source DU to the destination DU.

[0088] In another example, the telemetry data further describes the state of one or more UEs in the population. In another example, the forwarding rules are based on the cell configuration of the source DU and the destination DU, respectively. In another example, the forwarding rules are based on the allocation of physical radio resources. In another example, the IQ multiplexer is implemented using one of a programmable switch or a software switch. In another example, the IQ multiplexer is implemented using software instantiated along with a virtualized DU or a virtualized central unit (CU). In another example, the forwarding rules implement dynamic modification of slot allocation based on traffic load at the source DU and the destination DU.

[0089] A further example comprises one or more hardware-based persistent computer-readable memory devices storing computer-executable instructions that, when executed by one or more processors disposed in a computing device deployed in a 5G (fifth generation) network having a fronthaul between a single radio unit (RU) and multiple distributed units (DUs), cause the computing device to instantiate an intelligent controller to allocate physical radio resources to packets in the fronthaul, the physical radio resources being partitioned into segments including respective subcarriers and time slots, where a subcarrier uses a width of bandwidth and a time slot uses a length of time; configure the intelligent controller to receive telemetry data from multiple DUs; generate forwarding rules in response to the telemetry data to implement the radio resource allocation; and instantiate an IQ multiplexer in response to the forwarding rules generated by the intelligent controller, the IQ multiplexer configured to multiplex IQ (in-phase and quadrature) samples in the packets, so that the multiple DUs share a single RU according to the allocation.

[0090] In another example, the packet comprises an xRAN packet. In another example, the intelligent controller is instantiated in a RAN (Radio Access Network) Intelligent Controller (RIC). In another example, the physical radio resources are partitioned into segments defined by a numerology, which refers to values ​​of physical transmission parameters that define the air interface between a single RU and a user equipment (UE).

[0091] A further example includes a radio access network (RAN) comprising: a first distributed device (DU) in operative communication with a radio unit (RU) over a fronthaul network; a second DU in operative communication with the RU over the fronthaul network; an intelligent controller configured with control hooks to the first and second DUs, the intelligent controller configured to receive telemetry data indicative of respective data traffic loads on the first and second DUs, the intelligent controller further configured to generate forwarding rules for packets carried on the fronthaul network; and an IQ (in-phase and quadrature) multiplexer configured to receive the forwarding rules from the intelligent controller, the IQ multiplexer further configured in each of the first and second DUs to multiplex IQ samples within packets carried on the fronthaul network to the RU.

[0092] In another example, the RAN is utilized in a fifth-generation (5G) mobile network. In another example, the RAN is utilized in a fourth-generation long-term evolution (4G LTE) mobile network. In another example, data traffic is carried over an air interface of the RAN between the RAN and user equipment (UE). In another example, the intelligent controller supports at least one network function configured to schedule physical radio resources in the RAN, the physical radio resources being represented by subcarriers and time slots. In another example, the intelligent controller and IQ multiplexer operate to implement a single RU and its associated radio frequency (RF) spectrum to be shared among multiple different DUs. In another example, the intelligent controller and IQ multiplexer operate to handover user equipment (UE) traffic from a first DU to a second DU. In another example, the RAN is implemented virtually using a cloud computing infrastructure. In another example, the cloud computing infrastructure includes one of an edge, near edge, or far edge cloud computing platform.

[0093] Although the subject matter has been described in terms specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

[0094] Appendix: Acronyms 5G: Fifth Generation RAN: Radio Access Network RF: Radio Frequency O-RAN: Open RAN RU: Radio equipment DU: Distributed device CU: Central unit RLC: Radio Link Control IQ: In-phase and quadrature UE: User Equipment UL: Uplink DL: Downlink MO: Mobile Operator NR:New Radio OAM: Operation and Maintenance OFDM: Orthogonal Frequency Division Multiplexing O-RU: Open RU O-DU: Open DU O-CU: Open CU U-Plane: User Plane C-Plane: Control plane ETSI: European Telecommunications Standards Institute IMT: International Mobile Telecommunications ITU: International Telecommunication Union RAT: Radio Access Technology RT: Real-time RRC: Radio Resource Control RIC:RAN Intelligent Controller PTP: Precision Time Protocol MIB: Master Information Block SIB: System Information Block PCI: Physical Cell Identifier HARQ: Hybrid Automatic Repeat Request MIMO: Multiple Input Multiple Output MORAN: Multi-operator Radio Access Network MOCN: Multi-Operator Core Network PSS: Primary Sync Schedule SSS: Secondary Sync Schedule PBCH: Physical Broadcast Channel DMRS: Demodulation Reference Signal PDCCH: Physical Downlink Control Channel PDSCH: Physical Downlink Shared Channel CSI-RS: Channel State Information Reference Signal SSB: Synchronization signal block ASIC: Application Specific Integrated Circuit TOR: Top of the Rack PHY: Physical MAC: Medium Access Control DCI: Downlink Control Information PT-RS: Phase tracking reference signal FR: Frequency Range PRACH: Physical Random Access Channel PUCCH: Physical uplink control channel UCI: Uplink Control Information PUSCH: Physical Uplink Shared Channel SRS: Sounding Reference Signal NFV: Network Functions Virtualization SDN: Software-Defined Networking CN: Core Network MBB: Mobile Broadband URLLC: Highly reliable and low latency communication MMTC: Massive Machine Type Communication IoT: Internet of Things MIoT: Massive Internet of Things 3D: Three-dimensional UHD: Ultra high definition AI: Artificial intelligence QoS: Quality of Service SLA: Service Level Agreement VPN: Virtual Private Network SST: Slice / Service Type eMBB: High-speed, high-capacity mobile broadband V2X: vehicle-to-everything HMTC: High Performance Machine Type Communications NSSAI: Network Slice Selection Assistance Information SM: Session Management SD: slice identifier MFH: Mobile Fronthaul AR: Augmented Reality VR: Virtual Reality MBH: Mobile Backhaul API: Application Programming Interface DC: Data Center MEC: Multi-Access Edge Computing D / A: Digital-to-Analog IP: Internet Protocol PDCP: Packet Data Convergence Protocol RRC: Radio Resource Control CUPS: Separation of Control Plane and User Plane TX: Send RX: Receive LAN: Local Area Network VM: Virtual Machine DNS: Domain Name Server WAN: Wide Area Network

Claims

1. 1. A computer-implemented method for live migration of a radio access network (RAN), comprising: Hosting a virtual source distributed unit (DU) on a first server, the source DU communicating traffic from a population of user equipments (UEs); hosting a virtual destination distributed unit (DU) on a second server; operating an intelligent controller operable to receive telemetry data describing traffic load on said source DU and to create fronthaul packet forwarding rules in response to said telemetry data; operating an IQ (in-phase and quadrature) multiplexer to receive the transfer rule from the intelligent controller; using the IQ multiplexer to multiplex IQ samples in a fronthaul packet between the source DU and a radio unit (RU) based on the received forwarding rule to hand over the UE traffic from the source DU to the destination DU; 11. A computer-implemented method comprising:

2. The computer-implemented method of claim 1 , wherein the telemetry data further describes the state of one or more UEs in the population.

3. The computer-implemented method of claim 1 , wherein the forwarding rule is based on the cell configurations of the source DU and the destination DU, respectively.

4. The computer-implemented method of claim 1 , wherein the forwarding rules are based on physical radio resource allocation.

5. 10. The computer-implemented method of claim 1, wherein the IQ multiplexer is implemented using one of a programmable switch or a software switch.

6. The computer-implemented method of claim 1 , wherein the IQ multiplexer is implemented using software instantiated along with a virtualized DU or a virtualized central unit (CU).

7. The computer-implemented method of claim 1 , wherein the forwarding rules implement dynamically modifying slot allocation based on traffic load at the source DU and the destination DU.

8. One or more hardware-based computer-readable memory devices storing computer-executable instructions, which when executed by one or more processors located in a computing device deployed in a 5G (fifth generation) network having a fronthaul between a single radio unit (RU) and multiple distributed units (DUs), cause the computing device to: instantiating an intelligent controller to allocate physical radio resources to packets in the fronthaul, the physical radio resources being partitioned into segments comprising respective subcarriers and time slots, where the subcarriers occupy a width of bandwidth and the time slots occupy a length of time; configuring the intelligent controller to receive telemetry data from the plurality of DUs; and generating forwarding rules in response to the telemetry data to implement the radio resource allocation; instantiating an IQ multiplexer configured to multiplex IQ (in-phase and quadrature) samples in the packet in response to the forwarding rule generated by the intelligent controller, so that the multiple DUs share the single RU in accordance with the allocation; One or more hardware-based computer-readable memory devices.

9. 10. The one or more hardware-based computer-readable memory devices of claim 8, wherein the packets comprise xRAN packets.

10. 9. The one or more hardware-based computer-readable memory devices of claim 8, wherein the intelligent controller is instantiated in a RIC (RAN (Radio Access Network) Intelligent Controller).

11. 10. The one or more hardware-based computer-readable memory devices of claim 8, wherein the physical radio resources are partitioned into segments defined by a numerology, the numerology referring to values ​​of physical transmission parameters that define an air interface between the single RU and a user equipment (UE).

12. a first distributed device (DU) in operative communication with a radio unit (RU) over a fronthaul network; a second DU in operative communication with the RU via a fronthaul network; an intelligent controller configured with a control hook to the first and second DUs, the intelligent controller configured to receive telemetry data indicative of respective loads of data traffic on the first and second DUs, the intelligent controller further configured to generate forwarding rules for packets carried on the fronthaul network; an IQ (in-phase and quadrature) multiplexer configured to receive the forwarding rule from the intelligent controller, the IQ multiplexer further configured to multiplex IQ samples in the packets to be transported to the RU over the fronthaul network in each of the first and second DUs; A radio access network (RAN) comprising:

13. 13. The RAN of claim 12, wherein the intelligent controller supports at least one network function configured to schedule physical radio resources in the RAN, the physical radio resources being represented by subcarriers and time slots.

14. 13. The RAN of claim 12, wherein the intelligent controller and IQ multiplexer operate to implement a single RU and its associated RF (radio frequency) spectrum that can be shared among multiple different DUs.

15. 13. The RAN of claim 12, wherein the intelligent controller and IQ multiplexer operate to hand over traffic of a UE (User Equipment) from the first DU to the second DU.

Images