Common CU-up architecture for a radio access network

Abstract

Described are systems, apparatuses and methods for a One-Centralized-Unit-User-Plane (One-CU-UP) deployed in a same 4G and 5G Cloud Network Function (CNF) configured to support a Long Term Evolution (LTE) eNB CU-UP and a New Radio (NR) gNB CU-UP.

Description

COMMON CU-UP ARCHITECTURE FOR A RADIO ACCESS NETWORK

[0001] DESCRIPTION OF THE RELATED TECHNOLOGY

[0002] a. Field of the Disclosure

[0003] The present disclosure relates to systems and methods for radio access networks. The present disclosure is related to the design, operation, administration and management of various network elements of 4G, 5G, and further generations of a radio access network system.

[0004] SUMMARY OF THE DISCLOSURE

[0005] Described are implementations of a computer system, computer system components, computer apparatus, a method, and computer program products configured to execute program instructions for the method for radio access network, and operation, administration and management of various network elements of 4G, 5G, and further generations of the radio access network system. The method is performed by a computer system that comprises one or more processors and a computer-readable storage medium encoded with instructions executable by at least one of the processors and operatively coupled to at least one of the processors.

[0006] In an implementation, an apparatus comprises: an apparatus for RAN comprising: a One-Centralized-Unit-User-Plane (One-CU-UP) deployed in a same 4G and 5G Cloud Network Function (CNF) configured to support a Long Term Evolution (LTE) eNB CU-UP and a New Radio (NR) gNB CU-UP. The One-CU-UP can be further configured to support an NR Dual Connectivity (NR-DC) gNB-CU-CP CNF, an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) -NR Dual Connectivity (EN-DC) CU-CP-CNF, or a LTE CU-CP-CNF, or any combination thereof. The One-CU-UP can further comprise: a plurality of interfaces, the interfaces including E1, W1-U, F1-U, S1-U, X2, and NG-U. The One-CU-UP can be configured to support Data Radio  Bearer (DRB) Packet Data Convergence Protocol (PDCP) Secondary Node (SN) lengths and NR PDCP SN lengths.

[0007] The One-CU-UP can comprise: a 4G CU-CNF configured to handle 4G dedicated functions; and a 5G-CU-CNF configured to handle 5G dedicated functions. The One-CU-UP can comprise: the 5G-CU-CNF including a Service Data Adaptation Protocol (SDAP) module; and the 4G CU-CNF.

[0008] The One-CU-UP can be configured to comprise a plurality of LTE cells and a plurality of NR cells. The One-CU-UP can be configured to comprise a fast path virtual CPU (vCPU) configured with a maximum throughput for the plurality of LTE cells and the plurality of NR cells. The One-CU-UP can be configured to comprise horizontal scaling with a plurality of data path worker threads, a plurality of data path pods, or both. The One-CU-UP can further comprise an internal data buffer including an internal X2 / Xn-U interface. The One-CU-UP can be configured to process 4G data packets and 5G data packets for a single user on a single data path worker thread of the plurality of data path worker threads.

[0009] The One-CU-UP can comprise a Master Node (MN) PDCP entity and a SN PDCP entity in a same node. The One-CU-UP can be configured to handle a LTE bearer and a Non-Standalone Architecture (NSA) bearer in a same node. The One-CU-UP can be configured to use a Downlink (DL) User Equipment (UE) Aggregate Maximum Bit Rate (AMBR) for both the LTE bearer and a NSA bearer simultaneously. The One-CU-UP can be configured for dynamic resource allocation with LTE GBR preemption.

[0010] An implementation disclosed is a method comprising: sending by a Master Node (MN) , a UE addition request or UE release request to a Secondary Node (SN) ; establishing a Random Access Procedure between the SN and the User Equipment (UE) ; implementing data forwarding in One-Centralized-Unit-User-Plane (One-CU-UP) comprising an internal data buffer including a Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) for both the MN and the SN  and deployed in a same 4G and 5G Cloud Network Function (CNF) configured to support an Long Terme Evolution (LTE) eNB CU-UP and a New Radio (NR) gNB CU-UP; and implementing a path update procedure for processing both 4G and 5G data packets for the UE over a single data-path worker thread.

[0011] Where the MN is an eNB, the SN is a gNB, and the path update procedure comprises a Protocol Data Unit (PDU) session from the MN to an Access Mobility Function (AMF) . The method can further comprise sending a PDU Session modification indication to the AMF from the MN; and after the AMF sends a Bearer Modification to a User Plane Function (UPF) , receiving a User Plane Function (UPF) Session Modify Confirmation from the AMF at the MN.

[0012] Where the MN is an eNB, the SN is a gNB, and the path update procedure comprises a session from the MN to a Mobility Management Entity (MME) , the method can further comprise: the path update procedure comprising sending an E-UTRAN Radio Access Bearer (E-RAB) Modification Indication from the MN to an MME; and after the MME sends a Bearer Modification to a Serving Gateway (S-GW) ; receiving an Evolved Universal Terrestrial Radio Access Network Radio Access Bearer (E-RAB) Modification Confirmation from the MME at the MN.

[0013] Where the MN is an eNB, the SN is a gNB, and the path update procedure comprises a Protocol Data Unit (PDU) session from the MN to and AMF. The method can further comprise: sending a SN Release Request to the SN from the MN; and after the Path Update procedure, sending a UE Context Release from the MN to the SN.

[0014] Where the MN is an eNB, the SN is a gNB, and the path update procedure comprises a Protocol Data Unit (PDU) session from the MN to a Mobility Management Entity (MME) , the method can further comprises: sending a SN Release Request to the SN from the MN; and after the Path Update procedure, sending a UE Context Release from the MN to the SN.BRIEF DESCRIPTION OF THE DRAWINGS

[0015] FIG. 1 is a block diagram of a system architecture.

[0016] FIG. 2 shows an example of a User Plane Stack.

[0017] FIG. 3 shows an example of a Control Plane Stack.

[0018] FIG. 4A shows an example of high-level NG-RAN including a gNB CU and DU.

[0019] FIG. 4B shows an example of a Separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) in a 5G gNB.

[0020] FIG. 4C shows an example of a Separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) in a 4G ng-eNB.

[0021] FIG. 5 shows a DL (Downlink) Layer 2 Structure.

[0022] FIG. 6 shows an exemplary logical flow for implementing an RB allocation policy.

[0023] FIG. 7 shows an L2 Data Flow example.

[0024] FIG. 8A shows an example of an O-RAN architecture.

[0025] FIG. 8B shows an example of an O-RAN OAM architecture.

[0026] FIG. 9A illustrates a PDU Session architecture comprising of multiple DRBs and multiple QoS Flows.

[0027] FIG. 9B illustrates a flow for PDU sessions, DRBs and GTP-U Tunnels across CU and DU.

[0028] FIG. 9C illustrates a CU and DU view on PDU session, DRBs and GTP-U tunnels for a 5G network architecture.

[0029] FIG. 10 shows a Resource Allocation MAC Scheduler, DL Data, and Flow Control Feedback for 5G Network.

[0030] FIG. 11A is an EN-DC architecture.

[0031] FIG. 11B is a NG-RAN architecture.

[0032] FIG. 12A illustrates a Non-Standalone NSA architecture and logical flow.

[0033] FIG. 12B illustrates a Non-Standalone NSA architecture and logical flow.

[0034] FIG. 13 illustrates a One CU-UP network architecture.

[0035] FIG. 14A illustrates a One CU-UP.

[0036] FIG. 14B illustrates LTE a NR in a One CU-UP as opposed to a CU-UP separated between LTE and NR.

[0037] FIG. 15A illustrates a flow in an NSA setup for ng-eNB and gNB connecting to 5G Core.

