CN116601998A - QOS flow remapping support at handover - Google Patents

QOS flow remapping support at handover Download PDF

Info

Publication number
CN116601998A
CN116601998A CN202180082521.4A CN202180082521A CN116601998A CN 116601998 A CN116601998 A CN 116601998A CN 202180082521 A CN202180082521 A CN 202180082521A CN 116601998 A CN116601998 A CN 116601998A
Authority
CN
China
Prior art keywords
drb
gnb
qos flow
qos
remapping
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202180082521.4A
Other languages
Chinese (zh)
Inventor
韩载珉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of CN116601998A publication Critical patent/CN116601998A/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2491—Mapping quality of service [QoS] requirements between different networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0016—Hand-off preparation specially adapted for end-to-end data sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H04W36/0069—Transmission or use of information for re-establishing the radio link in case of dual connectivity, e.g. decoupled uplink/downlink
    • H04W36/00698—Transmission or use of information for re-establishing the radio link in case of dual connectivity, e.g. decoupled uplink/downlink using different RATs

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Apparatus and systems for lossless handover from a source gNB are described. The gNB-CU-CP determines whether QoS flow remapping for DRBs will occur during handoff and sends a bearer context setup request message for DRBs to the gNB-CU-UP. QoS flow remapping occurs after the transmission of PDCP SDUs for DRBs forwarded from the source gNB is completed. The message includes a PDU session resource to-establish list IE with a QoS map IE for the gNB-CU-UP to use for transmitting SDUs and a QoS remap IE indicating remap. The QoS remap IE has a first value to indicate that QoS flows are to be updated and a second value to indicate that no QoS flows are to be mapped to DRBs.

Description

