[go: up one dir, main page]

WO2024250029A1 - Network-side coordination of multi-user multiple-input multiple-output functionality - Google Patents

Network-side coordination of multi-user multiple-input multiple-output functionality Download PDF

Info

Publication number
WO2024250029A1
WO2024250029A1 PCT/US2024/032300 US2024032300W WO2024250029A1 WO 2024250029 A1 WO2024250029 A1 WO 2024250029A1 US 2024032300 W US2024032300 W US 2024032300W WO 2024250029 A1 WO2024250029 A1 WO 2024250029A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
network
information
network function
report
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
PCT/US2024/032300
Other languages
French (fr)
Inventor
Yoav Hebron
Michael Grimwood
Prem GOPANNAN
Clayton AMBROSE
Paul Richardson
Nicole GRIMWOOD
Naveen RAWAT
Shlomo Selim Rakib
Shachar Kons
Suzan Fishel BEN-KENAN
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.)
Cohere Technologies Inc
Original Assignee
Cohere Technologies Inc
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 Cohere Technologies Inc filed Critical Cohere Technologies Inc
Priority to AU2024281104A priority Critical patent/AU2024281104A1/en
Priority to PCT/US2024/058465 priority patent/WO2025207165A1/en
Publication of WO2024250029A1 publication Critical patent/WO2024250029A1/en
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/27—Control channels or signalling for resource management between access points
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/02—Diversity systems; Multi-antenna system, i.e. transmission or reception using multiple antennas
    • H04B7/04—Diversity systems; Multi-antenna system, i.e. transmission or reception using multiple antennas using two or more spaced independent antennas
    • H04B7/0413—MIMO systems
    • H04B7/0452—Multi-user MIMO systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports

Definitions

  • the present document relates to wireless communication.
  • a wireless communication method includes configuring a multi-user multi-input multi-output (MU-MIMO) control function in a wireless network comprising multiple network functions.
  • MU-MIMO control function provides an MU-MIMO capability to the wireless network using which the wireless network provides wireless connectivity to user devices using an MU-MIMO configuration.
  • a method of facilitating wireless communication includes generating, by a first network function, a proposed schedule of transmissions and receptions in a multi-user multiple-input multiple-output (MU-MIMO) network. Then, the first network function communicates the proposed schedule to a second network function that is logically and physically separated from the first network function.
  • the second network function is configured to determine, based on a time criticality of pending communication tasks, a final schedule of the transmissions and receptions by overwriting entries of the proposed schedule.
  • a method of facilitating wireless communication includes receiving, from a first network function, by a second network function that is logically and physically separated from the first network function, a proposed schedule of transmissions and receptions in a multi-user multiple-input multiple-output (MU-MIMO) network. Then, the second network function determines, based on a time criticality of pending communication tasks, a final schedule of the transmissions and receptions by overwriting entries of the proposed schedule generated by the first network function.
  • MU-MIMO multi-user multiple-input multiple-output
  • the above-described methods may be embodied as processorexecutable code and may be stored on a computer-readable program medium.
  • FIG. 1 shows a block diagram of an example system that can perform network-side coordination of MU-MIMO functionality.
  • FIG. 2 shows a block diagram of an example Open Radio Access Network (O-RAN) logical architecture.
  • O-RAN Open Radio Access Network
  • FIG. 3 shows a block diagram of the interactions of an example Near-Real Time RAN Intelligent Controller (Near-RT RIC).
  • Near-RT RIC Near-Real Time RAN Intelligent Controller
  • FIG. 4 shows a flow diagram for an example RIC Service REPORT.
  • FIGS. 5A and 5B show a flow diagram for an example RIC Service INSERT.
  • FIGS. 6A and 6B show a flow diagram for an example RIC Service CONTROL.
  • FIG. 7 shows a flow diagram for an example RIC Service QUERY.
  • FIG. 8 is a diagram showing a Universal Spectrum Multiplier (USM) communicating with a cellular node (e.g., a gNodeB) though a gRPC channel.
  • USM Universal Spectrum Multiplier
  • FIG. 9 shows a flow diagram for an example initialization procedure between the USM and gNB shown in FIG. 8.
  • FIG. 10 shows a flow diagram for the attachment of a user equipment (UE) to the gNB in the context of leveraging the USM.
  • UE user equipment
  • FIGS. 1 1A and 11 B show a flow diagram for the end-to-end flow between the USM and multiple UEs via various components and modules of the gNB.
  • FIG. 12 shows a block diagram for an MIMO scheduling management.
  • FIGS. 13-17 show an example scenario of how bandwidth scheduling may be managed between a Distributed Unit (DU) and the USM scheduler.
  • DU Distributed Unit
  • FIG. 18 shows an example of different traffic steering processing modes.
  • FIGS. 19A and 19B show a table detailing the Near RT RIC A1 -Policy Based Traffic Steering
  • FIGS. 19C and 19D show a flow diagram for the overall procedure for the Near RT RIC A1 -Policy based Traffic Steering use case
  • FIG. 19E show a table that lists examples of measurement information identified as required in this use case.
  • FIGS. 20A and 20B show a table detailing a Quality-of-Service (QoS)-Based Resource Optimization use case
  • FIG. 20C shows a flow diagram for the overall procedure for the QoS-Based Resource Optimization use case.
  • QoS Quality-of-Service
  • FIGS. 21 A and 21 B show a table detailing a RAN Slice SLA Assurance use case
  • FIG. 21 C shows a flow diagram for an example of the RAN Slice SLA Assurance use case.
  • FIGS. 22A and 22B show a table detailing AI/ML-assisted Non-GoB BF mode selection in Non- RT RIC, and FIGS. 22C and 22D show a flow diagram of an example of this use case.
  • FIG. 23A shows a table detailing AI/ML-assisted Non-GoB BF mode selection-model training in Near-RT RIC
  • FIG. 23B shows a flow diagram for an example of this use case.
  • FIG. 24A shows a table detailing AI/ML Inference
  • FIG. 24B shows a flow diagram for an example of this use case.
  • FIG. 25A shows a table detailing Near-RT RIC Beam-based Mobility Robustness Optimization - model training and initial beam grouping
  • FIG. 25B shows a flow diagram for the procedure for this use case.
  • FIGS. 26A and 26B show a table detailing Near RT RIC Beam-based Mobility Robustness Optimization - model inference and mobility optimization
  • FIGS. 26C and 26D show a flow diagram for the procedure for this use case.
  • FIGS. 27A and 27B show a table detailing an MU-MIMO Optimization procedure
  • FIGS. 27C and 27D show a flow diagram for the example MU-MIMO Optimization use case.
  • FIG. 28A shows a table detailing RAN Performance Analytics assisted QoE Optimization
  • FIG. 28B shows a flow diagram for the procedure for this use case.
  • FIG. 29A shows a table detailing RAN Performance Analytics assisted QoE Optimization using subscription based solution
  • FIG. 29B shows a flow diagram for the procedure for this use case.
  • FIG. 30 is a flowchart of an example method of facilitating wireless communication.
  • FIG. 31 is a flowchart of another example method of facilitating wireless communication.
  • FIG. 32 shows an example of a hardware platform that is used to implement one or more of the disclosed techniques and/or embodiments.
  • FIGS. 33A-33AI show examples of E2 messages exchanged with the CU.
  • FIGS. 34A-34U show examples of E2 messages exchanged with the DU.
  • FIGS. 35A-33D show examples of required information for MU-MIMO Optimization.
  • FIGS. 36A-36AW show examples of E2AP messages that implement the proposed implementation for E2SM RC.
  • Section headings are used in the present document to improve readability of the description and do not in any way limit the discussion or the embodiments to the respective sections only. Certain standard-specific terms are used for illustrative purpose only, and the disclosed techniques are applicable to any wireless communication systems.
  • wireless networks are ubiquitously present and provide wireless data connectivity to wireless (or user) devices, sometimes called user equipment (UE), such as mobile phones, laptops, pads, machine to machine communication devices and so on and so forth.
  • UE user equipment
  • UE user equipment
  • a recently introduced technology often called multi-user multiple-input multiple-output (MU-MIMO) allows a network device configured with multiple transmission antennas (or transmission points) to transmit or receive signals to multiple UEs, at least some of which are configured with multiple antennas.
  • MU-MIMO multi-user multiple-input multiple-output
  • O-RAN Open Radio Access Network
  • the present document discloses various techniques that address, among other things, improvements to existing O-RAN framework to enable support for MU-MIMO and allows for technical solutions that will be able to meet stringent performance requirements.
  • the disclosed embodiments improve spectral efficiency for communications service providers by as much as two times by enabling mobile networks to communicate with multiple users simultaneously using the same time and frequency resources. In an example, this is achieved by using dynamic and smart pairing as well as precoding techniques.
  • embodiments of the disclosed technology include the Universal Spectrum Multiplier (USM) that leverages the delay-Doppler channel representation, which enables highly accurate predictions of signal-to-noise ratio (SNR) and user pairing. This channel representation reduces computation complexity and can be used for predicting the future given that its geometric nature is slow changing.
  • USM Universal Spectrum Multiplier
  • USM xApp a software module associated with a cloud-based service that provides cellular network services (e.g., 5G connectivity) to any cloud-based application.
  • USM xApp is designed to overcome several challenges, including reference signal contamination (intercell interference); channel state information (CSI) aging; stability under mobility and other channel dynamics; higher number of layers per antenna configuration; computational complexity; and the requirement for explicit device feedback.
  • intercell interference reference signal contamination
  • CSI channel state information
  • FIG. 1 shows a block diagram of an example system that includes the Universal Spectrum Multiplier xApp and the RAN Intelligent Controller (RIC) as shown on the upper left of FIG. 1 .
  • An exploded view in the upper right of FIG. 1 shows that the USM xApp software runs in the service and management orchestration (SMO) stack with a precoding function attached to the RAN distributed unit (DU).
  • SMO service and management orchestration
  • DU RAN distributed unit
  • the Universal Spectrum Multiplier xApp works in the network and requires no changes to handsets.
  • the software offers significant MU-MIMO benefits, and can work with existing base stations. Moreover, it allows simultaneous 4G and 5G co-existence without the performance issues of DSS via a vendor neutral approach to dynamic spectrum reuse.
  • the disclosed embodiments can be configured to work for waveforms in any spectrum as well as operating in either Frequency Division Duplexing (FDD) or Time Division Duplexing (TDD) networks. This enables them to improve the strength and efficiency of any generation (“any G”) mobile network.
  • FDD Frequency Division Duplexing
  • TDD Time Division Duplexing
  • any G any generation
  • FIG. 2 shows an example block diagram of the logical architecture for an Open Radio Access Network (O-RAN).
  • O-RAN Open Radio Access Network
  • the O-RAN logical architecture includes:
  • RIC O-RAN near-real-time RAN Intelligent Controller: a logical function that enables near-real-time control and optimization of O-RAN elements and resources via finegrained data collection and actions over E2 interface.
  • Non-Real Time RIC O-RAN non-real-time RAN Intelligent Controller: a logical function that enables non-real-time control and optimization of RAN elements and resources, AI/ML workflow including model training and updates, and policy-based guidance of applications/features in near-RT RIC.
  • O-CU-CP O-RAN Central Unit-Control Plane: a logical node hosting the RRC and the control plane part of the PDCP protocol
  • O-CU-UP O-RAN Central Unit-User Plane: a logical node hosting the user plane part of the PDCP protocol and the SDAP protocol
  • O-DU O-RAN Distributed Unit: a logical node hosting RLC/MAC/High-PHY layers based on a lower layer functional split.
  • O-RU O-RAN Radio Unit: a logical node hosting Low-PHY layer and RF processing based on a lower layer functional split.
  • O-eNB O-RAN evolved NodeB: hardware associated with the RAN
  • O-RAN cloud a cloud computing platform comprised of a collection of physical infrastructure nodes that meet O-RAN requirements to host the relevant O-RAN functions, the supporting software components, and the appropriate management and orchestration functions.
  • the Near-RT RIC loop operates between 10 milliseconds and 1 second.
  • the O-DU loop which is responsible for real-time processing of radio scheduling information, HARQ, beamforming, etc., has to always operate below 10 milliseconds due to its real-time nature.
  • the internal architecture of the Near-RT RIC is shown in FIG. 3.
  • the Near-RT RIC supports an xApp, which is an application provided by any third party, is designed to run on the Near- RT RIC, and it allow services to be executed at the Near-RT RIC and the outcomes sent to the E2 Nodes via E2 interface.
  • an xApp is likely to consist of one or more microservices. At the point of on-boarding, microservices will identify which data it consumes and which data it provides.
  • the E2 interface enables a direct association between the xApp and the RAN functionality.
  • the E2 interface supports the following functions:
  • each of the disaggregated network function O-CU-CP, O-CU-UP and O-DU are called the E2 nodes.
  • E2 nodes support E2 interface towards near RT-RIC and O1 interface towards non-RT RIC.
  • E2AP is specified by O-RAN Alliance over SCTP/IP as the transport protocol.
  • E2AP application-specific controls and events are conveyed through E2 service models (E2SM).
  • E2SM E2 service models
  • E2SMs service models
  • Near-RT RIC uses a RIC Subscription and/or RIC Subscription Modification procedures to request that E2 Node sends a REPORT message to Near-RT RIC and the associated procedure continues in the E2 Node after each occurrence of a defined RIC Subscription procedure Event Trigger.
  • FIG. 4 shows a flow diagram of an example RIC REPORT service.
  • Near-RT RIC uses a RIC Subscription and/or RIC Subscription Modification procedures to request that E2 Node sends an INSERT message to Near-RT RIC and suspends the associated procedure in the E2 Node after each occurrence of a defined RIC Subscription procedure Event Trigger.
  • FIGS. 5A and 5B show a flow diagram of an example RIC INSERT service.
  • FIGS. 6A and 6B show a flow diagram of an example RIC CONTROL service.
  • - POLICY Near-RT RIC uses a RIC Subscription and/or RIC Subscription Modification procedures to request that E2 Node executes a specific POLICY during functioning of the E2 Node after each occurrence of a defined RIC Subscription procedure Event Trigger.
  • - QUERY Near-RT RIC sends a QUERY message to the E2 node to retrieve RAN- related and/or UE-related information from the E2 Node.
  • FIG. 7 shows a flow diagram of an example RIC QUERY service.
  • the E2 application protocol supports the following functional procedures to enable using the RIC services.
  • - RIC Subscription procedure is Near-RT RIC initiated, and used to install Event Trigger and associated sequence of Actions corresponding to one or more REPORT, INSERT and/or POLICY
  • - RIC Subscription Modification procedure is Near-RT RIC initiated, and used to modify
  • - RIC Subscription Modification Required procedure is E2 Node initiated, and used to request modification and/or removal of Actions corresponding to REPORT, INSERT and/or POLICY
  • - RIC Subscription Delete procedure is Near-RT RIC initiated, and used to delete previously installed RIC Subscription
  • - RIC Subscription Delete Required procedure is E2 Node initiated, and used to indicate that one or more previously installed RIC Subscriptions are required to be deleted
  • - RIC Indication procedure is E2 Node initiated, and used to carry outcome of RIC services REPORT and INSERT
  • - RIC Query procedure is Near-RT RIC initiated, and used to request RAN and/or UE related information from E2 Node
  • E2 service models are supported, using either ASN.1 or JSON, with the described scope.
  • E2SM-NI is the “Network Interface” RAN Function, which performs the following functionalities: (1) exposure of Network Interfaces, (2) modification of both incoming and outgoing network interface message contents, and (3) execution of policies that may result in change of network behavior
  • - E2SM-KPM_version1 is the “KPM Monitor” RAN Function, which performs the following functionalities: (1) exposure of O-DU’s cell related performance lEs through periodic KPM Report, (2) exposure of O-CU-CP’s cell/UE related performance lEs through periodic KPM Report, and (3) exposure of O-CU-UP’s bearer related performance lEs through periodic KPM Report.
  • E2SM-KPM_version2 is the “KPM Monitor” RAN Function, which performs the following functionalities: (1) exposure of available measurements from O-DU, O-CU-CP, and/or O-CU-UP via the RAN Function Definition IE, and (2) periodic reporting of measurements subscribed from Near-RT RIC.
  • - E2SM-RC is the “RAN Control” RAN Function, which performs the following functionalities: (1) exposure of RAN control and UE context related information, (2) modification and initiation of RAN control related call processes and messages, and (3) execution of policies that may result in change of RAN control behavior.
  • E2SM-CCC is the “Cell Configuration and Control” RAN Function, which performs the following functionalities: (1) exposure of node level and cell level configuration information, and (2) initiate control and/or configuration of node level and cell level parameters.
  • the following performance requirements are implemented by the E2 interface. These requirements, and the corresponding messages and example formats, have been described and enumerated next. It is noted that bolded text represents new parameters in existing E2SM services or new E2SM implementations.
  • BWP configuration (SCS, CP, DMRS config., MCS table, time resource allocations, PRB bundling, VRB to PRB)
  • DMRS Type A and B configurations • DMRS Type A and B configurations, VRB to PRB interleaver, Resource allocation type, PDSCH time domain allocation list and aggregation factor, MCS table, max No of codewords scheduled by DCI, PRB bundling type (static/dynamic)
  • TCI - indicates QCL of PDSCH with other signals (e.g. SS/PBCH/CSI)
  • the described embodiments advantageously provide control of a scheduler based on the collection of scheduling related information.
  • the following functionalities are defined:
  • E2 REPORT services used to expose traffic and layers 1 and 2 (MAC/PHY) UE related information that includes (1) E2 Node generated or UE reported PHY/MAC information, used for estimating the channel, and (2) Traffic status, used for triggering E2 Control
  • Scheduling Control used to control scheduling parameters of PDSCH transmission
  • the E2SM-RC can also be enhanced by adding the above-described functionalities to the E2SM-RC REPORT and CONTROL services.
  • the development and implementation of the E2SM-RC enhancements can be further constrained based on the following design considerations:
  • Zero Power CSI-RS (e.g., for SNR estimation) can optionally be used
  • the scheduling information can be sent without separating DCI 1_0 and 1_1 and let the DU decide which DCI to use Optionally control the PDSCH -ServingCellConfig IE
  • E2SM-CCC can be used for collecting cell configuration parameters
  • embodiments of the disclosed technology enable cloud-based applications to access cellular network services.
  • this is achieved by the USM xApp in the Near-RT RIC communicating with the other E2 nodes via the E2 interface.
  • This communication between the USM (e.g., in an xApp) and the cellular network (e.g., a gNodeB) is further detailed in the context of FIG. 8, which shows the USM using a general Remote Process Call (gRPC, which is a cross-platform open source high performance remote procedure call (RPC) framework) channel (or interface) to communicate with the gNB (that includes the CU and DU functionalities).
  • gRPC general Remote Process Call
  • RPC cross-platform open source high performance remote procedure call
  • FIG. 9 shows a flow diagram for an example initialization procedure between the USM and gNB shown in FIG. 8.
  • the gNB starts up by establishing gRPC links, which is followed by the USM starting up, establishing gRPC links, and requesting node config information (e.g., MIB and serving cell information).
  • the gNB shares this node configuration information, and the USM subscribes for required UE context information, which includes one of more of the following: [0116] - UE Capability Report
  • FIG. 10 shows a flow diagram for the attachment of a user equipment (UE) to the gNB in the context of leveraging the USM.
  • UE user equipment
  • the UE attachment commences only after the initialization (e.g., as described in FIG. 9) has been completed.
  • the gNB handles the initial attach procedure including allocation of the Radio Network Temporary Identifier (RNTI), and is configured to use SRB and dedicated PDSCH for the initial attachment procedure.
  • the gNB will send RRC Connection Setup message to USM, which will map gNB allocated RNTI and update the UE database.
  • the USM will receive UE context information via indication messages for connected UEs. Once one or more initial DRBs get established, gNB will hand over the UE to USM as per Served Bearer Scheduling Control message. Finally, USM will map one or more DRB flows with [RNTI, DRBJD] and update the flow database.
  • periodic data collection can be implemented for the various scenarios (and configurable periodicities) enumerated below.
  • aperiodic data collection can be implemented for the various scenarios (and specified triggers) enumerated below.
  • FIGS. 1 1A and 11 B show a flow diagram for the end-to-end flow between the USM and multiple UEs via various components and modules of the gNB.
  • the UEs upon completion of the initialization and the UEs (denoted UE_1 and UE_N) connecting, the UEs periodically transmit the SRS and CSI Report to the PHY layer of the gNB.
  • the PHY layer forwards this information, as well as a channel estimate, to the L1/L2 receiver of the gNB, which then transmits this to the USM.
  • HARQ feedback can be aggregated by the UEs and send to the USM in a similar manner.
  • the USM determines whether a bandwidth grant (e.g., slots that can be used by the UE) can be allocated to a particular UE, and sends that information (e.g., a UE list) to the gNB UE selection module (denoted gNB_UE_Selection).
  • the UE selection module adds the UE list received from the USM to the existing list prepared by the DU’s scheduler.
  • the gNB follows the suggested allocation for the USM’s grants, and provides the necessary information (e.g., precoder coefficients, grant information, etc.) to the PHY layer of the gNB, which them transmits this information to the respective UE.
  • the PDCP packet data convergence protocol
  • the DU can provide this information to a local scheduler operating in the DU.
  • This local scheduler (denoted "DU Scheduler") may track bandwidth assignments to time-sensitive (or time-critical) tasks such as hybrid automatic repeat request (HARQ), random access response (RAR), and ultra-reliable low latency communication (URLLC) transmissions.
  • HARQ hybrid automatic repeat request
  • RAR random access response
  • URLLC ultra-reliable low latency communication
  • the DU also includes a resource allocation function that receives inputs from the local scheduler and also from RLC, and operates to allocate transmission resources e.g., physical resource blocks (PRBs) or transport blocks (TBs), to outbound transmissions to be sent out by a transmitter circuitry Tx.
  • a resource allocation function that receives inputs from the local scheduler and also from RLC, and operates to allocate transmission resources e.g., physical resource blocks (PRBs) or transport blocks (TBs), to outbound transmissions to be sent out by a transmitter circuitry Tx.
  • PRBs physical resource blocks
  • TBs transport blocks
  • FIG. 12 also shows the DU being in communication with the USM scheduler (e.g., the USM xApp) over an interface that implements a predefined message protocol.
  • This interface may be an E2SM interface or a gRPC (Remote Procedure Call) interface.
  • the message protocol may support transmission of flow reports from the DU to the USM scheduler.
  • the flow report information may include information about which UEs at a current time are in need of flow data (transmission or reception) quality indicators associated with the flows and status (e.g., fullness) of queues for the flows.
  • the predefined message protocol defines a scheduling control message that is transmitted by the USM scheduler and received by the DU.
  • This message can include information about flow indexes, PRBs assigned to the flow indexes, modulation and coding scheme (MCS) assigned thereto, layer number, a size of transport block (TBS), precoding filter coefficients, etc.
  • MCS modulation and coding scheme
  • TBS transport block
  • precoding filter coefficients etc. This information may be applicable to next N slots, where N is an integer that may either be explicitly indicated in the scheduling control message or may be implicit based on a predefined understanding between the DU and the USM scheduler.
  • the message protocol also defines a scheduling response message that is transmitted by the DU and received by the USM scheduler.
  • the response message may include, for each indicated flow index, an actual TBS used by the DU.
  • the scheduling response message may provide an outcome that includes a list of fully executed grants and for the remaining grants, a number of bytes per LCID that were scheduled, and the like
  • eNodeB (eNB) / gNB / O-DU sends uplink channel estimates and downlink channel quality measurements to the RIC, which the mUMO xApp uses to predict the downlink channel and quality.
  • the eNB also sends information to the mUMO xApp that conveys downlink traffic activity and priority.
  • the received channel quality measurements are used to predict channel quality estimates and channel attributes which are provided to the USM Scheduler.
  • the USM Scheduler utilizes this information to create groupings of UEs that can be scheduled together to provide improved spectral reuse. Precoder coefficients are computed based on the USM Scheduler and provided over the E2 Interface for use in the DU.
  • the DU scheduler then uses that information to generate the specific scheduling control messages (DCIs). If high-priority low-latency packets need to be transmitted, the DU scheduler may replace part of the resources scheduled by the control message with the higher priority packets.
  • DCIs specific scheduling control messages
  • Timina requirements The mUMO xApp and the eNodeB/gNB are a near-real-time system.
  • the mUMO is providing scheduling parameters, and spatial multiplex group coefficients to the eNB/gNB, which must be used on particular LTE/5GNR Transmission Time Intervals (TTIs).
  • TTIs Transmission Time Intervals
  • the messages must arrive on time, with some processing-time margin, for the eNB/gNB to use them.
  • the eNB/gNB will typically have a mechanism to fall back to normal operation if they do not arrive, but if this happens frequently, the system will not meet its performance goals.
  • the mllMO xApp must start at a particular time t-X (relative to the eNB/gNB time), with sufficient process/thread priority to guarantee computation completion, and transmit over the network, for the messages to arrive at the eNB/gNB at time t.
  • Time synchronization requirement To meet this requirement, there must be time-synchronization between the Near-RT RIC (including xApp) and the eNB/gNB.
  • PTP is a logical choice, since the eNB will already be sync’d using PTP. The ⁇ 50ns time accuracy that PTP can provide is not required. Accuracy to +/- 10Ous should be sufficient to schedule and meet the 1 ms TTI time boundary.
  • Another choice applicable for O-RAN is to use the UTC time (already used in O-RAN) to time-stamp slots and received messages.
  • Timing measurement It is assumed that the network delay is symmetric (which is also an assumption of the PTP protocol), but since the latencies between the xApp and the E2 Node may include different processing modules, the latencies may be different. For that reason, the DL delay measurement will also be supported.
  • the main mechanism for the timing measurement will be the timestamped slot reports in the UL, and timestamping the received control messages in the DL which will be reported back to the xApp. In this mechanism, the xApp will request and receive timestamped slots reports (see 4.2.1 1 and 4.2.12). Based on this, the xApp can adjust its clock to match the O-DU clock.
  • the O-DU When the xApp sends a control message to the O-DU with the request for control Acknowledgement (e.g. when sending the Served Bearer Scheduling Configuration Control, see 4.2.16) the O-DU will send the Control Outcome with the timestamp of the received control message. This will provide the DL E2 interface latency, and with the reported processing time margin as part of the control outcome in response to the UE scheduling control message (see 4.2.13) the mUMO xApp will be able to adjust the timing of the UE scheduling control messages to arrive just in time. This per-message timing measurements may be fed to a software averag ing/filtering algorithm, which will most likely be a software phase-locked loop (PLL).
  • PLL software phase-locked loop
  • FIGS. 13-17 show an example scenario of how bandwidth scheduling may be managed between a Distributed Unit (DU) and the USM scheduler.
  • the DU maintains various flows that may each have a different fullness (indicated along vertical axis) for each flow index (numbering along horizontal axis). Some of these flows may be time-sensitive (denoted using a striped pattern), while others may not be time-sensitive (or may be less time-sensitive, and are denoted using a solid pattern).
  • flow reports carrying the above information are communicated from the DU to the USM scheduler.
  • time-sensitive and/or non-time-sensitive flow information may be reported to the USM xApp.
  • the USM scheduler can be configured to receive a snapshot of channel characteristics forthe UEs based on a reception of a reference signal, e.g., a sounding reference signal (SRS).
  • a reference signal e.g., a sounding reference signal (SRS).
  • SRS sounding reference signal
  • the channel characteristics and a database of UE and flow information may then be used to schedule non-time-critical flows.
  • FIG. 14 provides further details of the scheduling for MU-MIMO case.
  • the USM scheduler can decide how to perform spatial multiplexing (or how to form groups of UEs that can be scheduled using the same time/frequency resources).
  • a conceptual table is depicted on the left-hand side of FIG.
  • This information determined by the USM scheduler is used to generate a message that transmitted from USM scheduler to the DU as a proposed schedule, as shown in FIG. 15.
  • some “empty” PRBs may be available (depicted as white) for the DU.
  • the DU may be able to schedule time-sensitive traffic using the empty (or previously scheduled by the USM scheduler) PRBs, for example, by performing layered communication when overlapping PRBs are available (unallocated) in multiple layers.
  • the message may include flow priorities, channel estimation information, and scheduling recommendations forthe DU’s consideration.
  • FIG. 16 shows that DU may overwrite the proposed schedule with a final schedule in which the time-critical traffic was scheduled in a time symbol by pre-empting previously scheduled transmissions.
  • the DU decided not to use the blank PRBs (e.g., because both layers are not available), but instead overwrote the previously scheduled transmissions (including a portion of the transmission in the second slot in order to achieve spatial multiplexing).
  • the DU may not have sufficient information to perform spatial multiplexing of time-sensitive flows or UEs to or from which the communication is performed cannot be multiplexed because of their different channel characteristics.
  • FIG. 17 shows that the final schedule and transmission report is communicated in a scheduler response from the DU to the USM scheduler, which allows the scheduler to get an updated picture of buffer fullness of different flows.
  • FIG. 13-17 illustrates that the USM sends the DU scheduling controls with precoding coefficients, which significantly improves the spectral efficiency for most (non-time-sensitive) data flows.
  • Guaranteed bit rate (GBR) data flows with small packets and small latency (such as VoNR) will be scheduled using semi-persistent scheduling, coordinated between the USM scheduler and the DU.
  • the DU may add/adjust for other time-critical scheduling.
  • the existing E2SM-RC specification is expanded to support all the configurations related reports and controls described in this patent document.
  • E2SM spec e.g., E2SM-Lower Layers Control (LLC)
  • LLC Layers Control
  • either the complete IE defined in 3GPP e.g. CSI- MeasConfig, MeasGapConfig, defined in TS 38.331
  • the details of the IE as a list of parameters in the O-RAN spec (E2SM-RC and any other E2SM that is defined) can be included.
  • the full IE is used and shown as OCTET STRING that will be sent over the E2 interface and the xApp in the Near-RT RIC will extract the information it needs.
  • the complete list can be provided to support the future needs of any use case.
  • the UE RRC Connection Setup Report Request message is shown in FIG. 33E.
  • the UE RRC Connection Setup Report message is shown in FIG. 33F.
  • the UE RRC Connection Release Report Request message is shown in FIG. 33G.
  • the UE RRC Connection Release Report message is shown in FIG. 33H.
  • the UE RRC State Change Report Request message is shown in FIG. 331.
  • the UE RRC State Change Report message is shown in FIG. 33J.
  • the PDCP Traffic Report Request message is shown in FIG. 33K.
  • the PDCP Traffic Report message is shown in FIG. 33L.
  • the UE RRC CSI Measurement Configuration Report Request message is shown in FIG. 33M.
  • the UE RRC CSI Measurement Configuration Report message is shown in FIG. 33N.
  • the RRC Downlink Channel Quality Report Configuration message is shown in FIG. 330.
  • the UE RRC SRS Configuration Report Request message is shown in FIG. 33P.
  • the UE RRC SRS Configuration Report message is shown in FIG. 33Q.
  • the UE RRC BWP Downlink Configuration Report Request message is shown in FIG. 33U.
  • the UE RRC BWP Downlink Configuration Report message is shown in FIG. 33V.
  • the UE RRC PDSCH Configuration (not MVP) message is shown in FIG. 33W.
  • the Served Radio Bearer Configuration Report Request message is shown in FIG. 33X.
  • the Served Radio Bearer Configuration Report message is shown in FIG. 33Y.
  • the UE PDSCH of Serving Cell Configuration Report Request message is shown in FIG. 33AA.
  • the UE DRX Configuration Report Request message is shown in FIG. 33AC.
  • the UE DRX Configuration Report message is shown in FIG. 33AD.
  • the UE Capabilities Report Request message is shown in FIG. 33AE.
  • the UE Capabilities Report message is shown in FIG. 33AF.
  • the UE RRC BWP uplink Configuration Report (not MVP) message is shown in FIG. 33AH.
  • the UE RRC UL DMRS Configuration (not MVP) message is shown in FIG. 33AI.
  • the MAC Uplink Channel Estimate Report Request message is shown in FIG. 34A.
  • the MAC UL Raw SRS Report message is shown in FIG. 34D.
  • the MAC Downlink Channel Quality Report message is shown in FIG. 34F.
  • the MAC DL HARQ Feedback Report message is shown in FIG. 34H.
  • the DL RLC Traffic Report Request message is shown in FIG. 341.
  • the MAC UL Traffic Report Request (not MVP) message is shown in FIG. 34K.
  • the MAC UL Traffic Report (not MVP) message is shown in FIG. 34L.
  • the O-RU Antenna Information Report message is shown in FIG. 34R.
  • the E2 Compression Support Information Report Request message is shown in FIG. 34T.
  • the E2 Compression Support Information Report message is shown in FIG. 34U.
  • FIGS. 35A-35D show the Near-RT RIC and the E2 Node capabilities that are necessary for implementation of the MU-MIMO Optimization use case.
  • the required capabilities include control over E2 (FIG. 35A), UE context information from E2 nodes (FIG. 35B), measurements from E2 nodes (FIG. 35C), and E2 nodes configuration (FIG. 35D).
  • each of the following E2AP procedures contain specific E2 Node RAN Function dependent Information Elements (lEs).
  • This patent documents includes, in an example, the contents of the fields for the proposed RAN function “Lower Layers Control” (e.g., implemented as E2SM- LLC).
  • E2AP messages can be defined to implement MU-MIMO Optimization for each of the described requests and/or reports:
  • the RIC QUERY REQUEST and the RIC SUBSCRIPTION REQUEST are shown in FIGS. 36A and 36B, respectively.
  • the RIC QUERY REQUEST is shown in FIG. 36E.
  • the RIC SUBSCRIPTION REQUEST is shown in FIG. 36G.
  • the RIC INDICATION is shown in FIG. 36H.
  • the RIC SUBSCRIPTION REQUEST is shown in FIG. 361
  • the RIC INDICATION is shown in FIG. 36J.
  • the RIC QUERY REQUEST and the RIC SUBSCRIPTION REQUEST are shown in FIGS. 36M and 36N, respectively.
  • the RIC QUERY REQUEST and the RIC SUBSCRIPTION REQUEST are shown in FIGS. 36Q and 36R, respectively.
  • the RIC QUERY REQUEST and the RIC SUBSCRIPTION REQUEST are shown in FIGS. 36V and 36W, respectively.
  • the RIC QUERY REQUEST and the RIC SUBSCRIPTION REQUEST are shown in FIGS. 36Z and 36AA, respectively.
  • the RIC QUERY REQUEST and the RIC SUBSCRIPTION REQUEST are shown in FIGS. 36AH and 36AI, respectively.
  • the RIC QUERY REQUEST and the RIC SUBSCRIPTION REQUEST are shown in FIGS. 36AL and 36AM, respectively.
  • the RIC QUERY RESPONSE is shown in FIGS. 36AN and 36AO
  • the RIC INDICATION is shown in FIG. 36AP.
  • the RIC QUERY REQUEST is shown in FIG. 36AQ
  • the RIC QUERY RESPONSE is shown in FIG. 36AR.
  • the RIC QUERY REQUEST and the RIC QUERY RESPONSE are shown in FIGS. 36AS and 36AT, respectively.
  • the RIC QUERY REQUEST is shown in FIG. 36AV
  • the E2 Compression Support Information Report is shown in FIG. 36AW.
  • Embodiments of the disclosed technology can be configured to support a variety of use cases.
  • the motivation, description, and requirements for the O-RAN architecture to support these use cases are discussed in this section.
  • the rapid traffic growth and multiple frequency bands utilized in a commercial network make it challenging to steer the traffic in a balanced distribution.
  • Typical controls are limited to adjusting the cell reselection and handover parameters; and modifying load calculations and cell priorities.
  • the goal of Near-RT RIC Traffic Steering is to interpret the Policies received over A1 and to determine the optimum changes it can make towards achieving those goals. It may also leverage the A1 enrichment information. Traffic Steering may reuse mechanisms provided by other use cases to effect the changes necessary to achieve its goals. More specifically, Near-RT RIC triggers E2 procedure and related control/policies so as to obtain network performance that would fulfill the criteria identified in the A1 policies.
  • the entities and resources involved in this use case include:
  • FIG 18 shows three general Traffic Steering processing modes and the transitions between them. As shown therein, these modes represent the way the Near-RT RIC (or RAN) operates on a given group of UEs, and not the operation of any component as a whole. As such, the Near-RT RIC, could be operating in both modes 1 and 2 concurrently for different sets of UEs. For example, the transition from Mode 0 or 1 to 2 occurs only for a group of UE defined by the A1 policy Scope. At the same time, other UE groups may still be handled in Mode 0 and/or 1 .
  • the three processing modes are further described as:
  • (0) “Baseline” Traffic Steering Behavior OAM Functions in SMO domain uses O1 configuration on one or more E2 node to set up a desired baseline behavior. This also sets up baseline Performance Monitoring of E2 Node by the SMO. In this mode, Near-RT RIC is not involved.
  • Non-RT RIC in SMO domain uses A1-P to specify an A1 guided behavior for a targeted subset of E2 Nodes or UEs. If entering this from Mode 1 , this will have the effect of modifying the existing near-RT RIC “background” behavior to include a more specific A1 guided behavior. In this mode, the near-RT RIC may either set up or modify E2 mechanisms used to monitor E2 Nodes and will use Traffic Steering related E2 mechanisms to obtain the desired behavior of some targeted sub-set of E2 Nodes or UEs.
  • This mode terminates when the corresponding A1 -P Policy Delete message is received from Non-RT RIC in SMO domain and the system returns to either Mode 0 or Mode 1 , depending on whether or not OAM Functions in SMO domain had previously configured the optional Near-RT RIC “background” role (Mode 1).
  • Processing Mode 2 contain an ‘outer loop’ and an ‘inner loop’.
  • a number of different “E2 mechanism” may be used (Policy, Report/Control or Insert/Control) towards a number of different target RAN functions in order to either exercise existing RAN mechanisms or modifying their ongoing behavior.
  • the appropriate mechanism and target RAN Function would depend upon the RAN Function capabilities to support a given E2 mechanism, the A1-P scope and policy, the 01 configuration of the RIC and the performance observed through E2 monitoring.
  • FIGS. 19A and 19B further details the Near RT RIC A1 -Policy Based Traffic Steering, and describes the operations shown in the flow diagram in FIGS. 19C and 19D.
  • the following Near-RT RIC and the E2 Node capabilities are necessary for implementation of the Traffic Steering use case.
  • the serving cell can be chosen based on the resource status and QoS of the UE(s) targeted by an A1 Traffic steering policy. Moreover, load balancing can be achieved to improve the overall network performance. The following procedures can be used for Traffic Steering:
  • CA Carrier Aggregation
  • both RIC POLICY and RIC CONTROL can be used.
  • UE Context Information from E2 Nodes In some embodiments, the followings are examples of UE context information identified as required:
  • - DRB level e.g., established DRB ID, mapping with QoS flows, etc.
  • QoS related e.g., E-RAB Level QoS Parameters (4G, NSA) or QoS Flow Level QoS
  • UE ID, S-NSSAI, DRB ID, or QCI/5QI can be used to derive the QoS requirements and the resource occupation; the UE capabilities may be required to select the appropriate RRM action (e.g. CA/DC configuration).
  • Measurements from E2 Nodes the E2 measurements are necessary for inference and prediction in the Near-RT RIC as the driver for decisions in addition to KPMs.
  • the Near-RT RIC can translate an A1 policy (relatively static targets) into a flexible selection of controls over E2 (e.g. handover control, DC, CA, idle mode mobility) by taking into account the RAN resource utilization, cell level and the UE level performance, the radio conditions, etc.
  • the table in FIG. 19E lists the examples of measurement information identified as required.
  • cell level configuration parameters such as PCI, neighbor relations and related offsets etc. are needed at Near-RT RIC in order to e.g. configure UE measurements monitor cell level performance and manage mobility control (handover and cell reselection) according to the network topology and the related E2 parameters.
  • the network must offer means to prioritize resources while preserving the required QoS properties, e.g. reliability, latency, bandwidth requirements, as specified in 3GPP TS 23.203 [3].
  • Current RAN network coverage and capacity depends on rigorous planning and configuration. However, due to varying nature of traffic demands and radio channels as well as multiple services to co-exist, it is hard to satisfy all QoS requirements simultaneously. In summary, it is important for an E2 Node to achieve QoS targets as smoothly as possible.
  • the QoS aware resource optimization should provide a refined granularity of radio resource allocation based on varying radio conditions and traffics in order to meet the diverse requirements of reliability, latency, and bandwidth simultaneously.
  • the Near-RT RIC should be able to trigger re-allocation of radio resources so that the QoS indicators can move back within limits outlined in the A1 policies.
  • the entities and resources involved in this use case include:
  • - Send A1 policies to and receive policy feedback from Near-RT RIC to drive resource optimization at RAN level, e.g., QoS targets, such as Guaranteed Flow Bit Rate (GFBR), Maximum Flow Bit Rate (MFBR), Priority Level, PDB.
  • QoS targets such as Guaranteed Flow Bit Rate (GFBR), Maximum Flow Bit Rate (MFBR), Priority Level, PDB.
  • FIGS. 20A and 20B further details the QoS-Based Resource Optimization, and describes the operations shown in the flow diagram in FIG. 20C.
  • the following Near-RT RIC and the E2 Node capabilities are necessary for implementation of the QoS-based resource optimization use case.
  • RB control can be applied for modification of the following QoS properties:
  • DRB QoS modification e.g., DRB level QoS may be tuned to accommodate A1 policy requirement.
  • - QoS flow remapping e.g., the mapping relationship between QoS flows and DRBs may be adjusted.
  • Logical channel reconfiguration e.g., parameters such as priority, prioritized bit rate, bucket size duration, etc. can be considered.
  • Radio Admission Control e.g., DRB admission control such as reject or release may be applied.
  • Radio Resource Allocation such as configuration of DRX, semi-persistent scheduling (SPS), or guidance for the scheduling and rate selection in MAC, can be adjusted. For example, based on prediction, an E2 policy or control to reconfigure SPS configuration or ConfiguredGrantConfig for UL may be generated.
  • - DRX reconfiguration e.g., Long DRX cycle length, Short DRX cycle length as well as short DRX cycle timer can be considered.
  • SR periodicity reconfiguration e.g., both sr-ProhibitTimer and sr-TransMax can be treated.
  • - SPS configuration e.g., both SPS-Config (DL) and ConfiguredGrantConfig (UL) can be treated.
  • both RIC POLICY and RIC CONTROL can be used.
  • SPS can be configured via RIC CONTROL;
  • RIC POLICY can be used, e.g. to set the guidance for the scheduler.
  • Radio Access Control can be configured. Depending on operator's policies, deployment scenarios, subscriber profiles, and available services, different criterion will be used in determining which access attempt should be allowed or blocked when congestion occurs in the system. For example, access control may be applied to restrict access of other UEs for a specific cell in order to achieve better QoS for some UEs. A cell-level, UE-level, or slice-level access control can be applied. Four categories of radio access control are indicated as below:
  • both RIC POLICY and RIC CONTROL can be used.
  • Connection Mobility Control can be adjusted.
  • a neighboring cell may be selected for the optimization of QoS of a specific UE.
  • a neighbor handover restriction list may be configured to prevent the UEs from HO to some neighboring cells in order to guarantee QoS of the UEs served by those neighboring cells.
  • a capacity boosting mechanism may be used to achieve better QoS, e.g. enable CA/DC.
  • UE Context Information from E2 Nodes In some embodiments, the following are examples of UE context information identified as required:
  • - DRB level e.g., established DRB ID, mapping with QoS flows, etc.
  • - QoS related e.g., E-RAB Level QoS Parameters (4G, NSA) or QoS Flow Level QoS
  • RLC/MAC/PHY level e.g., logical channel, DRX, scheduling request, SPS configurations.
  • UE ID, S-NSSAI, DRB ID, or QCI/5QI can be used for different granularity of controls over E2; an established DRB level information may be needed to change the mapping of QoS flows to a specific DRB or modify DRB attributes; the UE capabilities may be required to make sure if CA/DC can be enabled.
  • the E2 measurements are necessary for inference and prediction in the Near-RT RIC as the driver for decisions in addition to KPMs.
  • the Near-RT RIC can translate an A1 policy (relatively static targets) into a flexible selection of controls over E2 (e.g. RB control, handover, access control) by taking into account the runtime status in the Near-RT RIC. Therefore, it is required to specify those measurement parameters as possible as needed over E2 interface.
  • the 3GPP standards architected a sliceable 5G infrastructure which allows creation and management of customized networks to meet specific service requirements that may be demanded by future applications, services and business verticals. Such a flexible architecture needs different requirements to be specified in terms of functionality, performance and group of users which may greatly vary from one service to the other.
  • the 5G standardization efforts have gone into defining specific slices and their Service Level Agreements (SLAs) based on application/service type. Since network slicing is conceived to be an end-to-end feature that includes the core network, the transport network and the radio access network (RAN), these requirements should be met at any slice subnet during the life-time of a network slice, especially in RAN side.
  • SLAs Service Level Agreements
  • Exemplary slice performance requirements are defined in terms of throughput, energy efficiency, latency and reliability at a high level in SDOs such as 3GPP and GSMA. These requirements are defined as a reference for SLA/contractual agreements for each slice, which individually need proper handling in NG-RAN.
  • network slicing support is started to be defined with 3GPP Release 15, slice assurance mechanisms in RAN needs to be further addressed to achieve deployable network slicing in an open RAN environment. It is necessary to assure the SLAs by dynamically controlling slice configurations based on slice specific performance information.
  • Existing RAN performance measurements and information model definitions are not enough to support RAN slice SLA assurance use cases. This use case is intended to clarify necessary mechanisms and parameters for RAN slice SLA assurance.
  • network slicing is a prominent feature which provides end-to-end connectivity and data processing tailored to specific business requirements. These requirements include customizable network capabilities such as the support of very high data rates, traffic densities, service availability and very low latency.
  • the 5G system should support the needs of the business through the specification of several service needs such as data rate, traffic capacity, user density, latency, reliability, and availability.
  • SLA Service Level Agreement
  • O-RAN’s open interfaces and AI/ML based architecture will enable such challenging mechanisms to be implemented and help pave the way for operators to realize the opportunities of network slicing in an efficient manner.
  • the entities and resources involved in this use case include:
  • FIGS. 21 A and 21 B further details the RAN Slice SLA Assurance use case, and describes the operations shown in the flow diagram in FIG. 21 C.
  • the following Near-RT RIC and the E2 Node capabilities are necessary for implementation of the QoS-based resource optimization use case.
  • Radio Resource Allocation such as configuration of slice level PRB quota
  • Radio Resource Allocation can be adjusted. For example, based on prediction, an E2 policy or control to reconfigure slice level PRB may be generated, e.g., configuration and/or reconfiguration of slice level PRB quota.
  • Radio Access Control can be adjusted. Depending on operator's policies, deployment scenarios, subscriber profiles, available services and SLA of slice, different criterion will be used in determining which access attempt should be allowed or blocked when congestion occurs in the system. For example, access control may be applied to restrict access of other UEs for a specific slice in order to achieve better SLA for some slice. A UE-level, or slice-level access control can be applied. Three categories of radio access control are indicated as below:
  • UE Context Information from E2 Nodes In some embodiments, the following are examples of UE context information identified as required:
  • the E2 measurements are necessary for inference and prediction in the Near-RT RIC as the driver for decisions in addition to KPMs.
  • the Near-RT RIC can translate an A1 policy (relatively static targets) into a flexible selection of controls over E2 (e.g. PRB control, access control) by taking into account the runtime status in the Near-RT RIC. Therefore, it is required to specify those measurement parameters as possible as needed over E2 interface.
  • the entities and resources involved in this use case include:
  • Model Training in Non-RT RIC details AI/ML-assisted Non-GoB BF mode selection in Non-RT RIC - model training, deployment, and update, and describes the operations shown in the flow diagram in FIGS. 22C and 22D.
  • Model Training in Near-RT RIC details AI/ML-assisted Non-GoB BF mode selection in Near-RT RIC - model training, deployment, and update, and describes the operations shown in the flow diagram in FIG. 23B.
  • Model Inference In some embodiments, the table shown in FIG. 24A details AI/ML-assisted Non- GoB BF mode selection - model inference, and describes the operations shown in the flow diagram in FIG. 24B.
  • Beam-based Mobility Robustness Optimization is an autonomous self-optimizing algorithm that improves beam-based inter-cell mobility performance by applying beam-specific HO parameters including Cell Individual Offsets (CIO), Time to Trigger (TTT), T310 counter, etc. on the handover configuration between neighbor cells, based on the analysis of beam-specific mobility-related counters and/or mobility failure events.
  • bMRO is capable to reduce the number of unnecessary handovers, handover failures as well as ping-pong handovers particularly in cells that cover areas with different mobility characteristics.
  • Signaling overhead and complexity can be further reduced by beam grouping in which case beams with similar mobility characteristics comprise a beam group (e.g., group 1 : low mobility pedestrian area, group 2: high mobility street).
  • Mobility reports consist of aggregated mobility KPI/PMs (e.g., number of too early HOs, number of too late HOs, number of HO to wrong cell) or individual failure reports with root cause (e.g., to early HO, too late HO, HO to wrong cell) or a combination of the two. Reports are sent per each SSB beam or SSB beam group towards each neighbor cell.
  • Individual mobility failure reports will also be reported per UE to allow UE or UE group-based optimization (besides beam or beam group specific reporting). While aggregated mobility KPIs/PMs are used for slow adaptations (e.g., 5 min), individual failure reports are used for faster adaptations (e.g., 100 ms) or for AI/ML based analysis of failure patterns. Measurement reporting periodicity and measurement type are configurable on a per cell basis considering the tradeoff between gain in mobility performance and associated signaling overhead.
  • Mobility KPIs and failure events are forwarded from the O-CU to the Near-RT RIC, and the near-RT RIC configures the CIO and the measurement reporting in the O-CUs.
  • CIOs might be beam- or beam group- based and can also be configurable per UE group (e.g., UE type, UE mobility or UE mode such as energy saving mode).
  • AI/ML methods/models can be used i) to build beam groups, to ii) decide on cell individual measurement configuration, to iii) detect changes in mobility characteristics (e.g., traffic jam) that trigger optimization, to iv) group UEs in UE groups as well as v) for the bMRO optimization algorithm itself to calculate the optimal cell individual offsets.
  • relevant mMIMO beam pattern information must be available at the Near-RT RIC, e.g., mobility reports might indicate a specific beam pattern.
  • FIG. 25A shows a table detailing Near-RT RIC Beam-based Mobility Robustness Optimization - model training and initial beam grouping
  • FIG. 25B shows a flow diagram for the procedure for this use case.
  • FIGS. 26A and 26B show a table detailing Near RT RIC Beam-based Mobility Robustness Optimization - model inference and mobility optimization, and FIGS. 26C and 26D show a flow diagram for the procedure for this use case.
  • FIGS. 27 A and 27B show a table detailing an MU-MIMO Optimization procedure, and FIGS. 27C and 27D show a flow diagram for the example MU-MIMO Optimization use case.
  • the following Near-RT RIC and the E2 Node capabilities are necessary for implementation of the MU-MIMO Optimization use case.
  • RAN analytics information as RAN service can be exposed to RAI service consumers for specific UE (identified according to [32] section 4.5) or for groups of UE (per slice, per cell, per PLMN, etc.). RAI is envisioned to be helpful for the applications to improve the user experience. Near-RT RIC and E2 interface are leveraged to support this use case.
  • Measurement data through E2 interface e.g., cell level data, UE level data
  • E2 interface can be acquired and processed via ML algorithms to support traffic recognition, QoE prediction, and QoS enforcement decisions.
  • the analytics information e.g., traffic rate, latency, packet loss rate
  • the RAI service consumers can be used to help applications execute logical control.
  • the entities and resources involved in this use case include:
  • FIG. 28A shows a table detailing RAN Performance Analytics assisted QoE Optimization
  • FIG. 28B shows a flow diagram for the procedure for this use case.
  • FIG. 29A shows a table detailing RAN Performance Analytics assisted QoE Optimization using subscription based solution
  • FIG. 29B shows a flow diagram for the procedure for this use case.
  • the mUMO enables dynamic scheduling by making all the scheduling decisions for non- time-critical flows and provides the scheduling parameters and any precoding information (spatial multiplexing groups of UEs with their resource assignments, precoding coefficients, etc.) to the O-DU for preparing the DCIs and transmitting the scheduled flows. This is done by separating the control plane of the DU from the data plane and moving most of the controls to the Near-RT RIC (xApp).
  • the mUMO can be implemented as an xApp in the Near-RT RIC (as detailed in this patent document).
  • the mUMO can be co-located with the DU as a separate module.
  • the mUMO can be co-located with the CU as a separate module creating a CU-DU interface similar to split-5.
  • FIG. 30 is a flowchart of an example method 3000 of facilitating wireless communication.
  • the method 3000 includes, at operation 3010, generating, by a first network function, a proposed schedule of transmissions and receptions in a multi-user multiple-input multiple-output (MU-MIMO) network.
  • MU-MIMO multi-user multiple-input multiple-output
  • the method 3000 includes, at operation 3020, communicating, by the first network function, the proposed schedule to a second network function that is logically and physically separated from the first network function.
  • the second network function is configured to determine, based on a time criticality of pending communication tasks, a final schedule of the transmissions and receptions by overwriting entries of the proposed schedule.
  • FIG. 31 is a flowchart of another example method 3100 of facilitating wireless communication.
  • the method 3100 includes, at operation 3110, receiving, from a first network function, by a second network function that is logically and physically separated from the first network function, a proposed schedule of transmissions and receptions in a multi-user multiple-input multiple-output (MU-MIMO) network.
  • MU-MIMO multi-user multiple-input multiple-output
  • the method 3100 includes, at operation 3120, determining, by the second network function and based on a time criticality of pending communication tasks, a final schedule of the transmissions and receptions by overwriting entries of the proposed schedule generated by the first network function.
  • a method of operating a wireless network comprising: operating a multi-user multi-input multi-output (MU-MIMO) control function in wireless network comprising multiple network functions, wherein the MU-MIMO control function provides an MU-MIMO capability to the wireless network using which the wireless network provides wireless connectivity to user devices using an MU-MIMO configuration.
  • MU-MIMO multi-user multi-input multi-output
  • A2 The method of solution A1 , further including: configuring the MU-MIMO function to operate as an xApp module such that the MU-MIMO control function communicates with the multiple network functions using existing interface protocols and/or using MU-MIMO enhancements to existing interface protocols.
  • A4 The method of solution A3, wherein a performance criterion met by the MU-MIMO function specifies a near-real-time (near-RT) operation of a control loop that comprises the MU-MIMO function, wherein the near-RT operation has a response time less than 1 second.
  • near-RT near-real-time
  • A5. The method of any of solutions A3 to A4, wherein the MU-MIMO function is configured to communicate information to assist scheduling to meet the near-RT operation of the control loop.
  • A6 The method of solution A3, wherein the one or more performance criteria include: an ability to receive or configure a cell configuration at a first time granularity, an ability to receive or configure UE- level information at a second time granularity, an ability to receive or configured channel state information or sounding reference signal information at a third time granularity, an ability to control parameter covered by downlink control information (DCI) format 1 .0, an ability to control parameter covered by downlink control information (DCI) format 1 .1 , an ability to control physical downlink shared channel configuration at a fourth time granularity, an ability to control a measurement gap configuration at a fifth time granularity, an ability to receive report of or configure active data radio bearer information at a sixth time granularity, an ability to control data transmission/reception scheduling information items at a respective time granularity, the items including uplink channel quality information, downlink channel quality information, PDCP buffer status, RLC buffer occupancy, timestamps or support for subband PMI,
  • A7 The method of any of above solutions, wherein the performance criteria include: ability to communicate information on the allocations of user devices to transmission resources; precoder coefficients per SMG; scheduling multiple slots into the future; or allocating amount of data per LCID.
  • Some solutions implementing the interface protocol, message syntax, and/or message field semantics include:
  • A8 The method of any of above solutions, wherein the MU-MIMO control functions is configured to communicate with the multiple network functions using a service interface according to one or more of a report message, an insert message, a control message, a policy message or a query message.
  • the query message comprises a management information base (MIB) information element (IE) or a field indicative of an IE indicating a periodicity of a synchronization signal transmission block within a cell served by the MU-MIMO control function.
  • MIB management information base
  • IE information element
  • A11 The method of any of above solutions, wherein the query message and the report message support querying or reporting a downlink bandwidth part information element.
  • control message is configured to (1) add or release resources of a channel state information configuration, (2) add or remove report configurations for reporting a channel state information, (3) add or remove entries of a sounding reference signal configuration, (4) add or remove a configuration of a physical downlink shared data channel, (5) report parameters of a bandwidth part information element or a physical downlink shared data channel information element.
  • A14 The method of any of above solutions, wherein the query message is configured to query a measurement gap configuration information element (IE) or a logical channel identity IE and the report message is configured to report the measurement gap configuration IE or the logical channel identity IE.
  • the query message is configured to query a measurement gap configuration information element (IE) or a logical channel identity IE and the report message is configured to report the measurement gap configuration IE or the logical channel identity IE.
  • SRS sounding reference signal
  • Rl resource indicator
  • PMI I precoding matrix indicator
  • CQI channel quality indicator
  • A16 A method, implemented by a processor, comprising: operating a network function to facilitate MU-MIMO operation of a network by transmitting or receiving a message having fields described in the present document.
  • A17 A method, implemented by a processor, comprising: operating a network function to facilitate MU-MIMO operation of a network by transmitting or receiving a message having fields in an order described in the present document.
  • a method of facilitating wireless communication comprising: generating, by a first network function, a proposed schedule of transmissions and receptions in a multi-user multi-input multi-output network; communicating, by the first network function, the proposed schedule to a second network function that is logically and physically separated from the first network function; wherein the second network function is permitted to determine a final schedule of transmissions and receptions by overwriting entries of the proposed schedule generated by the first network function.
  • a method of facilitating wireless communication comprising: receiving, by a second network function, from a first network function, a proposed schedule of transmissions and receptions in a multiuser multi-input multi-output network (MU-MIMO); and determining, by the second network function, a final schedule of transmissions and receptions by overwriting entries of the proposed schedule generated by the first network function based on time criticality of pending communication tasks.
  • MU-MIMO multi-input multi-output network
  • A20 The method of any of solutions A18 to A19, wherein the first network function and the second network function are configured to transmit or receive messages according to a message protocol.
  • A21 The method of any of above solutions, wherein the first network function comprises an xapp software module.
  • A22 The method of any of above solutions, wherein at least a portion of the second network function is included in a distributed unit (DU) of a wireless communication network.
  • DU distributed unit
  • A23 The method of any of above solutions, wherein the second network function is configured to maintain one or more flow queues, wherein each queue is associated with a quality indicator.
  • A24 The method of solution A23, wherein the message protocol specifies a flow report transmission from the second network function to the first network function, wherein the flow report transmission reports one or more of user equipment identifiers, quality indicators and queue status.
  • A25 The method of any of above solutions, wherein the first network function is configured to track channel statistics, maintain a database of flow(s) for each user equipment and priority information for each flow.
  • A26 The method of any of above solutions, wherein the first network function is configured to determine spatial multiplexing groupings of user equipment and use the spatial multiplexing groupings for the proposed schedule.
  • A27 The method of solution A26, wherein the first network function generates the proposed schedule by assigning bandwidth to non-time critical flows within available physical resource blocks.
  • A28 The method of solution A27, wherein the second network function performs the overwriting by assigning unassigned physical resource blocks to time-critical flows and/or by re-assigning physical resource blocks previously assigned to non-time critical flows in the proposed schedule to time-critical flows.
  • A29 The method of solution A28, wherein after the final schedule is determined, the final schedule a scheduling response is transmitted by the second network function and received by the first network function.
  • A30 The method of solution A29, wherein, based on the scheduling response, the first network function updates locally stored flow database.
  • A31 The method of any of solutions A20 to A30, wherein the API defines a message for exchanging information about semi-persistent scheduling flows.
  • A33 The method of any of above solutions, wherein the message protocol defines a first message transmitted from the first network function to a third network function, wherein the first message requests information about capabilities of user devices in the MU-MIMO network and a second message that carries requested information from the third network function to the first network function.
  • A34 The method of any of above solutions, wherein the message protocol defines a first message transmitted from the first network function to the second network function, wherein the first message requests antenna information and a second message that carries requested information from the second network function to the first network function.
  • A35 The method of any of above solutions, wherein the message protocol defines a message that communicates a served bearer scheduling configuration control information.
  • A36 The method of any of above solutions, wherein the message protocol defines a message that communicates information about support of compression capabilities.
  • A37 An apparatus comprising a processor configured to implement a method recited in any one or more of solutions A1 to A36.
  • a storage medium having computer-executable code stored thereon, the code, upon execution by a processor, causing the processor to implement a method recited in any one or more of solutions A1 to A36.
  • A39 A system comprising a plurality network functions configured to operate a radio access network that provides wireless connectivity to user devices, wherein the at least some of the network functions are configured to operate according to a technique described in the present document.
  • a method e.g., method 3000 in FIG. 30 of facilitating wireless communications, comprising: generating (3010), by a first network function, a proposed schedule of transmissions and receptions in a multi-user multiple-input multiple-output (MU-MIMO) network; and communicating (3020), by the first network function, the proposed schedule to a second network function that is logically and physically separated from the first network function, wherein the second network function is configured to determine, based on a time criticality of pending communication tasks, a final schedule of the transmissions and receptions by overwriting entries of the proposed schedule.
  • MU-MIMO multi-user multiple-input multiple-output
  • a method e.g., method 3100 in FIG. 31 of facilitating wireless communications, comprising: receiving (3110), from a first network function, by a second network function that is logically and physically separated from the first network function, a proposed schedule of transmissions and receptions in a multi-user multiple-input multiple-output (MU-MIMO) network; and determining (3120), by the second network function and based on a time criticality of pending communication tasks, a final schedule of the transmissions and receptions by overwriting entries of the proposed schedule generated by the first network function.
  • MU-MIMO multi-user multiple-input multiple-output
  • B4 The method of solution B3, wherein the second network function is configured to maintain one or more flow queues, and wherein each flow queue is associated with a quality indicator.
  • B5. The method of solution B4, wherein the message protocol specifies a transmission of a flow report from the second network function to the first network function, and wherein the flow report includes one or more wireless device identifiers, quality indicators, or queue statuses.
  • B17 The method of solution B1 or B2, wherein the proposed schedule is generated on a per time-domain symbol basis.
  • B18 The method of any of solutions B1 to B17, wherein the first network function comprises a software module associated with a cloud-based service that provides cellular network services to any cloud-based application.
  • the one or more performance criteria includes at least one of: an ability to receive or configure a cell configuration at a first time granularity; an ability to receive or configure a user equipment (UE)-level information at a second time granularity; an ability to receive or configure a channel state information (CSI) or a sounding reference signal (SRS) at a third time granularity; an ability to control a first parameter covered by downlink control information (DCI) format 1_0; an ability to control a second parameter covered by DCI format 1_1 ; an ability to control a physical downlink shared channel (PDSCH) configuration at a fourth time granularity; an ability to control a measurement gap configuration at a fifth time granularity; an ability to receive or configure active data radio bearer information at a sixth time granularity; an ability to control one or more parameters associated with data transmission/reception scheduling information, the one or more parameters comprising an uplink channel quality information (CQI), a
  • CQI uplink channel quality information
  • the method of solution B22, wherein the one or more performance criteria includes at least one of: an ability to communicate information regarding allocations of wireless devices to transmission resources; precoder coefficients per spatially multiplexed group (SMG); an ability to schedule multiple slots at one or more future times; or allocating an amount of data per logical channel identity (LCID).
  • SMG spatially multiplexed group
  • LCID logical channel identity
  • the query message comprises a management information database (MIB) information element (IE) or a field indicative of an IE indicating a periodicity of a synchronization signal block (SSB) within a cell served by the MU-MIMO control function.
  • MIB management information database
  • IE information element
  • SSB synchronization signal block
  • B29 The method of solution B27, wherein the report message comprises a field indicative of a change to a management information database (MIB) identity or a change in a synchronization signal block (SSB) periodicity.
  • MIB management information database
  • SSB synchronization signal block
  • control message is configured to (1) add or release resources of a channel state information (CSI) configuration, (2) add or remove report configurations for reporting CSI, (3) add or remove entries of a sounding reference signal (SRS) configuration, (4) add or remove a configuration of a physical downlink shared channel (PDSCH), (5) report parameters of a bandwidth part (BWP) information element (IE) or a PDSCH IE.
  • CSI channel state information
  • SRS sounding reference signal
  • PDSCH physical downlink shared channel
  • BWP bandwidth part
  • IE bandwidth part
  • IE bandwidth part
  • B34 The method of solution B27, wherein the MU-MIMO control function is further configured to communicate with the multiple network functions using a second service interface according to one or more of: a report triggered by receiving sounding reference signal (SRS) symbols; a resource indicator (Rl), a precoding matrix indicator (PMI), or a channel quality indicator (CQI) of one or more wireless devices upon receiving a channel state information report; a count of uplink acknowledgement (ACK) messages and negative acknowledgement (NACK) messages by the one or more wireless devices; a count of downlink ACK messages, NACK messages, and discontinuous transmission (DTX) messages; a buffer occupancy information at a protocol data convergence layer or a radio link control (RLC) layer.
  • SRS sounding reference signal
  • Rl resource indicator
  • PMI precoding matrix indicator
  • CQI channel quality indicator
  • ACK uplink acknowledgement
  • NACK negative acknowledgement
  • DTX discontinuous transmission
  • An apparatus comprising one or more processors and a transceiver communicatively coupled to the one or more processors, wherein the transceiver is configured to implement the communicating or the receiving operations recited in any one or more of solutions B1 to B34, and wherein the one or more processors are configured to implement the generating or the determining operations.
  • B36 A storage medium having computer-executable code stored thereon, the computerexecutable code, upon execution by one or more processors, causing the one or more processors to implement the method recited in any one or more of solutions B1 to B34.
  • the first network function and the second network functions may be a software module implemented on one or more processors implementing xApp and a distributed unit (DU), as is described in the present document.
  • DU distributed unit
  • FIG. 32 is a block diagram representation of a wireless hardware platform 3200 which may be used to implement the various methods described in the present document.
  • the hardware platform 3200 may be incorporated within a base station or a user device.
  • the hardware platform 3200 includes at least one processor 3202, a memory 3204 and a transceiver circuitry 3206.
  • the processor may execute instructions, e. g., by reading from the memory 3204, and control the operation of the transceiver circuitry 3206 and the hardware platform 3200 to perform the methods described herein.
  • the memory 3204 and/or the transceiver circuitry 3206 may be partially or completely contained within the processor 3202 (e.g., same semiconductor package).
  • the transceiver circuitry 3206 may be configured to implement a wired or a wireless communication protocol.
  • a scheduler function that schedules various uplink and/or downlink transmissions in the network may be implemented to perform MU-MIMO based communication. It will further be appreciated that, according to some embodiments, the scheduler may be implemented into two separately operating schedulers, e.g., one at a CU and one at a DU. One of the schedulers, e.g., implemented as an xApp, may provide non-time critical schedules.
  • the second scheduler e.g., implemented locally at the network element that is closest to the air interface, may implement time-critical tasks such as URLLC communication, retransmissions, and so on.
  • the second scheduler may operate to overwrite the schedule generated by the first scheduler in order to achieve the near-RT performance desired in a wireless network.
  • the disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus.
  • the computer readable medium can be a machine-readable storage device, a machine- readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more them.
  • data processing apparatus encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers.
  • the apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.
  • a propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus.
  • a computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
  • a computer program does not necessarily correspond to a file in a file system.
  • a program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code).
  • a computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
  • the processes and logic flows described in this document can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output.
  • the processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
  • processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer.
  • a processor will receive instructions and data from a read -only memory or a random access memory or both.
  • the essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data.
  • a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
  • mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
  • a computer need not have such devices.
  • Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks.
  • semiconductor memory devices e.g., EPROM, EEPROM, and flash memory devices
  • magnetic disks e.g., internal hard disks or removable disks
  • magneto optical disks e.g., CD ROM and DVD-ROM disks.
  • the processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