[0038] FIG. 15B illustrates a flow in an NSA release procedure for eNB (MN) and gNB connecting to a 4G EPC.

[0039] FIG. 16 illustrates a One-CU-UP 170 internal data buffer.

[0040] FIG. 17A illustrates a flow in an NSA release procedure for ng-eNB and gNB connecting to 5G Core.

[0041] FIG. 17B illustrates a flow in an NSA setup for ng-eNB and gNB connecting to a 4G EPC.

[0042] FIG. 18A illustrates a split DL UE AMBR configured at a 4G EPC and distributed at eNB and en-gNB.

[0043] FIG 18B illustrates a split DL UE AMBR targeted at a 4G EPC and a 5GC.

[0044] FIG. 19 illustrates a split DL UE AMBR targeted at a eNB and en-gNB of a 4G EPC.

[0045] FIG. 20 shows an exemplary dynamic resource allocation in a One-CU-UP for both LTE and NR.

[0046] DETAILED DESCRIPTION OF THE DISCLOSURE

[0047] Reference is made to Third Generation Partnership Project (3GPP) and the Internet Engineering Task Force (IETF) and related standards bodies in accordance with embodiments of the present disclosure. The present disclosure employs abbreviations, terms and technology defined in accord with Third Generation Partnership Project (3GPP) and / or Internet Engineering Task Force (IETF) technology standards and papers, including the following standards and definitions. 3GPP and IETF technical specifications (TS) , standards (including proposed standards) , technical reports (TR) and other papers are incorporated by reference in their entirety hereby, define the related terms and architecture reference models that follow.

[0048] O-RAN. WG4. MP. 0-R003-v13.00

[0049] 3GPP TS 23.203 V 17.2.0 2021-12-23

[0050] 3GPP TS 23.501 V 18.1.0 2023-04-05

[0051] 3GPP TS 38.300 V 17.4.0 03-28-2023

[0052] 3GPP TS 36.321 V 17.4.0 2023-03-29

[0053] 3GPP TS 36.323 V 17.2.0 2023-01-13

[0054] 3GPP TS 38.321 V 17.4.0 2023-03-29

[0055] 3GPP TS 38.401 V 17.4.0 2023-04-03

[0056] 3GPP TS 38.501 V 18.1.0 2023-04-05

[0057] 3GPP TS 38.425 17.3.0, 2023-04-03

[0058] Acronyms

[0059] 3GPP: Third generation partnership project

[0060] 5GC: 5G Core Network

[0061] 5G NR: 5G New Radio

[0062] 5QI: 5G QoS Identifier

[0063] ACK: Acknowledgement

[0064] ACLR: Gain and Adjacent Channel Leakage Ratio

[0065] ADC: Analog-to-Digital Converter

[0066] AM: Acknowledged Mode

[0067] AMF: Access Mobility Function

[0068] AMBR: Aggregate Maximum Bit Rate

[0069] APN: Access Point Name

[0070] ARP: Allocation and Retention Priority

[0071] ASIC: Application Specific Integrated Circuit

[0072] AWGN: Additive White Gaussian Noise

[0073] BFW: Beamforming weight

[0074] BS: Base Station

[0075] CNF: Cloud-Native Network Function

[0076] CP: Control Plane

[0077] C-RAN: cloud radio access network

[0078] CU: Centralized unit

[0079] CU-CP: Centralized Unit –Control Plane

[0080] CU-UP: Centralized Unit –User Plane

[0081] CQI: Channel Quality Indicator

[0082] DAC: Digital-to-Analog Converter

[0083] DC: Dual Connectivity

[0084] DCI: Downlink Control Information

[0085] DDDS: DL Data Delivery Status

[0086] DFE: Digital Front End

[0087] DL: Downlink

[0088] DMRS: Demodulation Reference Signal

[0089] DNN: Data Network Name

[0090] DRB: Data Radio Bearer

[0091] DU: Distributed unit

[0092] eNB: evolved Node B

[0093] eMBB: Enhanced Mobile Broadband

[0094] EPC: Evolved Packet Core

[0095] EN-DC

[0096] EP: Endpoint Pod

[0097] E-UTRAN: Evolved Universal Terrestrial Radio Access Network

[0098] E-RAB: E-UTRAN Radio Access Bearer

[0099] IoT: Internet of Things

[0100] IP: Internet Protocol

[0101] IWF: Interworking Function

[0102] GBR: Guaranteed Bit Rate

[0103] gNB: gNodeB (5G base station)

[0104] GTP-U: General Packet Radio Service (GPRS) Tunnelling Protocol –User Plane

[0105] GW: Gateway

[0106] HA: High Availability

[0107] L1: Layer 1

[0108] L2: Layer 2

[0109] L3: Layer 3

[0110] LC: Logical Channel

[0111] LTE: Long Term Evolution (4G)

[0112] MAC: Medium Access Control

[0113] MIMO: multiple-in multiple-out

[0114] MME: Mobility Management Entity

[0115] MR-DC: Multi-Radio Dual Connectivity

[0116] M-plane: Management plane interface between SMO and O-RU

[0117] NACK: Negative Acknowledgement

[0118] NAS: Non-Access Stratum

[0119] NB: Narrowband

[0120] Near-RT RIC: Near-Real-Time RIC

[0121] ng: Next Generation

[0122] NMS: Network Management System

[0123] NR: New Radio

[0124] NR-U: New Radio –User Plane

[0125] NSA: Non-Standalone Architecture

[0126] One-CU-UP: One O-RAN compliant Centralized Unit User Plane

[0127] OFDM: orthogonal frequency-division multiplexing

[0128] O-RAN: Open Radio Access Network

[0129] PA: Power Amplifier

[0130] PDB: Packet Delay Budget

[0131] PDCP : Packet Data Convergence Protocol

[0132] PDU: Protocol Data Unit

[0133] PDCCH: Physical Downlink Control Channel

[0134] PDSCH: Physical Downlink Shared Channel

[0135] PHY: Physical Layer

[0136] PRG: Physical Resource block Group

[0137] PUCCH: Physical Uplink Control Channel

[0138] PUSCH: Physical Uplink Shared Channel

[0139] QCI: QoS Class Identifier

[0140] QFI: QoS Flow Id

[0141] QFI: QoS Flow Identifier

[0142] QoS : Quality of Service

[0143] RAT: Radio Access Technology

[0144] RB: Resource Block

[0145] RDI: Reflective QoS Flow to DRB Indication

[0146] RIC: RAN Intelligent Controller

[0147] RLC: Radio Link Control

[0148] RLC-AM: RLC Acknowledged Mode

[0149] RLC-UM: RLC Unacknowledged Mode

[0150] RMM: Radio resource management

[0151] RQI: Reflective QoS Indication

[0152] RRC: Radio Resource Control

[0153] RU: Radio Unit

[0154] SA: Standalone Architecture

[0155] SCTP: Stream Control Transmission Protocol

[0156] SDAP: Service Data Adaptation Protocol

[0157] SDU: Service Data Unit

[0158] S-GW: Serving Gateway

[0159] SINR: Signal-to-Interference and Noise Ratio

[0160] SMO: Service Management and Orchestration system

[0161] SN: Secondary Node

[0162] SR: Scheduling Request

[0163] SRS: Sounding Reference Signal

[0164] TCP: Transmission Control Protocol

[0165] TEID: Tunnel Endpoint Identifier

[0166] U-plane: User plane

[0167] UPF: User Plane Function

[0168] UE: user equipment

[0169] UL: uplink

[0170] UM: Unacknowledged Mode

[0171] URLLC: Ultra Reliance Low Latency Communication

[0172] Described are implementations of technology for a cloud-based Radio Access Networks (RAN) , where a significant portion of the RAN layer processing is performed at a central unit (CU) and a distributed unit (DU) . Both CUs and DUs are also known as the baseband units (BBUs) . CUs are usually located in the cloud on commercial off the shelf servers, while DUs can be distributed. The RF and real-time critical functions can be processed in the remote radio unit (RU) .

[0173] RAN Architectures

[0174] FIG. 1 is a block diagram of a system 100 for implementations as described herein. System 100 includes a NR UE 101, a NR gNB 106. The NR UE and NR gNB 106 are communicatively coupled via a Uu interface 120.

[0175] NR UE 101 includes electronic circuitry, namely circuitry 102, that performs operations on behalf of NR UE 101 to execute methods described herein. Circuity 102 can be implemented with any or all of (a) discrete electronic components, (b) firmware, and (c) a programmable circuit 102A.

[0176] NR gNB 106 includes electronic circuitry, namely circuitry 107, that performs operations on behalf of NR gNB 106 to execute methods described herein. Circuity 107 can be implemented with any or all of (a) discrete electronic components, (b) firmware, and (c) a programmable circuit 107A.

[0177] Programmable circuit 107A, which is an implementation of circuitry 107, includes a processor 108 and a memory 109. Processor 108 is an electronic device configured of logic circuitry that responds to and executes instructions. Memory 109 is a tangible, non-transitory, computer-readable storage device encoded with a computer program. In this regard, memory 109 stores data and instructions, i.e., program code, that are readable and executable by processor 108 for controlling operations of processor 108. Memory 109 can be implemented in a random-access memory (RAM) , a hard drive, a read only memory (ROM) , or a combination thereof. One of the components of memory 109 is a program module, namely module 110. Module 110 contains instructions for controlling processor 108 to execute operations described herein on behalf of NR gNB 106.

[0178] The term "module" is used herein to denote a functional operation that can be embodied either as a stand-alone component or as an integrated configuration of a plurality of subordinate components. Thus, each of module 105 and 110 can be implemented as a single module or as a plurality of modules that operate in cooperation with one another.

[0179] While modules 110 are indicated as being already loaded into memories 109, and module 110 can be configured on a storage device 130 for subsequent loading into their memories 109. Storage device 130 is a tangible, non-transitory, computer-readable storage device that stores module 110 thereon. Examples of storage device 130 include (a) a compact disk, (b) a magnetic tape, (c) a read only memory, (d) an optical storage medium, (e) a hard drive, (f) a memory unit comprising of multiple parallel hard drives, (g) a universal serial bus (USB) flash drive, (h) a random-access memory, and (i) an electronic storage device coupled to NR gNB 106 via a data communications network.

[0180] Uu Interface (120) is the radio link between the NR UE and NR gNB, which is compliant to the 5G NR specification.

[0181] UEs 101 can be dispersed throughout a wireless communication network, and each UE can be stationary or mobile. A UE includes: an access terminal, a terminal, a mobile station, a subscriber unit, a station, and the like. A UE can also include be a cellular phone (e.g., a smart phone) , a personal digital assistant (PDA) , a wireless modem, a wireless communication device, a handheld device, a laptop computer, a cordless phone, a wireless local loop (WLL) station, a tablet, a camera, a gaming device, a drone, a robot / robotic device, a netbook, a smartbook, an ultrabook, a medical device, medical equipment, a healthcare device, a biometric sensor / device, a wearable device such as a smart watch, smart clothing, smart glasses, a smart wristband, and / or smart jewelry (e.g., a smart ring, a smart bracelet, and the like) , an entertainment device (e.g., a music device, a video device, a satellite radio, and the like) , industrial manufacturing equipment, a global positioning system (GPS) device, or any other suitable device configured to communicate via a wireless or wired medium. UEs can include UEs considered as machine-type communication (MTC) UEs or enhanced / evolved MTC (eMTC) UEs. MTC / eMTC UEs that can be implemented as IoT UEs. IoT UEs include, for example, robots / robotic devices, drones, remote devices, sensors, meters, monitors, cameras, location tags, and the like, that can communicate with a BS, another device (e.g.,  remote device) , or some other entity. A wireless node can provide, for example, connectivity for or to a network (e.g., a wide area network such as Internet or a cellular network) via a wired or wireless communication link.

[0182] One or more UEs 101 in the wireless communication network can be a narrowband bandwidth UE. As used herein, devices with limited communication resources, e.g. smaller bandwidth, are considered as narrowband UEs. Similarly, legacy devices, such as legacy and / or advanced UEs, can be considered as wideband UEs. Wideband UEs are generally understood as devices that use greater amounts of bandwidth than narrowband UEs.

[0183] The UEs 101 are configured to connect, for example, communicatively couple, with an or RAN. In embodiments, the RAN can be an NG RAN or a 5G RAN, an E-UTRAN, an MF RAN, or a legacy RAN, such as a UTRAN or GERAN. The term “NG RAN” or the like refers to a RAN 110 that operates in an NR or 5G system, the term “E-UTRAN” or the like refers to a RAN that operates in an LTE or 4G system, and the term “MF RAN” or the like refers to a RAN that operates in an MF system 100. The UEs 101 utilize connections (or channels) , respectively, each of which comprises a physical communications interface or layer. The connections and can comprise several different physical DL channels and several different physical UL channels. As examples, the physical DL channels include the PDSCH, PMCH, PDCCH, EPDCCH, MPDCCH, R-PDCCH, SPDCCH, PBCH, PCFICH, PHICH, NPBCH, NPDCCH, NPDSCH, and / or any other physical DL channels mentioned herein. As examples, the physical UL channels include the PRACH, PUSCH, PUCCH, SPUCCH, NPRACH, NPUSCH, and / or any other physical UL channels mentioned herein.

[0184] The RAN can include one or more AN nodes or RAN nodes. These access nodes can be referred to as BS, gNBs, RAN nodes, eNBs, NodeBs, RSUs, MF-APs, TRxPs or TRPs, and so forth, and comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell) . The term “NG RAN node” or the like refers to a RAN node that operates in an NR or 5G system (e.g., a gNB) , and the term “E-UTRAN node” or the like refers to a  RAN node that operates in an LTE or 4G system (e.g., an eNB) . According to various embodiments, the RAN nodes can be implemented as one or more of a dedicated physical device such as a macrocell base station, and / or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0185] In some embodiments, all or parts of the RAN nodes can be implemented as one or more software entities running on server computers as part of a virtual network, which can be referred to as a CRAN and / or a vBBU. In these embodiments, the CRAN or vBBU can implement a RAN function split, such as a PDCP split wherein RRC and PDCP layers are operated by the CRAN / vBBU and other L2 protocol entities are operated by individual RAN nodes; a MAC / PHY split where RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBU and the PHY layer is operated by individual RAN nodes; or a “lower PHY” split where RRC, PDCP, RLC, MAC layers and upper portions of the PHY layer are operated by the CRAN / vBBU and lower portions of the PHY layer are operated by individual RAN nodes. This virtualized framework allows the freed-up processor cores of the RAN nodes to perform other virtualized applications. In some implementations, an individual RAN node can represent individual gNB-DUs that are connected to a gNB-CU 151via individual F1 interfaces. In these implementations, the gNB-DUs can include one or more remote radio heads (RRH) , and the gNB-CU 151can be operated by a server that is located in the RAN or by a server pool in a similar manner as the CRAN / vBBU. One or more of the RAN nodes can be next generation eNBs (ng-eNBs) , which are RAN nodes that provide E-UTRA user plane and control plane protocol terminations toward the UEs 101, and are connected to a 5GC via an NG interface. In MF implementations, the MF-APs are entities that provide MultiFire radio services, and can be similar to eNBs in an 3GPP architecture.

[0186] In some implementations, access to a wireless interface can be scheduled, wherein a scheduling entity (e.g.: BS, gNB, and the like) allocates bandwidth resources for devices and equipment in its service area or cell. As  scheduling entity can be configured to schedule, assign, reconfigure, and release resources for one or more subordinate entities. In some examples, a UE 101 (or other device) can function as master node scheduling entity, scheduling resources for one or more secondary node subordinate entities (e.g., one or more other UEs 101) . Thus, in a wireless communication network with a scheduled access to time-frequency resources and having a cellular configuration, a P2P configuration, and a mesh configuration, a scheduling entity and one or more subordinate entities can communicate utilizing the scheduled resources.

[0187] BS or gNB 106 can be equipped with T antennas and UE 101 can be equipped with R antennas, where in general T≥1 and R≥1. At BS, a transmit processor is configured to receive data from a data source for one or more UEs 101 and select one or more modulation and coding schemes (MCS) for each UE based on channel quality indicators (CQIs) received from the UE 101. The BS is configured to process (e.g., encode and modulate) the data for each UE 101 based on the MCS (s) selected for the UE 101, and provide data symbols for all UEs. A transmit processor is also configured to process system information (e.g., for static resource partitioning information (SRPI) , and the like) and control information (e.g., CQI requests, grants, upper layer signaling, and the like) and can provide overhead symbols and control symbols. Processor 108 can also generate reference symbols for reference signals (e.g., the cell-specific reference signal (CRS) ) and synchronization signals (e.g., the primary synchronization signal (PSS) and the secondary synchronization signal (SSS) ) . A transmit (TX) multiple-input multiple-output (MIMO) processor can be configured perform spatial processing (e.g., precoding) on the data symbols, the control symbols, the overhead symbols, and / or the reference symbols, if applicable, and can be configured to provide T output symbol streams to T modulators (MODs) . Each modulator can be configured to process a respective output symbol stream (e.g., for OFDM, and the like) to obtain an output sample stream. Each modulator can further be configured to process (e.g., convert to analog, amplify, filter, and upconvert) the output sample stream to obtain  a downlink signal. T downlink signals from modulators can be transmitted via T antennas.

[0188] An overview of 5G NR Stacks is as follows. 5G NR (New Radio) user and control plane functions with monolithic gNB 106 are shown in FIG. 1 and FIG. 2. For the user plane, PHY (physical) , MAC (Medium Access Control) , RLC (Radio Link Control) , PDCP (Packet Data Convergence Protocol) and SDAP (Service Data Adaptation Protocol) sublayers are terminated in the gNB 106 on the network side. For the control plane, RRC (Radio Resource Control) , PDCP, RLC, MAC and PHY sublayers are terminated in the gNB 106 on the network side and NAS (Non-Access Stratum) is terminated in the AMF (Access Mobility Function) on the network side. FIG. 2 shows an example of a User Plane Stack as descried in 3GPP TS 38.300. FIG. 3 shows an example of a Control Plane Stack as described in 3GPP TS 38.300.

[0189] An NG-RAN (NG-Radio Access Network) architecture from 3GPP TS 38.401 is described below. F1 is the interface between gNB-CU 151 (gNB –Centralized Unit) and gNB-DU 152 (gNB –Distributed Unit) , NG is the interface between gNB-CU 151 (or gNB) and 5GC (5G Core) , E1 is the interface between CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) , and Xn is interface between gNBs.

[0190] A gNB 106 can comprise a gNB-CU-CP, multiple gNB-CU-UPs and multiple gNB-DUs. The gNB-CU-CP is connected to the gNB-DU 152 through the F1-C interface and to the gNB-CU-UP through the E1 interface. The gNB-CU-UP is connected to the gNB-DU 152 through the F1-U interface and to the gNB-CU-CP through the E1 interface. One gNB-DU 152 is connected to one gNB-CU-CP and one gNB-CU-UP is connected to one gNB-CU-CP. FIG. 4A shows an example of an NG-RAN Architecture as described in 3GPP TS 38.501. FIG. 4B shows an example of a Separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) as described in 3GPP TS 38.401.

[0191] A Layer 2 (L2) of 5G NR is split into the following sublayers is described in 3GPP TS 38.300) :

[0192] ○ Medium Access Control (MAC) : The MAC sublayer offers Logical Channels (LCs) to the RLC sublayer. This layer runs a MAC scheduler to schedule radio resources across different LCs (and their associated radio bearers) .

[0193] ○ Radio Link Control (RLC) : The RLC sublayer offers RLC channels to the PDCP sublayer. The RLC sublayer supports three transmission modes: RLC-Transparent Mode (RLC-TM) , RLC-Unacknowledged Mode (RLC-UM) and RLC-Acknowledgement Mode (RLC-AM) . RLC configuration is per logical channel. It hosts ARQ (Automatic Repeat Request) protocol for RLC-AM mode.

[0194] ○ Packet Data Convergence Protocol (PDCP) : The PDCP sublayer offers Radio Bearers (RBs) to the SDAP sublayer. There are two types of Radio Bearers: Data Radio Bearers (DRBs) for data and Signaling Radio Bearers (SRBs) for control plane.

[0195] ○ Service Data Adaptation Protocol (SDAP) : The SDAP offers QoS Flows to the 5GC (5G Core) . This sublayer provides mapping between a QoS flow and a DRB. It marks QoS Flow Id in DL (downlink) as well as UL (uplink packets) .

[0196] Prior to the present disclosure, 4G and 5G CU-UP are deployed separately as different network functions. FIG. 4C shows an example of a Separation of 4G CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) . The example shown in FIG. 4C shows ng-eNB but legacy eNB also applies same architecture.

[0197] FIG. 5 shows a DL (Downlink) Layer 2 Structure as described in 3GPP TS 38.300. FIG. 6 shows an UL (uplink) Layer 2 Structure in accord with 3GPP  TS38.300. FIG. 7 shows an L2 Data Flow example in accord with 3GPP TS 38.300 ( [H] denotes headers or subheaders in FIG. 7. )

[0198] O-RAN, which is based on disaggregated components and connected through open and standardized interfaces, is based on 3GPP NG-RAN. An overview of O-RAN with disaggregated RAN (CU, DU, and RU) , near-real-time RIC 160 and non-real-time RIC is shown in the figure below. Here, DU (Distributed Unit) and CU (Centralized Unit) are typically implemented using COTS (Commercial off-the-shelf) hardware.

[0199] FIGS. 8A-8B show an example of an O-RAN architecture. In FIG. 8A, the CU and the DU are connected using the F1 interface (with F1-C for control plane and F1-U for user plane traffic) over the midhaul (MH) path. One DU could host multiple cells (for example, one DU could host 24 cells) and each cell can support many users. For example, one cell can support 600 RRC connected users and out of these 600, there can be 200 Active users (i.e.; users which have data to send at a given point of time) .

[0200] A cell site can comprise multiple sectors and each sector can support multiple cells. For example, one site could comprise three sectors and each sector could support 8 cells (with 8 cells in each sector on different frequency bands) . One CU-CP could support multiple DUs and thus multiple cells. For example, a CU-CP could support 1000 cells and around 100,000 UEs. Each UE could support multiple DRBs and there could be multiple instances of CU-UP to serve these DRBs. For example, each UE could support 4 DRBs, and 400,000 DRBs (corresponding to 100,000 UEs) can be served by five CU-UP instances (and one CU-CP instance) .

[0201] DU can be located in a private data center or it could be located at a cell-site too. CU can also be located in a private data center or even hosted on a public cloud system. DU and CU can be tens of kilometers away. CU can communicate with 5G core system which could also be hosted in the same public  cloud system (or could be hosted by a different cloud provider) . RU (Radio Unit) is located at cell-site and communicated with DU via a fronthaul (FH) interface.

[0202] The E2 nodes (CU and DU) are connected to the near-real-time RIC 160 using the E2 interface. The E2 interface is used to send data (e.g., user, cell, slice KPMs) from the RAN, and deploy control actions and policies to the RAN at near-real-time RIC 160. The application or service at the near-real-time RIC 160 that deploys the control actions and policies to the RAN are called xApps. The near-real-time RIC 160 is connected to the non-real-time RIC 161 using the A1 interface.

[0203] SMO manages multiple regional networks, and O-RAN NFs (O-CUs, Near-RT RIC 160, O-DUs) can be deployed in a regional data center that is connected to multiple cell sites or in cell site which is close to localized O-RU according to network requirements. Since SMO Functions and O-RAN NFs are micro services and deployment-independent logical functions, SMO Functions and O-RAN NFs can be composed of multiple deployment instances deployed in the same O-Cloud or in a different O-Cloud in regional data center, or in cell site according to network requirements (ex. capacity, latency, security, and so on) if the secure connection among SMO Functions and O-RAN NFs are available.

[0204] As shown in FIG. 8B, an O-RAN compliant SMO defines TE&IV, RAN NF OAM, Non-RT RIC, and NFO, FOCOM services. SMO interacts with O-RAN NFs with O1 interface. SMO interacts with O-RU with Open FH M-Plane interface and interacts O-Cloud via the O2 interface. O-RAN NF OAM manages O-RAN NF CM, FM, PM and creates O-RAN NF inventory and topology in TE&IV. FOCOM / NFO manages O-Cloud resources and creates O-Cloud resources inventory and topology in TE&IV. Analytics / rApp in Non-RT RIC can subscribe O-RAN NFs PM / FM, O-Cloud PM / FM data based on O-RAN NF OAM and FOCOM / NFO. Analytics / rApp in Non-RT RIC can retrieve the O-RAN NF and O-Cloud resource inventory and topology.

[0205] PDU Sessions, DRBs, QoS Flows

[0206] In 5G networks, PDU connectivity service is a service that provides exchange of PDUs between a UE and a data network identified by a Data Network Name (DNN) . The PDU Connectivity service is supported via PDU sessions that are established upon request from the UE. This DNN defines the interface to a specific external data network. One or more QoS flows can be supported in a PDU session. All the packets belonging to a specific QoS flow have the same 5QI (5G QoS Identifier) . FIG. 9A illustrates a PDU Session architecture comprising of multiple DRBs. Each DRB can include multiple QoS flows (3GPP TS 23.501) . FIG. 9B illustrates a flow for PDU sessions, DRBs and GTP-U Tunnels across CU and DU. FIG. 9C illustrates a CU and DU view on PDU session, DRBs and GTP-U tunnels for a 5G network architecture.

[0207] As shown in FIGS. 9A-9C, a PDU session comprises the following:

[0208] A Data Radio Bearer (DRB) is between UE and CU in RAN and a NG-U GTP tunnel which is between CU and UPF (User Plane Function) in the core network. For the 3GPP’s 5G network architecture, the transport connection between the base station (i.e., CU-UP) and User Plane Function (UPF) uses a single GTP-U tunnel per PDU session. The PDU session is identified using GTP-U TEID (Tunnel Endpoint Identifier) . The transport connection between DU and CU-UP uses a single GTP-U tunnel per DRB.

[0209] SDAP

[0210] The SDAP (Service Adaptation Protocol) Layer receives downlink data from the UPF across the NG-U interface. It maps one or more QoS Flow (s) onto a specific DRB. The SDAP header is present between the UE and the CU (when reflective QoS is enabled) , and includes a field to identify the QoS flow in a specific PDU session. GTP-U protocol includes a field to identify the QoS flow and is present between CU and UPF (in the core network) .

[0211] Procedures and functionality of the F1-U interface are defined in 3GPP TS 38.425. This F1-U interface supports NR User Plane (NR UP) protocol that  provides support for flow control and reliability between CU-UP and DU for each DRB. FIG. 10 shows a Resource Allocation (MAC Scheduler) , DL Data, and Flow Control Feedback (DDDS) in 5G Networks. Downlink User Data (DUD) PDU are used to carry PDCP PDUs from CU-UP to DU for each DRB. Downlink Data Delivery Status (DDDS) PDU from DU to CU-UP. The DDDS message conveys Desired Buffer Size (DBS) , Desired Data Rate (DDR) and some other parameters from DU to CU-UP for each DRB as part of flow control feedback.

[0212] An E-UTRAN architecture is illustrated in FIG. 11A. The E-UTRAN comprises eNBs, providing the E-UTRAN U-plane (PDCP / RLC / MAC / PHY) and control plane (RRC) protocol terminations towards the UE. The eNBs are interconnected with each other by the X2 interface. The eNBs are also connected by the S1 interface to the EPC (Evolved Packet Core) , more specifically to the MME (Mobility Management Entity) by the S1-MME interface and to the Serving Gateway (S-GW) by the S1-U interface. The S1 interface supports a many-to-many relation between MMEs / Serving Gateways and eNBs.

[0213] E-UTRAN also supports MR-DC via E-UTRA-NR Dual Connectivity (EN-DC) , in which a UE is connected to one eNB that acts as a MN and one en-gNB 106 that acts as a SN. An EN-DC architecture is illustrated in FIG. 11A. The eNB is connected to the EPC 140 via the S1 interface and to the en-gNB 106 via the X2 interface. The en-gNB 106 might also be connected to the EPC 140 via the S1-U interface and other en-gNBs 106 via the X2-U interface. In EN-DC, an en-gNB 106 comprises gNB-CU 151and gNB-DU (s) 152.

[0214] As shown in FIG. 11B, in the NG-RAN architecture, an NG-RAN node is either:

[0215] a gNB, providing NR user plane and control plane protocol terminations towards the UE; or

[0216] an ng-eNB, providing E-UTRA user plane and control plane protocol terminations towards the UE. (3GPP TS 38.300 17.3.0. )

[0217] As shown in FIG. 11B, the gNBs 106 and ng-eNBs are interconnected with each other by the Xn interface. The gNBs 106 and ng-eNBs are also connected by the NG interfaces to the 5GC, more specifically to the AMF (Access and Mobility Management Function) by the NG-C interface and to the UPF (User Plane Function) by the NG-U interface.

[0218] The gNB 106 and ng-eNB host functions such as functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling) , connection setup and release; session Management; QoS Flow management and mapping to data radio bearers; and Dual Connectivity.

[0219] In an example, control information (e.g., scheduling information) can be provided for broadcast and / or multicast operation. The UE can monitor different bundle sizes for the control channel depending on the maximum number of repetitions.

[0220] NSA (Non-Standalone) Architecture

[0221] In the 5G Standalone (SA) architectures, 5G gNB 106 communicates with 5G Core (and not with 4G Evolved Packet Core 140) . Similarly, in the 4G architecture, 4G eNB 116 communicates with 4G Evolved Packet Core (EPC) 140 and not with 5G Core.

[0222] E-UTRA-NR Dual Connectivity (EN-DC) is a dominant form of the Non-Standalone (NSA) architecture. As shown in FIG. 12A, a 4G eNB 116 as well as 5G gNB 106 use 4G EPC 140 (Evolved Packet Core) , and 5G core is not used in this network architecture. In the architecture below, DL (downlink) data goes from 4G EPC 140 to 5G CU-UP 151 where it could be split across two different transmission paths (or network legs) : 1) 5G CU-UP 151to 4G DU 142 to NSA UE and 2) 5G CU-UP 151 to 5G DU 152 to NSA UE, and combined again at the NSA UE 101. Flow control between CU-UP 151 and DU as specified in the previous section is run 1) between  5G DU 152 and 5G CU-UP 151, and 2) between 4G DU 142 and 5G CU-UP 151 in this architecture.