QOS flow remapping support at handover
Priority statement
The present application claims priority from U.S. provisional patent application serial No. 63/134,743 filed on 7, 1, 2021, which is incorporated herein by reference in its entirety.
Technical Field
Embodiments relate to next generation wireless communications. In particular, some embodiments relate to handovers at a decomposed next generation radio access network (NG-RAN), and even more particularly, to quality of service (QoS) flow remapping at a decomposed NG-RAN handover.
Background
The use and complexity of wireless systems, including 5 th generation (5G) networks and beginning to include 6 th generation (6G) networks, etc., has increased due to the increase in device types of User Equipment (UEs) that use network resources and the increase in the amount of data and bandwidth used by various applications (e.g., video streaming) operating on these UEs. With the substantial increase in the number and diversity of communication devices, the corresponding network environments (including routers, switches, bridges, gateways, firewalls, and load balancers) have become increasingly complex. Without this, the advent of any new technology presents a number of problems.
Drawings
In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The accompanying drawings generally illustrate by way of example, and not by way of limitation, the various embodiments discussed in the present document.
Fig. 1A illustrates an architecture of a network in accordance with some aspects.
Fig. 1B illustrates a non-roaming 5G system architecture in accordance with some aspects.
Fig. 1C illustrates a non-roaming 5G system architecture in accordance with some aspects.
Fig. 2 illustrates a block diagram of a communication device in accordance with some embodiments.
Fig. 3 illustrates an O-RAN system architecture in accordance with some aspects.
Fig. 4 illustrates a logical architecture of the O-RAN system of fig. 3, in accordance with some aspects.
Fig. 5 illustrates an example O-RAN architecture in accordance with some aspects.
Fig. 6 illustrates a flow chart of a Handover (HO) procedure in accordance with some aspects.
Fig. 7 illustrates a bearer context establishment procedure in accordance with some embodiments.
Fig. 8 illustrates a gcb-CU-CP initiated bearer context modification procedure in accordance with some embodiments.
Fig. 9 illustrates a gcb-CU-UP initiated bearer context modification procedure in accordance with some embodiments.
Detailed Description
The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may involve structural, logical, electrical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of others. The embodiments set forth in the claims include all available equivalents of those claims.
Fig. 1A illustrates an architecture of a network in accordance with some aspects. Network 140A includes 3GPP LTE/4G and NG network functions that may be extended to 6G functions. Thus, while reference will be made to 5G, it should be understood that this can be extended to 6G structures, systems and functions. The network functions may be implemented as discrete network elements on dedicated hardware, as software instances running on dedicated hardware, and/or as virtualized functions instantiated on an appropriate platform (e.g., dedicated hardware or cloud infrastructure).
Network 140A is shown to include User Equipment (UE) 101 and UE 102. The UEs 101 and 102 are shown as smartphones (e.g., handheld touch screen mobile computing devices connectable to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a portable (notebook) or desktop computer, wireless handset, drone, or any other computing device including a wired and/or wireless communication interface. The UEs 101 and 102 may be collectively referred to herein as UE 101, and the UE 101 may be configured to perform one or more of the techniques disclosed herein.
Any of the radio links described herein (e.g., as used in network 140A or any other illustrated network) may operate according to any of the example radio communication techniques and/or standards. Any spectrum management scheme includes, for example, private licensed spectrum, unlicensed spectrum, (licensed) shared spectrum (e.g., licensed Shared Access (LSA) in 2.3-2.4GHz, 3.4-3.6GHz, 3.6-3.8GHz, and other frequencies, and Spectrum Access System (SAS) in 3.55-3.7GHz and other frequencies). Different single carrier or Orthogonal Frequency Domain Multiplexing (OFDM) modes (CP-OFDM, SC-FDMA, SC-OFDM, filter bank based multi-carrier (FBMC), OFDMA, etc.), in particular 3GPP NR, may be used by allocating OFDM carrier data bit vectors to the corresponding symbol resources.
In some aspects, either of the UEs 101 and 102 may include an internet of things (IoT) UE or a cellular IoT (CIoT) UE, which may include a network access layer designed for low power IoT applications that utilize short-lived UE connections. In some aspects, either of the UEs 101 and 102 may include Narrowband (NB) IoT UEs (e.g., enhanced NB-IoT (eNB-IoT) UEs and further enhanced (FeNB-IoT) UEs). IoT UEs may exchange data with machine-to-machine (M2M) or machine-type communication (MTC) servers or devices through Public Land Mobile Networks (PLMNs), proximity-based services (ProSe) or device-to-device (D2D) communications, sensor networks, or IoT networks using technologies such as MTC. The M2M or MTC data exchange may be a machine initiated data exchange. The IoT network includes interconnected IoT UEs that may include uniquely identifiable embedded computing devices (within the internet infrastructure) with short-lived connections. The IoT UE may execute a background application (e.g., keep-alive messages, status updates, etc.) to facilitate connection of the IoT network. In some aspects, either of the UEs 101 and 102 may include enhanced MTC (eMTC) UEs or further enhanced MTC (FeMTC) UEs.
The UEs 101 and 102 may be configured to connect (e.g., communicatively couple) with a Radio Access Network (RAN) 110. RAN 110 may be, for example, an evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access network (E-UTRAN), a next generation RAN (NG RAN), or other type of RAN.
The UEs 101 and 102 utilize connections 103 and 104, respectively, each of which includes a physical communication interface or layer (discussed in further detail below); in this example, connections 103 and 104 are shown as air interfaces that enable communicative coupling, and may conform to cellular communication protocols, such as global system for mobile communications (GSM) protocols, code Division Multiple Access (CDMA) network protocols, push-to-talk (PTT) protocols, PTT Over Cellular (POC) protocols, universal Mobile Telecommunications System (UMTS) protocols, 3GPP Long Term Evolution (LTE) protocols, 5G protocols, 6G protocols, and so forth.
In one aspect, the UEs 101 and 102 may further exchange communication data directly through the ProSe interface 105. ProSe interface 105 may also be referred to as a Side Link (SL) interface that includes one or more logical channels including, but not limited to, a physical side link control channel (PSCCH), a physical side link shared channel (PSSCH), a physical side link discovery channel (PSDCH), a physical side link broadcast channel (PSBCH), and a physical side link feedback channel (PSFCH).
UE 102 is shown configured to access an Access Point (AP) 106 via a connection 107. Connection 107 may comprise a local wireless connection, e.g., a connection conforming to any IEEE 802.11 protocol, according to which AP 106 may comprise wireless fidelityAnd a router. In this example, the AP 106 is shown connected to the internet and not to the core network of the wireless system (described in further detail below).
RAN 110 may include one or more access nodes that enable connections 103 and 104. These Access Nodes (ANs) may be referred to as Base Stations (BS), nodebs, evolved nodebs (enbs), next generation nodebs (gnbs), RAN nodes, etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a geographic area (e.g., cell). In some aspects, communication nodes 111 and 112 may be transmission/reception points (TRP). In the case where the communication nodes 111 and 112 are nodebs (e.g., enbs or gnbs), one or more TRPs may function within the communication cell of the NodeB. RAN 110 may include one or more RAN nodes (e.g., macro RAN node 111) for providing macro cells and one or more RAN nodes (e.g., low Power (LP) RAN node 112) for providing femto cells or pico cells (e.g., cells with smaller coverage areas, smaller user capacities, or higher bandwidths than macro cells).
Either of the RAN nodes 111 and 112 may terminate (terminate) the air interface protocol and may be the first point of contact for the UEs 101 and 102. In some aspects, either of RAN nodes 111 and 112 may implement various logical functions of RAN 110 including, but not limited to, radio Network Controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. In an example, any of nodes 111 and/or 112 may be a gNB, eNB, or other type of RAN node.
RAN 110 is shown communicatively coupled to a Core Network (CN) 120 through an S1 interface 113. In various aspects, the CN 120 may be an Evolved Packet Core (EPC) network, a next generation packet core (NPC) network, or some other type of CN (e.g., as shown with reference to fig. 1B-1C). In this aspect, the S1 interface 113 is divided into two parts: an S1-U interface 114 that carries traffic data between RAN nodes 111 and 112 and serving gateway (S-GW) 122; and an S1 Mobility Management Entity (MME) interface 115, which is a signaling interface between RAN nodes 111 and 112 and MME 121.
In this aspect, the CN 120 includes an MME 121, an S-GW 122, a Packet Data Network (PDN) gateway (P-GW) 123, and a Home Subscriber Server (HSS) 124.MME 121 may be similar in function to the control plane of a conventional serving General Packet Radio Service (GPRS) support node (SGSN). MME 121 may manage mobility aspects in the access such as gateway selection and tracking area list management. HSS 124 may include a database of network users including subscription-related information used to support network entity handling communication sessions. The CN 120 may include one or several HSS 124 depending on the number of mobile subscribers, the capacity of the device, the organization of the network, etc. For example, the HSS 124 may provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, and the like.
S-GW 122 may terminate S1 interface 113 towards RAN 110 and route data packets between RAN 110 and CN 120. Furthermore, the S-GW 122 may be a local mobility anchor for inter-RAN node handover and may also provide an anchor for inter-3 GPP mobility. Other responsibilities of S-GW 122 may include lawful interception, charging, and some policy enforcement.
The P-GW 123 may terminate the SGi interface towards the PDN. The P-GW 123 may route data packets between the CN 120 and external networks, e.g., networks including an application server 184 (or referred to as an Application Function (AF)), through an Internet Protocol (IP) interface 125. The P-GW 123 may also transmit data to other external networks 131A, which other external networks 131A may include the internet, an IP multimedia Subsystem (IPs) network, and other networks. In general, the application server 184 may be an element that provides an application that uses IP bearer resources with a core network (e.g., UMTS Packet Service (PS) domain, LTE PS data service, etc.). In this aspect, P-GW 123 is shown communicatively coupled to application server 184 through IP interface 125. The application server 184 may also be configured to support one or more communication services (e.g., voice over internet protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs 101 and 102 through the CN 120.
The P-GW 123 may also be a node for policy enforcement and charging data collection. Policy and Charging Rules Function (PCRF) 126 is a policy and charging control element of CN 120. In a non-roaming scenario, in some aspects, there may be a single PCRF in the Home Public Land Mobile Network (HPLMN) associated with an internet protocol connectivity access network (IP-CAN) session of the UE. In a roaming scenario with local traffic disruption, there may be two PCRFs associated with the IP-CAN session of the UE: a home PCRF (H-PCRF) within the HPLMN, and a visited PCRF (V-PCRF) within the Visited Public Land Mobile Network (VPLMN). PCRF 126 may be communicatively coupled to application server 184 through P-GW 123.
In some aspects, the communication network 140A may be an IoT network or a 5G or 6G network, including a 5G new radio network that uses communication in licensed (5G NR) and unlicensed (5G NR-U) spectrum. One of the current IoT implementations is the narrowband IoT (NB-IoT). Operations in the unlicensed spectrum may include Dual Connectivity (DC) operations and independent LTE systems in the unlicensed spectrum according to which LTE-based techniques operate only in the unlicensed spectrum without using "anchors" in the licensed spectrum, known as multewire. In future releases and 5G systems, it is desirable to further enhance the operation of LTE systems in licensed and unlicensed spectrum. Such enhanced operations may include techniques for side link resource allocation and UE processing behavior for NR side link V2X communications.
The NG system architecture (or 6G system architecture) may include RAN 110 and 5G core network (5 GC) 120.NG-RAN 110 may include multiple nodes, such as a gNB and NG-eNB. The CN 120 (e.g., 5G core network/5 GC) may include Access and Mobility Functions (AMFs) and/or User Plane Functions (UPFs). The AMF and UPF may be communicatively coupled to the gNB and the NG-eNB through NG interfaces. More specifically, in some aspects, the gNB and NG-eNB may connect to the AMF through a NG-C interface and to the UPF through a NG-U interface. The gNB and NG-eNB may be coupled to each other via an Xn interface.
In some aspects, the NG system architecture may use reference points between various nodes. In some aspects, each gNB and NG-eNB may be implemented as a base station, a mobile edge server, a small cell, a home eNB, or the like. In some aspects, in a 5G architecture, the gNB may be a Master Node (MN) and the NG-eNB may be a Slave Node (SN).
Fig. 1B illustrates a non-roaming 5G system architecture in accordance with some aspects. In particular, fig. 1B shows a 5G system architecture 140B, represented by a reference point, which can be extended to a 6G system architecture. More specifically, UE 102 may communicate with RAN 110 and one or more other 5GC network entities. The 5G system architecture 140B includes a plurality of Network Functions (NF), such as AMF 132, session Management Function (SMF) 136, policy Control Function (PCF) 148, application Function (AF) 150, UPF 134, network Slice Selection Function (NSSF) 142, authentication server function (AUSF) 144, and Unified Data Management (UDM)/Home Subscriber Server (HSS) 146.
The UPF 134 may provide a connection to a Data Network (DN) 152, which may include, for example, operator services, internet access, or third party services. The AMF 132 may be used to manage access control and mobility and may also include network slice selection functionality. The AMF 132 may provide UE-based authentication, authorization, mobility management, etc., and may be independent of access technology. The SMF 136 may be configured to set up and manage various sessions according to network policies. Thus, the SMF 136 may be responsible for session management and assignment of IP addresses to UEs. The SMF 136 may also select and control the UPF 134 for data transmission. The SMF 136 may be associated with a single session of the UE 101 or multiple sessions of the UE 101. That is, the UE 101 may have multiple 5G sessions. Each session may be assigned a different SMF. Using different SMFs may allow each session to be managed separately. Thus, the functionality of each session may be independent of the other.
The UPF 134 can be deployed in one or more configurations depending on the type of service desired and can be connected to a data network. PCF 148 may be configured to provide a policy framework (similar to PCRF in 4G communication systems) that uses network slicing, mobility management, and roaming. The UDM may be configured to store subscriber profiles and data (similar to HSS in a 4G communication system).
AF 150 may provide information about the packet flow to PCF 148 responsible for policy control to support the desired QoS. PCF 148 may set mobility and session management policies for UE 101. To this end, PCF 148 may use the packet flow information to determine an appropriate policy for the appropriate operation of AMF 132 and SMF 136. The AUSF 144 may store data for UE authentication.
In some aspects, the 5G system architecture 140B includes an IP Multimedia Subsystem (IMS) 168B and a plurality of IP multimedia core network subsystem entities, such as Call Session Control Functions (CSCFs). More specifically, the IMS 168B includes CSCFs that may act as proxy CSCF (P-CSCF) 162B, serving CSCF (S-CSCF) 164B, emergency CSCF (E-CSCF) (not shown in FIG. 1B), or interrogating CSCF (I-CSCF) 166B. P-CSCF 162B may be configured as a first point of contact for UE 102 within IM Subsystem (IMs) 168B. S-CSCF 164B may be configured to handle session states in the network and E-CSCF may be configured to handle certain aspects of emergency sessions, such as routing emergency requests to the correct emergency center or PSAP. I-CSCF 166B may be configured to act as a point of contact for all IMS connections within the operator's network that are destined for subscribers of the network operator or roaming subscribers currently located within the service area of the network operator. In some aspects, I-CSCF 166B may be connected to another IP multimedia network 170E, e.g., an IMS operated by a different network operator.
In some aspects, the UDM/HSS 146 may be coupled to an application server 160E, which application server 160E may include a Telephony Application Server (TAS) or other Application Server (AS). AS 160B may be coupled to IMS 168B through S-CSCF 164B or I-CSCF 166B.
The reference point representation shows that there may be interactions between the corresponding NF services. For example, fig. 1B shows the following reference points: n1 (between UE 102 and AMF 132), N2 (between RAN 110 and AMF 132), N3 (between RAN 110 and UPF 134), N4 (between SMF 136 and UPF 134), N5 (between PCF 148 and AF 150, not shown), N6 (between UPF 134 and DN 152), N7 (between SMF 136 and PCF 148, not shown), N8 (between UDM 146 and AMF 132, not shown), N9 (between two UPF 134, not shown), N10 (between UDM 146 and SMF 136, not shown), N11 (between AMF 132 and SMF 136), N12 (between AUSF 144 and AMF 132, not shown), N13 (between AUSF 144 and UDM 146, not shown), N14 (between PCF 148 and AMF 132 in the case of a non-roaming scenario, or between PCF 148 and AMF 132, not shown), N16 (between AMF 142 and nsf 132, not shown), N11 (between AMF 132 and nsf 132, not shown). Other reference point representations not shown in fig. 1B may also be used.
Fig. 1C shows a 5G system architecture 140C and a service-based representation. In addition to the network entities shown in fig. 1B, the system architecture 140C may also include a Network Exposure Function (NEF) 154 and a Network Repository Function (NRF) 156. In some aspects, the 5G system architecture may be service-based, and interactions between network functions may be represented by respective point-to-point reference points Ni, or as service-based interfaces.
In some aspects, as shown in fig. 1C, the service-based representation may be used to represent network functions within the control plane that enable other authorized network functions to access their services. In this aspect, 5G system architecture 140C may include the following service-based interfaces: namf 158H (service-based interface presented by AMF 132), nsmf 158I (service-based interface presented by SMF 136), nnef 158B (service-based interface presented by NEF 154), npcf 158D (service-based interface presented by PCF 148), nudm 158E (service-based interface presented by UDM 146), naf 158F (service-based interface presented by AF 150), nnrf 158C (service-based interface presented by NRF 156), nnssf 158A (service-based interface presented by NSSF 142), nausf 158G (service-based interface presented by AUSF 144). Other service-based interfaces not shown in fig. 1C (e.g., nudr, N5g-eir, and Nudsf) may also be used.
The NR-V2X architecture may support high reliability low latency side link communications with multiple traffic patterns, including periodic and aperiodic communications with random packet arrival times and sizes. The techniques disclosed herein may be used to support high reliability in distributed communication systems with dynamic topologies, including side link NR V2X communication systems.
Fig. 2 illustrates a block diagram of a communication device in accordance with some embodiments. The communication device 200 may be a UE (e.g., a dedicated computer, a personal or notebook computer (PC), a tablet PC, or a smart phone), a dedicated network device (e.g., an eNB), server running software configuring a server to operate as a network device, a virtual device, or any machine capable of executing instructions (sequentially or otherwise) specifying actions to be taken by the machine. For example, the communication device 200 may be implemented as one or more of the devices shown in fig. 1A-1C. Note that the communications described herein may be encoded prior to transmission by a transmitting entity (e.g., UE, gNB) for receipt by a receiving entity (e.g., gNB, UE) and decoded after receipt by the receiving entity.
Examples as described herein may include or may operate on logic or several components, modules, or mechanisms. Modules and components are tangible entities (e.g., hardware) that are capable of performing specified operations and that may be configured or arranged in a manner. In an example, the circuits may be arranged as modules in a specified manner (e.g., internally or to an external entity, such as other circuits). In an example, all or part of one or more computer systems (e.g., stand-alone, client, or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application portions, or applications) as modules that operate to perform specified operations. In an example, the software may reside on a machine readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.
Thus, the term "module" (and "component") is understood to encompass a tangible entity, be it physically constructed, a specially configured (e.g., hardwired), or a temporarily (e.g., transient) configured (e.g., programmed) entity to operate in a specified manner or to perform some or all of any of the operations described herein. Considering the example where modules are temporarily configured, it is not necessary to instantiate each module at any one time. For example, where a module includes a general-purpose hardware processor configured with software, the general-purpose hardware processor may be configured as each of the different modules at different times. The software may accordingly configure the hardware processor to constitute one particular module at one time and another module at another time, for example.
The communication device 200 may include a hardware processor (or equivalent processing circuit) 202 (e.g., a Central Processing Unit (CPU), GPU, hardware processor core, or any combination thereof), a main memory 204, and a static memory 206, some or all of which may communicate with each other via an interconnect (e.g., bus) 208. Main memory 204 may include any or all of removable storage and non-removable storage, volatile memory, or nonvolatile memory. The communication device 200 may also include a display unit 210, such as a video display, an alphanumeric input device 212 (e.g., a keyboard), and a User Interface (UI) navigation device 214 (e.g., a mouse). In an example, display unit 210, input device 212, and UI navigation device 214 may be touch screen displays. The communication device 200 may also include a storage device (e.g., a drive unit) 216, a signal generation device 218 (e.g., a speaker), a network interface device 220, and one or more sensors, such as a Global Positioning System (GPS) sensor, compass, accelerometer, or other sensor. The communication device 200 may also include an output controller, such as a serial (e.g., universal Serial Bus (USB)), parallel, or other wired or wireless (e.g., infrared (IR), near Field Communication (NFC), etc.) connection to communicate with or control one or more peripheral devices (e.g., printer, card reader, etc.).
The storage device 216 may include a non-transitory machine-readable medium 222 (hereinafter machine-readable medium) on which is stored one or more sets of data structures or instructions 224 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions 224 may also reside, completely or at least partially, within the main memory 204, within the static memory 206, and/or within the hardware processor 202 during execution thereof by the communication device 200. While the machine-readable medium 222 is shown to be a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 224.
The term "machine-readable medium" can include any medium that can store, encode, or carry instructions for execution by the communication device 200 and that cause the communication device 200 to perform any one or more of the techniques of this disclosure, or that can store, encode, or carry data structures used by or associated with such instructions. Non-limiting examples of machine readable media may include solid state memory, as well as optical and magnetic media. Specific examples of machine-readable media may include: nonvolatile memory such as semiconductor memory devices (e.g., electrically Programmable Read Only Memory (EPROM), electrically Erasable Programmable Read Only Memory (EEPROM)), and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disk; random Access Memory (RAM); CD-ROM and DVD-ROM discs.
The instructions 224 may also be transmitted or received over a communications network using a transmission medium 226 via the network interface device 220 using any of a number of Wireless Local Area Network (WLAN) transmission protocols (e.g., frame relay, internet Protocol (IP), transmission Control Protocol (TCP), user Datagram Protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a Local Area Network (LAN), a Wide Area Network (WAN), a packet data network (e.g., the internet), a mobile telephone network (e.g., a cellular network), a Plain Old Telephone (POTS) network, and a wireless data network. Communications over the network may include one or more different protocols, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards (referred to as Wi-Fi), the IEEE 802.16 family of standards (referred to as WiMax), the IEEE 802.15.4 family of standards, the Long Term Evolution (LTE) family of standards, the Universal Mobile Telecommunications System (UMTS) family of standards, point-to-point (P2P) networks, the Next Generation (NG)/fifth generation (5G) standards, and so forth. In an example, the network interface device 220 may include one or more physical jacks (e.g., ethernet, coaxial, or telephone jacks) or one or more antennas to connect to the transmission medium 226.
Note that the term "circuitry" as used herein refers to, is part of, or includes, hardware components configured to provide the described functionality, such as electronic circuitry, logic circuitry, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a Field Programmable Device (FPD) (e.g., a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a Complex PLD (CPLD), a high-capacity PLD (hcpll), a structured ASIC, or a programmable SoC), a Digital Signal Processor (DSP), or the like. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term "circuitry" may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) and program code for performing the functions of the program code. In these embodiments, a combination of hardware elements and program code may be referred to as a particular type of circuit.
Thus, the term "processor circuit" or "processor" as used herein refers to, is part of, or includes the following circuitry: the circuit is capable of sequentially and automatically performing a series of arithmetic or logical operations, or recording, storing and/or transmitting digital data. The term "processor circuit" or "processor" may refer to one or more application processors, one or more baseband processors, a physical Central Processing Unit (CPU), a single or multi-core processor, and/or any other device capable of executing or otherwise operating computer-executable instructions (e.g., program code, software modules, and/or functional processes).
Any of the radio links described herein may operate in accordance with any one or more of the following radio communication technologies and/or standards, including, but not limited to: global system for mobile communications (GSM) radio communications technology, general Packet Radio Service (GPRS) radio communications technology, enhanced data rates for GSM evolution (EDGE) radio communications technology, and/or third generation partnership project (3 GPP) radio communications technology, such as Universal Mobile Telecommunications System (UMTS), free multimedia access (FOMA), 3GPP Long Term Evolution (LTE), 3GPP long term evolution advanced (LTE-advanced), code division multiple access 2000 (CDMA 2000), cellular Digital Packet Data (CDPD), mobitex, third generation (3G), circuit Switched Data (CSD), high Speed Circuit Switched Data (HSCSD), universal mobile telecommunications system (third generation) (UMTS (3G)), wideband code division multiple access (universal mobile telecommunications system) (W-CDMA (UMTS)), high Speed Packet Access (HSPA), high Speed Downlink Packet Access (HSDPA), high Speed Uplink Packet Access (HSUPA), high speed packet access+ (a+), universal mobile telecommunications system time division duplex (UMTS-TDD), time division multiple access (HSPA-CDMA), time division multiple access (TD-synchronization (TD), third generation partnership project (TD-4) (3G), release 4 (release 4, release 4 (release 9.3G)), wideband code division multiple access (3 partnership project 4 (3G), 3GPP release 4 (release 9, release 4, 3.3G) 3GPP rel.11 (3 rd generation partnership project release 11), 3GPP rel.12 (3 rd generation partnership project release 12), 3GPP rel.13 (3 rd generation partnership project release 13), 3GPP rel.14 (3 rd generation partnership project release 14), 3GPP rel.15 (3 rd generation partnership project release 15), 3GPP rel.16 (3 rd generation partnership project release 16), 3GPP rel.17 (3 rd generation partnership project release 17) and subsequent releases (e.g., rel.18, rel.19, etc.), 3GPP 5G, 5G new radio (5G NR), 3GPP 5G new radio, 3GPP LTE extension, LTE advanced specialty, LTE Licensed Assisted Access (LAA), muLTEfire, UMTS Terrestrial Radio Access (UTRA), evolved UMTS terrestrial radio access (E-UTRA), long term evolution advanced (fourth generation) (LTE advanced (4G)), cdmaOne (2G), code division multiple access 2000 (third generation) (CDMA 2000 (3G)), optimized evolution data or evolution-only data (EV-DO), advanced mobile phone system (first generation) (AMPS (1G)), full access communication system/extended full access communication system (TACS/ETACS), digital AMPS (second generation) (D-AMPS (2G)), push-to-talk (PTT), mobile phone system (MTS), improved mobile phone system (IMTS), advanced mobile phone system (AMTS), norway (Offentlig Landmobil Telefoni, public land mobile phone) MTD (abbreviation of Swedish Mobiltelefonisystem D, or mobile phone system D), public automated land Mobile (Autotel/PALM), ARP (Autoloadiopuhin, "automotive radiotelephone"), NMT (Nordic Mobile telephone), a high capacity version of NTT (Japanese telecom telephone) (Hicap), cellular Digital Packet Data (CDPD), mobitex, dataTAC, integrated Digital Enhanced Network (iDEN), personal Digital Cellular (PDC), circuit Switched Data (CSD), personal handhelds phone system (PHS), broadband integrated digital enhanced network (WiDEN), iBurst, unlicensed Mobile Access (UMA), also known as 3GPP Universal Access network or GAN standard), zigbee, bluetooth (r), wireless systems operating at 10-300GHz and above, such as Wigig, IEEE 802.11ad, IEEE 802.11ay, etc.), technologies operating at 300GHz and THz bands, (reporting to other systems (e.g., systems operating in accordance with the 3GPP/LTE, IEEE 802.11, IEEE 11 or other short range communication systems (35) or other vehicles (usually by the public transport infrastructure) in accordance with the standard of 3GPP universal access network or GAN), zigbee, bluetooth (r), wireless gigabit (Wigig., IEEE 802.11ad, IEEE 802.11ay, and IEEE 2 MHz, and other vehicles (usually reporting (35) systems, 3 MHz and other communication infrastructure (35) systems, 3 MHz, 4 to the vehicle infrastructure (35) and other vehicles are usually the communication infrastructure (35) and (35) systems and the communication infrastructure (35) are generally, and the infrastructure (35I and 2 systems are generally the system and the infrastructure (2), the European style of IEEE 802.11 p-based DSRC includes ITS-G5A (i.e., ITS-G5 operated in the European ITS band dedicated to safety-related applications in the frequency range 5875GHz to 5905 GHz), ITS-G5B (i.e., operated in the European ITS band dedicated to ITS non-safety applications in the frequency range 5855GHz to 5875 GHz), ITS-G5C (i.e., ITS application operated in the frequency range 5470GHz to 5725 GHz)), DSRC in Japan in the 700MHz band (including 715MHz to 725 MHz), IEEE 802.11 bd-based systems, and so forth.
The various aspects described herein may be used in the context of any spectrum management scheme including dedicated licensed spectrum, unlicensed spectrum, licensed exempt spectrum, (licensed) shared spectrum (e.g., licensed Shared Access (LSA) in frequencies 2.3-2.4GHz, 3.4-3.6GHz, 3.6-3.8GHz and above, and Spectrum Access System (SAS)/Citizen Broadband Radio System (CBRS) in frequencies 3.55-3.7GHz and above). Suitable spectral bands include IMT (international mobile communications) spectrum and other types of spectrum/bands such as bands with national allocations (including 450-470MHz, 902-928MHz (note: e.g., allocated in US (FCC part 15)), 863-868.6MHz (note: e.g., allocated in the european union (ETSI EN 300 220)), 915.9-929.7MHz (note: e.g., allocated in japan), 917-923.5MHz (note: e.g., allocated in korea), 755-779MHz and 779-787MHz (note: e.g., allocated in china), 790-960MHz, 1710-2025MHz, 2110-2200MHz, 2300-2400MHz, 2.4-2.4835GHz (note: which is an ISM band with global availability), and which is used by the-Fi technology series (11 b/g/n/ax) and bluetooth), 2500-2690MHz, 698-790MHz, 610-790.7 MHz, 0-3600MHz, 0-3 MHz, and 3.7 MHz (note: e.g., allocated in china), and 3-2025 MHz (note: e.25.g., allocated in EU), and 775.725 (note: e.g., allocated in EU 5 i.25-5 GHz), total, and 60.725 (note: e.g., allocated in EU 25-5.g., EU 5 MHz), and 60-5.725 (see e.g., normal bands such as those in EU 25.25.25.25.25.725, 25.725, which are allocated in the whole, and 60.725 radio bands (e.g., the internet bands). The next generation Wi-Fi system is expected to include the 6GHz spectrum as the operating band, but notably, by 12 months in 2017, wi-Fi systems have not been allowed to be used in that band. The regulations are expected to be completed in 2019-2020, IMT advanced spectrum, IMT-2020 spectrum (which is expected to include 3600-3800MHz, 3800-4200MHz, 3.5GHz band, 700MHz band, 24.25-86GHz band, etc.), spectrum available under the FCC "front of spectrum" 5G initiative (including 27.5-28.35GHz, 29.1-29.25GHz, 31-31.3GHz, 37-38.6GHz, 38.6-40GHz, 42-42.5GHz, 57-64GHz, 71-76GHz, 81-86GHz, 92-94GHz, etc.), ITS (intelligent transportation system) band currently allocated to WiGig (e.g., wiGig band 1 (57.24-59.40 GHz), wiGig band 2 (59.40-61.56 GHz), and wig 3GHz (61.56-63.72 GHz), and wig band (78-96 GHz), and a total of which is allocated to the radio spectrum (e.g., 35-96 GHz) and 35GHz band (which is allocated to the future radio system) of 35.85-5.85-5.925 GHz and 63-64GHz, and the other bands (e.g., 35-64 GHz), and the other bands (which are allocated to the future radio bands (e.g., 35-96 GHz) of the future radio system) are allocated to the future radio bands (35-71 GHz and 35 GHz-96 GHz) and 35GHz (which are allocated to the future-allocated portions of the radio bands (e.g.g.g.35-71-35 GHz and 35-71 and 35 GHz-71, and 35-71-15) and the future-allocated to the future-allocated bands). Furthermore, the scheme may be used on the basis of assistance of frequency bands such as the TV white space band (typically below 790 MHz), with 400MHz and 700MHz frequency bands being promising candidate frequency bands. In addition to cellular applications, specific applications in the vertical market may also be addressed, such as PMSE (programming and special events), medical, health, surgical, automotive, low latency, drone, etc. applications.
Various aspects described herein can also enable hierarchical application of an aspect, such as by introducing hierarchical usage priorities for different types of users (e.g., low/medium/high priority, etc.) based on priority access to spectrum, such as a level 1 user having the highest priority, followed by a level 2 user, followed by a level 3 user, etc.
Various aspects described herein may also be applied to different single carriers or OFDM types (CP-OFDM, SC-FDMA, SC-OFDM, filter group based multi-carrier (FBMC), OFDMA, etc.), by allocating OFDM carrier data bit vectors to corresponding symbol resources (in particular, 3GPP NR (new radio)).
Some features in this document are defined for the network side, e.g. AP, eNB, NR, or gNB, noting that this term is commonly used in the context of 3gpp 5G and 6G communication systems, etc. Nonetheless, the UE may also play this role and act as an AP, eNB or gNB; that is, some or all of the features defined for the network device may be implemented by the UE.
As described above, fig. 3 illustrates an O-RAN system architecture in accordance with some aspects. Fig. 3 provides a high-level view of an O-RAN architecture 300. The O-RAN architecture 300 includes four O-RAN defined interfaces, namely an A1 interface, an O2 interface, and an open forwarding management (M) plane interface, that connect a Service Management and Orchestration (SMO) framework 302 to O-RAN Network Functions (NF) 304 and O-clouds 306.
The O1 interface is an interface between an Orchestration/NMS entity (organization/NMS) and an O-RAN management element for operation and management, through which FCAPS management, software management, file management, and other similar functions are implemented. The O2 interface is the interface between the SMO framework and O-Cloud. The A1 interface is an interface between Non-RT RIC and Near-RT RIC to implement policy driven guidance of Near-RT RIC applications/functions and support AI/ML workflow.
SMO 302 is also connected to an external system 310, external system 310 providing SMO 302 with additional configuration data. Fig. 3 also shows an A1 interface connecting an O-RAN non-real-time (RT) RAN Intelligent Controller (RIC) 312 in SMO 302 or at SMO 302 and an O-RAN Near-RT RIC 314 in O-RAN NF 304 or at O-RAN NF 304. The O-RAN NF 304 may be a Virtualized Network Function (VNF), such as a Virtual Machine (VM) or container, located on top of the O-Cloud 306 and/or a Physical Network Function (PNF) using custom hardware. When interfacing with SMO framework 302, it is desirable that all O-RANs NF 304 support the O1 interface. The O-RAN NF 304 is connected to NG-Core 308 via an NG interface (this is a 3GPP defined interface). The open forward M-plane interface between SMO 302 and O-RAN radio unit (O-RU) 316 supports O-RU 316 management in the O-RAN hybrid model. The open forward M-plane interface is an optional interface to SMO 302 that is included for backward compatibility purposes and is used only to manage O-RU 316 in hybrid mode. The O-RU 316 terminal of the O1 interface is oriented towards SMO 302.
Fig. 4 illustrates a logical architecture of the O-RAN system of fig. 3, in accordance with some aspects. Fig. 4 illustrates an O-RAN logical architecture 400 corresponding to the O-RAN architecture 300 of fig. 3. In FIG. 4, SMO 402 corresponds to SMO 302, O-Cloud 406 corresponds to O-Cloud 306, non-RT RIC 412 corresponds to Non-RT RIC 312, near-RT RIC 414 corresponds to Near-RT RIC 314, and O-RU 416 corresponds to O-RU 316 of FIG. 3, respectively. The O-RAN logical architecture 400 includes a radio part and a management part.
The management portion/side of architecture 400 includes SMO framework 402 containing Non-RT RIC 412 and may include O-Cloud 406.O-Cloud 406 is a Cloud computing platform that includes a collection of physical infrastructure nodes to host related O-RAN functions (e.g., near-RT RIC 414, O-RAN central unit-control plane (O-CU-CP) 421, O-RAN central unit-user plane (O-CU-UP) 422, and O-RAN distributed units (O-DU) 415), supporting software components (e.g., OS, VMM, container runtime engines, ML engines, etc.), and appropriate management and orchestration functions.
The radio part/side of the logical architecture 400 includes Near-RT RIC 414, O-RAN distributed units (O-DUs) 415, O-RUs 416, O-RAN central unit-control plane (O-CU-CP) 421, and O-RAN central unit-user plane (O-CU-UP) 422 functions. The radio portion/side of the logical architecture 400 may also include an O-e/gNB 410.
O-DU 415 is a logical node that hosts: radio Link Control (RLC), medium Access Control (MAC) and higher Physical (PHY) layer entities/elements (higher PHY layer) based on lower layer functional partitioning. O-RU 416 is a logical node that hosts: lower PHY layer entities/elements (lower PHY layers) based on lower layer functional partitioning (e.g., inverse fast fourier transform/inverse fast fourier transform (FFT/iFFT), physical Random Access Channel (PRACH) extraction, etc.) and RF processing elements. The O-CU-CP 421 is a logical node that hosts the Control Plane (CP) portion of the Radio Resource Control (RRC) and Packet Data Convergence Protocol (PDCP) protocols. O-CU-UP 422 is a logical node that hosts the user plane portion of the PDCP protocol and the Service Data Adaptation Protocol (SDAP) protocol.
The E2 interface terminates a plurality of E2 nodes. The E2 node is a logical node/entity terminating the E2 interface. For NR/5G access, the E2 node comprises an O-CU-CP 421, an O-CU-UP 422, an O-DU 415, or any combination of elements. For E-UTRA access, the E2 node includes an O-E/gNB 410. As shown in FIG. 4, the E2 interface also connects O-E/gNB 410 to Near-RT RIC 414. The protocol over the E2 interface is based solely on the CP protocol. The E2 functions are grouped into the following categories: (a) Near-RT RIC 414 services (REPORT, INSERT, CONTROL and POLICY); and (b) Near-RT RIC 414 support functions including E2 interface management (E2 setup, E2 reset, reporting of general error conditions, etc.) and Near-RT RIC service updates (e.g., capability exchange related to E2 node function lists published by E2).
Fig. 4 shows Uu interfaces between UE 401 and O-e/gNB 410 and between UE 401 and O-RAN components. The Uu interface is a 3GPP defined interface that includes the complete protocol stack from L1 to L3 and terminates NG-RAN or E-UTRAN. O-E/gNB 410 is an LTE eNB, 5G gNB, or ng-eNB supporting an E2 interface. The O-e/gNB 410 can be the same as or similar to other RAN nodes discussed previously. UE 401 may correspond to the previously discussed UE, etc. There may be multiple UEs 401 and/or multiple O-e/gnbs 410, each of which may be connected to each other via a respective Uu interface. Although not shown in FIG. 4, O-e/gNB 410 supports O-DU 415 and O-RU 416 functions with an Open Forward (OF) interface therebetween.
The OF interface is between the O-DU 415 and O-RU 416 functions. The OF interface includes a Control User Synchronization (CUS) plane and a management (M) plane. Fig. 3 and 4 also show that O-RU 416 terminates an OF M-plane interface towards O-DU 415 and optionally an OF M-plane interface towards SMO 402. O-RU 416 terminates the OF CUS plane interface towards O-DU 415 and SMO 402.
The F1-c interface connects the O-CU-CP 421 with the O-DU 415. The F1-c interface is located between the gNB-CU-CP and the gNB-DU node as defined by 3 GPP. However, for O-RAN purposes, an F1-c interface is employed between the O-CU-CP 421 and O-DU 415 functions, while reusing 3GPP defined principles and protocol stacks and the definition of the interoperability profile (profile) specification.
The F1-u interface connects O-CU-UP 422 with O-DU 415. The F1-u interface is located between gNB-CU-UP and gNB-DU nodes as defined by 3 GPP. However, for O-RAN purposes, the F1-u interface is employed between O-CU-UP 422 and O-DU 415 functions while reusing 3GPP defined principles and protocol stacks and the definition of interoperability profile specifications.
The NG-c interface is defined by 3GPP as the interface between the gNB-CU-CP and AMF in 5 GC. NG-c is also known as the N2 interface. The NG-u interface is defined by 3GPP as an interface between the gNB-CU-UP and the UPF in 5 GC. The NG-u interface is referred to as the N3 interface. In the O-RAN, the NG-c and NG-u protocol stacks defined by the 3GPP are reused and may be adapted for O-RAN purposes.
The X2-c interface is defined in 3GPP for transmitting control plane information in EN-DC between enbs or between an eNB and an EN-gcb. The X2-u interface is defined in 3GPP for transmitting user plane information in EN-DC between enbs or between an eNB and an EN-gcb. In O-RAN, the X2-c and X2-u protocol stacks defined by 3GPP are reused and may be suitable for O-RAN purposes.
An Xn-c interface is defined in 3GPP for transmitting control plane information between the gnbs, ng-enbs or between the ng-enbs and the gnbs. An Xn-u interface is defined in 3GPP for transmitting user plane information between the gnbs, ng-enbs or between the ng-enbs and the gnbs. In O-RAN, the Xn-c and Xn-u protocol stacks defined by 3GPP are reused and may be suitable for O-RAN purposes.
The E1 interface is defined by the 3GPP as the interface between gNB-CU-CP and gNB-CU-UP. In the O-RAN, the E1 protocol stack defined by the 3GPP is reused and adapted as an interface between the O-CU-CP 421 and the O-CU-UP 422 functions.
The O-RAN n-RT RIC 412 is a logic function within the SMO framework 302, 402 that enables Non-real time control and optimization of RAN elements and resources; AI/Machine Learning (ML) workflow, including model training, reasoning, and updating; policy-based guidance of applications/features in Near-RT RIC 414.
The O-RAN Near-RT RIC 414 is a logic function that enables Near real-time control and optimization of RAN elements and resources through fine-grained data collection and actions over the E2 interface. Near-RT RIC 414 may include one or more AI/ML workflows, including model training, reasoning, and updating.
Non-RT RICs 412 may be ML training hosts that host the training of one or more ML models. ML training may be performed offline using data collected from RICs, O-DUs 415, and O-RUs 416. For supervised learning, non-RT RIC 412 is part of SMO 402, and ML training host and/or ML model host/participant may be part of Non-RT RIC 412 and/or Near-RT RIC 414. For unsupervised learning, the ML training host and ML model host/participant may be part of Non-RT RIC 412 and/or Near-RT RIC 414. For reinforcement learning, the ML training host and ML model host/participant may be co-located as part of the Non-RT RIC 412 and/or the Near-RT RIC 414. In some implementations, non-RT RIC 412 may request or trigger ML model training in the training host, regardless of where the model is deployed and executed. The ML model may have been trained but is not currently deployed.
In some embodiments, non-RT RIC 412 provides ML designers/developers with a queriable directory to publish/install trained ML models (e.g., executable software components). In these implementations, non-RT RIC 412 may provide a discovery mechanism as to whether a particular ML model may be executed in a target ML inference host (MF), and what number and type of ML models may be executed in the MF. For example, non-RT RIC 412 may discover three types of ML directories: design-time directories (e.g., residing outside of Non-RT RIC 412 and hosted by some other ML platform), training/deployment-time directories (e.g., residing within Non-RT RIC 412), and runtime directories (e.g., residing within Non-RT RIC 412). Non-RT RIC 412 supports the necessary capabilities of ML model reasoning to support ML auxiliary solutions running in Non-RT RIC 412 or some other ML reasoning host. These capabilities enable executable software to be installed, such as VMs, containers, etc. Non-RT RIC 412 may also include and/or operate one or more ML engines for running ML models, which are packaged software executable libraries that provide methods, routines, data types, etc. Non-RT RIC 412 may also implement policies to switch and activate ML model instances under different operating conditions.
Non-RT RIC 412 may access feedback data (e.g., FM and PM statistics) about ML model performance and perform the necessary evaluations via an O1 interface. If the ML model fails at runtime, an alert may be generated as feedback to the Non-RT RIC 412. How the ML model performs in terms of prediction accuracy or other operational statistics it produces can also be sent to Non-RT RIC 412 via O1. Non-RT RIC 412 may also scale ML model instances running in the target MF over the O1 interface by observing resource utilization in the MF. The environment (e.g., MF) running the instance of the ML model monitors the resource utilization of the running ML model. For example, this may be accomplished in Near-RT RIC 414 and/or Non-RT RIC 412 using an ORAN-SC component called resource monitor, which continuously monitors resource utilization. If the resources are less than or below a particular threshold, the runtime environment in Near-RT RIC 414 and/or Non-RT RIC 412 provides a scaling mechanism to add more ML instances. The scaling mechanism may include scaling factors such as numbers, percentages, and/or other similar data for scaling up/down the number of ML instances. An instance of the ML model running in the target ML inference host can be automatically scaled by observing the resource utilization in the MF. For example, the number of the cells to be processed, The (K8 s) runtime environment typically provides an auto-scaling feature.
The A1 interface is between Non-RT RIC 412 (either inside or outside SMO 402) and Near-RT RIC 414. The A1 interface supports three types of services including policy management services, rich information services, and ML model management services. The A1 policy has the following features with respect to persistent configuration: the A1 strategy is not critical to the flow; a1 strategy has a temporary validity period; the A1 policy may handle a single UE or a dynamically defined group of UEs; a1 policies work in and take precedence over configuration; and the A1 policy is non-persistent, i.e. does not persist after a Near-RT RIC restart.
Fig. 5 illustrates an example O-RAN architecture in accordance with some aspects. As shown, the Near-RT RIC is a logical network node placed between the SMO layer hosting the Non-RT RIC and the E2 node. The Near-RT-RIC logic architecture and associated interfaces are shown in FIG. 5. The Near-RT RIC is connected to the Non-RT RIC via an A1 interface. Near-RT RICs are connected to only one Non-RT RIC. As described above, E2 is a logical interface that connects the Near-RT RIC and E2 nodes. Near-RT RIC is connected to O-CU-CP. Near-RT RIC is connected to O-CU-UP. Near-RT RIC is connected to O-DU. Near-RT RIC is connected to O-eNB. The E2 node is connected to only one Near-RT RIC. The Near-RT RIC may be connected to a plurality of E2 nodes, i.e. a plurality of O-CU-CPs, O-CU-UP, O-DUs and O-eNB. F1 (F1-C, F1-U) and E1 are logical 3GPP interfaces whose protocols, endpoints and cardinalities are specified in 3GPP TS 38.401.
Near-RT RIC hosts one or more xapps that collect Near-real-time information (e.g., UE basis, cell basis) and provide value-added services using an E2 interface. Near-RT RIC may receive declarative policies and obtain data enrichment information over the A1 interface. The protocol on the E2 interface is based on the control plane protocol. In case of E2 or Near-RT RIC failure, the E2 node may provide services, but may interrupt some value added services that can only be provided using Near-RT RIC.
Near-RT RIC provides a database function that stores configuration related to E2 nodes, cells, bearers, flows, UEs, and mappings between them. Near-RT RIC provides ML tools that support data pipelining. Near-RT RICs provide a messaging infrastructure. Near-RT RIC provides logging, tracking, and metric collection from Near-RT RIC framework and xApp to SMO. Near-RT RIC provides security functions. Near-RT RIC supports conflict resolution to resolve potential conflicts or overlaps that may be caused by requests from an xApp.
The Near-RT RIC also provides an open API that enables hosting of the 3 rd party xApp and xApp from the Near-RT RIC platform vendor. Near-RT RIC also provides an open API separate from the particular implementation solution, including a Shared Data Layer (SDL) that acts as an overlay to the underlying database and enables simplified data access.
xApp is an application designed to run on a Near-RT RIC. Such an application might include or provide one or more micro-services and would identify which data it uses and which data to provide when online. xApp is independent of Near-RT RIC and can be provided by any third party. E2 implements a direct association between xApp and RAN functions. RAN functions are specific functions in the E2 node; examples include X2AP, F1AP, E1AP, S1AP, NGAP interfaces and RAN internal functions handling UEs, cells, etc.
The architecture of the xApp has code that implements the logic of the xApp and a RIC library that allows the xApp to: sending and receiving messages; reading from and writing to and retrieving notifications from the SDL layer; and writing a log message. Other libraries will be available in future versions, including libraries for setting and resetting alarms and sending statistics. In addition, xApp can use an access library to access a particular namespace in the SDL layer. For example, the R-NIB may be read by using an R-NIB access library, which provides information about which E2 nodes (e.g., CUs/DUs) the RIC is connected to and which SMs each E2 node supports.
The O-RAN standard interfaces (e.g., O1, A1, and E2) are disclosed to the xApp as follows: xApp receives its configuration through K8s configmap—the configuration can be updated at xApp runtime, and xApp can be notified of this modification using inotify (); xApp may send statistics (PM) by: (a) Directly send it in VES format to VES collector, (b) disclose statistics over REST interface for promethaus collection; the xApp will receive A1 policy guidelines (policy instance creation and deletion operations) through a particular type of RMR message; and xApp can subscribe to E2 events by constructing and sending E2 subscription asn.1 payloads as messages (RMR), xApp will receive E2 messages (e.g., E2 INDICATION) as RMR messages with asn.1 payloads. Similarly, xApp may issue an E2 control message.
In addition to messages related to A1 and E2, xApp may also send messages processed by other xApps and may receive messages generated by other xApps. Communication inside the RIC is policy driven, i.e. the xApp cannot specify the destination of the message-the xApp simply sends a specific type of message, and the routing policy specified for the RIC instance determines to which destinations (logical publish/subscribe) the message is to be delivered.
Logically, an xApp is an entity that implements well-defined functions. Mechanically, xApp is a K8s pod comprising one or more containers. For a deployable xApp, the xApp has an xApp descriptor (e.g., JSON) that describes the configuration parameters of the xApp and the information that the RIC platform uses to configure the RIC platform for the xApp. The xApp developer also provides a JSON architecture for descriptors.
In addition to these basic requirements, xApp can perform any of the following operations: reading initial configuration parameters (passed in xApp descriptor); receiving updated configuration parameters; sending and receiving messages; read and write persistent shared data stores (key value stores); an operation for receiving an A1-P policy directive message, in particular for creating or deleting a policy instance (JSON payload on RMR message) associated with a given policy type; defining a new A1 strategy type; subscribing to the RAN through an E2 interface, receiving an E2 INDICATION message from the RAN, and issuing an E2POLICY and CONTROL message to the RAN; and reports metrics related to RAN events performed or observed by itself.
The lifecycle of xApp development and deployment includes the following states: development: designing, implementing and locally testing; and (3) issuing: the xApp code and xApp descriptor are submitted to the LF Gerrit repository and included in the O-RAN version. xApp is packed into a Docker container and an image thereof is issued to the LF Release registry; load/distribution: the xApp descriptor (and potential palm chart (s)) is customized for a given RIC environment, and the generated customized palm chart is stored in a local palm chart repository used by the xApp manager of the RIC environment; runtime parameter configuration: prior to deploying an xApp, the operator will provide runtime handle diagram parameters to customize xApp Kubernetes deployment instances. The process is mainly used for configuring unique handle chart parameters at the running time, such as instance UUID, liveness check, eastern and northbound service endpoints (e.g. DBAAS portals, VES collector endpoints) and the like; deployment: the xApp has been deployed by the xApp manager and the xApp cabin (pod) is running on the RIC instance. For meaningful xapps, the deployment state can be further divided into other states controlled by xApp configuration updates. For example, running, stopped.
General principles guiding the definition of the Near-RT RIC architecture and the interfaces between Near-RT RIC, E2 nodes and SMO include the following: the Near-RT RIC and E2 node functions are completely separated from the transport functions. The addressing schemes used in the Near-RT RIC and E2 nodes are independent of the addressing scheme of the transmission function; the E2 node supports all protocol layers and interfaces defined in the 3GPP radio access network, including eNB for E-UTRAN and gNB/NG-eNB for NG-RAN; near-RT RIC and hosted "xApp" applications use a set of services disclosed by E2 nodes, described by a series of RAN functions and Radio Access Technology (RAT) -related "E2 service models"; the Near-RT RIC interface is defined according to the following principles: the functional partitioning between interfaces has as few options as possible, and the interfaces are based on a logical model of the entity controlled by the interfaces, one physical network element can implement a plurality of logical nodes.
xApp can enhance RRM functions of Near-RT RIC. xApp provides logging, tracking, and metric collection for Near-RT RICs.
According to various embodiments, xApp includes xApp descriptors and xApp images. An xApp image is a software package. The xApp image contains all files for deploying the xApp. An xApp may have multiple versions of the xApp image, marked by xApp image version numbers.
The xApp descriptor describes the package format of the xApp image. The xApp descriptors also provide data to enable their management and orchestration. The xApp descriptor provides the xApp management service with information necessary for the xApp's LCM, such as deployment, deletion, upgrade, etc. The xApp descriptor also provides additional parameters related to xApp health management, such as automatic scaling when the xApp is too heavily loaded and automatic repair when the xApp becomes unhealthy. The xApp descriptor provides FCAPS and control parameters to the xApp upon start-up of the xApp.
The definition of the xApp descriptor includes: basic information of xApp, including name, version, vendor, URL of xApp image, virtual resource requirement (such as CPU), etc. This information is used to support the xApp LCM. Additionally or alternatively, the basic information includes or indicates configuration, metrics and control data about the xApp; FCAPS management specifications specifying configuration options for the xApp, performance metric collection, etc.; a control specification that specifies xApp as a data type for control capability usage and provisioning (e.g., performance Management (PM) data to which xApp subscribes, message type of control message).
Additionally or alternatively, the xApp descriptor component includes the following: configuration: the xApp configuration specification includes a data dictionary of configuration data, i.e., metadata, such as yang definitions or lists of configuration parameters and their semantics. Furthermore, it may include an initial configuration of the xApp; and (3) control: the xApp control specification shall include the data types (e.g., xApp URL, parameters, input/output types) it uses and provides to implement the control capabilities. Measurement: the xApp metric specification includes a list of metrics (e.g., metric names, types, units, and semantics) provided by the xApp.
In these examples, the Near-RT RIC has the following functions: a database function that allows reading and writing RAN/UE information; xApp subscription management that consolidates subscriptions from different xapps and provides unified data distribution for xapps; conflict mitigation, which resolves potential overlapping or conflicting requests from multiple xapps; message infrastructure implementing message interactions between Near-RT RIC internal functions; security, which provides a security scheme for xApp; and a management service comprising: fault management, configuration management and performance management of service providers as SMOs; managing the life cycle of xApp; and logging, tracking and metrics collection that captures, monitors and collects the status inside the Near-RT RIC and can be transmitted to external systems for further evaluation; and interface termination, comprising: an E2 termination terminating an E2 interface from the E2 node; a1 termination terminating the A1 interface from the Non-RT RIC; and an O1 termination terminating an O1 interface from SMO; and a function hosted by the xApp that allows services to be performed at the Near-RT RIC and sends the results to the E2 node over the E2 interface.
The xApp may provide UE related information for storage in a UE-NIB (UE network information base) database. The UE-NIB maintains a list of UEs and related data. The UE-NIB maintains tracking and correlation of UE identities associated with connected E2 nodes. The xApp may provide radio access network related information to store in an R-NIB (radio network information base) database. The R-NIB stores configuration and near real-time information about the connected E2 node and the mapping between them.
xApp subscription management manages subscriptions from xapps to E2 nodes. The xApp subscription management enforces policy authorization that controls the access of the xApp to the message. The xApp subscription management implementation merges the same subscriptions from different xapps into a single subscription to the E2 node.
Fig. 6 illustrates a flow chart of a Handover (HO) procedure in accordance with some aspects. As described above, a high mobility or dense environment with a large number of cells (microcells and other cells) may increase the frequency with which UEs participate in the handover process. As shown in the figure:
1. the source gNB-CU-CP sends a handover request message to the target gNB-CU-CP. In the case of conditional handover, the target gNB is considered as a candidate gNB, which is accessed by the UE only if CHO conditions are met.
Bearer context establishment procedures are performed as described in section 8.9.2 of 3gpp TS 38.401.
5. The target gNB-CU-CP responds to the source gNB-CU-CP with a handover request confirm message.
6. An F1 UE context modification procedure is performed to send a handover command to the UE and instruct to stop data transmission for the UE.
7-8. Bearer context modification procedure (gNB-CU-CP initiation) is performed to enable gNB-CU-CP to retrieve PDCP UL/DL status and exchange data forwarding information of the bearer.
9. The source gNB-CU-CP sends an SN status transfer message to the target gNB-CU-CP.
10-11. Bearer context modification procedure is performed as described in section 8.9.2. If the PDCP state (e.g., full configuration) does not need to be preserved, the target gNB-CU-CP will not transmit the PDCP UL/DL state carried from the SN state transmission message to the target gNB-CU-UP.
12. Data forwarding from the source gNB-CU-UP to the target gNB-CU-UP may be performed.
In case of DAPS handover or conditional handover, the target gNB-CU-CP sends a handover success message to the source gNB-CU-CP to inform the UE that the target cell has been successfully accessed.
In the case of DAPS handoff or conditional handoff, an F1 UE context modification procedure is performed to instruct to stop data transmission to the UE.
12c-12d. In case of DAPS handoff or conditional handoff, a bearer context modification procedure (gNB-CU-CP initiation) is performed to instruct the source gNB-CU-UP to stop packet transmission and also retrieve PDCP UL/DL state.
In case of DAPS handover or conditional handover, the source gNB-CU-CP sends an SN status transfer message to the target gNB-CU-CP.
12f-12g. In case of a DAPS handoff or conditional handoff, a bearer context modification procedure is performed to provide PDCP UL/DL state to the target gNB-CU-UP (only when the PDCP state needs to be preserved), as described in TS 38.300.
13-15. Perform a path switching procedure to update the DL TNL address information of the NG-U to the core network.
16. The target gNB-CU-CP sends a UE context release message to the source gNB-CU-CP.
17 and 19. Bearer context release procedure is performed.
18. An F1 UE context release procedure is performed to release the UE context in the source gNB-DU.
The 3GPP has supported data forwarding and lossless transmission when a UE is handed over from one cell to another. For NR (i.e. from 3GPP Rel-15), support for lossless is extended even if QoS flows are remapped to different Data Radio Bearers (DRBs) at handover. During lossless transmission where QoS flows are mapped to different DRBs at the time of handover, the old DRBs (i.e., configured by the source node) are configured in the target cell. For ordered transmission in the Downlink (DL), the target gNB first transmits forwarded PDCP Service Data Units (SDUs) on the old DRB and then new data from the 5GC on the new DRB. In the Uplink (UL), the target gNB may not transmit data from the QoS flow of the new DRB to the 5GC until an end-marker on the old DRB is received from the UE.
Achieving lossless during handover is based on source forwarding PDCP SDUs, where Sequence Numbers (SNs) are allocated but not acknowledged by UEs in old DRBs. In fact, DL QoS flows can be forwarded in a lossless manner through PDU session tunnels, but in this case the old DRB is configured to have DL SDAP headers present to determine to which QoS flow (based on QoS Flow Identifier (QFI)) the Service Data Adaptation Protocol (SDAP) SDU extracted from those PDCP SDUs, which has been processed by the SDAP entity, belongs. In addition, qoS flow level forwarding by establishing a PDU session forwarding tunnel does not guarantee duplicate transmission protection. To ensure lossless and avoid duplicate transmissions, while also ensuring in-order transmissions through existing PDCP SN save mechanisms, the target side configures the old DRBs and temporarily continues, and the source performs DRB level forwarding and forwards QoS flows of the old DRBs by PDCP SDUs until the source receives an end-marker from the CN.
This mechanism is sufficient when aggregating target nodes. However, in the case of a separate CP-UP, the current target CU-CP first establishes the old DRB on the target CU-UP side, and then updates the mapping (or establishes the new DRB) separately through the E1AP bearer context establishment and bearer context modification procedure. Of course, such updating of the DRB configuration by the E1AP bearer context modification procedure should not occur until the target CU-UP has completed transmitting the PDCP SDU of the forwarded old DRB. This may disrupt the lossless transmission of the old DRB. Furthermore, since QoS flow remapping will occur at the time of handover, the mapping update of the old DRB preferably occurs in time, i.e. once the target CU-UP has completed transmitting the forwarded PDCP SDUs. However, it is the target CU-UP-target CU-CP that is responsible for user plane processing that does not know when the target CU-UP will complete for the dependent DRB. As is well known, a bearer context is an information block in a gNB-CU-UP node associated with one UE, which is used for communication over the E1 interface. The bearer context may include information about the data radio bearer, the PDU session, and the QoS flows associated with the UE, and contain information for maintaining user plane services towards the UE.
In some embodiments, the target CU-CP may estimate the timing because the CN sends an end mark to the source upon receiving a path switch request from the target CU-CP. However, there may be an unpredictable processing delay on the CN side. Furthermore, the number of packets buffered at the source side (and thus the time to complete forwarding at the source side and the time to complete transmission at the target side) varies from DRB to DRB. Blind estimation of the timing of updating DRB configuration by the E1AP bearer context modification procedure may lead to corrupted lossless transmissions (if advanced (as described above) or if delayed), the benefit of QoS flow remapping at handoff is lost. Even if the target CU-CP is assumed to be able to determine an accurate timing, the target CU-CP may eventually trigger multiple bearer context modification procedures (since the timing may be DRB-specific), which is inefficient. Thus, when the target NG-RAN node has CP-UP separation, a mechanism needs to be provided to overcome the above-mentioned limitations in NR.
Fig. 7-9 illustrate bearer context establishment and modification procedures. In particular, fig. 7 illustrates a bearer context establishment procedure in accordance with some embodiments. The bearer context establishment procedure allows the gNB-CU-CP to establish a bearer context in the gNB-CU-UP. The gNB-CU-CP initiates the procedure by sending a bearer context setup request message to the gNB-CU-UP. If the gNB-CU-UP successfully establishes the requested resources, it replies to the gNB-CU-CP with a bearer context setup response message. The gNB-CU-UP reports the results of all requested resources to the gNB-CU-CP in a bearer context setup response message, including for NG-RAN: a list of successfully established PDU session resources in the PDU session resource establishment list IE; a list of PDU session resources that have not been established in the PDU session resource failure list IE; for each established PDU session resource, the DRB establishes a list of successfully established DRBs in the list IE; for each established PDU session resource, a list of DRBs that have not been established in the DRB failure list IE; for each established DRB, a list of QoS flows successfully established in the flow establishment list IE; for each established DRB, a list of QoS flows in the failure list IE that cannot be established is lost.
Fig. 8 illustrates a gcb-CU-CP initiated bearer context modification procedure in accordance with some embodiments. The gNB-CU-CP initiated bearer context modification procedure allows the gNB-CU-CP to modify the bearer context in the gNB-CU-UP. The gNB-CU-CP initiates the procedure by sending a bearer context modification request message to the gNB-CU-UP. If the gNB-CU-UP successfully modifies the bearer context, it replies to the gNB-CU-CP with a bearer context modification response message.
Fig. 9 illustrates a gcb-CU-UP initiated bearer context modification procedure in accordance with some embodiments. The gNB-CU-UP initiated bearer context modification procedure allows the gNB-CU-UP to modify the bearer context (e.g., due to local issues) and notify the gNB-CU-CP. The gNB-CU-UP initiates the procedure by sending a bearer context modification required message to the gNB-CU-CP. The gNB-CU-CP replies with a bearer context modification acknowledgement message.
Example 1: the target CU-CP establishes an old DRB in the target CU-UP. Then, the target CU-UP informs the target CU-CP when the target CU-UP finishes transmitting the forwarded PDCP SDUs, so that the target CU-CP can update the DRB configuration in time through a subsequent bearer context modification procedure. In this case, it may not matter to know the exact timing, as the target CU-UP is responsible for the user plane processing. However, the round trip delay and the indication from the target CU-UP and subsequent updates from the target CU-CP may occur multiple times, as the exact timing may differ from DRB to DRB. An example implementation of E1AP (TS 38.463) is as follows:
For TS 38.463
9.3.3.2 PDU session resource to-be-established list
The IE contains PDU session resource related information used at the bearer context setup request.
/>
/>
/>
As shown, when forwarding is complete, the forwarding completion notification request IE may indicate a request for a forwarding completion notification message from the gNB-CU-UP.
9.2.2.X Forward completion Notification
The message is sent by the gNB-CU-UP to indicate to the gNB-CU-CP that the forwarded PDCP SDUs have completed transmission for the listed DRBs.
The direction is: gNB-CU-UP→gNB-CU-CP
/>
The message type IE uniquely identifies the message being sent. gNB-CU-CP UE E1AP ID uniquely identifies the UE association on the E1 interface within the gNB-CU-CP. The gNB-CU-UP UE E1AP ID uniquely identifies the UE association on the E1 interface within the gNB-CU-UP. The DRB ID uniquely identifies the DRB for the UE.
Example 2: the target CU-CP establishes a superset of the old and new DRBs in the target CU-UP and at the same time indicates an updated mapping to the old DRBs to be reflected when the target CU-UP completes transmitting the forwarded PDCP SDUs. In this embodiment, qoS flows may not be subject to forwarding because each DRB is a superset of QoS flows to be established for that DRB. In this case, the source DRB configuration is preserved and then updated to the new mapping, which occurs once the target CU-UP has completed transmitting forwarded PDCP SDUs for each old DRB (whose timing may be different from DRB to DRB). No additional communication, or potential delay that may be involved, is used between the target CU-CP and CU-UP as in embodiment 1; a one-time bearer context establishment procedure may be sufficient.
For TS 38.463
9.3.3.2 PDU session resource to-be-established list
The IE contains PDU session resource related information used at the bearer context setup request.
/>
/>
/>
/>
If an update QoS flow information IE to be established exists, the QoS flow mapping in the DRB is updated once the transfer of forwarded PDCP SDUs from the source during handover has completed. The following provides a list of QoS flow QoS parameters that are included:
9.3.1.25QoS flow QoS parameter List
The IE contains a QoS flow list including QoS flow parameters.
/>
Range limitations Interpretation of the drawings
maxnoofQoSFlows Maximum number of QoS flows in PDU session. The value is 64.
In some embodiments, the QoS flow remapping parameters may be used instead of the updated QoS flow information parameters to be established as described above. The QoS flow remapping parameters are similar to the updated QoS flow information parameters to be established, indicating a change in DRB configuration of the DRB used during forwarding after the DRB from the source gNB is completed. In particular, the enumerated value of the QoS flow remapping parameter may indicate that the DRB is still present but that the QoS flow of the DRB is to be changed (enumerated value "updated") or may indicate that the DRB may be deleted (enumerated "source configuration").
Thus, in some embodiments, if the QoS flow remapping IE is contained within the DRB to-be-established list IE in the bearer context setup request message for the DRB and is set to "update", the gNB-CU-UP may consider that the QoS flow mapped for the DRB is updated to the QoS flow included in the QoS flow information IE to be established after processing the forwarded PDCP SDU is completed during the intra-system handover procedure. If the QoS flow remapping IE is contained in the DRB to-be-established list IE in the bearer context setup request message for the DRB and set to "source configuration", the gNB-CU-UP may consider that no QoS flow is mapped to the DRB after processing of PDCP SDUs forwarded through the DRB is completed during the intra-system handover procedure and ignore the information included in the to-be-established QoS flow information IE for the relevant DRB.
In some embodiments, the QoS flow remapping IE may be contained within a DRB to be established list IE of PDU session resource to be modified list IEs in the bearer context modification request message.
Although embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader scope of the disclosure. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show, by way of illustration and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This detailed description is, therefore, not to be taken in a limiting sense, and the scope of the various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.
The subject matter may be referred to herein, individually and/or collectively, by the term "embodiment" merely for convenience and without intending to voluntarily limit the scope of this application to any single inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.
In this document, the terms "a" or "an" are used, as is common in patent documents, to include one or more than one, independent of any other instance or use of "at least one" or "one or more". In this document, the term "or" is used to refer to a non-exclusive or, such that "a or B" includes "a, but no B", "B, but no a" and "a and B", unless otherwise indicated. In this document, the terms "comprise" and "wherein" are used as plain english equivalents of the respective terms "comprising" and "wherein. In addition, in the appended claims, the terms "including" and "comprising" are open-ended, that is, a system, UE, article, composition, formulation, or process that includes other elements in addition to those listed after such term in a claim is still considered to fall within the scope of that claim. In addition, in the appended claims, the terms "first", "second", and "third", etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.
The abstract of the disclosure is provided to conform to 37c.f.r.1.72 (b), which requires an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. The abstract was submitted under the following cleavage: it is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Furthermore, in the foregoing detailed description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment.

Claims (20)

1. An apparatus for a 5 th generation NodeB central unit-control plane (gNB-CU-CP), the apparatus comprising:
processing circuitry configured to:
determining that a handover of a User Equipment (UE) from a source gNB will occur;
determining whether quality of service (QoS) flow remapping for a Data Radio Bearer (DRB) will occur during the handoff; and
in response to determining that the QoS flow remapping is to occur, providing a message for the DRB to a central unit-user plane (gNB-CU-UP) via an E1 interface, the message indicating: for the gNB-CU-UP, qoS flow remapping will occur after completion of transmission of Packet Data Convergence Protocol (PDCP) Service Data Units (SDUs) of the DRBs forwarded from the source gNB; and
a memory configured to store the message.
2. The apparatus of claim 1, wherein the handover is a lossless handover.
3. The apparatus of claim 1, wherein the message comprises a PDU session resource to establish list Information Element (IE) indicating the QoS flow remapping in a QoS remapping IE.
4. The apparatus of claim 3, wherein the PDU session resource to establish list IE further comprises a QoS mapping IE for DRBs from the source gNB for use by the gNB-CU-UP in transmitting the PDCP SDUs forwarded from the source gNB.
5. The apparatus of claim 1, wherein the message indicates that the gNB-CU-UP is to automatically apply the QoS remapping after completion of transmission of the PDCP SDU forwarded from the source gNB.
6. The apparatus of claim 1, wherein:
the processing circuitry is further configured to decode a request to establish the DRB in the gNB-CU-UP; and
the message indicates an updated DRB configuration for the DRB in response to the request, the updated DRB configuration including the QoS flow remapping.
7. The apparatus of claim 1, wherein:
the processing circuitry is further configured to decode a request to establish the DRB in the gNB-CU-UP; and
the message indicates an updated DRB configuration for the DRB, the updated DRB configuration including the QoS flow remapping, the updated DRB configuration indicated after the DRB is established.
8. The apparatus of claim 1, wherein the processing circuitry is further configured to provide an updated DRB configuration to update the DRB configuration of the DRB via a bearer context setup request procedure, the updated DRB configuration comprising the QoS flow remapping.
9. The apparatus of claim 8, wherein the bearer context establishment request procedure comprises: and transmitting a bearer context establishment request message to the gNB-CU-UP, and receiving a bearer context establishment response message from the gNB-CU-UP in response to the gNB-CU-UP successfully establishing a bearer context.
10. The apparatus of claim 1, wherein:
the message is a bearer context setup request message,
the bearer context setup request message includes a DRB to-be-setup list IE,
the DRB to-be-established list IE includes QoS flow information IE to be established and QoS flow remapping IE, and
the QoS flow remapping IE indicates to the gNB-CU-UP: after the transmission of the PDCP SDU of the DRB is completed, the QoS flow mapped for the DRB will be updated to at least one QoS flow included in the QoS flow information IE to be established.
11. The apparatus of claim 1, wherein:
the message is a bearer context setup request message,
the bearer context setup request message includes a DRB to-be-setup list IE,
the DRB to-be-established list IE includes QoS flow information IE to be established and QoS flow remapping IE, and
the QoS flow remapping IE indicates to the gNB-CU-UP: after the transmission of the PDCP SDU of the DRB is completed, qoS flows that are not mapped for the DRB will be mapped to the DRB, and for the DRB, information included in the QoS flow information IE to be established will be ignored.
12. An apparatus for a 5 th generation NodeB central unit-user plane (gNB-CU-UP), the apparatus comprising:
Processing circuitry configured to:
during a lossless handover of a User Equipment (UE) from a source gNB, receiving a bearer context setup request message from a central unit-control plane (gNB-CU-CP) via an E1 interface, the message indicating: after completion of transmission of Packet Data Convergence Protocol (PDCP) Service Data Units (SDUs) of the DRB forwarded from the source gNB, whether quality of service (QoS) flow remapping will occur;
determining whether transmission of the PDCP SDU has been completed; and
responsive to determining that transmission of the PDCP SDU has been completed and that the QoS flow remapping is to occur, providing to a central unit-control plane (gNB-CU-CP) via an E1 interface, adjusting a DRB configuration of the DRB based on the bearer context setup request message; and
and a memory configured to store the bearer context setup request message.
13. The apparatus of claim 12, wherein the bearer context setup request message comprises a PDU session resource to establish list Information Element (IE) indicating the QoS flow remapping in a QoS remapping IE.
14. The apparatus of claim 13, wherein the PDU session resource to establish list IE further comprises a QoS map IE for the DRB for use by the gNB-CU-UP in transmitting the PDCP SDU forwarded from the source gNB.
15. The apparatus of claim 12, wherein the bearer context setup request message indicates: the gNB-CU-UP will automatically apply the QoS remapping after completing the transmission of the PDCP SDUs forwarded from the source gNB.
16. The apparatus of claim 12, wherein:
the bearer context setup request message includes a DRB to-be-setup list IE,
the DRB to-be-established list IE comprises QoS flow information IE to be established and QoS flow remapping IE, and
the QoS flow remapping IE indicates to the gNB-CU-UP: after the transmission of the PDCP SDU of the DRB is completed, the QoS flow mapped for the DRB will be updated to at least one QoS flow included in the QoS flow information IE to be established.
17. The apparatus of claim 12, wherein:
the bearer context setup request message includes a DRB to-be-setup list IE,
the DRB to-be-established list IE comprises QoS flow information IE to be established and QoS flow remapping IE, and
the QoS flow remapping IE indicates to the gNB-CU-UP: after the transmission of the PDCP SDU of the DRB is completed, qoS flows that are not mapped for the DRB will be mapped to the DRB, and for the DRB, information included in the QoS flow information IE to be established will be ignored.
18. A non-transitory computer-readable storage medium storing instructions for execution by one or more processors of a 5 th generation NodeB central-control-plane (gNB-CU-CP), the one or more processors configured to, when executed:
determining that a lossless handover of a User Equipment (UE) from within a source gNB;
determining whether quality of service (QoS) flow remapping for a Data Radio Bearer (DRB) will occur during the handoff; and
in response to determining that the QoS flow remapping is to occur, providing a bearer context setup request message for the DRB to a central unit-user plane (gNB-CU-UP) via an E1 interface, the message indicating: for the gNB-CU-UP, qoS flow remapping will occur after completion of transmission of Packet Data Convergence Protocol (PDCP) Service Data Units (SDUs) of the DRBs forwarded from the source gNB.
19. The non-transitory computer-readable storage medium of claim 18, wherein the bearer context setup request message comprises a PDU session resource to setup list Information Element (IE) indicating the QoS flow remapping in a QoS remapping IE.
20. The non-transitory computer-readable storage medium of claim 19, wherein the PDU session resource to establish list IE further comprises a QoS map IE for use by the gNB-CU-UP in transmitting the PDCP SDU forwarded from the source gNB.
CN202180082521.4A 2021-01-07 2021-12-14 QOS flow remapping support at handover Pending CN116601998A (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US202163134743P 2021-01-07 2021-01-07
US63/134,743 2021-01-07
PCT/US2021/063292 WO2022150154A1 (en) 2021-01-07 2021-12-14 Qos flow remapping support at handover

Publications (1)

Publication Number Publication Date
CN116601998A true CN116601998A (en) 2023-08-15

Family

ID=82357558

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180082521.4A Pending CN116601998A (en) 2021-01-07 2021-12-14 QOS flow remapping support at handover

Country Status (2)

Country Link
CN (1) CN116601998A (en)
WO (1) WO2022150154A1 (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024073090A1 (en) * 2022-09-30 2024-04-04 F5, Inc. Apparatus and methods for radio access network optimization by extending near-rt and non-rt ric functionality for o-cloud optimization and management and devices thereof
CN118042443A (en) * 2022-11-14 2024-05-14 中国移动通信有限公司研究院 Data transmission method, device, related equipment and storage medium
WO2024127559A1 (en) * 2022-12-14 2024-06-20 日本電気株式会社 System, device, method, and non-transitory computer-readable medium

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020226546A1 (en) * 2019-05-03 2020-11-12 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus in a network node or base station

Also Published As

Publication number Publication date
WO2022150154A1 (en) 2022-07-14

Similar Documents

Publication Publication Date Title
US11641608B2 (en) Software-defined networking data re-direction
CN116601998A (en) QOS flow remapping support at handover
NL2030612B1 (en) Ric subscription removal over e2 interface
WO2022046756A1 (en) Computing workload transport over control plane in next generation cellular networks
US20230129575A1 (en) Network slice subnet instance resource optimization for 5g ?systems
WO2022232098A1 (en) Ran service-based interfaces
WO2022187130A1 (en) Ul packet delay distribution measurement
WO2022232132A1 (en) Charging for obtaining ue location, acr management event and ac information notification
WO2022235560A1 (en) Data-centric computing and communication infrastructure
WO2022155200A1 (en) Edge computing to 5gc function connections
EP4218275A1 (en) Efficient access for single operator network slices
WO2022047320A1 (en) Ran node and ue configured for beam failure detection reporting to support to ai and ml based beam management
NL2030840B1 (en) E2 service model ran control message format
US20240121664A1 (en) Cloud eas lifecycle management
US20240121156A1 (en) Instantiation support of cloud eas
US11963036B2 (en) Computing workload transport over control plane in next generation cellular networks
US20240121745A1 (en) Data plane for ng cellular networks
US20230023383A1 (en) Edge application servers and 5gc network function measurements
US12081412B2 (en) Federated learning across UE and RAN
US20240129790A1 (en) Sdt and cn buffering co-existence in inactive state
US20240292371A1 (en) User equipment paging monitoring
US20240260052A1 (en) Non-terrestrial user equipment measurements
WO2023023034A1 (en) E2 node initiated radio access network (ran) intelligent controller (ric) subscription removal in near-real time (rt) ric
CN116349291A (en) Management service for load balancing optimization
WO2023164096A1 (en) E2sm kpm reporting structure

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination