System and method for optimizing configurations of DMRS-downlink and DMRS-uplink in o-ran

Abstract

Systems and methods dynamically select and enforce demodulation reference signal (DMRS) configurations in an Open Radio Access Network (O-RAN). In some embodiments, a Service Management and Orchestration (SMO) / Non-Real-Time RAN Intelligent Controller (Non-RT RIC) framework collects configuration parameters, measurements, and KPI targets, trains an artificial intelligence and / or machine learning (AI / ML) model, and deploys a DMRS configuration policy to a Near-RT RAN Intelligent Controller (Near-RT RIC). The Near-RT RIC receives Layer 1 and Layer 2 information from E2 nodes, maps the information to the policy, and selects DMRS-downlink and DMRS-uplink configurations on a per-cell basis, including configuration type, mapping type, symbol allocation, and DMRS occasions per slot.

Description

SYSTEM AND METHOD FOR OPTIMIZING CONFIGURATIONS OF DMRS-DOWNLINK AND DMRS-UPLINK IN O-RANBACKGROUND1. Field

[0001] The present disclosure is related to Open Radio Access Network (O-RAN) wireless networks and radio resource management (RRM) policies in O-RAN Networks. The disclosure focuses on the Radio Access Network (RAN) design for Stand-Alone (SA) and Non-Stand-Alone (NSA) 5G-based mobile networks.2. Prior Art

[0002] In the existing 5G networks (SA / NSA), gNodeB (gNB) transmits the Demodulation Reference Signal (DMRS) with the Physical Downlink Shared Channel (PDSCH) to each UE (precoded with the UE-specific beamforming weights) that enables the UE to detect the multiplexed MIMO layer data transmissions. Likewise, UE transmits the DMRS with the Physical Uplink Shared Channel (PUSCH) to each gNB (precoded with the UE-specific beamforming weights) that enables the gNB to detect the multiplexed MIMO layer data transmissions.5G provides various choices to configure DMRS over the timefrequency resources such as, configuration type 1, configuration type 2, allocation type A, allocation type B, single symbol DMRS, double symbol DMRS, number of DMRS occasions per slot etc. The orthogonality among the DMRS ports can be achieved in time, frequency, and code domain.

[0003] In the existing 5G networks (SA / NSA), DMRS transmission is configured statically or semi-statically. This solution may be sub-optimal for various reasons:• UE speed (i.e., Coherence-time / doppler-spread of channel) vary across the site with time.o High-speed UEs (such as, cars in highways) would require additional DMRS to accommodate the small coherence time trading off higher overhead. Low- speed UEs do not require additional DMRS (In fact, gNB may omit DMRS transmission for a few slots to reduce the overhead).• Traffic load varies across the network with time.o A high traffic load scenario would require type 2 and double symbol DMRS. Low traffic load can be served with type 1 and single symbol DMRS.• The coherence-bandwidth / delay-spread varies across the network with time.o Depending on the multipath environment, coherence-bandwidth / delay- spread varies across the network. Therefore, statically configuring the frequency domain properties of DMRS transmission leads to suboptimal performance.• KPI requirements can vary across the network.o To support ultra-low latency KPIs, it is often required to transmit with a fraction of slot (also known as, ‘minislot’) where DMRS is preferably allocated with mapping type B (not required to figure out the slot boundary to process the DMRS). During full slot transmissions, mapping type A would be preferred so that CORSET can be placed in the first symbols of the slot.

[0004] In the existing 5G networks, the configurations of DMRS-downlink and DMRS-uplink are set statically / manually or semi-statically (with static logic) at the deployment time. The static configurations aim to accommodate the worst-case scenario of the network which can appear only for a small window of time. Furthermore, static logics cannot adapt the network dynamics.

[0005] Currently, the process / method to dynamically optimize configurations of DMRS is not available. Key challenge is to accommodate the time complexity of algorithm with the dynamics of the network. For example, if the algorithm takes too long to converge, then the solution may not be valid at the present state of the network.SUMMARY

[0006] Described are systems, methods, and computer program products for a system configured to execute Artificial Intelligence / Machine Learning AI / ML models.

[0007] This disclosure provides methods and systems which aim to exploit the various configuration choices of DMRS towards improving the key performance indices (KPIs) of the network. For example, in a fast- fading channel, an additional DMRS occasion per slot can be configured to mitigate the channel-aging effect while trading off higher overhead; in a low traffic-load scenario, smaller number of DMRS ports (such as, Type 1 single-symbol DMRS) can be configured to reduce the overhead; in a low-latency KPI requirements scenario, DMRS ports can be allocated as per mapping type B and the like.

[0008] An example embodiment of a method according to the present disclosure aims to achieve the following: update / modify DMRS-downlink and DMRS-uplink configuration per cell (i.e., type 1 or type 2, type A or type B, and single or double symbol, additional DMRS etc.) at near-real time.

[0009] Towards achieving the goal, this disclosure utilizes the Near-Real-Time RAN Intelligent Controller (Near-RT RIC] and the Service Management Orchestration(SMO] / Non-Real-Time RAN Intelligent Controller (Non-RT RIC] Framework of 0-RAN ecosystem.

[0010] Specifically, the SMO / Non-RT RIC Framework determines the policy to configure DMRS-downlink and DMRS-uplink and deploy the policy to the Near-RT RIC. After that, by associating LI, L2 information with the policy received from the SMO / Non-RT RIC Framework; the Near-RT RIC configures DMRS-downlink and DMRS-uplink per cell. Furthermore, the updated DMRS configuration can result in a number DMRS ports which is less than the maxMIMO-Layers (maximum number of MIMO layers that can be supported) supported by the cell. In that case, the Near-RT RIC sets the maxMIMO-Layers as the maximum number of DMRS ports supported by the DMRS configuration.