[0223] FIG. 12B shows another UL Split bearer in NSA Architecture. In this variant of the NSA Architecture, DL data from 4G EPC 140 is first sent to 4G CU-UP 141 where it is split across two transmission paths (or network legs) : 1) 4G CU-UP 141 to 4G DU 142 to NSA UE 101 and 2) 4G CU-UP 141 to 5G DU 152 to UE 101, and then combined again at the NSA UE 101. For the UL split bearer in the NSA architecture, uplink data from the UE 101 towards the 5G DU 152 / 4G DU 142 is split at the UE 101. After splitting, some packets are sent on the 5G leg 154 and other on the 4G leg 144 of the network.

[0224] As noted above with respect to FIGS. 4A and 4B, prior to the present disclosure, the 4G CU-UP and 5G CU-UP are deployed separately as different network functions. In this architecture, the CPU and memory resource are dedicated for 4G and 5G, which cannot be shared to achieve a pooling gain. As shown in Table 1, 4G and 5G have some common PDCP functions which are CPU and memory intensive:

[0225] ● Integrity Protection

[0226] ○ EIA1 SNOW 3G based algorithm.

[0227] ○ EIA2 AES based algorithm.

[0228] ○ EIA3 ZUC based algorithm.

[0229] ● Ciphering

[0230] ○ EEA1 SNOW 3G based algorithm.

[0231] ○ EEA2 AES based algorithm.

[0232] ○ EEA3 ZUC based algorithm.

[0233] ● ROHC (Robust header compression and decompression)

[0234] Table 1

[0235] Prior to present disclosure, the common PDCP functions identified above are usually in different software bases and can be deployed in different network nodes that will miss a pooling gain. Also, some NSA functions, such as data forwarding / SN status transfer / UE AMBR and of the like, cannot be optimized due to separate deployments.

[0236] CU-UP function is much more common among different RATs than other components. However, in legacy RAN architecture, eNB and gNB are 2 different NFs (Network Functions) for different RATs that are being deployed separately. Thus, the CU-UP function in eNB and gNB work individually.

[0237] CU-UP PDCP security is a high CPU intensive entity but is quite common for 4G and 5G. Especially for NSA, where eNB and gNB can be at a same site. However, as CU-UP in eNB and gNB are deployed as 2 different NFs / nodes, the pooling gain is again missed.

[0238] As a 3GPP evolution, ng-eNB was introduced with a gNB like architecture. The ng-eNB-CU-UP and gNB-CU-UP are almost homogeneous. In an OpenRAN cloud-native architecture, CU-UP runs as a dedicated Cloud Network Function (CNF) . Before the present disclosure, 4G and 5G CU-UP are in different CNFs. The present disclosure advantageously describes implementation of a common 4G and 5G CU-UP that is deployed in a same CNF, hereinafter referred as One-CU-UP CNF or One-CU-UP. By deploying a One-CU-UP CNF, advantages include higher pooling gains. Also in NSA, data forwarding over X2-U / Xn-U interface and SN  status transfer procedure is not required any longer, as 4G and 5G CU-UP are in same CNF. This makes the CNF more efficient in NSA data traffic handling.

[0239] One-CU-UP CNF also provides a great advantage for disaggregated NSA deployment where both 4G and 5G CU-CP and CU-UP are deployed at the cell site and CPU / memory resource is quite limited.

[0240] One-CU-UP also brings more flexibility for deployment, for example, by serving multiple eNB-CU-CP or gNB-CU-CP instances.

[0241] Further advantages include:

[0242] ● NSA option 3x: Deploy one eNB-CU-CP CNF, one gNB-CU-CP CNF and single instance of one-CU-UP CNF.

[0243] ● LTE: one or more eNB-CU-CP CNFs connected to one or more one-CU-UP CNFs.

[0244] ● NR : one or more gNB-CU-CP CNFs connected to one or more one-CU-UP CNFs.

[0245] ● NR-DC: one or more gNB-CU-CP CNFs connected to one or more one-CU-UP CNFs.

[0246] Accordingly, described are implementations of a One-CU-UP CNF 150 and service module, which works for both 4G and 5G. As shown in FIG. 13, the One CU-UP 170

[0247] ● Shares CPU and memory resource for 4G and 5G to get pooling gain.

[0248] ● Supports both 4G CU-UP 141 and 5G CU-UP 151 functions.

[0249] ● Supports both 4G and 5G UE context.

[0250] ● Supports multiple external interfaces as E1, W1-U, F1-U, S1-U, NG-U, and the like.

[0251] In NSA including both 4G eNB and 5G gNB 106, some functions can be optimized even further. It will be noted that the example shown in FIG. 13 takes ng-eNB 141 and the legacy eNB and applies the same architecture.

[0252] In One-CU-UP 170, as shown in Table 2, all 3GPP defined DRB PDCP SN lengths (7, 12, 15, 16, 18) can be supported. As shown in Table 3, NR PDCP SN lengths (12, 18) can also be supported. 3GPP TS 38.323.

[0253] Table 2

[0254] Table 3

[0255] In One-CU-UP 170, some 4G CU and 5G CU functions can be dedicated to a specific RAT, for example, functions that cannot be shared such as:

[0256] ● SDAP, which is 5G specific which only works for 5G node. Then 4G data packets can bypass the SDAP functionality entity along the data path within One-CU-UP CF 170 service.

[0257] ● Re-ordering functionality in 4G is handled by RLC, and in 5G it is handled by PDCP. As a result, uplink data packets for 4G can bypass the PDCP reordering handler along the data path within One-CU-UP 170.

[0258] Optimization 1: 4G and 5G pooling gain in One-CU-UP

[0259] In an implementation, 4G and 5G context are implemented together in One-CU-UP service. CPU and memory resource can be shared between 4G and 5G to have pooling gains. As shown in FIG. 14A, the One-CU-CP includes, for example, UE / bearer context for both 4G and 5G and PDCP buffer pool for both 4G and 5G. The  One CU-UP also includes a plurality of cells vCore1, vCore2…vCoreN. In an exemplary basic deployment, One CU-UP can comprise 3 LTE cells and 3 NR cells. A vCPU is pinned by CU-UP for fast path handling, which means this vCPU is fully occupied by CU-UP fast-path. An exemplary maximum throughput can be defined as 80Mbps per one LTE cell, 1000Mbps per one NR cell. The traffic model is that all the cells work at average 30%full capacity as: 3 LTE cells throughput at (80Mbps *3 ) *30%= 72Mbps and 3 NR cells throughput at (1000Mbps *3 ) *30%= 900Mbps The maximum capacity of each vCPU is 1.5Gbps.

[0260] Table 4

[0261] As shown in Table 4 and FIG. 14B, the exemplary deployment of the One CU-UP 170 has an almost 50%pooling gain, which is reduced from 2 vCPUs to 1 vCPU for CU-UP fastpath.

[0262] To maximize the pooling gains and not to limit the overall system capacity, the architecture of One-CU-UP 170 service can be scalable to support horizontal scaling with multiple data path worker threads or multiple data path pods / containers. Such scalability can be based on several metrics including CPU utilization, memory utilization, the number of bearers served by current data path worker threads.

[0263] Optimization2: NSA data forwarding in One-CU-UP

[0264] FIG. 15A shows an exemplary general call flow in an NSA setup for ng-eNB and gNB connecting to 5GC. At block 201, the MN (ng-eNB 141) sends an SN Addition Request to the SN (gNB 106) , which at block 202 the SN 106 acknowledges to the MN. At block 202a, the MS sends the SN an Xn-U Address Indication. At block 203, the MN sends UE 101 an RRC reconfiguration message. At block 204, when the UE reconfiguration is completed, the UE 101 sends the MN a RRC reconfiguration complete message. At block 205, the MN sends the SN a Reconfiguration Complete message. At block 206, a Random Access Procedure is established between the SN and the UE 101. At block 207, the MN sends an SN Status Transfer to the SN.

[0265] Prior to the present disclosure, at block 208 there is a data forwarding process from MN (ng-eNB) to SN (gNB) where PDCP SDUs are to be forwarded from MN CU-UP to SN CU-UP over X2-U interface. This introduces additional delays and requires data buffers at both MN and SN. A Path Update procedure commences at block 209 with a PDU session from the MN to the AMF. At block 210, the AMF sends a Bearer Modification to UPF. At block 211, the MN sends an End Marker Packet to the UPF, and at block 212, the AMF sends a PDU Session Modify Confirmation to the MN.

[0266] In an implementation of One-CU-UP , the X2-U / Xn-U is an internal interface, which advantagously does away with the need for data forwarding, which saves the buffer resource and has a simplified NSA flow As will be appreciated, while the example of FIG. 15B shows an NSA setup, where data forwarding is an NSA release procedure, the release can be simillarluy opitimized using the One CU-UP 170. As shown in FIG. 15A, for data forwarding step 208, the internal data buffer can replace the external data forwarding over Xn-U interface.

[0267] FIG. 15B shows an exemplary general call flow in an NSA setup for ng-eNB and gNB connecting to4G EPC 140. As shown in FIG. 15B, at block 301, the MN (ng-eNB 141) sends an SN Addition Request to the SN (gNB 106) , which at block 302 the SN 106 acknowledges to the MN. At block 303, the MN sends UE 101 an RRC connection reconfiguration message. At block 304, when the UE reconfiguration is  completed, UE 101 sends the MN a RRC Connection Reconfiguration Complete message. At block 305, the MN sends the SN a Reconfiguration Complete message. At block 306, a Random Access Procedure is established between the SN and the UE 101. At block 307, the MN sends an SN Status Transfer to the SN.

[0268] At block 308, there is a data forwarding process from MN (ng-eNB) to SN (gNB) . In an implementation, the One CU-UP 170 can be employed in NSA setup for eNB and gNB connecting to 4G EPC 140. In FIGS. 15A-15B, step 208, 308 data forwarding can be replaced by One-CU-UP 170 internal data buffer. For efficient packet processing, 4G and 5G data packets pertaining to single user can be processed by single datapath worker thread. For example, as shown in FIG. 16, the One-CU-UP 170 internal data buffer 175 management thus handles PDCP SDU buffer pool for the MN (ng-eNB) to the SN (gNB) . This avoids the need for any thread-to-thread communication and helps in improving the overall system efficiency. As shown in FIG. 16, there is no communication even core-to-core / thread-to-thread. Thus again, for efficient packet processing, 4G and 5G data packets pertaining to single user shall be processed by single data-path worker thread.

[0269] A Path Update procedure commences at block 309 with an E-RAB Modification Indication the MN to the MME. At block 310, the MME sends a Bearer Modification to S-GW. At block 311, the MN sends an End Marker Packet to the S-GW, and at block 12, the MME sends an E-RAB Modification Confirmation to the MN.

[0270] Optimization3: NSA SN status transfer in One-CU-UP

[0271] FIG. 17A shows an exemplary general call flow in NSA release for ng-eNB and gNB connecting to 5CGC. At block 401, the MN (ng-eNB 141) sends an SN Release Request to the SN (gNB 106) , which at block 402 the SN 106 acknowledges to the MN. At block 402a, the MS sends the SN an Xn-U Address Indication. At block 403 the MN sends UE 101 a RRC reconfiguration message. At block 404, when the UE reconfiguration is completed, the UE 101 sends the MN a RRC reconfiguration Complete message. At block 405, the SN sends the MN a Status Transfer.

[0272] Prior to the present disclosure, in NSA release procedure step 405 of FIG. 17A, there is SN Status Transfer over X2 / Xn between SN and MN. As PDCP function is in a different node, the PDCP SN for RLC AM bearer is transferred when PDCP node is changed. As such, the step 405 SN Status Transfer over X2 / Xn between SN and MN is optional and can be skipped. At block 406, the SN sends the MN a Data Forwarding. At block 407, the SN sends the MN a Secondary RAT Data Usage Report. At block 408 is a PDU Session Path Update procedure, and at block 409, the MN sends the SN a UE Context Release.

[0273] FIG. 17B shows an exemplary general call flow in NSA release for ng-eNB and gNB connecting to 4G EPC 540. At block 501, the MN (ng-eNB 141) sends an SgNB Release Request to the SN (gNB 106) , which at block 502 the SN 106 acknowledges to the MN. At block 503, the MN sends UE 101 a RRC reconfiguration message. At block 504, when the UE reconfiguration is completed, the UE 101 sends the MN a RRC reconfiguration complete message. At block 505, the SN sends the MN a Status Transfer.

[0274] Prior to the present disclosure, in NSA release procedure step 505 of FIG. 17B, there is SN Status Transfer over X2 / Xn between SN and MN. As PDCP function is in a different node, the PDCP SN for RLC AM bearer is transferred when PDCP node is changed. As such, the step 505 SN Status Transfer over X2 / Xn between SN and MN is optional and can be skipped. At block 506, the SN starts Data Forwarding with MN. At block 507, the SN sends the MN a Secondary RAT Data Usage Report. At block 508 is a PDU Session Path Update procedure, and at block 509, the MN sends the SN a UE Context Release.

[0275] In the implementations, the One-CU-UP 170 has the MN PDCP entity and SN PDCP entity in the same node. As such, the PDCP SN can be shared just in time. As such in FIGS. 17A-17B, the SN status transfer procedure can be skipped, which advantageously makes NSA release procedure more efficient. While the example shows an NSA release procedure, the One CU-UP 170 can similarly be employed for an SN status transfer in NSA gNB addition procedure.

[0276] Optimization4: DL UE AMBR handling in One-CU-UP

[0277] Prior to the present disclosure, an LTE bearer’s PDCP entity is conventionally handled in eNB, while NSA bearer’s PDCP entity is handled in gNB. There is no efficient way to decide the DL UE AMBR targeted at eNB and gNB CU-UP yet. Generally, there are 2 conventional solutions prior to the present disclosure.

[0278] The first conventonal solution is a fixed configuration is used to split the DL UE AMBR targeted at 4G and 5G. For instance, as shown in FIG. 18A if Core Network assigns DL UE AMBR at 500mbps, it can be split to 80mbps at eNB and 420mbps at gNB. Then eNB controls the DL UE AMBR at 80mbps for LTE bearer while gNB controls at 420mbps for NSA bearer, which cannot be shared. In this solution, as some DL UE AMBR is to be reservered in the 4G, then 5G can not get the full DL UE AMBR value 500mbps.

[0279] The second conventional solution is a dynamic DL UE AMBR value exhange between 4G and 5G via signalling message. For instance, as shown in FIG. 18B, if Core Network assigns DL UE AMBR at 500mbps, initially it splits at 80mbps at eNB and 420mbps at gNB if there is both 4G bearer and NSA 5G bearer. Later the value between 4G and 5G can be updated timely by X2-AP messges (SgNB modification procedure) or private message between 4G and 5G according its algorithm. For instance, if 4G bearer is released and there is no 4G bearer anymore, then DL UE AMBR 500mbps can be fully assinged to NSA 5G bearer. 3GPP only defines the 4G to 5G X2AP message (SgNB modification procedure) to change UE AMBR. As algorithms require a 5G to 4G UE AMBR value change, 5G to 4G private IE / messages are added for UE AMBR update. Moreover, the signalling between 4G and 5G has some delay and adds additional load.

[0280] The limiations of the first and second solutions described above are advantagously overcome with the One-CU-UP, as LTE bearer and NSA bearer are handled in a single node. Then DL UE AMBR can be consumed by 4G and 5G  simultaneously. As shown in FIG. 19, using One-CU-UP, an exemplary 500mbps DL UE AMBR can be used for both LTE bearer and NSA bearer in any conditions.

[0281] Optimization 5: Dynamic resource allocation in One-CU-UP

[0282] In an implementation, 4G and 5G CU-UP resources are handled in One-CU-UP service. Dynamic resource allocation with LTE GBR preemption can be done as shown in FIG. 20. In the example of FIG. 20, X is the overall resource in One-CU-UP service for both LTE and NR. Y is the maximum CU-UP resource non-GBR for LTE and NR. A is the fixed LTE GBR reserved resource. B is the dynamic LTE GBR preempted resource. C is the remaining LTE+NR non-GBR resource. Resource B is dynamically preempted from Y according to LTE GBR service load condition. C=Y-B is the remaining LTE+NR non-GBR resource.

[0283] Changes to 3GPP specifications can support implementations as follows.

[0284] 3GPP 28.552 5G performance measurements: as common 4G and 5G CU-UP, an eNodeB description for CU-UP related performance measurement can be added to section 5.1.3.

[0285] 3GPP 37.483 E1A: a description that NSA SN transfer and data-forwarding in NSA addition and deletion is optional can be added. Some IEs in E1AP can be modified to optional. Also, E1 setup / reset / config update / resource status reporting procedures can be updated as needed.

[0286] 3GPP 36.423 X2AP: a description that NSA SN transfer and data-forwarding in NSA addition and deletion is optional can be added. Some IEs in X2AP can be modified to be optional.

[0287] 3GPP 37.340 Multi-connectivity: a description that NSA SN transfer and data-forwarding in NSA addition and deletion is optional can be added. An NSA call flow can be updated in section 10.

[0288] ORAN E2AP, E2SM: details about single E2 node (One-CU-UP ) acting as both eNB-CU-UP and gNB-CU-UP can be added.

[0289] It will be understood that implementations and embodiments can be implemented by computer program instructions. These program instructions can be provided to a processor to produce a machine, so that the instructions, which execute on the processor, create means for implementing the actions specified herein. The computer program instructions can be executed by a processor to cause a series of operational steps to be performed by the processor to produce a computer-implemented process so that the instructions, which execute on the processor to provide steps for implementing the actions specified. Moreover, some of the steps can also be performed across more than one processor, such as might arise in a multi-processor computer system or even a group of multiple computer systems. In addition, one or more blocks or combinations of blocks in the flowchart illustration can also be performed concurrently with other blocks or combinations of blocks, or even in a different sequence than illustrated without departing from the scope or spirit of the disclosure.

Claims

1.An apparatus for RAN comprising:a One-Centralized-Unit-User-Plane (One-CU-UP) deployed in a same 4G and 5G Cloud Network Function (CNF) configured to support a Long Term Evolution (LTE) eNB CU-UP and a New Radio (NR) gNB CU-UP.2.The apparatus of claim 1, wherein the One-CU-UP is further configured to support an NR Dual Connectivity (NR-DC) gNB-CU-CP CNF, or an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) -NR Dual Connectivity (EN-DC) CU-CP-CNF, or a LTE CU-CP-CNF, or any combination thereof.3.The apparatus of claim 1, wherein the One-CU-UP further comprises:a plurality of interfaces, the interfaces including E1, W1-U, F1-U, S1-U, X2, and NG-U.4.The apparatus of claim 1, wherein the One-CU-UP is configured to support Data Radio Bearer (DRB) Packet Data Convergence Protocol (PDCP) Secondary Node (SN) lengths and NR PDCP SN lengths.5.The apparatus of claim 1, wherein the One-CU-UP comprises:a 4G CU-CNF configured to handle 4G dedicated functions; anda 5G-CU-CNF configured to handle 5G dedicated functions.6.The apparatus of claim 1, wherein the One-CU-UP comprises:the 5G-CU-CNF including a Service Data Adaptation Protocol (SDAP) module; andthe 4G CU-CNF.7.The apparatus of claim 1, wherein the One-CU-UP is configured to comprise a plurality of LTE cells and a plurality of NR cells.8.The apparatus of claim 7 wherein the One-CU-UP is configured to comprise a fast path virtual CPU (vCPU) configured with a maximum throughput for the plurality of LTE cells and the plurality of NR cells.9.The apparatus of claim 7, wherein the One-CU-UP is configured to comprise horizontal scaling with a plurality of data path worker threads, a plurality of data path pods, or both.10.The apparatus of claim 1, wherein the One-CU-UP further comprises an internal data buffer including an internal X2 / Xn-U interface.11.Thea apparatus of claim 9, wherein the One-CU-UP is configured to process 4G data packets and 5G data packets for a single user on a single data path worker thread of the plurality of data path worker threads.12.The apparatus of claim 1, wherein the One-CU-UP comprises:a Master Node (MN) PDCP entity and a SN PDCP entity in a same node.13.The apparatus of claim 1, wherein the One-CU-UP is configured to handle a LTE bearer and a Non-Standalone Architecture (NSA) bearer in a same node.14.The apparatus of claim 13, wherein the One-CU-UP is configured to use a Downlink (DL) User Equipment (UE) Aggregate Maximum Bit Rate (AMBR) for both the LTE bearer and a NSA bearer simultaneously.15.The apparatus of claim 1, wherein the One-CU-UP is configured for dynamic resource allocation with LTE GBR preemption.16.A method comprisingsending by a Master Node (MN) , a UE addition request or UE release request to a Secondary Node (SN) ;establishing a Random Access Procedure between the SN and the User Equipment (UE) ;implementing data forwarding in One-Centralized-Unit-User-Plane (One-CU-UP) comprising an internal data buffer including a Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) for both the MN and the SN and deployed in a same 4G and 5G Cloud Network Function (CNF) configured to support an Long Terme Evolution (LTE) eNB CU-UP and a New Radio (NR) gNB CU-UP; andimplementing a path update procedure for processing both 4G and 5G data packets for the UE over a single data-path worker thread.17.The method of claim 16, wherein the MN is an eNB, the SN is a gNB, and the path update procedure comprises a Protocol Data Unit (PDU) session from the MN to an Access Mobility Function (AMF) , the method further comprising:sending a PDU Session modification indication to the AMF from the MN; andafter the AMF sends a Bearer Modification to a User Plane Function (UPF) , receiving a User Plane Function (UPF) Session Modify Confirmation from the AMF at the MN.18.The method of claim 16, wherein the MN is an eNB, the SN is a gNB, and the path update procedure comprises a session from the MN to a Mobility Management Entity (MME) , further comprising:the path update procedure comprising sending an E-UTRAN Radio Access Bearer (E-RAB) Modification Indication from the MN to an MME; andafter the MME sends a Bearer Modification to a Serving Gateway (S-GW) , receiving an Evolved Universal Terrestrial Radio Access Network Radio Access Bearer (E-RAB) Modification Confirmation from the MME at the MN.19.The method of claim 16, wherein the MN is an eNB, the SN is a gNB, and the path update procedure comprises a Protocol Data Unit (PDU) session from the MN to and AMF, the method further comprising:sending a SN Release Request to the SN from the MN; andafter the Path Update procedure, sending a UE Context Release from the MN to the SN.20.The method of claim 16, wherein the MN is an eNB, the SN is a gNB, and the path update procedure comprises a Protocol Data Unit (PDU) session from the MN to a Mobility Management Entity (MME) , further comprising:sending a SN Release Request to the SN from the MN; andafter the Path Update procedure, sending a UE Context Release from the MN to the SN.

Images