Landscapes

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

Abstract

Methods, systems, and devices for operating a wireless communication network are described. One example method includes configuring a multi-user multi-input multi-output (MU-MIMO) control function in a wireless network comprising multiple network functions, where the MU-MIMO control function provides an MU-MIMO capability to the wireless network using which the wireless network provides wireless connectivity to user devices using an MU-MIMO configuration.

Description

NETWORK-SIDE COORDINATION OF MULTI-USER MULTIPLE-INPUT MULTIPLEOUTPUT FUNCTIONALITY
CROSS-REFERENCE TO RELATED APPLICATIONS
[001J This application claims priority to U.S. Provisional Patent Application No. 63/506,021 , filed June 2, 2023, U.S. Provisional Patent Application No. 63/583,209, filed September 15, 2023, U.S. Provisional Patent Application No. 63/569,711 , filed March 25, 2024, and U.S. Provisional Patent Application No. 63/572,095, filed March 29, 2024, the disclosures of which are hereby incorporated by reference herein in their entirety.
TECHNICAL FIELD
[002] The present document relates to wireless communication.
BACKGROUND
[003] Due to an explosive growth in the number of wireless user devices and the amount of wireless data that these devices can generate or consume, current wireless communication networks are fast running out of bandwidth to accommodate such a high growth in data traffic and provide high quality of service to users.
[004] Various efforts are underway in the telecommunication industry to come up with next generation of wireless technologies that can keep up with the demand on performance of wireless devices and networks. Many of those activities involve situations in which a large number of user devices may be served by a network.
SUMMARY
[005] This document discloses techniques that may be used by wireless networks to achieve several operational improvements.
[006] In an example aspect, a wireless communication method is disclosed. The method includes configuring a multi-user multi-input multi-output (MU-MIMO) control function in a wireless network comprising multiple network functions. Herein, the MU-MIMO control function provides an MU-MIMO capability to the wireless network using which the wireless network provides wireless connectivity to user devices using an MU-MIMO configuration.
[007] In another example aspect, a method of facilitating wireless communication is disclosed. The method includes generating, by a first network function, a proposed schedule of transmissions and receptions in a multi-user multiple-input multiple-output (MU-MIMO) network. Then, the first network function communicates the proposed schedule to a second network function that is logically and physically separated from the first network function. In this example method, the second network function is configured to determine, based on a time criticality of pending communication tasks, a final schedule of the transmissions and receptions by overwriting entries of the proposed schedule.
[008] In yet another example aspect, a method of facilitating wireless communication is disclosed. The method includes receiving, from a first network function, by a second network function that is logically and physically separated from the first network function, a proposed schedule of transmissions and receptions in a multi-user multiple-input multiple-output (MU-MIMO) network. Then, the second network function determines, based on a time criticality of pending communication tasks, a final schedule of the transmissions and receptions by overwriting entries of the proposed schedule generated by the first network function.
[009] In yet another example aspect, a wireless communication apparatus that implements the abovedescribed methods is disclosed.
[010] In yet another example aspect, a wireless system in which one or more of the above-described methods are implemented is disclosed.
[OU] In yet another example aspect, the above-described methods may be embodied as processorexecutable code and may be stored on a computer-readable program medium.
[012] These, and other, features are described in this document.
BRIEF DESCRIPTION OF THE DRAWINGS
[013] Drawings described herein are used to provide a further understanding and constitute a part of this application. Example embodiments and illustrations thereof are used to explain the technology rather than limit its scope.
[014] FIG. 1 shows a block diagram of an example system that can perform network-side coordination of MU-MIMO functionality.
[015] FIG. 2 shows a block diagram of an example Open Radio Access Network (O-RAN) logical architecture.
[016] FIG. 3 shows a block diagram of the interactions of an example Near-Real Time RAN Intelligent Controller (Near-RT RIC).
[017] FIG. 4 shows a flow diagram for an example RIC Service REPORT.
[018] FIGS. 5A and 5B show a flow diagram for an example RIC Service INSERT.
[019] FIGS. 6A and 6B show a flow diagram for an example RIC Service CONTROL.
[020] FIG. 7 shows a flow diagram for an example RIC Service QUERY.
[021] FIG. 8 is a diagram showing a Universal Spectrum Multiplier (USM) communicating with a cellular node (e.g., a gNodeB) though a gRPC channel.
[022] FIG. 9 shows a flow diagram for an example initialization procedure between the USM and gNB shown in FIG. 8. [023] FIG. 10 shows a flow diagram for the attachment of a user equipment (UE) to the gNB in the context of leveraging the USM.
[024] FIGS. 1 1A and 11 B show a flow diagram for the end-to-end flow between the USM and multiple UEs via various components and modules of the gNB.
[025] FIG. 12 shows a block diagram for an MIMO scheduling management.
[026] FIGS. 13-17 show an example scenario of how bandwidth scheduling may be managed between a Distributed Unit (DU) and the USM scheduler.
[027] FIG. 18 shows an example of different traffic steering processing modes.
[028] FIGS. 19A and 19B show a table detailing the Near RT RIC A1 -Policy Based Traffic Steering, FIGS. 19C and 19D show a flow diagram for the overall procedure for the Near RT RIC A1 -Policy based Traffic Steering use case, and FIG. 19E show a table that lists examples of measurement information identified as required in this use case.
[029] FIGS. 20A and 20B show a table detailing a Quality-of-Service (QoS)-Based Resource Optimization use case, and FIG. 20C shows a flow diagram for the overall procedure for the QoS-Based Resource Optimization use case.
[030] FIGS. 21 A and 21 B show a table detailing a RAN Slice SLA Assurance use case, and FIG. 21 C shows a flow diagram for an example of the RAN Slice SLA Assurance use case.
[031] FIGS. 22A and 22B show a table detailing AI/ML-assisted Non-GoB BF mode selection in Non- RT RIC, and FIGS. 22C and 22D show a flow diagram of an example of this use case.
[032] FIG. 23A shows a table detailing AI/ML-assisted Non-GoB BF mode selection-model training in Near-RT RIC, and FIG. 23B shows a flow diagram for an example of this use case.
[033] FIG. 24A shows a table detailing AI/ML Inference, and FIG. 24B shows a flow diagram for an example of this use case.
[034] FIG. 25A shows a table detailing Near-RT RIC Beam-based Mobility Robustness Optimization - model training and initial beam grouping, and FIG. 25B shows a flow diagram for the procedure for this use case.
[035] FIGS. 26A and 26B show a table detailing Near RT RIC Beam-based Mobility Robustness Optimization - model inference and mobility optimization, and FIGS. 26C and 26D show a flow diagram for the procedure for this use case.
[036] FIGS. 27A and 27B show a table detailing an MU-MIMO Optimization procedure, and FIGS. 27C and 27D show a flow diagram for the example MU-MIMO Optimization use case.
[037] FIG. 28A shows a table detailing RAN Performance Analytics assisted QoE Optimization, and FIG. 28B shows a flow diagram for the procedure for this use case.
[038] FIG. 29A shows a table detailing RAN Performance Analytics assisted QoE Optimization using subscription based solution, and FIG. 29B shows a flow diagram for the procedure for this use case. [039] FIG. 30 is a flowchart of an example method of facilitating wireless communication.
[040] FIG. 31 is a flowchart of another example method of facilitating wireless communication.
[041] FIG. 32 shows an example of a hardware platform that is used to implement one or more of the disclosed techniques and/or embodiments.
[042] FIGS. 33A-33AI show examples of E2 messages exchanged with the CU.
[043] FIGS. 34A-34U show examples of E2 messages exchanged with the DU.
[044] FIGS. 35A-33D show examples of required information for MU-MIMO Optimization. [045] FIGS. 36A-36AW show examples of E2AP messages that implement the proposed implementation for E2SM RC.
DETAILED DESCRIPTION
[046] To make the purposes, technical solutions and advantages of this disclosure more apparent, various embodiments are described in detail below with reference to the drawings. Unless otherwise noted, embodiments and features in embodiments of the present document may be combined with each other.
[047] Section headings are used in the present document to improve readability of the description and do not in any way limit the discussion or the embodiments to the respective sections only. Certain standard-specific terms are used for illustrative purpose only, and the disclosed techniques are applicable to any wireless communication systems.
[048] 1. Introduction and System Overview
[049] Today, wireless networks are ubiquitously present and provide wireless data connectivity to wireless (or user) devices, sometimes called user equipment (UE), such as mobile phones, laptops, pads, machine to machine communication devices and so on and so forth. Although the use of wireless networks has become widespread, there still remain many technical challenges. The ever-increasing number of UEs requires more bandwidth and more efficient operation of networks to provide uninterrupted data connectivity to UEs. In this regard, the wireless industry has undertaken several initiatives to address the technical problems both on the network-side and on user-side. A recently introduced technology, often called multi-user multiple-input multiple-output (MU-MIMO) allows a network device configured with multiple transmission antennas (or transmission points) to transmit or receive signals to multiple UEs, at least some of which are configured with multiple antennas.
[050] Effective use of such a configuration, however, requires increased complexity on the network side to be able to accommodate the increased network capacity, sometimes measured as bits per Hz per second per user. For example, it is beneficial for the network to quickly react to changing wireless conditions on a channel between multiple antennas (or transmission points) between UEs and base stations. Currently, there are no technical solutions that meet near real-time performance requirements for such network configurations. [051] To address general network operational issues, an industry group, called Open Radio Access Network (O-RAN) has assembled a set of performance requirements and standard interfaces among various network elements to enable networks to keep up with the ever-increasing demand for wireless network availability and performance.
[052] The present document discloses various techniques that address, among other things, improvements to existing O-RAN framework to enable support for MU-MIMO and allows for technical solutions that will be able to meet stringent performance requirements. The disclosed embodiments improve spectral efficiency for communications service providers by as much as two times by enabling mobile networks to communicate with multiple users simultaneously using the same time and frequency resources. In an example, this is achieved by using dynamic and smart pairing as well as precoding techniques. Specifically, embodiments of the disclosed technology include the Universal Spectrum Multiplier (USM) that leverages the delay-Doppler channel representation, which enables highly accurate predictions of signal-to-noise ratio (SNR) and user pairing. This channel representation reduces computation complexity and can be used for predicting the future given that its geometric nature is slow changing.
[053] The disclosed embodiments can be implemented as a software module (termed USM xApp) associated with a cloud-based service that provides cellular network services (e.g., 5G connectivity) to any cloud-based application. USM xApp is designed to overcome several challenges, including reference signal contamination (intercell interference); channel state information (CSI) aging; stability under mobility and other channel dynamics; higher number of layers per antenna configuration; computational complexity; and the requirement for explicit device feedback.
[054] FIG. 1 shows a block diagram of an example system that includes the Universal Spectrum Multiplier xApp and the RAN Intelligent Controller (RIC) as shown on the upper left of FIG. 1 . An exploded view in the upper right of FIG. 1 shows that the USM xApp software runs in the service and management orchestration (SMO) stack with a precoding function attached to the RAN distributed unit (DU). The lower portion of FIG. 1 is the benefit: multiple users sharing the spectrum. The result is improved spectral efficiency and network latency that helps Mobile Network Operators (MNOs) deliver a better user experience and ease capacity bottlenecks when demand is high.
[055] The Universal Spectrum Multiplier xApp works in the network and requires no changes to handsets. The software offers significant MU-MIMO benefits, and can work with existing base stations. Moreover, it allows simultaneous 4G and 5G co-existence without the performance issues of DSS via a vendor neutral approach to dynamic spectrum reuse. The disclosed embodiments can be configured to work for waveforms in any spectrum as well as operating in either Frequency Division Duplexing (FDD) or Time Division Duplexing (TDD) networks. This enables them to improve the strength and efficiency of any generation (“any G”) mobile network. [056] Although specific examples of O-RAN framework are used, it will be appreciated by one of skill in the art that the disclosed techniques may be implemented in other wireless networks that implement different interfacing protocols.
[057] 2. Overview of O-RAN Architecture and E2 Interface
[058] FIG. 2 shows an example block diagram of the logical architecture for an Open Radio Access Network (O-RAN). As shown therein, the O-RAN logical architecture includes:
[059] - Near-Real Time RIC: O-RAN near-real-time RAN Intelligent Controller: a logical function that enables near-real-time control and optimization of O-RAN elements and resources via finegrained data collection and actions over E2 interface.
[060] - Non-Real Time RIC: O-RAN non-real-time RAN Intelligent Controller: a logical function that enables non-real-time control and optimization of RAN elements and resources, AI/ML workflow including model training and updates, and policy-based guidance of applications/features in near-RT RIC.
[061] - O-CU-CP: O-RAN Central Unit-Control Plane: a logical node hosting the RRC and the control plane part of the PDCP protocol
[062] - O-CU-UP: O-RAN Central Unit-User Plane: a logical node hosting the user plane part of the PDCP protocol and the SDAP protocol
[063] - O-DU: O-RAN Distributed Unit: a logical node hosting RLC/MAC/High-PHY layers based on a lower layer functional split.
[064] - O-RU: O-RAN Radio Unit: a logical node hosting Low-PHY layer and RF processing based on a lower layer functional split.
[065] - O-eNB: O-RAN evolved NodeB: hardware associated with the RAN
[066] - O-Cloud: O-RAN cloud: a cloud computing platform comprised of a collection of physical infrastructure nodes that meet O-RAN requirements to host the relevant O-RAN functions, the supporting software components, and the appropriate management and orchestration functions.
[067] These components are further detailed in 3GPP TR 21 .905 (up to and including version 18.0.0) and other related documents.
[068] In the O-RAN framework described in FIG. 2, three different types of control loops may be specified for operations according to the control timing of the loop decision process.
[069] 1) the Non-RT RIC loop operates at over 1 second.
[070] 2) the Near-RT RIC loop operates between 10 milliseconds and 1 second.
[071] 3) the O-DU loop, which is responsible for real-time processing of radio scheduling information, HARQ, beamforming, etc., has to always operate below 10 milliseconds due to its real-time nature.
[072] It is noted that all of these loops run in parallel to each other and, depending on the use case, may or may not have any interaction between them. [073] The internal architecture of the Near-RT RIC is shown in FIG. 3. As shown therein, the Near-RT RIC supports an xApp, which is an application provided by any third party, is designed to run on the Near- RT RIC, and it allow services to be executed at the Near-RT RIC and the outcomes sent to the E2 Nodes via E2 interface. In some examples, an xApp is likely to consist of one or more microservices. At the point of on-boarding, microservices will identify which data it consumes and which data it provides. Herein, the E2 interface enables a direct association between the xApp and the RAN functionality.
[074] The E2 interface supports the following functions:
[075] - Allows southbound nodes to set up the E2 interface and register the list of applications the southbound nodes support.
[076] - Allows xApps running in the near-RT RIC to subscribe for events from the southbound nodes such as prescribe an action to execute upon encountering an event where the action can be to report the event, report, and wait for further control instructions from the xApp, or execute a policy.
[077] - Provides control instructions.
[078] In the O-RAN architecture, and as seen in FIGS. 2 and 3, each of the disaggregated network function O-CU-CP, O-CU-UP and O-DU are called the E2 nodes. E2 nodes support E2 interface towards near RT-RIC and O1 interface towards non-RT RIC. Further, an application protocol called E2AP is specified by O-RAN Alliance over SCTP/IP as the transport protocol. On top of E2AP, application-specific controls and events are conveyed through E2 service models (E2SM). The xApps in the Near-RT RIC use the E2SMs.
[079] In some embodiments, the following service models (E2SMs) are supported over the E2 interface:
[080] - REPORT: Near-RT RIC uses a RIC Subscription and/or RIC Subscription Modification procedures to request that E2 Node sends a REPORT message to Near-RT RIC and the associated procedure continues in the E2 Node after each occurrence of a defined RIC Subscription procedure Event Trigger. FIG. 4 shows a flow diagram of an example RIC REPORT service.
[081] - INSERT: Near-RT RIC uses a RIC Subscription and/or RIC Subscription Modification procedures to request that E2 Node sends an INSERT message to Near-RT RIC and suspends the associated procedure in the E2 Node after each occurrence of a defined RIC Subscription procedure Event Trigger. FIGS. 5A and 5B show a flow diagram of an example RIC INSERT service.
[082] - CONTROL: Near-RT RIC sends a CONTROL message to E2 Node to initiate a new associated procedure or resume a previously suspended associated procedure in the E2 Node. FIGS. 6A and 6B show a flow diagram of an example RIC CONTROL service.
[083] - POLICY: Near-RT RIC uses a RIC Subscription and/or RIC Subscription Modification procedures to request that E2 Node executes a specific POLICY during functioning of the E2 Node after each occurrence of a defined RIC Subscription procedure Event Trigger. [084] - QUERY: Near-RT RIC sends a QUERY message to the E2 node to retrieve RAN- related and/or UE-related information from the E2 Node. FIG. 7 shows a flow diagram of an example RIC QUERY service.
[085] In some embodiments, the E2 application protocol (E2AP) supports the following functional procedures to enable using the RIC services.
[086] - RIC Subscription procedure is Near-RT RIC initiated, and used to install Event Trigger and associated sequence of Actions corresponding to one or more REPORT, INSERT and/or POLICY [087] - RIC Subscription Modification procedure is Near-RT RIC initiated, and used to modify
Event Trigger and/or add, modify and/or remove Actions corresponding to REPORT, INSERT and/or POLICY
[088] - RIC Subscription Modification Required procedure is E2 Node initiated, and used to request modification and/or removal of Actions corresponding to REPORT, INSERT and/or POLICY [089] - RIC Subscription Delete procedure is Near-RT RIC initiated, and used to delete previously installed RIC Subscription
[090] - RIC Subscription Delete Required procedure is E2 Node initiated, and used to indicate that one or more previously installed RIC Subscriptions are required to be deleted
[091] - RIC Indication procedure is E2 Node initiated, and used to carry outcome of RIC services REPORT and INSERT
[092] - RIC Control procedure is Near-RT RIC initiated, and used to initiate RIC service
CONTROL
[093] - RIC Query procedure is Near-RT RIC initiated, and used to request RAN and/or UE related information from E2 Node
[094] In some embodiments, the following E2 service models are supported, using either ASN.1 or JSON, with the described scope.
[095] - E2SM-NI is the “Network Interface” RAN Function, which performs the following functionalities: (1) exposure of Network Interfaces, (2) modification of both incoming and outgoing network interface message contents, and (3) execution of policies that may result in change of network behavior
[096] - E2SM-KPM_version1 is the “KPM Monitor” RAN Function, which performs the following functionalities: (1) exposure of O-DU’s cell related performance lEs through periodic KPM Report, (2) exposure of O-CU-CP’s cell/UE related performance lEs through periodic KPM Report, and (3) exposure of O-CU-UP’s bearer related performance lEs through periodic KPM Report.
[097] - E2SM-KPM_version2 is the “KPM Monitor” RAN Function, which performs the following functionalities: (1) exposure of available measurements from O-DU, O-CU-CP, and/or O-CU-UP via the RAN Function Definition IE, and (2) periodic reporting of measurements subscribed from Near-RT RIC. [098] - E2SM-RC is the “RAN Control” RAN Function, which performs the following functionalities: (1) exposure of RAN control and UE context related information, (2) modification and initiation of RAN control related call processes and messages, and (3) execution of policies that may result in change of RAN control behavior.
[099] - E2SM-CCC is the “Cell Configuration and Control” RAN Function, which performs the following functionalities: (1) exposure of node level and cell level configuration information, and (2) initiate control and/or configuration of node level and cell level parameters.
[0100] In some embodiments, the following performance requirements are implemented by the E2 interface. These requirements, and the corresponding messages and example formats, have been described and enumerated next. It is noted that bolded text represents new parameters in existing E2SM services or new E2SM implementations.
[0101] - Cell configuration
• Cell configuration (-hours) [requirements]
• Served Cell Information (cell ID, freq, band, FDD/TDD, BW, etc.)
• MIB
• SSB Periodicity of Serving Cell
• Cell Configuration [proposed solutions]
• RIC QUERY Service Style 1 : E2 Node Information Query (for initial state)
• RAN Parameters for QUERY Service Style 1 are listed in Clause
8.6.1
• Served Cell Information (RAN Parameter ID=1)
• Add 2 new IDs to cover MIB IE and ssb- periodicityServingCell IE (TR 38.331)
• REPORT Service Style 3: E2 Node Information (for changes)
• Triggering (E2 Node Information Change ID)
• E2 Node Information Changes are listed in Clause 7.3.4
• Cell Configuration Change (ID=1)
• Add 2 new IDs to cover MIB Change and SSB Periodicity Change
• Reporting (RAN Parameter ID)
• RAN Parameters for REPORT Service Style 3 are listed in Clause 8.3.2
• Cell Context Information (ID=1 )
• Add 2 new IDs to cover MIB and SSB Periodicity
[0102] - UE information UE Information (~Nx100ms) [requirement]
• List of connected UEs
• Notification when
• New UEs connect
• Handed over
• Move to a different O-DU
• Connection release
• UEs change state
• BWP configuration (SCS, CP, DMRS config., MCS table, time resource allocations, PRB bundling, VRB to PRB)
Connected UEs per Cell [proposed solutions]
• RIC QUERY Service Style 2: UE Information Query (for initial state)
• RAN Parameters for QUERY Service Style 2 are listed in Clause
8.6.2
• Cell Global ID (ID=1)
• REPORT Service Style 4: UE Information (for changes)
• Triggering (UE Information Change ID)
• UE Identifier Changes are listed in Clause 7.3.5
• New UE Connected (ID=1)
• UE Handed Over (from another E2 Node) (ID=2)
• UE Context Information changes are listed in Clause
8.1.1.17 referencing 8.1 .1.1
• UE Handed over from another cell (RAN Parameter ID = 10001 - NR CGI)
• Reporting (RAN Parameter ID)
• RAN Parameters for REPORT Service Style 4 are listed in Clause 8.2.4
• Old UE ID (RAN Parameter ID = 300)
• Current UE ID (RAN Parameter ID = 301)
• Cell Global ID (RAN Parameter ID = 400) Connection Release
• REPORT Service Style 4: UE Information
• Triggering (UE Information Change ID)
• UE Identifier Changes are listed in Clause 7.3.5
• UE ID Removed (ID=4)
• Reporting (RAN Parameter ID) • RAN Parameters for REPORT Service Style 4 are listed in Clause 8.2.4
• Old UE ID (RAN Parameter ID = 300)
• RRC State Change
• REPORT Service Style 4: UE Information
• Triggering (RRC State changed to)
• RRC State Changes are defined in Clause 9.3.37
• ENUMERATED (RRC_Connected, RRCJnactive, RRCJdle, Any, ...) - We can select ‘Any’
• Reporting (RAN Parameter ID)
• RAN Parameters for REPORT Service Style 4 are listed in Clause 8.2.4
• Current RRC State (RAN Parameter ID - 201)
• RRC State Changed To (RAN Parameter ID = 202)
• BWP Configuration
• RIC QUERY Service Style 2: UE Information Query (for initial state)
• RAN Parameters for QUERY Service Style 2 are listed in Clause 8.6.2 (also referencing 8.1.1.17)
• Add a new ID to cover BWP-Downlink IE (TR 38.331) and potentially the full list of elements in that IE; or alternatively report downlinkBWP-ToAddModList
• REPORT Service Style 4: UE Information (for changes)
• Triggering (UE Information Change ID)
• UE Context Information changes are listed in Clause 8.1.1 .17
• Use the newly added BWP-Downlink IE or sub-parameters if we add the complete list
• Reporting (RAN Parameter ID)
• RAN Parameters for REPORT Service Style 4 are listed in Clause 8.2.4 (also referencing 8.1.1.17)
• Use the newly added BWP-Downlink IE or sub-parameters if we add the complete list
[0103] - Configuration for channel estimation
• Reporting and controlling the following (~Nx100ms) [requirements]
• CSI Measurement Configuration (CSI -MeasConfig IE)
• Includes CSI resource configuration (NZP CSI-RS and CSI-IM) and CSI report configuration • SRS Configuration
• Collecting CSI Measurement Configuration [proposed solutions]
• RIC QUERY Service Style 2: UE Information Query (for initial state)
• RAN Parameters for QUERY Service Style 2 are listed in Clause 8.6.2 (also referencing 8.1.1.17)
• Add a new ID to cover CSI-MeasConfig IE (TR 38.331)
• REPORT Service Style 4: UE Information (for changes)
• Triggering (UE Information Change ID)
• UE Context Information changes are listed in Clause 8.1.1.17
• Use the newly added CSI-MeasConfig IE
• Reporting (RAN Parameter ID)
• RAN Parameters for REPORT Service Style 4 are listed in Clause 8.2.4 (also referencing 8.1 .1.17)
• Use the newly added CSI-MeasConfig IE
• Configuring CSI Resources
• CONTROL Service Style 2: Radio Resource Allocation Control
• Control Actions are listed in Clause 7.6.3.1
• Add a new Control Action ID to cover CSI Resource Configuration referencing 8.4.3.x for Associated RAN parameters
• Control Parameters will be listed in a new Clause 8.4.3.x
• Add csi-ResourceConfigToAddModList IE and csi- ResourceConfigToReleaseList IE (TR 38.331) with all their parameters
• Configuring CSI Report
• CONTROL Service Style 2: Radio Resource Allocation Control
• Control Actions are listed in Clause 7.6.3.1
• Proposing to use Control Action ID 5 and change its name from CQI table to CSI Report
• Control Parameters are listed in Clause 8.4.3.5
• Proposing to change the name of RAN Parameter ID 1 to List of CSI Report Configurations to Add or Modify and add the missing parameters of CSI-ReportConfig IE (TR 38.331)
• Proposing to add List of CSI Report Configurations to remove parameter with its lEs Collecting SRS Configuration
• RIC QUERY Service Style 2: UE Information Query (for initial state)
• RAN Parameters for QUERY Service Style 2 are listed in Clause 8.6.2 (also referencing 8.1.1.17)
• SRS Configuration (ID=21541 )
• REPORT Service Style 4: UE Information (for changes)
• Triggering (UE Information Change ID)
• UE Context Information changes are listed in Clause 8.1.1.17
• SRS Configuration (ID=21541)
• Reporting (RAN Parameter ID)
• RAN Parameters for REPORT Service Style 4 are listed in Clause 8.2.4
• SRS Configuration (ID=21541) Configuring SRS
• CONTROL Service Style 2: Radio Resource Allocation Control
• Control Actions are listed in Clause 7.6.3.1
• Add a new Control Action ID to cover SRS Configuration referencing 8.4.3.x for Associated RAN parameters
• Control Parameters will be listed in a new Clause 8.4.3.x
• Add srs-ResourceToAddModList IE and srs-
ResourceToReleaseList IE (TR 38.331) with all their parameters
[0104] - Downlink control information 1_0
Used as a ‘Fallback’ DCI format for low coverage cases [requirements]
• For single layer transmissions of PDSCH
• Smaller payload with more robust coding Parameters of interest:
• Freq Domain Resources
• Allocates a set of VRBs and always uses Resource Allocation Type I (RIV)
• Time Domain Resources
• A pointer to a row in look-up table (3GPP predefined or RRC configured)
• Slot offset, PDSCH mapping type, starting symbol, number of allocated symbols • VRB to PRB Mapping
• 1 bit indicating interleaved or non-interleaved VRB to PRB mapping of PDSCH
• MCS
• A pointer to a row in one of the three 3GPP defined MCS tables
• Redundancy Value
• Indicates the puncturing pattern at the output of the LDPC coder
[0105] - Downlink control information 1_1
• Used to provide resource allocation for PDSCH [requirements]
• Parameters of interest:
• Freq Domain Resources
• Allocates a set of VRBs and supports Resource Allocations Type 0 (bit-map), and Type 1 (RIV), and dynamically switching between them (using an additional bit in this field)
• Time Domain Resources
• A pointer to a row in look-up table (3GPP predefined or RRC configured)
• Slot offset, PDSCH mapping type, starting symbol, number of allocated symbols
• VRB to PRB Mapping
• 1 bit indicating interleaved or non-interleaved VRB to PRB mapping of PDSCH
• PRB Bundling Size Indicator
• Used when dynamic PRB bundling is configured (in PDSCH-Config) for PRG
• MCS (TB1 and TB2)
• A pointer to a row in one of the three 3GPP defined MCS tables
• Redundancy Value (TB1 and TB2)
• Indicates the puncturing pattern at the output of the LDPC coder
• Antenna Ports
• A pointer to a row in one of the 4 3GPP defined look-up tables identifying the DMRS resources
[0106] - Configuration for scheduling
• PDSCH Configuration (PDSCH-Config IE) - reporting and configuring (~Nx100ms) [requirements]
• Identifying Resource Allocation Type • VRB to PRB Interleaving
• PRB bundling type and size
• DMRS Downlink configuration
• MCS table selection
• PDSCH time domain allocation
• Measurement Gap Configuration - Reporting (~Nx100ms)
• Active DRBs - reporting (~Nx100ms)
• DRB ID, Priority level, RLC mode , LCID
• Collecting PDSCH Configuration [proposed solutions]
• Covered by the BWP Configuration QUERY and REPORT
• Configuring PDSCH
• CONTROL Service Style 2: Radio Resource Allocation Control
• Control Actions are listed in Clause 7.6.3.1
• Add a new Control Action ID to cover PDSCH Configuration referencing 8.4.3.x for Associated RAN parameters
• Control Parameters will be listed in a new Clause 8.4.3.x
• Add BWP - Id IE, and PDSCH - Config IE (TR 38.331) with all the relevant parameters:
• DMRS Type A and B configurations, VRB to PRB interleaver, Resource allocation type, PDSCH time domain allocation list and aggregation factor, MCS table, max No of codewords scheduled by DCI, PRB bundling type (static/dynamic)
• Collecting Measurement GAP Configuration
• RIC QUERY Service Style 2: UE Information Query (for initial state)
• RAN Parameters for QUERY Service Style 2 are listed in Clause 8.6.2 (also referencing 8.1.1.17)
• Add a new ID to cover MeasGapConfig IE (TR 38.331)
• REPORT Service Style 4: UE Information (for changes)
• Triggering (UE Information Change ID)
• UE Context Information changes are listed in Clause 8.1 .1 .17
• Use the newly added MeasGapConfig IE
• Reporting (RAN Parameter ID)
• RAN Parameters for REPORT Service Style 4 are listed in Clause 8.2.4 (also referencing 8.1.1.17)
• Use the newly added MeasGapConfig IE
• Collecting Active DRB Configuration
• RIC QUERY Service Style 2: UE Information Query (for initial state) • RAN Parameters for QUERY Service Style 2 are listed in Clause
8.6.2 (also referencing 8.1.1.17)
• List of DRBs (ID= 21524) under List of PDU Sessions (ID=21521) cover the following parameters:
• DRB ID (ID=21546)
• Priority Level of mapped QoS flows (ID=14008)
• RLC Mode (14302)
• Add a new ID to cover LogicalChannelldentity IE (TR 38.331)
• REPORT Service Style 2: Call Process (for changes)
• Triggering (Call Process Breakpoint)
• Call Process Types and Call Process Breakpoints are listed in Clause 7.3.3
• Call Process Type: Bearer Context Management (ID=2)
• Call Breakpoint Name: Bearer Context Setup (ID=1), Bearer Context Modification (ID=2), Bearer Context Release (ID=3)
• Reporting (RAN Parameter ID)
• RAN Parameters for REPORT Service Style 2 are listed in Clauses 8.2.2 (also referencing 8.1.1.17)
• List of PDU Sessions (I D=21521), and we can filter down to the list in the QUERY
• Includes the newly added LogicalChannelldentity IE
[0107] - Information used for scheduling
• UL Channel Quality [requirements]
• Raw SRS (~Nx1 ms)
• ACK/NACK counts* (~Nx10ms)
• DL Channel Quality
• CSI Reports - RI/PMI**/CQI (~Nx10ms)
• ACK/NACK/HARQ - DTX counts - per codeword, SFN (~Nx10ms)
• PDCP Buffer Status (~Nx1 ms)
• Per DRB (DRB ID) per UE
• RLC Buffer Occupancy (~Nx1 ms)
• Per Logical Channel (LCID) per UE • Timestamps (~Nx100ms)
• SFN, Slot Indication, Measured Time
• Support for subband PMI
• Raw SRS - use REPORT triggered on received SRS symbols [proposed solutions]
• List of SRS reports
• Time Stamp
• Sequence of SRSs
• UE ID
• SRS Resource ID
• Sequence of SRS Symbols
• Sequence of Receive Antennas
• Raw SRS vector
• RI/PMI/CQI - use REPORT triggered on received CSI Report
• List of CSI reports
• Time Stamp
• UE ID
• Rl
• CHOICE pmi-Formatlndicator
• widebandPMI
• PMI-i1
• PMI-I2
• SubbandPMI
• CHOICE cqi-Formatlndicator
• widebandCQI
• Wideband CQI TB1
• Wideband CQI TB2
• SubbandCQI
• Wideband CQI TB1
• Wideband CQI TB2
• Subband CQI List TB1
• Subband Differential CQI
• Subband CQI List TB2
• Subband Differential CQI
• UL ACK/NACK counts - use REPORT triggered on time period
Time Stamp
List of Channel Quality reports UE ID
Sequence of Codeword (1..2)
• Number of UL ACKs
• Number of UL NACKs
• DL ACK/NACK/HARQ-DTX counts - use REPORT triggered on time period
• Time Stamp
• List of Channel Quality reports
• UE ID
• Sequence of Codeword (1 ..2)
• Number of DL ACKs
• Number of DL NACKs
• Number of HARQ-DTX
• PDCP Buffer Occupancy (Data volume per section 5.6 of 38.323) - use REPORT triggered on time period
• List of PDCP Buffer Status reports
• UE ID
• Sequence of DRBs
• DRB ID
• DL PDCP Buffer Status
• RLC Buffer Occupancy (BO per section 8.2.2(c) of 25.321) - use REPORT triggered on time period
• List of RLC Buffer Status reports
• UE ID
• Sequence of Logical Channels
• LCID
• DL RLC Buffer Status
• Time Stamps (38.473 clause 9.3.1.171) - use REPORT triggered on time period
• Sequence of Cells
• Cell ID
• SFN
• Slot index (selected per CHOICE of SCS)
• Measurement Time
[0108] - Parameters used for controlling the scheduler (~Nx1 ms)
• Cell ID [requirements]
• Per Slot • Slot number
• BWP ID
• UE ID
• Per logical channel
• LCID
• # of bytes (optionally, per TB)
• Time/Freq. resources
• VRB to PRB Mapping (interleaved or not)
• PRB Bundling Size Indicator (only when bundling is configured as dynamic)
• Pointer to a row in the selected MCS table
• Redundancy Version (only when aggregation factor is configured)
• Antenna ports (in DCI 1_1)
• Precoder coefficients; per layer, per spatially multiplexed group (SMG), per Antenna
• TCI - indicates QCL of PDSCH with other signals (e.g. SS/PBCH/CSI)
Scheduling - use CONTROL
• Cell ID
• Sequence of Slots
• SFN
• Slot Index
• Sequence of Grants
• BWP ID, UE ID, Layer ID
• Sequence of Logical Channels
• LCID
• # of bytes
• DCI 1_0 or DCI 1_1 content
• Sequence of PDSCH SMGs
• Precoder ID
• Start RB
• # of RBs
• Start symbol
• # of symbols
• Sequence of PDCCH SMGs
• Precoder ID
• Start RB # of RBs
• Start symbol
• # of symbols
• Sequence of Precoders
• Sequence of Layers
• Sequence of Antennas
• Vertical Coefficients
• Horizontal Coefficients
[0109] The described embodiments advantageously provide control of a scheduler based on the collection of scheduling related information. In some implementations, the following functionalities are defined:
[0110] - E2 REPORT services used to expose traffic and layers 1 and 2 (MAC/PHY) UE related information that includes (1) E2 Node generated or UE reported PHY/MAC information, used for estimating the channel, and (2) Traffic status, used for triggering E2 Control
[0U1] - E2 CONTROL services used to modify RAN scheduling process that include
Scheduling Control, used to control scheduling parameters of PDSCH transmission
[0112] Subsequently, the E2SM-RC can also be enhanced by adding the above-described functionalities to the E2SM-RC REPORT and CONTROL services. In some instances, the development and implementation of the E2SM-RC enhancements can be further constrained based on the following design considerations:
• xApp will not control retransmissions
• Near-RT RIC loop latency may be too high
• Operate instead at 1 E-3 to avoid retransmissions
• Evaluate performance with interference vs. retransmissions
• Require special treatment at lowest MCS
• Proactive retransmissions
• Let DU scheduler retransmit when needed
• Occasionally will override xApp scheduler
• xApp cannot be involved in TA
• Zero Power CSI-RS (e.g., for SNR estimation) can optionally be used
• Autocalibration control over the E2 interface can be used
• The scheduling information can be sent without separating DCI 1_0 and 1_1 and let the DU decide which DCI to use Optionally control the PDSCH -ServingCellConfig IE
• It includes cell-wide PDSCH configuration (e.g. max MIMO Layers)
• Some reports should include SFN/Time stamp
• E2SM-CCC can be used for collecting cell configuration parameters
[0113] 3. Example Embodiments for USM and gNB Interactions
[0114] As discussed in the previous sections, embodiments of the disclosed technology (e.g., USM xApp) enable cloud-based applications to access cellular network services. In some examples, this is achieved by the USM xApp in the Near-RT RIC communicating with the other E2 nodes via the E2 interface. This communication between the USM (e.g., in an xApp) and the cellular network (e.g., a gNodeB) is further detailed in the context of FIG. 8, which shows the USM using a general Remote Process Call (gRPC, which is a cross-platform open source high performance remote procedure call (RPC) framework) channel (or interface) to communicate with the gNB (that includes the CU and DU functionalities).
[0115] FIG. 9 shows a flow diagram for an example initialization procedure between the USM and gNB shown in FIG. 8. As shown therein, the gNB starts up by establishing gRPC links, which is followed by the USM starting up, establishing gRPC links, and requesting node config information (e.g., MIB and serving cell information). The gNB shares this node configuration information, and the USM subscribes for required UE context information, which includes one of more of the following: [0116] - UE Capability Report
[0117] - DL BWP Config Report
[0118] - CSI Meas Config Report
[0119] - PDSCH Serving Cell Config Report
[0120] - Measurement Gap Config Report
[0121] - Served Radio Bearer Configuration Report for existing UE DRB flows in gNB
[0122] - HARQ feedback
[0123] - DL Channel info
[0124] - UL Channel Est
[0125] Having subscribed to the gNB, the USM now requests ConnectedJJEJJst, which is shared by the gNB, and then requests UE context information for all connected UEs. The USM will then exchange Served Bearer Scheduling Control message for all connected UEs and their relevant flows, with the gNB to take over applicable existing UE DRB flows scheduling. The USM initialization message is sent to the gNB, and the gNB start periodically sending slot indication information to the USM (e.g., with a period of ~10 msec). [0126] FIG. 10 shows a flow diagram for the attachment of a user equipment (UE) to the gNB in the context of leveraging the USM. As shown therein, the UE attachment commences only after the initialization (e.g., as described in FIG. 9) has been completed. For the UE attachment, the gNB handles the initial attach procedure including allocation of the Radio Network Temporary Identifier (RNTI), and is configured to use SRB and dedicated PDSCH for the initial attachment procedure. Then, the gNB will send RRC Connection Setup message to USM, which will map gNB allocated RNTI and update the UE database. The USM will receive UE context information via indication messages for connected UEs. Once one or more initial DRBs get established, gNB will hand over the UE to USM as per Served Bearer Scheduling Control message. Finally, USM will map one or more DRB flows with [RNTI, DRBJD] and update the flow database.
[0127] In some embodiments, periodic data collection can be implemented for the various scenarios (and configurable periodicities) enumerated below.
Figure imgf000024_0001
[0128] In other embodiments, aperiodic data collection can be implemented for the various scenarios (and specified triggers) enumerated below.
Figure imgf000024_0002
Figure imgf000025_0001
[0129] In these embodiments, the following scheduler and control-related messages are defined:
Figure imgf000025_0002
[0130] Similarly, the following configurations can be defined:
Figure imgf000025_0003
[0131] FIGS. 1 1A and 11 B show a flow diagram for the end-to-end flow between the USM and multiple UEs via various components and modules of the gNB. As shown in FIG. 11 A, upon completion of the initialization and the UEs (denoted UE_1 and UE_N) connecting, the UEs periodically transmit the SRS and CSI Report to the PHY layer of the gNB. The PHY layer forwards this information, as well as a channel estimate, to the L1/L2 receiver of the gNB, which then transmits this to the USM. Alternatively, or additionally, HARQ feedback can be aggregated by the UEs and send to the USM in a similar manner. [0132] In FIG. 11 B, the USM then determines whether a bandwidth grant (e.g., slots that can be used by the UE) can be allocated to a particular UE, and sends that information (e.g., a UE list) to the gNB UE selection module (denoted gNB_UE_Selection). The UE selection module adds the UE list received from the USM to the existing list prepared by the DU’s scheduler. Typically, the gNB follows the suggested allocation for the USM’s grants, and provides the necessary information (e.g., precoder coefficients, grant information, etc.) to the PHY layer of the gNB, which them transmits this information to the respective UE. [0133] The block diagram of FIG. 8, which shows a high-level perspective of communication between the USM and the gNB is further detailed in the block diagram shown in FIG. 12. As shown therein, the PDCP (packet data convergence protocol) layer of the centralized unit (CU) communicates flow data packets and information about quality-of-service (QoS) flows established in the wireless network to the radio link control (RLC) layer of each of one or more distributed units (DUs). The DU can provide this information to a local scheduler operating in the DU. This local scheduler (denoted "DU Scheduler") may track bandwidth assignments to time-sensitive (or time-critical) tasks such as hybrid automatic repeat request (HARQ), random access response (RAR), and ultra-reliable low latency communication (URLLC) transmissions. The DU also includes a resource allocation function that receives inputs from the local scheduler and also from RLC, and operates to allocate transmission resources e.g., physical resource blocks (PRBs) or transport blocks (TBs), to outbound transmissions to be sent out by a transmitter circuitry Tx.
[0134] FIG. 12 also shows the DU being in communication with the USM scheduler (e.g., the USM xApp) over an interface that implements a predefined message protocol. This interface may be an E2SM interface or a gRPC (Remote Procedure Call) interface. On the interface, the message protocol may support transmission of flow reports from the DU to the USM scheduler. The flow report information may include information about which UEs at a current time are in need of flow data (transmission or reception) quality indicators associated with the flows and status (e.g., fullness) of queues for the flows.
[0135] In some embodiments, the predefined message protocol defines a scheduling control message that is transmitted by the USM scheduler and received by the DU. This message can include information about flow indexes, PRBs assigned to the flow indexes, modulation and coding scheme (MCS) assigned thereto, layer number, a size of transport block (TBS), precoding filter coefficients, etc. This information may be applicable to next N slots, where N is an integer that may either be explicitly indicated in the scheduling control message or may be implicit based on a predefined understanding between the DU and the USM scheduler. The message protocol also defines a scheduling response message that is transmitted by the DU and received by the USM scheduler. The response message may include, for each indicated flow index, an actual TBS used by the DU. In some embodiments, the scheduling response message may provide an outcome that includes a list of fully executed grants and for the remaining grants, a number of bytes per LCID that were scheduled, and the like.
[0136] Said another way, eNodeB (eNB) / gNB / O-DU sends uplink channel estimates and downlink channel quality measurements to the RIC, which the mUMO xApp uses to predict the downlink channel and quality. The eNB also sends information to the mUMO xApp that conveys downlink traffic activity and priority. The received channel quality measurements are used to predict channel quality estimates and channel attributes which are provided to the USM Scheduler. The USM Scheduler utilizes this information to create groupings of UEs that can be scheduled together to provide improved spectral reuse. Precoder coefficients are computed based on the USM Scheduler and provided over the E2 Interface for use in the DU. The DU scheduler then uses that information to generate the specific scheduling control messages (DCIs). If high-priority low-latency packets need to be transmitted, the DU scheduler may replace part of the resources scheduled by the control message with the higher priority packets.
[0137] Timina requirements. The mUMO xApp and the eNodeB/gNB are a near-real-time system. The mUMO is providing scheduling parameters, and spatial multiplex group coefficients to the eNB/gNB, which must be used on particular LTE/5GNR Transmission Time Intervals (TTIs). The messages must arrive on time, with some processing-time margin, for the eNB/gNB to use them. The eNB/gNB will typically have a mechanism to fall back to normal operation if they do not arrive, but if this happens frequently, the system will not meet its performance goals. Therefore, the mllMO xApp must start at a particular time t-X (relative to the eNB/gNB time), with sufficient process/thread priority to guarantee computation completion, and transmit over the network, for the messages to arrive at the eNB/gNB at time t.
[0138] Time synchronization requirement. To meet this requirement, there must be time-synchronization between the Near-RT RIC (including xApp) and the eNB/gNB. PTP is a logical choice, since the eNB will already be sync’d using PTP. The ~50ns time accuracy that PTP can provide is not required. Accuracy to +/- 10Ous should be sufficient to schedule and meet the 1 ms TTI time boundary. Another choice applicable for O-RAN is to use the UTC time (already used in O-RAN) to time-stamp slots and received messages.
[0139] Timing measurement. It is assumed that the network delay is symmetric (which is also an assumption of the PTP protocol), but since the latencies between the xApp and the E2 Node may include different processing modules, the latencies may be different. For that reason, the DL delay measurement will also be supported. The main mechanism for the timing measurement will be the timestamped slot reports in the UL, and timestamping the received control messages in the DL which will be reported back to the xApp. In this mechanism, the xApp will request and receive timestamped slots reports (see 4.2.1 1 and 4.2.12). Based on this, the xApp can adjust its clock to match the O-DU clock. When the xApp sends a control message to the O-DU with the request for control Acknowledgement (e.g. when sending the Served Bearer Scheduling Configuration Control, see 4.2.16) the O-DU will send the Control Outcome with the timestamp of the received control message. This will provide the DL E2 interface latency, and with the reported processing time margin as part of the control outcome in response to the UE scheduling control message (see 4.2.13) the mUMO xApp will be able to adjust the timing of the UE scheduling control messages to arrive just in time. This per-message timing measurements may be fed to a software averag ing/filtering algorithm, which will most likely be a software phase-locked loop (PLL).
[0140] FIGS. 13-17 show an example scenario of how bandwidth scheduling may be managed between a Distributed Unit (DU) and the USM scheduler. As shown in FIG. 13, the DU maintains various flows that may each have a different fullness (indicated along vertical axis) for each flow index (numbering along horizontal axis). Some of these flows may be time-sensitive (denoted using a striped pattern), while others may not be time-sensitive (or may be less time-sensitive, and are denoted using a solid pattern). In some embodiments, flow reports carrying the above information are communicated from the DU to the USM scheduler. In various embodiments, time-sensitive and/or non-time-sensitive flow information may be reported to the USM xApp. The USM scheduler can be configured to receive a snapshot of channel characteristics forthe UEs based on a reception of a reference signal, e.g., a sounding reference signal (SRS). The channel characteristics and a database of UE and flow information may then be used to schedule non-time-critical flows. [0141] FIG. 14 provides further details of the scheduling for MU-MIMO case. Here, based on the information from the database, the USM scheduler can decide how to perform spatial multiplexing (or how to form groups of UEs that can be scheduled using the same time/frequency resources). A conceptual table is depicted on the left-hand side of FIG. 14, in which spatial multiplexing of the various flows is performed, where a check-mark in a cell in the table indicates that the corresponding flow buffer is to be multiplexed between row entry and column entry. Therefore, flows that have a check mark in the cell covered by the flows can be scheduled with other flows having a check box (e.g., spatially multiplexed) by forming spatial beams that can be simultaneously used between UEs and the base station (e.g., the gNB), without one beam interfering with another beam.
[0142] This information determined by the USM scheduler is used to generate a message that transmitted from USM scheduler to the DU as a proposed schedule, as shown in FIG. 15. In the proposed schedule (in the top right of FIG. 15), some “empty” PRBs may be available (depicted as white) for the DU. The DU may be able to schedule time-sensitive traffic using the empty (or previously scheduled by the USM scheduler) PRBs, for example, by performing layered communication when overlapping PRBs are available (unallocated) in multiple layers. The message may include flow priorities, channel estimation information, and scheduling recommendations forthe DU’s consideration.
[0143] FIG. 16 shows that DU may overwrite the proposed schedule with a final schedule in which the time-critical traffic was scheduled in a time symbol by pre-empting previously scheduled transmissions. Here, to meet time budget of a time-sensitive flow, the DU decided not to use the blank PRBs (e.g., because both layers are not available), but instead overwrote the previously scheduled transmissions (including a portion of the transmission in the second slot in order to achieve spatial multiplexing). For example, the DU may not have sufficient information to perform spatial multiplexing of time-sensitive flows or UEs to or from which the communication is performed cannot be multiplexed because of their different channel characteristics.
[0144] FIG. 17 shows that the final schedule and transmission report is communicated in a scheduler response from the DU to the USM scheduler, which allows the scheduler to get an updated picture of buffer fullness of different flows.
[0145] The example shown in FIG. 13-17 illustrates that the USM sends the DU scheduling controls with precoding coefficients, which significantly improves the spectral efficiency for most (non-time-sensitive) data flows. Guaranteed bit rate (GBR) data flows with small packets and small latency (such as VoNR) will be scheduled using semi-persistent scheduling, coordinated between the USM scheduler and the DU. Furthermore, the DU may add/adjust for other time-critical scheduling.
[0146] 4. Example Embodiments for the E2 Interface
[0147] In some embodiments, the existing E2SM-RC specification is expanded to support all the configurations related reports and controls described in this patent document. For the MAC and PHY parameters collected either by the O-DU receiving control messages from the UEs or counting received ACK/NACK type information from the UEs, these can be covered in a new E2SM spec (e.g., E2SM-Lower Layers Control (LLC)), but can also be added in a similar manner to the existing E2SM-RC.
[0148] For all the configuration report messages, either the complete IE defined in 3GPP (e.g. CSI- MeasConfig, MeasGapConfig, defined in TS 38.331) can be sent orthe details of the IE as a list of parameters in the O-RAN spec (E2SM-RC and any other E2SM that is defined) can be included. In most of the cases defined in this patent document, the full IE is used and shown as OCTET STRING that will be sent over the E2 interface and the xApp in the Near-RT RIC will extract the information it needs. Alternatively, only the list of parameters from the IE that the xApp needs can be included, or the complete list can be provided to support the future needs of any use case.
[0149] 4.1 E2 Messages Exchanged with CU
[0150] The RRC Parameter Report Request message is shown in FIG. 33A.
[0151] The RRC Parameter Report message is shown in FIG. 33B.
[0152] The RRC Connected UE Report Request message is shown in FIG. 33C.
[0153] The RRC Connected UE Report message is shown in FIG. 33D.
[0154] The UE RRC Connection Setup Report Request message is shown in FIG. 33E.
[0155] The UE RRC Connection Setup Report message is shown in FIG. 33F.
[0156] The UE RRC Connection Release Report Request message is shown in FIG. 33G.
[0157] The UE RRC Connection Release Report message is shown in FIG. 33H.
[0158] The UE RRC State Change Report Request message is shown in FIG. 331.
[0159] The UE RRC State Change Report message is shown in FIG. 33J.
[0160] The PDCP Traffic Report Request message is shown in FIG. 33K.
[0161] The PDCP Traffic Report message is shown in FIG. 33L.
[0162] The UE RRC CSI Measurement Configuration Report Request message is shown in FIG. 33M. [0163] The UE RRC CSI Measurement Configuration Report message is shown in FIG. 33N.
[0164] The RRC Downlink Channel Quality Report Configuration message is shown in FIG. 330.
[0165] The UE RRC SRS Configuration Report Request message is shown in FIG. 33P.
[0166] The UE RRC SRS Configuration Report message is shown in FIG. 33Q.
[0167] The RRC Uplink SRS Configuration message is shown in FIG. 33R.
[0168] The Measurement Gap Configuration Report Request message is shown in FIG. 33S.
[0169] The Measurement Gap Configuration Report message is shown in FIG. 33T.
[0170] The UE RRC BWP Downlink Configuration Report Request message is shown in FIG. 33U.
[0171] The UE RRC BWP Downlink Configuration Report message is shown in FIG. 33V.
[0172] The UE RRC PDSCH Configuration (not MVP) message is shown in FIG. 33W.
[0173] The Served Radio Bearer Configuration Report Request message is shown in FIG. 33X. [0174] The Served Radio Bearer Configuration Report message is shown in FIG. 33Y.
[0175] The RRC CSI Resource Configuration message is shown in FIG. 33Z.
[0176] The UE PDSCH of Serving Cell Configuration Report Request message is shown in FIG. 33AA.
[0177] The UE PDSCH of Serving Cell Configuration Report message is shown in FIG. 33AB.
[0178] The UE DRX Configuration Report Request message is shown in FIG. 33AC.
[0179] The UE DRX Configuration Report message is shown in FIG. 33AD.
[0180] The UE Capabilities Report Request message is shown in FIG. 33AE.
[0181] The UE Capabilities Report message is shown in FIG. 33AF.
[0182] The UE RRC BWP Uplink Configuration Report Request (not MVP) message is shown in FIG.
33AG.
[0183] The UE RRC BWP uplink Configuration Report (not MVP) message is shown in FIG. 33AH.
[0184] The UE RRC UL DMRS Configuration (not MVP) message is shown in FIG. 33AI.
[0185] 4.2 E2 Messages Exchanged with DU
[0186] The MAC Uplink Channel Estimate Report Request message is shown in FIG. 34A.
[0187] The MAC Uplink Channel Estimate Report message is shown in FIG. 34B.
[0188] The MAC UL Channel Quality Report (Not MVP) message is shown in FIG. 34C.
[0189] The MAC UL Raw SRS Report message is shown in FIG. 34D.
[0190] The MAC Downlink Channel Quality Report Request message is shown in FIG. 34E.
[0191] The MAC Downlink Channel Quality Report message is shown in FIG. 34F.
[0192] The MAC DL CSI Report message is shown in FIG. 34G.
[0193] The MAC DL HARQ Feedback Report message is shown in FIG. 34H.
[0194] The DL RLC Traffic Report Request message is shown in FIG. 341.
[0195] The DL RLC Traffic Report message is shown in FIG. 34J.
[0196] The MAC UL Traffic Report Request (not MVP) message is shown in FIG. 34K.
[0197] The MAC UL Traffic Report (not MVP) message is shown in FIG. 34L.
[0198] The MAC Slot Indication Request message is shown in FIG. 34M.
[0199] The MAC Slot Indication message is shown in FIG. 34N.
[0200] The MAC DL UE Scheduling message is shown in FIG. 340.
[0201] The RIC Control Outcome from E2 Node (O-DU) is shown in FIG. 34P.
[0202] The O-RU Antenna Information Report Request message is shown in FIG. 34Q.
[0203] The O-RU Antenna Information Report message is shown in FIG. 34R.
[0204] The Served Bearer Scheduling Configuration Control message is shown in FIG. 34S.
[0205] The E2 Compression Support Information Report Request message is shown in FIG. 34T. [0206] The E2 Compression Support Information Report message is shown in FIG. 34U.
[0207] 4.3 E2 Node Configuration for MU-MIMO Optimization
[0208] In some embodiments, FIGS. 35A-35D show the Near-RT RIC and the E2 Node capabilities that are necessary for implementation of the MU-MIMO Optimization use case. As shown therein, the required capabilities include control over E2 (FIG. 35A), UE context information from E2 nodes (FIG. 35B), measurements from E2 nodes (FIG. 35C), and E2 nodes configuration (FIG. 35D).
[0209] 5. Example Embodiments for the E2 Service Model (E2SM)
[0210] In some embodiments, each of the following E2AP procedures contain specific E2 Node RAN Function dependent Information Elements (lEs). This patent documents includes, in an example, the contents of the fields for the proposed RAN function “Lower Layers Control” (e.g., implemented as E2SM- LLC).
Figure imgf000031_0001
[0211] In some embodiments, the following E2AP messages can be defined to implement MU-MIMO Optimization for each of the described requests and/or reports:
[0212] For the RRC Parameter Report Request, the RIC QUERY REQUEST and the RIC SUBSCRIPTION REQUEST are shown in FIGS. 36A and 36B, respectively.
[0213] For the RRC Parameter Report, the RIC QUERY RESPONSE and the RIC INDICATION are shown in FIGS. 36C and 36D, respectively.
[0214] For the RRC Connected UE Report Request, the RIC QUERY REQUEST is shown in FIG. 36E.
[0215] For the RRC Connected UE Report, the RIC QUERY RESPONSE is shown in FIG. 36F.
[0216] For the RRC Connection Setup Report Request, the RIC SUBSCRIPTION REQUEST is shown in FIG. 36G. [0217] For the UE RRC Connection Setup Report, the RIC INDICATION is shown in FIG. 36H.
[0218] For the UE RRC Connection Release Report Request, the RIC SUBSCRIPTION REQUEST is shown in FIG. 361, and for the UE RRC Connection Release Report, the RIC INDICATION is shown in FIG. 36J.
[0219] For the UE RRC State Change Report, the RIC INDICATION in shown in FIG. 36L.
[0220] For the CSI Measurement Configuration Report Request, the RIC QUERY REQUEST and the RIC SUBSCRIPTION REQUEST are shown in FIGS. 36M and 36N, respectively.
[0221] For the CSI Measurement Configuration Report, the RIC QUERY RESPONSE is shown in FIG. 360.
[0222] For the RRC Downlink Channel Quality Report Configuration, the RIC CONTROL REQUEST is shown in FIG. 36P.
[0223] For the SRS Configuration Report Request, the RIC QUERY REQUEST and the RIC SUBSCRIPTION REQUEST are shown in FIGS. 36Q and 36R, respectively.
[0224] For the SRS Configuration Report, the RIC QUERY RESPONSE and the RIC INDICATION are shown in FIGS. 36S and 36T, respectively.
[0225] For the RRC Uplink SRS Configuration, the RIC CONTROL REQUEST is shown in FIG. 36U.
[0226] For the Measurement Gap Configuration Report Request, the RIC QUERY REQUEST and the RIC SUBSCRIPTION REQUEST are shown in FIGS. 36V and 36W, respectively.
[0227] For the Measurement Gap Configuration Report, the RIC QUERY RESPONSE and the RIC INDICATION are shown in FIGS. 36X and 36Y, respectively.
[0228] For the UE RRC BWP DL Configuration Report Request, the RIC QUERY REQUEST and the RIC SUBSCRIPTION REQUEST are shown in FIGS. 36Z and 36AA, respectively.
[0229] For the UE RRC BWP DL Configuration Report, the RIC QUERY RESPONSE is shown in FIG. 36AB.
[0230] For the Served Radio Bearer Configuration Report Request, the RIC QUERY RESPONSE and the RC SUBSCRIPTION REQUEST are shown in FIGS. 36AC and 36AD, respectively.
[0231] For the Served Radio Bearer Configuration Report, the RIC QUERY RESPONSE and the RIC INDICATION are shown in FIGS. 36AE and 36AF, respectively.
[0232] For the RRC CSI Resource Configuration, the RIC CONTROL REQUEST is shown in FIG. 36AG.
[0233] For the PDSCH Serving Cell Configuration Report Request, the RIC QUERY REQUEST and the RIC SUBSCRIPTION REQUEST are shown in FIGS. 36AH and 36AI, respectively.
[0234] For the PDSCH Serving Cell Configuration Report, the RIC QUERY RESPONSE and the RIC INDICATION are shown in FIGS. 36AJ and 36AK, respectively.
[0235] For the UE DRX Configuration Report Request, the RIC QUERY REQUEST and the RIC SUBSCRIPTION REQUEST are shown in FIGS. 36AL and 36AM, respectively. [0236] For the UE DRX Configuration Report, the RIC QUERY RESPONSE is shown in FIGS. 36AN and 36AO, and the RIC INDICATION is shown in FIG. 36AP.
[0237] For the UE Capabilities Report Request, the RIC QUERY REQUEST is shown in FIG. 36AQ, and for the UE Capabilities Report, the RIC QUERY RESPONSE is shown in FIG. 36AR.
[0238] For the O-RU Antenna Information Report Request, the RIC QUERY REQUEST and the RIC QUERY RESPONSE are shown in FIGS. 36AS and 36AT, respectively.
[0239] For the Served Bearer Scheduling Control, the RIC CONTROL REQUEST is shown in FIG. 36AU.
[0240] For the E2 Compression Support Information Request, the RIC QUERY REQUEST is shown in FIG. 36AV, and for the E2 Compression Support Information Report, the RIC QUERY RESPONSE is shown in FIG. 36AW.
[0241] 6. Example Use Cases for the Disclosed Embodiments
[0242] Embodiments of the disclosed technology can be configured to support a variety of use cases. The motivation, description, and requirements for the O-RAN architecture to support these use cases are discussed in this section.
[0243] 6.1 Traffic Steering
[0244] The rapid traffic growth and multiple frequency bands utilized in a commercial network make it challenging to steer the traffic in a balanced distribution. Typical controls are limited to adjusting the cell reselection and handover parameters; and modifying load calculations and cell priorities. The goal of Near-RT RIC Traffic Steering is to interpret the Policies received over A1 and to determine the optimum changes it can make towards achieving those goals. It may also leverage the A1 enrichment information. Traffic Steering may reuse mechanisms provided by other use cases to effect the changes necessary to achieve its goals. More specifically, Near-RT RIC triggers E2 procedure and related control/policies so as to obtain network performance that would fulfill the criteria identified in the A1 policies.
[0245] In some embodiments, the entities and resources involved in this use case include:
[0246] (1) OAM Functions in SMO domain:
[0247] - Collect necessary measurement metrics from network level measurement report and enrichment data (may acquire data from application) for constructing/training relevant AI/ML models [0248] - Deploy or update, configure the relevant TS optimization AI/ML models to Near-RT RIC via 01 .
[0249] (2) Non-RT RIC in SMO domain:
[0250] - Send A1 policies and receive policy feedback to/from Near-RT RIC to drive resource optimization at RAN level.
[0251] (3) Near-RT RIC:
[0252] - Supports update of AI/ML models from SMO. [0253] - Supports inference, such as traffic prediction, using AI/ML models from Non-RT RIC based on network data, e.g. measurement reports from E2 Node.
[0254] - Supports interpretation and execution of A1 policies from Non-RT RIC.
[0255] - Sends TS resource optimization related policies and commands to E2 Node to influence RRM behavior.
[0256] - Sends the relevant A1 policy feedback to Non-RT RIC for potential policy update.
[0257] - Sends the relevant 01 performance data to OAM Functions; these may be used by
Non-RT RIC for potential policy update
[0258] (4) E2 Node:
[0259] - Supports reporting of UE context, network measurements, and UE measurements to
Near-RT RIC over E2 interface.
[0260] - Executes policies and commands received from Near-RT RIC over E2 interface
[0261] - Supports network and UE performance report to OAM Functions in SMO domain over
O1 interface.
[0262] FIG 18 shows three general Traffic Steering processing modes and the transitions between them. As shown therein, these modes represent the way the Near-RT RIC (or RAN) operates on a given group of UEs, and not the operation of any component as a whole. As such, the Near-RT RIC, could be operating in both modes 1 and 2 concurrently for different sets of UEs. For example, the transition from Mode 0 or 1 to 2 occurs only for a group of UE defined by the A1 policy Scope. At the same time, other UE groups may still be handled in Mode 0 and/or 1 . The three processing modes are further described as:
[0263] (0) “Baseline” Traffic Steering Behavior: OAM Functions in SMO domain uses O1 configuration on one or more E2 node to set up a desired baseline behavior. This also sets up baseline Performance Monitoring of E2 Node by the SMO. In this mode, Near-RT RIC is not involved.
[0264] (1) “Background” Near-RT RIC Processing: OAM Functions in SMO domain uses O1 configuration of near-RT RIC to set up a desired “background near-RT RIC behavior”. In this mode the near-RT RIC sets up E2 mechanisms to monitor E2 Node and uses Traffic Steering related E2 mechanisms to achieve the desired background behavior of the set of E2 Nodes connected to the near- RT RIC.
[0265] (2) “A1 -Policy based” Near-RT RIC Processing: This mode may be entered from either
Mode 0 or Mode 1. Non-RT RIC in SMO domain uses A1-P to specify an A1 guided behavior for a targeted subset of E2 Nodes or UEs. If entering this from Mode 1 , this will have the effect of modifying the existing near-RT RIC “background” behavior to include a more specific A1 guided behavior. In this mode, the near-RT RIC may either set up or modify E2 mechanisms used to monitor E2 Nodes and will use Traffic Steering related E2 mechanisms to obtain the desired behavior of some targeted sub-set of E2 Nodes or UEs. This mode terminates when the corresponding A1 -P Policy Delete message is received from Non-RT RIC in SMO domain and the system returns to either Mode 0 or Mode 1 , depending on whether or not OAM Functions in SMO domain had previously configured the optional Near-RT RIC “background” role (Mode 1).
[0266] It is noted that Processing Mode 2 contain an ‘outer loop’ and an ‘inner loop’. In the inner loop, a number of different “E2 mechanism” may be used (Policy, Report/Control or Insert/Control) towards a number of different target RAN functions in order to either exercise existing RAN mechanisms or modifying their ongoing behavior. The appropriate mechanism and target RAN Function would depend upon the RAN Function capabilities to support a given E2 mechanism, the A1-P scope and policy, the 01 configuration of the RIC and the performance observed through E2 monitoring.
[0267] The table shown in FIGS. 19A and 19B further details the Near RT RIC A1 -Policy Based Traffic Steering, and describes the operations shown in the flow diagram in FIGS. 19C and 19D.
[0268] In some embodiments, the following Near-RT RIC and the E2 Node capabilities are necessary for implementation of the Traffic Steering use case.
[0269] Control over E2. In some embodiments, and with regard to mobility control, the serving cell can be chosen based on the resource status and QoS of the UE(s) targeted by an A1 Traffic steering policy. Moreover, load balancing can be achieved to improve the overall network performance. The following procedures can be used for Traffic Steering:
[0270] - Handover from the source cell to the target cell
[0271] - Configuration/reconfiguration of handover restriction list
[0272] - Configuration of idle mode mobility parameters
[0273] - Enable, disable, or modify Carrier Aggregation (CA)
[0274] - Enable, disable, or modify Dual Connectivity
[0275] In some embodiments, both RIC POLICY and RIC CONTROL can be used.
[0276] UE Context Information from E2 Nodes. In some embodiments, the followings are examples of UE context information identified as required:
[0277] - UE ID
[0278] - Slice level: S-NSSAI
[0279] - DRB level: e.g., established DRB ID, mapping with QoS flows, etc.
[0280] - QoS related: e.g., E-RAB Level QoS Parameters (4G, NSA) or QoS Flow Level QoS
Parameters (NG-RAN).
[0281] - UE capabilities: CA and DC capabilities
[0282] For example, UE ID, S-NSSAI, DRB ID, or QCI/5QI can be used to derive the QoS requirements and the resource occupation; the UE capabilities may be required to select the appropriate RRM action (e.g. CA/DC configuration). [0283] Measurements from E2 Nodes. In some embodiments, the E2 measurements are necessary for inference and prediction in the Near-RT RIC as the driver for decisions in addition to KPMs. For the Traffic Steering use case, the Near-RT RIC can translate an A1 policy (relatively static targets) into a flexible selection of controls over E2 (e.g. handover control, DC, CA, idle mode mobility) by taking into account the RAN resource utilization, cell level and the UE level performance, the radio conditions, etc. The table in FIG. 19E lists the examples of measurement information identified as required.
[0284] E2 Node Configuration. In some embodiments, cell level configuration parameters, such as PCI, neighbor relations and related offsets etc. are needed at Near-RT RIC in order to e.g. configure UE measurements monitor cell level performance and manage mobility control (handover and cell reselection) according to the network topology and the related E2 parameters.
[0285] 6.2 QoS-Based Resource Optimization
[0286] The network must offer means to prioritize resources while preserving the required QoS properties, e.g. reliability, latency, bandwidth requirements, as specified in 3GPP TS 23.203 [3]. Current RAN network coverage and capacity depends on rigorous planning and configuration. However, due to varying nature of traffic demands and radio channels as well as multiple services to co-exist, it is hard to satisfy all QoS requirements simultaneously. In summary, it is important for an E2 Node to achieve QoS targets as smoothly as possible. The QoS aware resource optimization should provide a refined granularity of radio resource allocation based on varying radio conditions and traffics in order to meet the diverse requirements of reliability, latency, and bandwidth simultaneously. In addition, it should coordinate allocation of radio resources for co-existing multiple services, which may have different priorities, to achieve the optimal utilization of radio resources. In case when the network performance data is observed outside the boundary of the defined QoS targets, the Near-RT RIC should be able to trigger re-allocation of radio resources so that the QoS indicators can move back within limits outlined in the A1 policies.
[0287] In some embodiments, the entities and resources involved in this use case include:
[0288] (1) OAM Functions in SMO domain:
[0289] - Collect necessary measurement metrics from network level measurement report and enrichment data (may acquire data from application) for constructing/training relevant AI/ML models [0290] - Deploy or update, configure the relevant QoS optimization AI/ML models to Near-RT
RIC via 01.
[0291] (2) Non-RT RIC in SMO domain:
[0292] - Send A1 policies to and receive policy feedback from Near-RT RIC to drive resource optimization at RAN level, e.g., QoS targets, such as Guaranteed Flow Bit Rate (GFBR), Maximum Flow Bit Rate (MFBR), Priority Level, PDB.
[0293] (3) Near-RT RIC:
[0294] - Support update of AI/ML models from SMO. [0295] - Support inference, such as QoS prediction, using AI/ML models from Non-RT RIC based on network data, e.g. measurement reports from E2 Node.
[0296] - Support interpretation and execution of A1 policies from Non-RT RIC.
[0297] - Sending QoS resource optimization related policies and commands to E2 Node to influence RRM behavior.
[0298] - Sending the relevant A1 policy feedback to Non-RT RIC for potential policy update.
[0299] - Sending the relevant 01 performance data to OAM Functions, may be used by Non-RT
RIC for potential policy update.
[0300] (4) E2 Node:
[0301] - Support reporting of UE context, network measurements, and UE measurements to
Near-RT RIC over E2 interface.
[0302] - Executes policies and commands received from Near-RT RIC over E2 interface
[0303] - Support network and UE performance report to OAM Functions in SMO domain over
O1 interface.
[0304] The table shown in FIGS. 20A and 20B further details the QoS-Based Resource Optimization, and describes the operations shown in the flow diagram in FIG. 20C.
[0305] In some embodiments, the following Near-RT RIC and the E2 Node capabilities are necessary for implementation of the QoS-based resource optimization use case.
[0306] Control Over E2. In some embodiments, and with regard to DRB control, RB control can be applied for modification of the following QoS properties:
[0307] - DRB QoS modification, e.g., DRB level QoS may be tuned to accommodate A1 policy requirement.
[0308] - QoS flow remapping, e.g., the mapping relationship between QoS flows and DRBs may be adjusted.
[0309] - Logical channel reconfiguration, e.g., parameters such as priority, prioritized bit rate, bucket size duration, etc. can be considered.
[0310] - Radio Admission Control, e.g., DRB admission control such as reject or release may be applied.
[0311] - Modification of dual-connectivity DRB, e.g., change of bearer termination point (MN or
SN) and/or bearer types (MCG/SCG/split), and control of split ratio for a split bearer.
[0312] - Activation and deactivation of packet duplication and configuration of the number of legs in DC, CA, or DC+CA scenarios.
[0313] Herein, RIC CONTROL (e.g. request for QoS flow remapping) or RIC POLICY (e.g. DRB admission policy) can be applicable. [0314] In some embodiments, Radio Resource Allocation, such as configuration of DRX, semi-persistent scheduling (SPS), or guidance for the scheduling and rate selection in MAC, can be adjusted. For example, based on prediction, an E2 policy or control to reconfigure SPS configuration or ConfiguredGrantConfig for UL may be generated.
[0315] - DRX reconfiguration, e.g., Long DRX cycle length, Short DRX cycle length as well as short DRX cycle timer can be considered.
[0316] - SR periodicity reconfiguration, e.g., both sr-ProhibitTimer and sr-TransMax can be treated.
[0317] - SPS configuration, e.g., both SPS-Config (DL) and ConfiguredGrantConfig (UL) can be treated.
[0318] - Reconfiguration of slice level PRB quota
[0319] - Configuration of CQI table with certain target block error rate
[0320] Herein, both RIC POLICY and RIC CONTROL can be used. For example, SPS can be configured via RIC CONTROL; RIC POLICY can be used, e.g. to set the guidance for the scheduler.
[0321] In some embodiments, Radio Access Control can be configured. Depending on operator's policies, deployment scenarios, subscriber profiles, and available services, different criterion will be used in determining which access attempt should be allowed or blocked when congestion occurs in the system. For example, access control may be applied to restrict access of other UEs for a specific cell in order to achieve better QoS for some UEs. A cell-level, UE-level, or slice-level access control can be applied. Four categories of radio access control are indicated as below:
[0322] - RACH Backoff
[0323] - RRC Connection Reject
[0324] - RRC Connection Release
[0325] - Access Barring
[0326] Herein, both RIC POLICY and RIC CONTROL can be used.
[0327] In some embodiments, Connection Mobility Control can be adjusted. For example, a neighboring cell may be selected for the optimization of QoS of a specific UE. A neighbor handover restriction list may be configured to prevent the UEs from HO to some neighboring cells in order to guarantee QoS of the UEs served by those neighboring cells. Or, a capacity boosting mechanism may be used to achieve better QoS, e.g. enable CA/DC.
[0328] - Handover from the source cell to the target cell
[0329] - Configuration/reconfiguration of handover restriction list
[0330] - Enable, disable, or modify CA
[0331] - Enable, disable, or modify dual connectivity
[0332] Herein, both RIC POLICY and RIC CONTROL can be used. [0333] UE Context Information from E2 Nodes. In some embodiments, the following are examples of UE context information identified as required:
[0334] - UE ID
[0335] - Slice level: S-NSSAI
[0336] - DRB level: e.g., established DRB ID, mapping with QoS flows, etc.
[0337] - QoS related: e.g., E-RAB Level QoS Parameters (4G, NSA) or QoS Flow Level QoS
Parameters (NG-RAN).
[0338] - UE capabilities: CA and DC capabilities
[0339] - RLC/MAC/PHY level: e.g., logical channel, DRX, scheduling request, SPS configurations.
[0340] For example, UE ID, S-NSSAI, DRB ID, or QCI/5QI can be used for different granularity of controls over E2; an established DRB level information may be needed to change the mapping of QoS flows to a specific DRB or modify DRB attributes; the UE capabilities may be required to make sure if CA/DC can be enabled.
[0341] Measurements from E2 Nodes. In some embodiments, the E2 measurements are necessary for inference and prediction in the Near-RT RIC as the driver for decisions in addition to KPMs. For the QoS based resource optimization use case, the Near-RT RIC can translate an A1 policy (relatively static targets) into a flexible selection of controls over E2 (e.g. RB control, handover, access control) by taking into account the runtime status in the Near-RT RIC. Therefore, it is required to specify those measurement parameters as possible as needed over E2 interface.
[0342] 6.3 RAN Slice SLA Assurance
[0343] The 3GPP standards architected a sliceable 5G infrastructure which allows creation and management of customized networks to meet specific service requirements that may be demanded by future applications, services and business verticals. Such a flexible architecture needs different requirements to be specified in terms of functionality, performance and group of users which may greatly vary from one service to the other. The 5G standardization efforts have gone into defining specific slices and their Service Level Agreements (SLAs) based on application/service type. Since network slicing is conceived to be an end-to-end feature that includes the core network, the transport network and the radio access network (RAN), these requirements should be met at any slice subnet during the life-time of a network slice, especially in RAN side. Exemplary slice performance requirements are defined in terms of throughput, energy efficiency, latency and reliability at a high level in SDOs such as 3GPP and GSMA. These requirements are defined as a reference for SLA/contractual agreements for each slice, which individually need proper handling in NG-RAN. Although network slicing support is started to be defined with 3GPP Release 15, slice assurance mechanisms in RAN needs to be further addressed to achieve deployable network slicing in an open RAN environment. It is necessary to assure the SLAs by dynamically controlling slice configurations based on slice specific performance information. Existing RAN performance measurements and information model definitions are not enough to support RAN slice SLA assurance use cases. This use case is intended to clarify necessary mechanisms and parameters for RAN slice SLA assurance.
[0344] In the 5G era, network slicing is a prominent feature which provides end-to-end connectivity and data processing tailored to specific business requirements. These requirements include customizable network capabilities such as the support of very high data rates, traffic densities, service availability and very low latency. According to 5G standardization efforts, the 5G system should support the needs of the business through the specification of several service needs such as data rate, traffic capacity, user density, latency, reliability, and availability. These capabilities are always provided based on a Service Level Agreement (SLA) between the mobile operator and the business customer, which brought up interest for mechanisms to ensure slice SLAs and prevent its possible violations. O-RAN’s open interfaces and AI/ML based architecture will enable such challenging mechanisms to be implemented and help pave the way for operators to realize the opportunities of network slicing in an efficient manner.
[0345] In some embodiments, the entities and resources involved in this use case include:
[0346] (1) Non-RT RIC:
[0347] - Retrieve RAN slice SLA target from respective entities such as SMO, NSSMF
[0348] - Long term monitoring of RAN slice performance measurements
[0349] - Training of potential ML models that will be deployed in Non-RT RIC for slow loop optimization and/or Near-RT RIC for fast loop optimization.
[0350] - Support deployment and update of AI/ML models into Near-RT RIC
[0351] - Receive slice control/slice SLA assurance rApps from SMO
[0352] - Create and update A1 policies based on RAN intent and A1 feedback.
[0353] - Send A1 policies and enrichment information to Near-RT RIC to drive slice assurance
[0354] - Send O1 reconfiguration requests to SMO for slow-loop slice assurance
[0355] (2) Near-RT RIC:
[0356] - Near real-time monitoring of slice specific RAN performance measurements
[0357] - Support deployment and execution of the AI/ML models from Non-RT RIC
[0358] - Receive slice SLA assurance xApps from SMO
[0359] - Support interpretation and execution of policies from Non-RT RIC
[0360] - Perform optimized RAN (E2) actions to achieve RAN slice requirements based on O1 configuration, A1 policy, and E2 reports.
[0361] (3) E2 Node:
[0362] - Support slice assurance actions such as slice-aware resource allocation, prioritization, etc. through E2.
[0363] - Support slice specific performance measurements through O1 [0364] - Support slice specific performance reports through E2
[0365] The table shown in FIGS. 21 A and 21 B further details the RAN Slice SLA Assurance use case, and describes the operations shown in the flow diagram in FIG. 21 C.
[0366] In some embodiments, the following Near-RT RIC and the E2 Node capabilities are necessary for implementation of the QoS-based resource optimization use case.
[0367] Control over E2. In some embodiments, Radio Resource Allocation, such as configuration of slice level PRB quota, can be adjusted. For example, based on prediction, an E2 policy or control to reconfigure slice level PRB may be generated, e.g., configuration and/or reconfiguration of slice level PRB quota.
[0368] In some embodiments, Radio Access Control can be adjusted. Depending on operator's policies, deployment scenarios, subscriber profiles, available services and SLA of slice, different criterion will be used in determining which access attempt should be allowed or blocked when congestion occurs in the system. For example, access control may be applied to restrict access of other UEs for a specific slice in order to achieve better SLA for some slice. A UE-level, or slice-level access control can be applied. Three categories of radio access control are indicated as below:
[0369] - RRC Connection Reject
[0370] - RRC Connection Release
[0371 ] - Access Ba rri ng
[0372] UE Context Information from E2 Nodes. In some embodiments, the following are examples of UE context information identified as required:
[0373] - UE ID
[0374] - Slice level: S-NSSAI
[0375] Measurements from E2 Nodes. In some embodiments, the E2 measurements are necessary for inference and prediction in the Near-RT RIC as the driver for decisions in addition to KPMs. For the Slice SLA Assuarance use case, the Near-RT RIC can translate an A1 policy (relatively static targets) into a flexible selection of controls over E2 (e.g. PRB control, access control) by taking into account the runtime status in the Near-RT RIC. Therefore, it is required to specify those measurement parameters as possible as needed over E2 interface.
[0376] 6.4 Massive MIMO Optimization
[0377] In some embodiments, the entities and resources involved in this use case include:
[0378] (1) SMO/on-RT RIC:
[0379] - Retrieve necessary performance indicators, measurement reports and RAN configurations from E2 nodes via the O1 interface for the purpose of AI/ML model training and performance monitoring, e.g. the number of supported Non-GoB BF modes in O-DU [0380] - Collect enrichment information from Application servers and associate enrichment information with collected measurements and configurations
[0381] - Perform AI/ML model training and deployment
[0382] - Perform AI/ML model performance monitoring and re-training
[0383] - Send enrichment information to the Near-RT RIC for inference via the A1 interface
[0384] (2) Near-RT RIC:
[0385] - Support AI/ML model deployment from the Non-RT RIC via the 01/02 interface
[0386] - Subscribe and retrieve necessary performance and failure indicators, measurement reports, UE context information and RAN configurations from E2 nodes via the E2 interface for the purpose of mUMO optimization.
[0387] - Retrieve enrichment information from Non-RT RIC via the A1 interface, and associate enrichment information with collected measurements and configurations
[0388] - Perform AI/ML model training and inference.
[0389] - Perform AI/ML model performance monitoring and re-training.
[0390] - Send control or policy message for massive MIMO optimization to E2 nodes via the E2 interface.
[0391] (3) E2 Nodes:
[0392] - Support reporting of necessary performance indicators, measurement reports, UE context information and RAN configurations with required granularity to SMO/Non-RT RIC via the O1 interface
[0393] - Support reporting of necessary performance and failure indicators, measurement reports, UE context information collection and RAN configurations with required granularity to Near-RT RIC via the E2 interface
[0394] - Execute control/policy message received from the Near-RT RIC via the E2 interface
[0395] 6.4.1 AI/ML-assisted Non-Grid-of-Beams Beamforming Optimization
[0396] Model Training in Non-RT RIC. In some embodiments, the table shown in FIGS. 22A and 22B details AI/ML-assisted Non-GoB BF mode selection in Non-RT RIC - model training, deployment, and update, and describes the operations shown in the flow diagram in FIGS. 22C and 22D.
[0397] Model Training in Near-RT RIC. In some embodiments, the table shown in FIG. 23A details AI/ML-assisted Non-GoB BF mode selection in Near-RT RIC - model training, deployment, and update, and describes the operations shown in the flow diagram in FIG. 23B.
[0398] Model Inference. In some embodiments, the table shown in FIG. 24A details AI/ML-assisted Non- GoB BF mode selection - model inference, and describes the operations shown in the flow diagram in FIG. 24B.
[0399] 6.4.2 Beam-based Mobility Robustness Optimization (bMRO) [0400] Beam-based Mobility Robustness Optimization (bMRO) is an autonomous self-optimizing algorithm that improves beam-based inter-cell mobility performance by applying beam-specific HO parameters including Cell Individual Offsets (CIO), Time to Trigger (TTT), T310 counter, etc. on the handover configuration between neighbor cells, based on the analysis of beam-specific mobility-related counters and/or mobility failure events. bMRO is capable to reduce the number of unnecessary handovers, handover failures as well as ping-pong handovers particularly in cells that cover areas with different mobility characteristics.
[0401] Signaling overhead and complexity (RRC re-configuration, mobility reporting and O-CU reconfiguration messages) can be further reduced by beam grouping in which case beams with similar mobility characteristics comprise a beam group (e.g., group 1 : low mobility pedestrian area, group 2: high mobility street). Mobility reports consist of aggregated mobility KPI/PMs (e.g., number of too early HOs, number of too late HOs, number of HO to wrong cell) or individual failure reports with root cause (e.g., to early HO, too late HO, HO to wrong cell) or a combination of the two. Reports are sent per each SSB beam or SSB beam group towards each neighbor cell. Individual mobility failure reports will also be reported per UE to allow UE or UE group-based optimization (besides beam or beam group specific reporting). While aggregated mobility KPIs/PMs are used for slow adaptations (e.g., 5 min), individual failure reports are used for faster adaptations (e.g., 100 ms) or for AI/ML based analysis of failure patterns. Measurement reporting periodicity and measurement type are configurable on a per cell basis considering the tradeoff between gain in mobility performance and associated signaling overhead.
Mobility KPIs and failure events are forwarded from the O-CU to the Near-RT RIC, and the near-RT RIC configures the CIO and the measurement reporting in the O-CUs. CIOs might be beam- or beam group- based and can also be configurable per UE group (e.g., UE type, UE mobility or UE mode such as energy saving mode).
[0402] While AI/ML based approaches are not mandated, AI/ML methods/models can be used i) to build beam groups, to ii) decide on cell individual measurement configuration, to iii) detect changes in mobility characteristics (e.g., traffic jam) that trigger optimization, to iv) group UEs in UE groups as well as v) for the bMRO optimization algorithm itself to calculate the optimal cell individual offsets. In case of dynamic beam pattern optimization, relevant mMIMO beam pattern information must be available at the Near-RT RIC, e.g., mobility reports might indicate a specific beam pattern.
[0403] FIG. 25A shows a table detailing Near-RT RIC Beam-based Mobility Robustness Optimization - model training and initial beam grouping, and FIG. 25B shows a flow diagram for the procedure for this use case.
[0404] FIGS. 26A and 26B show a table detailing Near RT RIC Beam-based Mobility Robustness Optimization - model inference and mobility optimization, and FIGS. 26C and 26D show a flow diagram for the procedure for this use case. [0405] FIGS. 27 A and 27B show a table detailing an MU-MIMO Optimization procedure, and FIGS. 27C and 27D show a flow diagram for the example MU-MIMO Optimization use case.
[0406] In some embodiments, the following Near-RT RIC and the E2 Node capabilities are necessary for implementation of the MU-MIMO Optimization use case.
[0407] Control over E2.
[0408] Non-Grid-of-Beams Beamforming Optimization
Figure imgf000044_0001
[0409] Beam-based Mobility Robustness Optimization
Figure imgf000044_0002
Figure imgf000045_0001
[0410] MU-MIMO Optimization
Figure imgf000045_0002
[0411] 6.5 QoE Optimization
[0412] The highly demanding 5G native applications like Cloud VR are both bandwidth consuming and latency sensitive. However, for such traffic-intensive and highly interactive applications, current semistatic QoS framework can be insufficient to satisfy diversified QoE requirements especially taking into account potentially significant fluctuation of radio transmission capability. It is expected that QoE estimation/prediction can help deal with such uncertainty and improve the efficiency of radio resources, and eventually improve user experience. RAN analytics information (RAI) as RAN service can be exposed to RAI service consumers for specific UE (identified according to [32] section 4.5) or for groups of UE (per slice, per cell, per PLMN, etc.). RAI is envisioned to be helpful for the applications to improve the user experience. Near-RT RIC and E2 interface are leveraged to support this use case. Measurement data through E2 interface, e.g., cell level data, UE level data, can be acquired and processed via ML algorithms to support traffic recognition, QoE prediction, and QoS enforcement decisions. When requested, the analytics information, e.g., traffic rate, latency, packet loss rate, is exposed to the RAI service consumers to help applications execute logical control.
[0413] In some embodiments, the entities and resources involved in this use case include:
[0414] (1) Near-RT RIC:
[0415] - Support receiving request or subscription messages from RAI service consumer. [0416] - Support receiving network state and UE performance report from RAN.
[0417] - Support data analysis and executing the AI/ML models to infer RAN analytics information, e.g., QoE prediction, and available bandwidth prediction.
[0418] - Support exposure RAN analytics information to RAI service consumer.
[0419] (2) RAN:
[0420] - Support network state and UE performance report with required granularity to Near-RT
RIC over E2 interface.
[0421] (3) RAI service consumer:
[0422] - Request or subscribe to RAN analytics information from the Near-RT RIC.
[0423] - Support UE identification using data structure defined in O-RAN Architecture.
[0424] FIG. 28A shows a table detailing RAN Performance Analytics assisted QoE Optimization, and FIG. 28B shows a flow diagram for the procedure for this use case.
[0425] FIG. 29A shows a table detailing RAN Performance Analytics assisted QoE Optimization using subscription based solution, and FIG. 29B shows a flow diagram for the procedure for this use case.
[0426] 7. Example embodiments and implementations of the disclosed technology
[0427] As discussed in the previous sections, the characteristics and potential implementations of the MU-MIMO Optimization (e.g., as shown in FIG. 3, and referred to as mUMO) can be summarized as follows:
[0428] - The mUMO enables MU-MIMO in systems with deployed RUs not designed to support
MIMO without the need for any modifications in the RU mounted on the towers. This is enabled by employing the automatic calibration and tracking algorithms as part of the mUMO application and some functionality being added to the DL PHY function implemented in the eNB/gNB/O-DU (e.g. in FlexRAN).
[0429] - The mUMO enables dynamic scheduling by making all the scheduling decisions for non- time-critical flows and provides the scheduling parameters and any precoding information (spatial multiplexing groups of UEs with their resource assignments, precoding coefficients, etc.) to the O-DU for preparing the DCIs and transmitting the scheduled flows. This is done by separating the control plane of the DU from the data plane and moving most of the controls to the Near-RT RIC (xApp).
[0430] - The mUMO can be implemented as an xApp in the Near-RT RIC (as detailed in this patent document).
[0431] - The mUMO can be co-located with the DU as a separate module.
[0432] - The mUMO can be co-located with the CU as a separate module creating a CU-DU interface similar to split-5.
[0433] - The mUMO can be expanded to support multiple DUs enabling the support for CoMP and for cell-less MIMO where a precoder applies to antennas from multiple towers. [0434] FIG. 30 is a flowchart of an example method 3000 of facilitating wireless communication. The method 3000 includes, at operation 3010, generating, by a first network function, a proposed schedule of transmissions and receptions in a multi-user multiple-input multiple-output (MU-MIMO) network.
[0435] The method 3000 includes, at operation 3020, communicating, by the first network function, the proposed schedule to a second network function that is logically and physically separated from the first network function. In this example method, the second network function is configured to determine, based on a time criticality of pending communication tasks, a final schedule of the transmissions and receptions by overwriting entries of the proposed schedule.
[0436] FIG. 31 is a flowchart of another example method 3100 of facilitating wireless communication. The method 3100 includes, at operation 3110, receiving, from a first network function, by a second network function that is logically and physically separated from the first network function, a proposed schedule of transmissions and receptions in a multi-user multiple-input multiple-output (MU-MIMO) network.
[0437] The method 3100 includes, at operation 3120, determining, by the second network function and based on a time criticality of pending communication tasks, a final schedule of the transmissions and receptions by overwriting entries of the proposed schedule generated by the first network function.
[0438] The following listing of solutions may be preferably implemented by some embodiments.
[0439] A1 . A method of operating a wireless network, comprising: operating a multi-user multi-input multi-output (MU-MIMO) control function in wireless network comprising multiple network functions, wherein the MU-MIMO control function provides an MU-MIMO capability to the wireless network using which the wireless network provides wireless connectivity to user devices using an MU-MIMO configuration.
[0440] A2. The method of solution A1 , further including: configuring the MU-MIMO function to operate as an xApp module such that the MU-MIMO control function communicates with the multiple network functions using existing interface protocols and/or using MU-MIMO enhancements to existing interface protocols.
[0441] A3. The method of solution A1 or A2, wherein the MU-MIMO control function is configured to operate to meet one or more performance criteria.
[0442] Some solutions related to performance requirements include:
[0443] A4. The method of solution A3, wherein a performance criterion met by the MU-MIMO function specifies a near-real-time (near-RT) operation of a control loop that comprises the MU-MIMO function, wherein the near-RT operation has a response time less than 1 second.
[0444] A5. The method of any of solutions A3 to A4, wherein the MU-MIMO function is configured to communicate information to assist scheduling to meet the near-RT operation of the control loop.
[0445] A6. The method of solution A3, wherein the one or more performance criteria include: an ability to receive or configure a cell configuration at a first time granularity, an ability to receive or configure UE- level information at a second time granularity, an ability to receive or configured channel state information or sounding reference signal information at a third time granularity, an ability to control parameter covered by downlink control information (DCI) format 1 .0, an ability to control parameter covered by downlink control information (DCI) format 1 .1 , an ability to control physical downlink shared channel configuration at a fourth time granularity, an ability to control a measurement gap configuration at a fifth time granularity, an ability to receive report of or configure active data radio bearer information at a sixth time granularity, an ability to control data transmission/reception scheduling information items at a respective time granularity, the items including uplink channel quality information, downlink channel quality information, PDCP buffer status, RLC buffer occupancy, timestamps or support for subband PMI, and/or an ability to control schedule at a slot-level granularity according to slot number, bandwidth part ID, UE ID, virtual resource block to physical resource block mapping, a bundling size indicator, antenna ports, or precoder coefficients.
[0446] A7. The method of any of above solutions, wherein the performance criteria include: ability to communicate information on the allocations of user devices to transmission resources; precoder coefficients per SMG; scheduling multiple slots into the future; or allocating amount of data per LCID. [0447] Some solutions implementing the interface protocol, message syntax, and/or message field semantics include:
[0448] A8. The method of any of above solutions, wherein the MU-MIMO control functions is configured to communicate with the multiple network functions using a service interface according to one or more of a report message, an insert message, a control message, a policy message or a query message.
[0449] A9. The method of solution A8, wherein the query message comprises a management information base (MIB) information element (IE) or a field indicative of an IE indicating a periodicity of a synchronization signal transmission block within a cell served by the MU-MIMO control function.
[0450] A10. The method of any of solutions A8 to A9, wherein the report message comprises a field indicative of a change to a management information database identity or a change in a synchronization signal block periodicity.
[0451] A11 . The method of any of above solutions, wherein the query message and the report message support querying or reporting a downlink bandwidth part information element.
[0452] A12. The method of any of above solutions, wherein the query message and the report message support querying or reporting a channel state information measurement configuration information element.
[0453] A13. The method of any of above solutions, wherein the control message is configured to (1) add or release resources of a channel state information configuration, (2) add or remove report configurations for reporting a channel state information, (3) add or remove entries of a sounding reference signal configuration, (4) add or remove a configuration of a physical downlink shared data channel, (5) report parameters of a bandwidth part information element or a physical downlink shared data channel information element.
[0454] A14. The method of any of above solutions, wherein the query message is configured to query a measurement gap configuration information element (IE) or a logical channel identity IE and the report message is configured to report the measurement gap configuration IE or the logical channel identity IE. [0455] A15. The method of solution A8, wherein the MU-MIMO control functions is configured to communicate with the multiple network functions using a service interface according to one or more of: (a) a report triggered by received sounding reference signal (SRS) symbols, (b) a resource indicator (Rl) I precoding matrix indicator (PMI) / channel quality indicator (CQI) of one or more user devices triggered on received channel state information report, (c) a count of uplink ACK/NACK by user devices, (d) a count of downlink ACK/NACK/DTX, (e) buffer occupancy information at a protocol data convergence layer or a radio link control layer.
[0456] A16. A method, implemented by a processor, comprising: operating a network function to facilitate MU-MIMO operation of a network by transmitting or receiving a message having fields described in the present document.
[0457] A17. A method, implemented by a processor, comprising: operating a network function to facilitate MU-MIMO operation of a network by transmitting or receiving a message having fields in an order described in the present document.
[0458] Some solutions related to source and target network functions, and additional messaging, include:
[0459] A18. A method of facilitating wireless communication, comprising: generating, by a first network function, a proposed schedule of transmissions and receptions in a multi-user multi-input multi-output network; communicating, by the first network function, the proposed schedule to a second network function that is logically and physically separated from the first network function; wherein the second network function is permitted to determine a final schedule of transmissions and receptions by overwriting entries of the proposed schedule generated by the first network function.
[0460] A19. A method of facilitating wireless communication, comprising: receiving, by a second network function, from a first network function, a proposed schedule of transmissions and receptions in a multiuser multi-input multi-output network (MU-MIMO); and determining, by the second network function, a final schedule of transmissions and receptions by overwriting entries of the proposed schedule generated by the first network function based on time criticality of pending communication tasks.
[0461] A20. The method of any of solutions A18 to A19, wherein the first network function and the second network function are configured to transmit or receive messages according to a message protocol.
[0462] A21 . The method of any of above solutions, wherein the first network function comprises an xapp software module. [0463] A22. The method of any of above solutions, wherein at least a portion of the second network function is included in a distributed unit (DU) of a wireless communication network.
[0464] A23. The method of any of above solutions, wherein the second network function is configured to maintain one or more flow queues, wherein each queue is associated with a quality indicator.
[0465] A24. The method of solution A23, wherein the message protocol specifies a flow report transmission from the second network function to the first network function, wherein the flow report transmission reports one or more of user equipment identifiers, quality indicators and queue status.
[0466] A25. The method of any of above solutions, wherein the first network function is configured to track channel statistics, maintain a database of flow(s) for each user equipment and priority information for each flow.
[0467] A26. The method of any of above solutions, wherein the first network function is configured to determine spatial multiplexing groupings of user equipment and use the spatial multiplexing groupings for the proposed schedule.
[0468] A27. The method of solution A26, wherein the first network function generates the proposed schedule by assigning bandwidth to non-time critical flows within available physical resource blocks. [0469] A28. The method of solution A27, wherein the second network function performs the overwriting by assigning unassigned physical resource blocks to time-critical flows and/or by re-assigning physical resource blocks previously assigned to non-time critical flows in the proposed schedule to time-critical flows.
[0470] A29. The method of solution A28, wherein after the final schedule is determined, the final schedule a scheduling response is transmitted by the second network function and received by the first network function.
[0471] A30. The method of solution A29, wherein, based on the scheduling response, the first network function updates locally stored flow database.
[0472] A31 . The method of any of solutions A20 to A30, wherein the API defines a message for exchanging information about semi-persistent scheduling flows.
[0473] A32. The method of any of above solutions, wherein the proposed schedule is generated on a per time-domain symbol basis.
[0474] A33. The method of any of above solutions, wherein the message protocol defines a first message transmitted from the first network function to a third network function, wherein the first message requests information about capabilities of user devices in the MU-MIMO network and a second message that carries requested information from the third network function to the first network function.
[0475] A34. The method of any of above solutions, wherein the message protocol defines a first message transmitted from the first network function to the second network function, wherein the first message requests antenna information and a second message that carries requested information from the second network function to the first network function.
[0476] A35. The method of any of above solutions, wherein the message protocol defines a message that communicates a served bearer scheduling configuration control information.
[0477] A36. The method of any of above solutions, wherein the message protocol defines a message that communicates information about support of compression capabilities.
[0478] A37. An apparatus comprising a processor configured to implement a method recited in any one or more of solutions A1 to A36.
[0479] A38. A storage medium having computer-executable code stored thereon, the code, upon execution by a processor, causing the processor to implement a method recited in any one or more of solutions A1 to A36.
[0480] A39. A system comprising a plurality network functions configured to operate a radio access network that provides wireless connectivity to user devices, wherein the at least some of the network functions are configured to operate according to a technique described in the present document.
[0481] A40. A system, method or apparatus disclosed in the present document.
[0482] B1. A method (e.g., method 3000 in FIG. 30) of facilitating wireless communications, comprising: generating (3010), by a first network function, a proposed schedule of transmissions and receptions in a multi-user multiple-input multiple-output (MU-MIMO) network; and communicating (3020), by the first network function, the proposed schedule to a second network function that is logically and physically separated from the first network function, wherein the second network function is configured to determine, based on a time criticality of pending communication tasks, a final schedule of the transmissions and receptions by overwriting entries of the proposed schedule.
[0483] B2. A method (e.g., method 3100 in FIG. 31) of facilitating wireless communications, comprising: receiving (3110), from a first network function, by a second network function that is logically and physically separated from the first network function, a proposed schedule of transmissions and receptions in a multi-user multiple-input multiple-output (MU-MIMO) network; and determining (3120), by the second network function and based on a time criticality of pending communication tasks, a final schedule of the transmissions and receptions by overwriting entries of the proposed schedule generated by the first network function.
[0484] B3. The method of solution B1 or B2, wherein the first network function and the second network function are configured to transmit or receive messages according to a message protocol and an application programming interface (API).
[0485] B4. The method of solution B3, wherein the second network function is configured to maintain one or more flow queues, and wherein each flow queue is associated with a quality indicator. [0486] B5. The method of solution B4, wherein the message protocol specifies a transmission of a flow report from the second network function to the first network function, and wherein the flow report includes one or more wireless device identifiers, quality indicators, or queue statuses.
[0487] B6. The method of solution B3, wherein the API defines a message for exchanging information about semi-persistent scheduling (SPS) flows.
[0488] B7. The method of solution B3, wherein the message protocol defines: a first message, transmitted from the first network function to a third network function, comprising a request for information regarding capabilities of wireless devices in the MU-MIMO network; and a second message, transmitted from the third network function to the first network function, comprising the information.
[0489] B8. The method of solution B3, wherein the message protocol defines: a first message, transmitted from the first network function to the second network function, comprising a request for antenna information; and a second message, transmitted from the second network function to the first network function, comprising the antenna information.
[0490] B9. The method of solution B3, wherein the message protocol defines a message that includes scheduling configuration control information for a radio bearer being served.
[0491] B10. The method of solution B3, wherein the message protocol defines a message comprising information regarding compression capabilities supported by devices in the MU-MIMO network.
[0492] B11 . The method of solution B1 or B2, wherein the first network function is configured to (a) track channel statistics and (b) maintain, for each wireless device, a database of flows that includes priority information for each flow.
[0493] B12. The method of solution B1 or B2, wherein the first network function is configured to determine spatially multiplexed groupings of wireless devices, and wherein generating the proposed schedule is based on the spatially multiplexed groupings.
[0494] B13. The method of solution B1 or B2, wherein the first network function generates the proposed schedule by assigning available physical resource blocks (PRBs) to non-time-critical flows.
[0495] B14. The method of solution B13, wherein the second network function overwrites the entries of the proposed schedule by (a) assigning unassigned PRBs to time-critical flows and/or (b) re-assigning PRBs previously assigned to the non-time-critical flows in the proposed schedule to the time-critical flows.
[0496] B15. The method of solution B14, wherein, subsequent to the final schedule being determined, the second network function is configured to transmit a scheduling response message comprising the final schedule to the first network function.
[0497] B16. The method of solution B15, wherein the first network function is configured, upon receiving the scheduling response message, to update a locally-stored flow database.
[0498] B17. The method of solution B1 or B2, wherein the proposed schedule is generated on a per time-domain symbol basis. [0499] B18. The method of any of solutions B1 to B17, wherein the first network function comprises a software module associated with a cloud-based service that provides cellular network services to any cloud-based application.
[0500] B19. The method of any of solutions B1 to B17, wherein at least a portion of the second network function is included in a distributed unit (DU) of a wireless communication network.
[0501] B20. The method of solution B1 or B2, wherein the first network function comprises an MU-MIMO control function that (a) provides an MU-MIMO capability to a wireless communication network and (b) enables the wireless communication network to provide wireless connectivity to wireless devices using an MU-MIMO configuration.
[0502] B21. The method of solution B20, wherein the wireless communication network comprises multiple network functions, and wherein the MU-MIMO control function is configured to communicate with the multiple network functions using existing interface protocols and/or using MU-MIMO enhancements to the existing interface protocols.
[0503] B22. The method of solution B20, wherein the MU-MIMO control function is configured to operate to meet one or more performance criteria.
[0504] B23. The method of solution B22, wherein the one or more performance criteria includes a response time of a near-real-time (near-RT) operation of a control loop being less than one second, and wherein the control loop comprises the MU-MIMO control function.
[0505] B24. The method of solution B22, wherein the MU-MIMO control function is configured to communicate information in order to meet the one or more performance criteria.
[0506] B25. The method of solution B22, wherein the one or more performance criteria includes at least one of: an ability to receive or configure a cell configuration at a first time granularity; an ability to receive or configure a user equipment (UE)-level information at a second time granularity; an ability to receive or configure a channel state information (CSI) or a sounding reference signal (SRS) at a third time granularity; an ability to control a first parameter covered by downlink control information (DCI) format 1_0; an ability to control a second parameter covered by DCI format 1_1 ; an ability to control a physical downlink shared channel (PDSCH) configuration at a fourth time granularity; an ability to control a measurement gap configuration at a fifth time granularity; an ability to receive or configure active data radio bearer information at a sixth time granularity; an ability to control one or more parameters associated with data transmission/reception scheduling information, the one or more parameters comprising an uplink channel quality information (CQI), a downlink CQI, a Packet Data Convergence Protocol (PDCP) buffer status, a Radio Link Control (RLC) buffer occupancy, a timestamp, or support for subband precoding matrix indicator (PMI); or an ability to control scheduling at a slot-level granularity based on at least one of a slot number, a bandwidth part (BWP) identifier, a wireless device identifier, a virtual resource block to physical resource block (VRB-to-PRB) mapping, a bundling size indicator, antenna ports, or precoder coefficients. [0507] B26. The method of solution B22, wherein the one or more performance criteria includes at least one of: an ability to communicate information regarding allocations of wireless devices to transmission resources; precoder coefficients per spatially multiplexed group (SMG); an ability to schedule multiple slots at one or more future times; or allocating an amount of data per logical channel identity (LCID).
[0508] B27. The method of solution B20, wherein the wireless communication network comprises multiple network functions, and wherein the MU-MIMO control function is configured to communicate with the multiple network functions using a first service interface according to one or more of a report message, an insert message, a control message, a policy message, or a query message.
[0509] B28. The method of solution B27, wherein the query message comprises a management information database (MIB) information element (IE) or a field indicative of an IE indicating a periodicity of a synchronization signal block (SSB) within a cell served by the MU-MIMO control function.
[0510] B29. The method of solution B27, wherein the report message comprises a field indicative of a change to a management information database (MIB) identity or a change in a synchronization signal block (SSB) periodicity.
[0511] B30. The method of solution B27, wherein the query message and the report message support querying and reporting, respectively, a downlink bandwidth part (BWP) information element.
[0512] B31 . The method of solution B27, wherein the query message and the report message support querying and reporting, respectively, a channel state information (CSI) measurement configuration information element.
[0513] B32. The method of solution B27, wherein the control message is configured to (1) add or release resources of a channel state information (CSI) configuration, (2) add or remove report configurations for reporting CSI, (3) add or remove entries of a sounding reference signal (SRS) configuration, (4) add or remove a configuration of a physical downlink shared channel (PDSCH), (5) report parameters of a bandwidth part (BWP) information element (IE) or a PDSCH IE.
[0514] B33. The method of solution B27, wherein the query message is configured to query a measurement gap configuration information element (IE) or a logical channel identity IE, and wherein the report message is configured to report the measurement gap configuration IE or the logical channel identity IE.
[0515] B34. The method of solution B27, wherein the MU-MIMO control function is further configured to communicate with the multiple network functions using a second service interface according to one or more of: a report triggered by receiving sounding reference signal (SRS) symbols; a resource indicator (Rl), a precoding matrix indicator (PMI), or a channel quality indicator (CQI) of one or more wireless devices upon receiving a channel state information report; a count of uplink acknowledgement (ACK) messages and negative acknowledgement (NACK) messages by the one or more wireless devices; a count of downlink ACK messages, NACK messages, and discontinuous transmission (DTX) messages; a buffer occupancy information at a protocol data convergence layer or a radio link control (RLC) layer. [0516] B35. An apparatus comprising one or more processors and a transceiver communicatively coupled to the one or more processors, wherein the transceiver is configured to implement the communicating or the receiving operations recited in any one or more of solutions B1 to B34, and wherein the one or more processors are configured to implement the generating or the determining operations. [0517] B36. A storage medium having computer-executable code stored thereon, the computerexecutable code, upon execution by one or more processors, causing the one or more processors to implement the method recited in any one or more of solutions B1 to B34.
[0518] In various embodiments, the first network function and the second network functions may be a software module implemented on one or more processors implementing xApp and a distributed unit (DU), as is described in the present document.
[0519] FIG. 32 is a block diagram representation of a wireless hardware platform 3200 which may be used to implement the various methods described in the present document. The hardware platform 3200 may be incorporated within a base station or a user device. The hardware platform 3200 includes at least one processor 3202, a memory 3204 and a transceiver circuitry 3206. The processor may execute instructions, e. g., by reading from the memory 3204, and control the operation of the transceiver circuitry 3206 and the hardware platform 3200 to perform the methods described herein. In some embodiments, the memory 3204 and/or the transceiver circuitry 3206 may be partially or completely contained within the processor 3202 (e.g., same semiconductor package). The transceiver circuitry 3206 may be configured to implement a wired or a wireless communication protocol.
[0520] It will be appreciated by one of skill in the art that the present document provides techniques that may be implemented on the network-side in a wireless communication system. Using the disclosed techniques, a scheduler function that schedules various uplink and/or downlink transmissions in the network may be implemented to perform MU-MIMO based communication. It will further be appreciated that, according to some embodiments, the scheduler may be implemented into two separately operating schedulers, e.g., one at a CU and one at a DU. One of the schedulers, e.g., implemented as an xApp, may provide non-time critical schedules. The second scheduler, e.g., implemented locally at the network element that is closest to the air interface, may implement time-critical tasks such as URLLC communication, retransmissions, and so on. For example, the second scheduler may operate to overwrite the schedule generated by the first scheduler in order to achieve the near-RT performance desired in a wireless network.
[0521] It will further be appreciated by one of skill in the art that the present document describes various messages and syntax elements that may be communicated in a network to facilitate the second scheduler to prove the near-real time scheduling performance. Among other messages, these messages include messages exchanged at RLC, PDCP layer, messages exchanged over E2 interface, and so on. [0522] The disclosed and other embodiments, modules and the functional operations described in this document can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in combinations of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium can be a machine-readable storage device, a machine- readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more them. The term “data processing apparatus’’ encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus.
[0523] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
[0524] The processes and logic flows described in this document can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
[0525] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read -only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
[0526] While this patent document contains many specifics, these should not be construed as limitations on the scope of an invention that is claimed or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination. Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results.
[0527] Only a few examples and implementations are disclosed. Variations, modifications, and enhancements to the described examples and implementations and other implementations can be made based on what is disclosed.