[0011] The goal of the optimization is to maximize the target KPIs under the constraints of configuration choices of DMRS-downlink and DMRS-uplink.

[0012] The AI / ML models can exploit the relations of the channel properties and traffic load with the configuration parameters (e.g., relations between doppler-spread andtime-domain properties, delay-spread and frequency-domain properties, traffic-load and number of ports etc.) towards maximizing the target KPIs.

[0013] The overall procedure (call-flow) is provided in Figure 1. The description of each step in the call-flow is provided in Table 1. An Example of AI / ML training at the SMO / Non-RT RIC Framework to optimize DMRS-downlink and DMRS-uplink Configurations is provided in Figure 2. In this example, Deep-Q Learning-based Reinforcement Learning (DRL) technique is used.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIG. la is a block diagram of a system architecture.

[0015] FIG. lb shows an example of a User Plane Stack.

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

[0017] FIG. 3 shows an example of high-level NG-RAN including a gNB CU and DU.

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

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

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

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

[0022] FIG. 8a shows an example of an 0-RAN architecture.

[0023] FIG. 8b shows a logical flow for an 0-RAN architecture.

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

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

[0026] FIG. 11 shows a procedure for Optimizing DMRS-downlink and DMRS-uplink Configuration

[0027] FIG. 12 shows an example of AI / ML training at the SMO / Non-RT RIC Framework to Optimize DMRS-downlink and DMRS-uplink ConfigurationsDETAILED DESCRIPTION

[0028] In the following sections, overview of Next Generation Radio Access Network [NG-RAN] architecture and 5G New Radio [NR] stacks will be discussed. 5G NR [New Radio] user and control plane functions with monolithic gNB [gNodeB] are shown in FIGS, la, lb and 2. For the user plane [shown in FIG. la, which is in accordance with 3GPP TS 38.300], PHY [physical], MAC [Medium Access Control], RLC [Radio Link Control], PDCP [Packet Data Convergence Protocol] and SDAP [Service Data Adaptation Protocol] sublayers originate in the UE 101 and are terminated in the gNB 102 on the network side.

[0029] As shown in FIG. lb, which is a block diagram illustrating the user plane protocols stacks for a PDU session, in accordance with 3GPP TS 23.501, PDU layer 9010 corresponds to the PDU carried between the UE 101 and the data network [DN] 9011 over the PDU session. As shown in FIG. lb, UE 101 is connected to the 5G access network [AN] 902, which AN 902 is in turn connected via the N3 interface to the Intermediate UPF [I-UPF] 903a portion of the UPF 903, which I-UPF 903a is in turn connected via the N9 interface to the PDU session anchor 903b portion of the UPF 903, and the PDU session anchor 903b is connected to the DN 9011. The PDU session can correspond to IPv4, IPv6, or both types of IP packets, when the PDU session is of type IPv4, IPv6 or IPv4v6, respectively. GTP-U shown in FIG. lb supports tunnelling user plane data over N3 and N9 interfaces and provides encapsulation of end user PDUs for N3 and N9 interfaces.

[0030] For the control plane, as shown in FIG. 2 in accordance with 3GPP TS 38.300, RRC [Radio Resource Control], PDCP, RLC, MAC and PHY sublayers originate in the UE 101and are terminated in the gNB 102 on the network side, and NAS (Non-Access Stratum) originate in the UE 101 and is terminated in the AMF (Access Mobility Function) 103 on the network side.

[0031] NG-Radio Access Network (NG-RAN) architecture from 3GPP TS 38.401 is shown in FIGS. 3-4. As shown in FIG. 3, the NG-RAN 301 comprises of a set of gNBs 302 connected to the 5GC 303 through the NG interface. Each gNB comprises gNB-CU 304 and one or more gNB-DU 305 (see FIG. 3). As shown in FIG. 4, which illustrates separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane), El is the interface between gNB-CU-CP (CU-Control Plane) 304a and gNB-CU-UP (CU-User Plane) 304b, Fl-C is the interface between gNB-CU-CP 304a and gNB-DU 305, and Fl-U is the interface between gNB-CU-UP 304b and gNB-DU 305. As shown in FIG. 4, gNB 302 comprises a gNB-CU-CP 304a, multiple gNB-CU-UPs (or gNB-CU-UP instances) 304b and multiple gNB-DUs (or gNB-DU instances) 305. A gNB-DU 305 is connected to gNB-CU-CP 304a, and gNB-CU-UP 304b is connected to gNB-CU-CP 304a.

[0032] In the example, Fl-AP (Fl-Application Protocol) running on Fl-C is specified in 3GPP TS38.473 version 18.1.0, and NR-U (NR User Plane) running on Fl-U is specified in 3GPP TS38.425 version 18.0.0.

[0033] In this section, an overview of Layer 2 (L2) of 5G NR is provided in connection with FIGS. 5-7. L2 of 5G NR is split into the following sublayers in accordance with 3GPP TS 38.30:

[0034] 1) Medium Access Control (MAC) 501 in FIGS. 5-7: Logical Channels (LCs) are SAPs (Service Access Points) between the MAC and RLC layers. This layer runs a MAC scheduler to schedule radio resources across different LCs (and their associated radio bearers). For the downlink direction, the MAC layer processes and sends RLC PDUs received on LCs to the Physical layer as Transport Blocks (TBs). For the uplink direction, it receives transport blocks (TBs) from the physical layer, processes these and sends them to the RLC layer using the LCs.

[0035] 2] Radio Link Control (RLC) 502 in FIGS. 5-7: The RLC sublayer presents RLC channels to the Packet Data Convergence Protocol (PDCP) sublayer. The RLC sublayer supports three transmission modes: RLC-Transparent Mode (RLC-TM), RLC-Unacknowledged Mode (RLC-UM) and RLC-Acknowledgement Mode (RLC-AM). RLC configuration is per logical channel. It hosts ARQ (Automatic Repeat Request) protocol for RLC-AM mode.

[0036] 3) Packet Data Convergence Protocol (PDCP) 503 in FIGS. 5-7: The PDCP sublayer presents Radio Bearers (RBs) to the SDAP sublayer. There are two types of Radio Bearers: Data Radio Bearers (DRBs) for data and Signaling Radio Bearers (SRBs) for control plane.

[0037] 4) Service Data Adaptation Protocol (SDAP) 504 in FIGS. 5-7: The SDAP maps QoS flows in a PDU session to a specific Data Radio Bearer.

[0038] FIG. 5 is a block diagram illustrating DL L2 structure, in accordance with 3GPP TS 38.300. FIG. 6 is a block diagram illustrating UL L2 structure, in accordance with 3GPP TS 38.300. FIG. 7 is a block diagram illustrating L2 data flow example, in accordance with 3GPP TS 38.300 (in FIG.7, H denotes headers or sub-headers).

[0039] Open Radio Access Network (0-RAN) is based on disaggregated components which are connected through open and standardized interfaces based on 3GPP NG-RAN. An overview of O-RAN with disaggregated RAN CU (Centralized Unit), DU (Distributed Unit), and RU (Radio Unit), Near-RT Radio Intelligent Controller (RIC) and non-real-time RIC is illustrated in FIG.8a.

[0040] As shown in FIG.8a, the CU (shown split as O-CU-CP 801a and O-CU-UP 801b) and the DU (shown as O-DU 802) are connected using the Fl interface (with Fl-C for control plane and Fl-U for user plane traffic) over a mid-haul (MH) path. One DU can host multiple cells (e.g., one DU can host 24 cells) and each cell can support many users. For example, one cell can support 800 Radio Resource Control (RRC) -connected users and out of these 800, there can be 250 Active users (i.e., users that have data to send at a given point of time).

[0041] A cell site can comprise multiple sectors, and each sector can support multiple cells. For example, one site can comprise three sectors and each sector can support eight cells (with each cell being on a different frequency band in a given sector). One CU-CP (CU-Control Plane) can support multiple DUs and thus multiple cells. For example, a CU-CP can support 500 cells and around 100,000 User Equipment (UEs). Each UE can support multiple Data Radio Bearers (DRBs) and there can be multiple instances of CU-UP (CU-User Plane) to serve these DRBs. For example, each UE can support 4 DRBs, and 400,000 DRBs (corresponding to 100,000 UEs) can be served by five CU-UP instances (and one CU-CP instance).

[0042] The DU can be located in a private data center, or it can be located at a cellsite. The CU can also be in a private data center or even hosted on a public cloud system. The DU and CU, which are typically located at different physical locations, can be tens of kilometers apart. The CU communicates with a 5G core system, which can also be hosted in the same public cloud system (or can be hosted by a different cloud provider). A RU (Radio Unit) (shown as O-RU 803 in FIG. 8a?) is located at a cell-site and communicates with the DU via a front-haul (FH) interface.

[0043] The E2 nodes (CU and DU) are connected to the Near-RT RIC 132 using the E2 interface. The E2 interface is used to send data (e.g., user and / or cell KPMs) from the RAN, and deploy control actions and policies to the RAN at Near-RT RIC 132. The applications or services at the Near-RT RIC 132 that deploys the control actions and policies to the RAN are called xApps. During the E2 setup procedures, the E2 node advertises the metrics it can expose, and an xApp in the near-RT RIC can send a subscription message specifying key performance metrics which are of interest. The Near-RT RIC 132 is connected to the non-real-time RIC 133 (which is shown as part of Service Management and Orchestration (SMO) Framework 805 in FIG. 8a?) using the Al interface. The applications that are hosted at non-RT-RIC are called rApps. Also shown in FIG. 8a? are O-eNB 806 (which is shown as being connected to the Near-RT RIC 132 and the SMO Framework 805) and O-Cloud 804 (which is shown as being connected to the SMO Framework 805).

[0044] As in FIG. 8b, E2 node (which is DU or CU) and Near-RT-RIC establish E2 session using E2 SETUP REQUEST and E2 SETUP RESPONSE. Near-RT-RIC can subscribe to certain parameters from the E2 node (on behalf the xApp running at Near-RT-RIC) using the RIC SUBSCRIPTION REQUEST and E2 node acknowledges this message by sending RIC SUBSCRIPTION RESPONSE to the Near-RT-RIC. As part of this, xApp running at the Near-RT-RIC also provides the event triggers to E2 node, e.g. it can ask E2 node to REPORT subscribed parameters periodically to the xApp or to REPORT these subscribed parameters based on certain events to the xApp. E2 node communicates subscribed parameters to Near-RT-RIC (and the xApp) using RIC INDICATION as shown in FIG. 8b. After analyzing received parameters from the E2 nodes (and based on network operator policies), Near-RT-RIC can send RIC CONTROL REQUEST to take an action at the E2 node (e.g. influence mobility decision). E2 node acknowledges this message by sending RIC CONTROL ACKNOWLEDGE to Near-RT-RIC while E2 node takes action as asked by the Near-RT-RIC.

[0045] In this section, PDU sessions, DRBs, and Quality of Service (QoS) flows EW are described. In 5G networks, PDU connectivity service is a service that provides exchange of PDUs between a UE and a Data Network (DN) identified by a Data Network Name (DNN). The PDU Connectivity service is supported via PDU sessions that are established upon request from the UE. The DNN defines the interface to a specific external data network. One or more QoS flows can be supported in a PDU session. Packets belonging to a specific QoS flow have the same 5QI (5G QoS Identifier). A PDU session includes the following: Data Radio Bearers which are between UE and CU in RAN; and an NG-U GTP tunnel which is between CU and UPF (User Plane Function) in the core network. FIG. 9 illustrates an example PDU session (in accordance with 3GPP TS 23.501) comprising multiple DRBs, where each DRB can include multiple QoS flows. In FIG. 9, three components are shown for the PDU session 901: UE 101; access network (AN) 902; and UPF 903, which includes Packet Detection Rules (PDRs) 9031.

[0046] A 3GPP 5G network architecture is illustrated in FIG. 9. In the context of multiple PDU sessions involving multiple DRBs and QoS Flow Identifiers (QFIs), which PDU sessions are implemented involving UE 101, gNodeB 102, UPF 903, and DNNs 9011a and9011b) and FIG. 10 (in the context of Radio Resource Management (RRM) for connecting UE 101 to the network via RU 306 with a MAC Scheduler 1001):

[0047] 1) The transport connection between the base station (i.e., CU-UP 304b of FIG.9) and the UPF 903 uses a single GTP-U tunnel per PDU session, as shown in FIGS.9 and 10. The PDU session is identified using GTP-U TEID (Tunnel Endpoint Identifier).

[0048] 2) The transport connection between the DU 305 and the CU-UP 304b of FIG.10 uses a single GTP-U tunnel per DRB (see also FIG.9). The DU is provided with an UL GTP-U TEID and the CU is provided with the corresponding DL GTP-U TEID to allow for data communication for that DRB between DU and CU-UP.

[0049] 3) SDAP:

[0050] a) The SDAP (Service Adaptation Protocol) 504 Layer receives downlink data from the UPF 903 across the NG-U interface (see FIG. 10).

[0051] b) The SDAP 504 maps one or more QoS Flow(s) onto a specific DRB.

[0052] c) The SDAP header is present between the UE 101 and the CU (when reflective QoS is enabled) and includes a field to identify the QoS flow within a specific PDU session.

[0053] 4) GTP-U protocol includes a field to identify the QoS flow and is present between CU and UPF 903 (in the core network).

[0054] 5) One (logical) DU (or REC) queue exists per DRB (or per logical channel) for RLC PDUs that are to be transmitted for the first time, as shown in FIG. 10. Separate logical queues can exist in DU for packets that are to be retransmitted to UE.

[0055] In this section, basic structures and characteristics of neural networks will be discussed. Recurrent neural networks (RNNs) are a family of neural networks that are suited for handling sequential data. RNNs use a hidden state associated with each time-step and the output at each time step is computed using the input and the previous hidden state.

[0056] RNN architectures suffer from some limitations. First, RNNs fail to store information for a long period of time and thus do not handle the situations well in which a reference to certain information stored quite a long time ago is used to predict the current output. Second, there is no fine control to select which part of the context needs to be carried forward and or can be "forgotten”. Also, in RNNs, gradients in early layers are computed as the product of terms from later layers. With this, gradients in early layers can grow exponentially large (e.g. if the terms in later layers are large enough) or can exponentially decrease [e.g. if terms in later layers are small).

[0057] Long Short-Term Memory (LSTM) networks, which are an extension of recurrent neural networks (RNNs), have been introduced to handle situations where RNNs do not work well. The basic difference between the architectures of RNNs and LSTMs is that the hidden layer of LSTM is a gated unit or a gated cell, which has four layers that interact with one another in a way to produce the output of that cell along with the cell state. The output and the cell state are then passed onto the next hidden layer. Unlike RNNs which have only a single neural net layer of tanh (hyperbolic tangent), LSTMs comprise three logistic sigmoid gates and one tanh layer. It will be noted that output of sigmoid activation function is in the range (0 to 1) for any real value as input, while the output of tanh is in the range (-1 to 1).

[0058] Gates are provided in LSTM in order to limit the information that is passed through the cell, i.e., the gates determine which part of the information will be needed by the next cell and which part is to be discarded. The output is usually in the range of 0 to 1, where "0” means "reject all", and "1” means "include all”. Information is retained by the cells, and the memory manipulations are done by the gates. Three gates are provided in LSTM: 1) forget gate; 2) input gate; and 3) output gate.

[0059] In this section, basic working on Deep Neural Networks (DNNs) such as MLP (Multi-Layer Perceptron) with higher number of hidden layers is briefly described. DNNs train the model to learn the dependencies between the target and the independent variables from a dataset. These architectures have three types of layers: input layer, hiddenlayers and output layer. DNNs can map nonlinear input to output by extracting subtle patterns and multiple features from a dataset through each layer.

[0060] The input layer processes the input data and passes it to the hidden layer. Each hidden layer processes the output from the previous layer and passes it to the next layer. Activation functions such as ReLU, sigmoid and tanh are used. The output layer produces the DNN result. Weights used in the DNN architecture are usually updated using gradient descent process where the gradient indicates how the weights can change in order to reduce the error or loss (i.e. the gap between the output produced by the DNN model based on its current outputs and the correct output]. The training process is repeated iteratively to continuously reduce the overall error (or loss] until the error (or loss] is below a predefined threshold. Once a DNN is trained, it can compute the output of the network using the weights derived during the training process.

[0061] In a wireless network environment, channel conditions can vary depending on many factors such as atmospheric conditions, multi-path propagation, and mobility. So, mere interpolation of channel estimates will not promise optimal performance.

[0062] Also, traffic conditions vary for services like video streaming, live streaming and the like.

[0063] AI / ML techniques (such as deep neural networks] can be used to predict channel state information (CSI]. 3GPP TR38.843 version 18.0.0 considers some such methods.

[0064] An example embodiment of the method according to the present disclosure aims to optimize DMRS-downlink and DMRS-uplink configurations by utilizing the SMO / Non-RT RIC and the Near-RT RIC. The overall procedure (call-flow] is provided in FIG. 11. FIG. 11 illustrates an outer-loop optimization process executed at the SMO / Non-RT RIC and an inner-loop control process executed at the Near-RT RIC.

[0065] Data Collection and Pre-Processing

[0066] At block 202, O-RUs collect observation and measurement data and forward the data to the E2-Nodes over the fronthaul (TH) interface.

[0067] At block 203, the E2-Nodes forward the collected observation and measurement data to the Service Management and Orchestration (SMO) framework over the 01 interface.

[0068] At block 204, the E2-Nodes report Layer-1 and Layer-2 information, including traffic load, uplink Doppler spread, and CSI feedback for individual UEs, to the Near-RT RIC over the E2 interface.

[0069] At block 205, the Near-RT RIC performs local data processing on the received LI and L2 information.

[0070] At block 206, the Near-RT RIC sends aggregated and processed UE-level data to the SMO over the 01 interface.

[0071] At block 207, the operator provides performance KPI targets to the SMO.

[0072] At block 208, the SMO performs data pre-processing and generates AI / ML training data based on the collected measurements, processed UE-level data, and KPI targets.

[0073] AI / ML Training

[0074] At block 209, the SMO sends the AI / ML training data to the Non-RT RIC rApps over the R1 interface.

[0075] At block 210, the rApps perform Al / ML model training using the received training data.

[0076] Model Deployment

[0077] At block 211, the rApps send a request to the SMO over the R1 interface to deploy the trained AI / ML model.

[0078] At block 212, the SMO deploys the resulting policy to the Near-RT RIC over the 01 and / or 02 interface to configure DMRS parameters.

[0079] E2 Control and Policy Enforcement

[0080] At block 213, the E2-Nodes continue to report Layer-1 and Layer-2 information, including traffic load, uplink Doppler spread, and CSI feedback for individual UEs, to the Near-RT RIC over the E2 interface.

[0081] At block 214, the Near-RT RIC performs policy mapping by associating the received L1 / L2 information with the DMRS configuration policy.

[0082] At block 215, the Near-RT RIC deploys DMRS control actions to the E2-Nodes over the E2 interface, including (i) DMRS-downlink configuration and maximum MIMO layers for downlink, and (ii) DMRS-uplink configuration and maximum MIMO layers for uplink.

[0083] At block 216, the E2-Nodes forward the updated configuration parameters to the O-RUs over the fronthaul interface.

[0084] ML Agent Performance Monitoring and Fallback Handling

[0085] At block 217, the O-RUs continue collecting operational data and report the data to the E2-Nodes over the fronthaul interface.

[0086] At block 218, the E2-Nodes send KPIs, measurement reports, and observations to the SMO over the 01 interface.

[0087] At block 219, the SMO forwards performance data to the Non-RT RIC rApps.

[0088] At block 220, the rApps evaluate the performance of the deployed AI / ML model.

[0089] At block 221, if performance indicator degradation is detected, the rApps send a default or fallback DMRS configuration to the SMO over the R1 interface.

[0090] At block 222, the SMO forwards the default or fallback DMRS configuration to the E2 -Nodes over the 01 interface.

[0091] At block 223, the SMO sends a model retraining and update request to the rApps over the R1 interface.

[0092] At block 224, the rApps trigger AI / ML model retraining.

[0093] The description of each step above in the call-flow is provided in Table 1.Block DetailsGoal Optimizes DMRS-downlink and DMRS-uplink configurationsSMO / Non-RT RIC Framework and / or Near-RT RIC perform data evaluation, Begins when determines that DMRS configuration optimization is initiated or updated and establishes target(s).(Start of Outer loop control}Block 201- 202 (M) SMO / Non-RT RIC Framework collects the necessary configurations, performance indicators, and measurement reports from E2 Nodes and O-RUs via 01 interface. Near-RT RIC collects LI, L2 information such as traffic load, doppler spread of Bloc 203 (M) uplink channel, CSI-feedback of individual UE from E2 node periodically or event- triggered.Step 204- Near RT RIC processes, aggregates and reports the data over 01 interface to the 205(M) SMO / Non-RT RIC Framework.Step 206(M) SMO / Non-RT RIC Framework collects the target KPIs data.Step 207- SMO / Non-RT RIC Framework pre-processes the data to feed into the rApp. 208(M)Step 209 (M) rApp trains AI / ML modelStep 210- SMO / Non-RT RIC Framework deploys the policies to Near-RT RIC via 01 / 02 11(M) interface(Start of Inner loop control)Step 212- 13(M) E2 Nodes report LI, L2 information such as doppler spread of uplink channel and traffic load of individual UE to Near-RT RIC. By associating the LI, L2 informationwith the policies received from the SMO / Non-RT RIC Framework, the Near-RTRIC configures the DMRS-downlink, DMRS-uplink per cell and the maxMIMO- Layers for UL and DL.Near-RT RIC writes / updates DMRS-downlink, DMRS-uplink configurations and Step 214- the maxMIMO-Layers for UL and DL to E2 nodes via E2 interface.15(M)Step 12 to Step 15 can repeat. (End of Inner loop control)rApps continuously monitors KPIs in respective cells. In case of unsatisfactory performance, it initiates fallback and requests Al / ML model retraining / update. Step 216- Then, rApp retrains / updates the respective AI / ML modelfs].223(M]Step 1 to Step 23 can repeat. (End of Outer loop control)Non-RT RIC decides to delete the DMRS configurations optimization Al / ML model Ends when and sends the related message or following internal trigger, the Near-RT RIC terminates the DMRS configurations inference procedure.Exceptions NonePost Non-RT RIC continues to collect and monitor the DMRS optimization related Conditions measurement data from E2 Node.Table 1: Description of the Procedure for Optimizing the configurations of DMRS- downlinkand DMRS-uplink.

[0094] An example embodiment of the proposed scheme has primarily three steps: Data-Collection, Training / Optimization and Deployment.

[0095] Data-Collection:

[0096] The SMO / Non-RT RIC Framework collects the configuration [CM] parameters (such as, supported configurations of DMRS-downlink, DMRS-uplink, maxMIMO-Layers per cell), key performance indicators (KPI) (such as, integrity and latency KPIs, DL / UL throughput / spectral efficiency per cell) from the E2 nodes (O-CU-CP, O-CU-UP, 0-DU, O-eNB) via 01 interface. In addition, the SMO / Non-RT RIC Framework also collects the service level assurance such as, KPI targets from the operator.

[0097] The Near-RT RIC subscribes and retrieves LI, L2 information such as traffic load, doppler spread of uplink channel, CSI-feedback etc. of each UE over the E2 interfacefrom the E2 nodes. After that, the Near-RT RIC processes, aggregates and reports the UE-level data over 01 interface to the SMO / Non-RT RIC Framework.

[0098] Note that the doppler spread of UL channel can be easily obtained from the PUSCH channel. However, the doppler spread of DL channel is not readily available. In 3GPP Rel 17, there is no provision for UEs reporting doppler spread of the downlink channel to gNB. In future releases, new UE-capability can be introduced to report doppler spread or, Time Domain Correlation Profile (TDCP) of downlink channel to gNB to assist the high mobility scenarios. However, instead of relying on the UE capability, a method for measuring doppler spread from the CSI-feedback can be designed as follows.

[0099] CSI-feedback contains PMI (in the case of closed-loop MIMO transmission mode) or P2-beam RSRP (which helps to determine P2-beam index) or partial channel feedback (in the case of open-loop MIMO transmission mode, which is available as channel matrix, or its corresponding Eigen vectors of the channel between the E2 node and the UE). Let us consider the Precoding Matrix corresponding to the strongest layer (or beamforming weight of the P2-beam producing highest RSRP; or channel matrix or strongest eigen vector of the channel) at frequency fat time t is W(f,t). Then, the TDCP can be computed from a pair of time-stamped CSI-feedback as follows:[ooioo] c^t= i w(f, tj. w(f, t2y

[0101] The doppler spread can be computed from the second order derivative of TDCP as-|Cor7-"(At=0)|

[00102] faoppier = ~ where At = t2- tr.

[0103] To improve the estimation, multiple pairs of time-stamped CSI-feedback can be considered and the estimated TDCP from the multiple pairs can be averaged.

[0104] Model Training / Optimization:

[0105] The SMO / Non-RT RIC Framework allows rApp to receive the CMs, and KPIs measurement data (collected via 01) to determine the configurations of DMRS-downlink and DMRS-uplink such that the desired KPIs are maximized.

[0106] The optimization problem can be formulated as follows. Lets denotes the set of cells considered for the optimization. Cell s, s E S, supports a set of configurations for DMRS-downlink as Dsand a set of configurations for DMRS-uplink transmission Us. Let xsdG {0,1}, d 6 Ds, s G S, be a binary decision variable indicating whether the DMRS-downlink configuration d is selected for cell s. LetySMG {0,1}, u G Us, s G S, be a binary decision variable indicating whether the DMRS-uplink configuration u is selected for cell s. Let Ks, s E S, denotes the set of RRC_connected UEs in cell s. Here, is used to denote the variable is stochastic. For a selection of xsd, ysu), let the KPI achieved at UE k, k E Ks, s E S, is tjj(xsd,ysuj. Let Ts, s E S, denotes the KPI target of cell s. Then, a stochastic optimization problem can be formulated as:

[0107] maximize EsesS keKs1<ltk(xsdjysll)> Ts}I deDs,ueus,ses Jsubject to-.xsdG {0, 1}, v d G Ds, vs E S (2)ysuE {0, 1}, V u E Us, s G S (3)

[0108] The objective function (1) represents the sum of the number of UEs achieving KPI targets across the set of cells S. Here, 1{ j is an indicator function which equals one if the condition inside the brackets { } is satisfied and it equals zero otherwise. Constraints (2) and (3) ensure that the selected configurations of DMRS-downlink and DMRS-uplink are supported by the individual cells.

[0109] Various approaches can be taken to solve the optimization problem. Here, an approach based on Deep-Q-Learning-based Reinforcement Learning [DRL] is described. In the DRL, the action is: select a tuple of < raffic load, doppler spread and DMRS configuration> from the pool of choices (e.g., traffic load = 50%, doppler spread = 10 Hz,DMRS configuration = Type 1 single symbol DMRS without any additional DMRS], The state is the indicators of UEs achieving the KPIs (a vector of 1 / Os]. The reward is the fraction of UEs achieving the KPIs.

[0110] Online training of a DRL can be costly in terms of performance and complexity. Taking this into consideration, an offline training procedure is described in FIG.12, which uses a simulation environment 402 (such as Digital Twin]. In this procedure a DRL Agent takes an action based on e-greedy policy i.e., with probability e, it tries a random action, and with probability (1 — e), the agent selects the best known action so far. Now, in the simulation environment, at block 402 at every n TTIs, DMRS configuration is determined by associating LI, L2 information (such as traffic load, CSI-RSRP and doppler spread etc.] with the policy set by the DRL Agent at block 401. Here, n is configurable proprietary Near-real time periodicity. Simulation can be run for N TTIs (N»n]. The recommended value of N is 2000 and n is 5. At the end of the simulation, at block 403 state and reward are collected from the simulation environment and feed into DRL Agent 404. DRL Agent’s goal is to maximize the cumulative discounted future reward. The agent gathers its experiences as tuples, (st, at, rt, st+1), where stdenotes current UE KPI achieving state (1 / 0]; atdenotes the action taken at state st; rtis the instantaneous reward obtained from state stand by taking action at; and st+1is the next state. The agent stores history of its experiences in a memory called experience replay memory, and replay memory stores the tuples, (st, at, rt, st+1), for all time steps. The DRL agent randomly samples mini-batches of experience from the replay memory for training, and selects an action based on e-greedy policy. The optimum action in a particular state is selected based on maximum Q-values corresponding to that state. The Q-values are predicted using deep neural network. Input to the neural network is the UEs’ KPI-achieving (1 / 0] vector representing the state of the RL environment, and output is the Q-values corresponding to all the possible actions. In this way, the offline training is performed.

[0111] Deployment:

[0112] After the training is completed, the rApps writes / updates the policy for DMRS-downlink and DMRS-uplink configuration to the SMO / Non-RT RIC Framework viaRl. Subsequently, the SMO / Non-RT RIC Framework deploys the policies for DMRS-downlink and DMRS-uplink configurations to the Near-RT RIC via 01 / 02 interface.

[0113] After that, the Near-RT RIC configures DMRS-downlink and DMRS-uplink per cell by associating traffic-load and doppler-spread with the policy received from the SMO / Non-RT RIC Framework. Furthermore, the updated DMRS configuration can result into a number DMRS ports which is less than the maxMIMO-Layers (maximum number of MIMO layers that can be supported) supported by the cell. In that case, the Near-RT RIC sets the maxMIMO-Layers as the maximum number of DMRS ports supported by the DMRS configuration. Finally, the Near-RT RIC writes / up dates the configurations of DMRS-downlink, DMRS-uplink and the maxMIMO-Layers per cell via E2 interface (to 0-DU).

[0114] Reference is made to Third Generation Partnership Project (3GPP), 0-RAN Alliance and the Internet Engineering Task Force (IETF) and related standards bodies in accordance with embodiments of the present disclosure. The present disclosure employs abbreviations, terms and technology defined in accord with Third Generation Partnership Project (3GPP), 0-RAN Alliance and / or Internet Engineering Task Force (IETF) technology standards and papers, including the following standards and definitions. 3GPP, 0-RAN and IETF technical specifications (TS), standards (including proposed standards), technical reports (TR), RFCs and other papers are incorporated by reference in their entirety hereby, define the related terms and architecture reference models that follow.3GPP TS 23.501 V 18.1.0 2024-06-263GPP TS 38.300 V 18.1.0 4-03-20243GPP TS 38.401 V 18.1.0 2024-03-293GPP TS 38.473 version 18.1.0 2024-03-293GPP TS 38.425 version 18.0.0 2024-01-120-RAN Near-RT-Architecture 6.0, 0-RAN. WG3. RICARCH-R003-v06.00, R003, June 2024O-RAN E2 Service Model (E2SM) KPM 5.0, 0-RAN. WG3. E2SM-KPM-R003-v05.00, R003, June 2024O-RAN E2 Application Protocol (E2AP) 5.0, 0-RAN. WG3. E2AP-R003-v05.00, R003, February 2024O-RAN Al Interface: Application Protocol 4.02, 0-RAN. WG2. A1AP v04.02, R003, June 2024

[0115] A list of abbreviations used in the present specification is provided below:5GC: 5G Core Network5G NR: 5G New Radio5QI: 5G QoS IdentifierACK: AcknowledgementAl: Artificial IntelligenceAl / ML: Artificial Intelligence and Machine LearningAM: Acknowledged ModeAPN: Access Point NameARP: Allocation and Retention PriorityBO: Buffer OccupancyBS: Base StationBSR: Buffer Status ReportCNN: Convolution Neural NetworkCP: Control PlaneCSI: Channel State InformationCQI: Channel Quality IndicatorCU: Centralized UnitCU-CP: Centralized Unit - Control PlaneCU-UP: Centralized Unit - User PlaneDL: DownlinkDDDS: DL Data Delivery StatusDNN: Data Network NameDNN: Deep Neural NetworkDQN: Deep Q NetworkDRB: Data Radio BearerDU: Distributed UniteNB: evolved NodeBEPC: Evolved Packet CoreEN-DC: E-UTRAN New Radio Dual Connectivity GBR: Guaranteed Bit RategNB: gNodeBGTP-U: GPRS Tunnelling Protocol - User PlaneIP: Internet ProtocolL1: Layer 1L2: Layer 2L3: Layer 3L4S: Low Latency, Low Loss and Scalable Throughput LC: Logical ChannelLESS: Low Energy Scheduler SolutionLSTM: Long Short-Term MemoryMAC: Medium Access ControlMDP: Markov Decision ProcessMIB: Master Information BlockML: Machine LearningMR-DC: Multi-RAT Dual ConnectivityNACK: Negative AcknowledgementNAS: Non-Access StratumNG-RAN: Next Generation Radio Access Network NR-U: New Radio - User PlaneNSI: Network Slice InstanceNSSI: Network Slice Subnet Instance NWDAF: Network Data Analytics FunctionO-RAN: Open Radio Access NetworkOAM: Operations, Administration Maintenance PDB: Packet Delay BudgetPDCP: Packet Data Convergence Protocol PDU: Protocol Data UnitPER: Packet Error RatePF: Proportional FairPHY: Physical LayerPRB: Physical Resource BlockQCI: QoS Class IdentifierQFI: QoS Flow IdentifierQoS: Quality of ServiceRAN: Radio Access NetworkRAT: Radio Access TechnologyRB: Resource BlockRDI: Reflective QoS Flow to DRB IndicationRL: Reinforcement LearningRLC: Radio Link ControlRLC-AM: RLC Acknowledged ModeRLC-UM: RLC Unacknowledged ModeRNN: Recurrent Neural NetworksRQI: Reflective QoS IndicationRRC: Radio Resource ControlRRM: Radio Resource ManagementRTP: Real-Time Transport ProtocolRTCP: Real-Time Transport Control Protocol RU: Radio UnitSCTP: Stream Control Transmission Protocol SD: Slice DifferentiatorSDAP: Service Data Adaptation ProtocolSIB: System Information BlockSLA: Service Level AgreementS-NSSAI: Single Network Slice Selection Assistance SST: Slice / Service TypeTB: Transport BlockTCP: Transmission Control ProtocolTEID: Tunnel Endpoint IdentifierTTI: Transmission Time IntervalUE: User EquipmentUP: User PlaneUL: UplinkUM: Unacknowledged ModeUPF: User Plane Function

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

Claims

CLAIMS1. A radio access network control system comprising:a management controller configured to collect network data and determine policies for demodulation reference signal (DMRS) configuration for downlink and uplink; and a real-time controller configured to receive the policies, process information from network nodes, and dynamically update DMRS configurations for each cell in accordance with the policies and processed information.

2. The system of claim 1, wherein the management controller is further configured to train artificial intelligence or machine learning models using the collected network data.

3. The system of claim 2, wherein the artificial intelligence or machine learning models comprise a deep Q-learning reinforcement learning model.

4. The system of claim 3, wherein the deep Q-learning reinforcement learning model is trained offline using a simulation environment that simulates network conditions over a configurable number of transmission time intervals.

5. The system of claim 1, wherein the management controller is configured to deploy the policies to the real-time controller.

6. The system of claim 1, wherein the real-time controller is configured to process Layer-1 and Layer-2 information from network nodes.

7. The system of claim 6, wherein the Layer-1 and Layer-2 information includes traffic load and Doppler spread.

8. The system of claim 1, wherein the real-time controller is configured to instruct network nodes to apply the selected DMRS configurations.

9. The system of claim 1, wherein the real-time controller is configured to dynamically update DMRS configurations in response to changes in the processed information.

10. The system of claim 1, wherein the management controller is configured to collect performance indicator targets from an operator.

11. The system of claim 1, wherein the management controller is configured to collect configuration parameters and KPI measurement data from network nodes.

12. The system of claim 1, wherein the real-time controller sets the maximum number of MIMO layers for the cell equal to the number of supported DMRS ports when a selected DMRS configuration supports fewer DMRS ports than a maximum number of MIMO layers of a cell.

13. The system of claim 1, wherein the management controller is configured to pre-process collected data to generate training data for artificial intelligence or machine learning models.

14. The system of claim 1, wherein the management controller is configured to deploy policies for DMRS configuration to the real-time controller via a network interface.

15. The system of claim 1, wherein the real-time controller is configured to compute a time-domain correlation profile from channel state information feedback, wherein the time-domain correlation profile is computed as:=^2^1 W^i) •where W(f, t)is a precoding matrix or channel feedback at frequency f and time t, and Nis the number of frequency bins.

16. The system of claim 1, wherein the real-time controller is configured to derive a Doppler spread from the time-domain correlation profile, wherein the Doppler spread is computed as:fdoppler =^-Corr^M = 0) «where At = t2— t17. The system of claim 1, wherein the management controller is configured to formulate an optimization problem for DMRS configuration selection, wherein the objective function is:maximize{xsd, ysu} hs / < (XsdWsu ) > A }'where xsdand ysuare binary decision variables for DMRS-downlink and DMRS-uplink configuration selection, Sis a set of cells, Ksis a set of UEs in cell s, and Tsis a KPI target.

18. A method for optimizing DMRS configuration in a radio access network, comprising:collecting network data;determining policies for DMRS configuration for downlink and uplink based on the network data;deploying the policies to a real-time controller; processing information from network nodes; anddynamically updating DMRS configurations for each cell in accordance with the policies and processed information.

19. The method of claim 18, further comprising computing a time-domain correlation profile from channel state information feedback, wherein the time-domain correlation profile is computed as:^= ^=1WA) -where W(f, t)is a precoding matrix or channel feedback at frequency f and time t, and Nis the number of frequency bins.

20. The method of claim 18, further comprising deriving a Doppler spread from the time-domain correlation profile, wherein the Doppler spread is computed as:•jl—Corrt fdoppler y / COTTf (At O')where At = t2— tr

Images