Claims

WHAT IS CLAIMED IS:
1. A method of facilitating wireless communications, comprising: generating, by a first network function, a proposed schedule of transmissions and receptions in a multi-user multiple-input multiple-output (MU-MI MO) network; and communicating, by the first network function, the proposed schedule to a second network function that is logically and physically separated from the first network function, wherein the second network function is configured to determine, based on a time criticality of pending communication tasks, a final schedule of the transmissions and receptions by overwriting entries of the proposed schedule.
2. A method of facilitating wireless communications, comprising: receiving, from a first network function, by a second network function that is logically and physically separated from the first network function, a proposed schedule of transmissions and receptions in a multi-user multiple-input multiple-output (MU-MIMO) network; and determining, by the second network function and based on a time criticality of pending communication tasks, a final schedule of the transmissions and receptions by overwriting entries of the proposed schedule generated by the first network function.
3. The method of claim 1 or 2, wherein the first network function and the second network function are configured to transmit or receive messages according to a message protocol and an application programming interface (API).
4. The method of claim 3, wherein the second network function is configured to maintain one or more flow queues, and wherein each flow queue is associated with a quality indicator.
5. The method of claim 4, wherein the message protocol specifies a transmission of a flow report from the second network function to the first network function, and wherein the flow report includes one or more wireless device identifiers, quality indicators, or queue statuses.
6. The method of claim 3, wherein the API defines a message for exchanging information about semi-persistent scheduling (SPS) flows.
7. The method of claim 3, wherein the message protocol defines: a first message, transmitted from the first network function to a third network function, comprising a request for information regarding capabilities of wireless devices in the MU-MIMO network; and a second message, transmitted from the third network function to the first network function, comprising the information.
8. The method of claim 3, wherein the message protocol defines: a first message, transmitted from the first network function to the second network function, comprising a request for antenna information; and a second message, transmitted from the second network function to the first network function, comprising the antenna information.
9. The method of claim 3, wherein the message protocol defines a message that includes scheduling configuration control information for a radio bearer being served.
10. The method of claim 3, wherein the message protocol defines a message comprising information regarding compression capabilities supported by devices in the MU-MIMO network.
11 . The method of claim 1 or 2, wherein the first network function is configured to (a) track channel statistics and (b) maintain, for each wireless device, a database of flows that includes priority information for each flow.
12. The method of claim 1 or 2, wherein the first network function is configured to determine spatially multiplexed groupings of wireless devices, and wherein generating the proposed schedule is based on the spatially multiplexed groupings.
13. The method of claim 1 or 2, wherein the first network function generates the proposed schedule by assigning available physical resource blocks (PRBs) to non-time-critical flows.
14. The method of claim 13, wherein the second network function overwrites the entries of the proposed schedule by (a) assigning unassigned PRBs to time-critical flows and/or (b) re-assigning PRBs previously assigned to the non-time-critical flows in the proposed schedule to the time-critical flows.
15. The method of claim 14, wherein, subsequent to the final schedule being determined, the second network function is configured to transmit a scheduling response message comprising the final schedule to the first network function.
16. The method of claim 15, wherein the first network function is configured, upon receiving the scheduling response message, to update a locally-stored flow database.
17. The method of claim 1 or 2, wherein the proposed schedule is generated on a per time-domain symbol basis.
18. The method of any of claims 1 to 17, wherein the first network function comprises a software module associated with a cloud-based service that provides cellular network services to any cloud-based application.
19. The method of any of claims 1 to 17, wherein at least a portion of the second network function is included in a distributed unit (DU) of a wireless communication network.
20. The method of claim 1 or 2, wherein the first network function comprises an MU-MIMO control function that (a) provides an MU-MIMO capability to a wireless communication network and (b) enables the wireless communication network to provide wireless connectivity to wireless devices using an MU- MIMO configuration.
21 . The method of claim 20, wherein the wireless communication network comprises multiple network functions, and wherein the MU-MIMO control function is configured to communicate with the multiple network functions using existing interface protocols and/or using MU-MIMO enhancements to the existing interface protocols.
22. The method of claim 20, wherein the MU-MIMO control function is configured to operate to meet one or more performance criteria.
23. The method of claim 22, wherein the one or more performance criteria includes a response time of a near-real-time (near-RT) operation of a control loop being less than one second, and wherein the control loop comprises the MU-MIMO control function.
24. The method of claim 22, wherein the MU-MIMO control function is configured to communicate information in order to meet the one or more performance criteria.
25. The method of claim 22, wherein the one or more performance criteria includes at least one of: an ability to receive or configure a cell configuration at a first time granularity; an ability to receive or configure a user equipment (UE)-level information at a second time granularity; an ability to receive or configure a channel state information (CSI) or a sounding reference signal (SRS) at a third time granularity; an ability to control a first parameter covered by downlink control information (DCI) format 1_0; an ability to control a second parameter covered by DCI format 1_1 ; an ability to control a physical downlink shared channel (PDSCH) configuration at a fourth time granularity; an ability to control a measurement gap configuration at a fifth time granularity; an ability to receive or configure active data radio bearer information at a sixth time granularity; an ability to control one or more parameters associated with data transmission/reception scheduling information, the one or more parameters comprising an uplink channel quality information (CQI), a downlink CQI, a Packet Data Convergence Protocol (PDCP) buffer status, a Radio Link Control (RLC) buffer occupancy, a timestamp, or support for subband precoding matrix indicator (PMI); or an ability to control scheduling at a slot-level granularity based on at least one of a slot number, a bandwidth part (BWP) identifier, a wireless device identifier, a virtual resource block to physical resource block (VRB-to-PRB) mapping, a bundling size indicator, antenna ports, or precoder coefficients.
26. The method of claim 22, wherein the one or more performance criteria includes at least one of: an ability to communicate information regarding allocations of wireless devices to transmission resources; precoder coefficients per spatially multiplexed group (SMG); an ability to schedule multiple slots at one or more future times; or allocating an amount of data per logical channel identity (LCID).
27. The method of claim 20, wherein the wireless communication network comprises multiple network functions, and wherein the MU-MIMO control function is configured to communicate with the multiple network functions using a first service interface according to one or more of a report message, an insert message, a control message, a policy message, or a query message.
28. The method of claim 27, wherein the query message comprises a management information database (MIB) information element (IE) or a field indicative of an IE indicating a periodicity of a synchronization signal block (SSB) within a cell served by the MU-MIMO control function.
29. The method of claim 27, wherein the report message comprises a field indicative of a change to a management information database (MIB) identity or a change in a synchronization signal block (SSB) periodicity.
30. The method of claim 27, wherein the query message and the report message support querying and reporting, respectively, a downlink bandwidth part (BWP) information element.
31 . The method of claim 27, wherein the query message and the report message support querying and reporting, respectively, a channel state information (CSI) measurement configuration information element.
32. The method of claim 27, wherein the control message is configured to (1) add or release resources of a channel state information (CSI) configuration, (2) add or remove report configurations for reporting CSI, (3) add or remove entries of a sounding reference signal (SRS) configuration, (4) add or remove a configuration of a physical downlink shared channel (PDSCH), (5) report parameters of a bandwidth part (BWP) information element (IE) or a PDSCH IE.
33. The method of claim 27, wherein the query message is configured to query a measurement gap configuration information element (IE) or a logical channel identity IE, and wherein the report message is configured to report the measurement gap configuration IE or the logical channel identity IE.
34. The method of claim 27, wherein the MU-MIMO control function is further configured to communicate with the multiple network functions using a second service interface according to one or more of: a report triggered by receiving sounding reference signal (SRS) symbols; a resource indicator (Rl), a precoding matrix indicator (PMI), or a channel quality indicator (CQI) of one or more wireless devices upon receiving a channel state information report; a count of uplink acknowledgement (ACK) messages and negative acknowledgement (NACK) messages by the one or more wireless devices; a count of downlink ACK messages, NACK messages, and discontinuous transmission (DTX) messages; a buffer occupancy information at a protocol data convergence layer or a radio link control (RLC) layer.
35. An apparatus comprising one or more processors and a transceiver communicatively coupled to the one or more processors, wherein the transceiver is configured to implement the communicating or the receiving operations recited in any one or more of claims 1 to 34, and wherein the one or more processors are configured to implement the generating or the determining operations.
36. A storage medium having computer-executable code stored thereon, the computer-executable code, upon execution by one or more processors, causing the one or more processors to implement the method recited in any one or more of claims 1 to 34.
PCT/US2024/032300 2023-06-02 2024-06-03 Network-side coordination of multi-user multiple-input multiple-output functionality Pending WO2024250029A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2024281104A AU2024281104A1 (en) 2023-06-02 2024-06-03 Network-side coordination of multi-user multiple-input multiple-output functionality
PCT/US2024/058465 WO2025207165A1 (en) 2024-03-25 2024-12-04 Network-side coordination of multi-user multiple-input multiple-output functionality

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US202363506021P 2023-06-02 2023-06-02
US63/506,021 2023-06-02
US202363583209P 2023-09-15 2023-09-15
US63/583,209 2023-09-15
US202463569711P 2024-03-25 2024-03-25
US63/569,711 2024-03-25
US202463572092P 2024-03-29 2024-03-29
US63/572,092 2024-03-29

Publications (1)

Publication Number Publication Date
WO2024250029A1 true WO2024250029A1 (en) 2024-12-05

Family

ID=93658570

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2024/032300 Pending WO2024250029A1 (en) 2023-06-02 2024-06-03 Network-side coordination of multi-user multiple-input multiple-output functionality

Country Status (2)

Country Link
AU (1) AU2024281104A1 (en)
WO (1) WO2024250029A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20250031111A1 (en) * 2023-07-19 2025-01-23 Verizon Patent And Licensing Inc. Method and system for offset-based mobility prioritization

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016213533A (en) * 2015-04-30 2016-12-15 西日本電信電話株式会社 Communication apparatus and communication method
US20170150482A1 (en) * 2012-10-24 2017-05-25 Qualcomm Incorporated Enhanced srs transmission for mimo operation in lte-a
US20190373627A1 (en) * 2018-05-29 2019-12-05 Qualcomm Incorporated Supporting scheduling plan indications
US20210410159A1 (en) * 2015-09-25 2021-12-30 Samsung Electronics Co., Ltd. Terminal and communication method to provide communication services

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170150482A1 (en) * 2012-10-24 2017-05-25 Qualcomm Incorporated Enhanced srs transmission for mimo operation in lte-a
JP2016213533A (en) * 2015-04-30 2016-12-15 西日本電信電話株式会社 Communication apparatus and communication method
US20210410159A1 (en) * 2015-09-25 2021-12-30 Samsung Electronics Co., Ltd. Terminal and communication method to provide communication services
US20190373627A1 (en) * 2018-05-29 2019-12-05 Qualcomm Incorporated Supporting scheduling plan indications

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20250031111A1 (en) * 2023-07-19 2025-01-23 Verizon Patent And Licensing Inc. Method and system for offset-based mobility prioritization

Also Published As

Publication number Publication date
AU2024281104A1 (en) 2025-11-27

Similar Documents

Publication Publication Date Title
US11917599B2 (en) SDN-based methods and apparatuses for providing TDD radio access network services
Patriciello et al. An E2E simulator for 5G NR networks
US10973071B2 (en) Improving communication reliability
US12156188B2 (en) User equipment and scheduling device
CN118743293A (en) Operation of TA timer expiration in multi-TA for MDCI MTRP
CN120498610A (en) Communication device, scheduling node, method thereof and integrated circuit
CN120883700A (en) Full-duplex feasibility-aware sidelink resource selection
CN118556441A (en) Time division duplex mode configuration for cellular networks
KR20220078591A (en) User Equipment and Scheduling Nodes
WO2024250029A1 (en) Network-side coordination of multi-user multiple-input multiple-output functionality
JP2024512125A (en) User equipment and scheduling nodes
US20250280408A1 (en) User equipment, scheduling node, method for user equipment, and method for scheduling node
WO2025207165A1 (en) Network-side coordination of multi-user multiple-input multiple-output functionality
US20240205912A1 (en) Sidelink feedback for network energy savings
JP2025534866A (en) Coordination for cross-link interference processing.
TW202433983A (en) Bsr trigger enhancements
US20240348383A1 (en) User equipment and base station involved in resource indication for control channel carrier switching
JP2025526780A (en) COMMUNICATION DEVICE AND BASE STATION INVOLVED IN UPLINK SETTING - Patent application
EP4591674A1 (en) Managing signals on multiple wireless links
EP3369277B1 (en) Method and apparatus for implementing signalling to re-configure logical channels
WO2024036460A1 (en) Methods and apparatuses for slice scheduling
US20240121042A1 (en) Network node, user equipment and methods for channel estimation for periodic transmissions
WO2025111448A1 (en) Wtru assisted proactive phy frame reconfiguration associated with low latency applications
WO2023100471A1 (en) Base station, terminal, and communication method
JP2025514149A (en) Video transmission over periodic radio resources - Patents.com

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24816682

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: AU2024281104

Country of ref document: AU

ENP Entry into the national phase

Ref document number: 2024281104

Country of ref document: AU

Date of ref document: 20240603

Kind code of ref document: A