Optimizing enforcement of UE aggregate maximum bit rate (AMBR) in network slicing environment in o-ran networks

Abstract

A method of optimization of User Equipment (UE) Aggregate Maximum Bit Rate (AMBR) enforcement in network slicing environment in an Open Radio Access Network (O-RAN) where there is one Control Unit-Control Plane (CU-CP) and multiple Control Unit-User Planes (CU-UPs) and a 5G SA UE supports different slices and traffic for each slice can be sent via different CU-UPs, the method including: obtaining by a DL-UE-AMBR module a measured data rate for DL data from the CU-UPs; and providing control messages to the CU-UPs based on measured DL data and aggregated DL data between the CU-UPs.

Description

Optimizing Enforcement of UE Aggregate Maximum Bit Rate (AMBR) in Network Slicing Environment in O-RAN NetworksBACKGROUND1. Field of the Disclosure

[0001] The present disclosure is related to Open Radio Access Network (O-RAN) wireless networks and relates more particularly to optimization of User Equipment (UE) Aggregate Maximum Bit Rate (AMBR) enforcement in network slicing environment in O-RAN networks.2. Description of Related Art

[0002] An overview of Next Generation Radio Access Network (NG-RAN) architecture and 5G New Radio (NR) stacks is presented below. 5G NR (New Radio) user and control plane functions with monolithic gNodeB (gNB) are shown in FIGS. 1 A, IB and 2. For the user plane (shown in FIG. 1A, which is in accordance with 3GPP TS 38.300), Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP) and Service Data Adaptation Protocol (SDAP) are sublayers that originate in the UE 101 and are terminated in the gNB 102 on the network side.

[0003] As shown in FIG. IB, which is a block diagram illustrating the user plane protocols stacks for a Protocol Data Unit (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. IB, 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 which 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. IB supports tunnelling user plane data over N3 and N9 interfaces and provides encapsulation of end user PDUs for N3 and N9 interfaces.

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

[0005] NG-Radio Access Network (NG-RAN) architecture from 3GPP TS 38.401 is shown in FIGS. 3 and 4. As shown in FIG. 3, the NG-RAN 301 comprises 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 (FIG. 3). As shown in FIG. 4, which illustrates separation of Control Unit-Control Plane (CU-CP) and Control Unit-User Plane (CU-UP), El is the interface between gNB-CU-CP 304a and gNB-CU-UP 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 may comprise a gNB-CU-CP 304a, multiple gNB-CU-UPs (or gNB-CU-UP instances) 304b and multiple gNB-DUs (or gNB-DU instances) 305. One gNB-DU 305 is connected to only one gNB-CU-CP 304a, and one gNB-CU-UP 304b is connected to only one gNB-CU-CP 304a.

[0006] An overview of Layer 2 (L2) of 5G NR is provided in connection with FIG. 5. L2 of 5G NR is split into the following sublayers (in accordance with 3GPP TS 38.300):

[0007] 1) MAC 501 in FIG. 5: Logical Channels (LCs) are Service Access Points (SAPs) 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 PHY as Transport Blocks (TBs). For the uplink direction, it receives TBs from the PHY, processes these and sends to the RLC layer using the LCs.

[0008] 2) RLC 502 in FIG. 5: The RLC sublayer presents RLC channels to the PDCP sublayer. The RLC sublayer supports three transmission modes: RLC-Transparent Mode (RLC-TM), RLC-Unacknowledged Mode (RLC -UM) and RLC-Acknowledgement Mode (RLC-AM). RLC configuration is per logical channel. It hosts Automatic Repeat Request (ARQ) protocol for RLC-AM mode.

[0009] 3) PDCP 503 in FIG. 5: 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 the control plane.

[0010] 4) SDAP 504 in FIG. 5: The SDAP maps (Quality of Service) QoS flows within a PDU session to a specific Data Radio Bearer.

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

[0012] As shown in FIG. 6, 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 could host 24 cells) and each cell may support many users. In one example, one cell may support 800 Radio Resource Control (RRC)-connected users and out of these 800, there may be subset of 250 Active users (i.e., users that have data to send at a given point of time).

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

[0014] The DU could be in a private data center, or it could be located at a cell-site. The CU could 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, could be located many kilometers from each other. The CU communicates with a 5G core system, which could also be hosted in the same public cloud system (or could be hosted by a different cloud provider). A RU (shownas O-RU 803 in FIG. 6) is located at a cell-site and communicates with the DU via a front-haul (FH) interface.

[0015] The E2 nodes (CU and DU) are connected to the near-real-time 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-real-time RIC 132. The applications or services at the near-real-time 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-real-time 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. 6 using the Al interface. The applications that are hosted at non-RT- RIC are called rApps. Also shown in FIG. 6 are Open evolved Node B (O-eNB) 806, which is shown as being connected to the near-real-time RIC 132 and the SMO Framework 805 and O- Cloud 804, which is shown as being connected to the SMO Framework 805.

[0016] PDU sessions, DRBs, and Quality of Service (QoS) flows will now be discussed. 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 Connecitivity 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. All the packets belonging to a specific QoS flow have the same 5G QoS Identifier (5QI). A PDU session comprises the following: Data Radio Bearers that are between UE and CU in RAN; and an NG-U GTP tunnel that is between CU and User Plane Function (UPF) in the core network. FIG. 7 illustrates an example PDU session (in accordance with 3GPP TS 23.501) comprising multiple DRBs, where each DRB may comprise multiple QoS flows. In FIG. 7, three components are shown for the PDU session 901: UE 101; AN 902; and UPF 903, which includes Packet Detection Rules (PDRs) 9031.

[0017] The following should be noted for 3GPP 5G network architecture, which is illustrated in FIG. 8 (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, UPF903, and DNNs 901 la and 901 lb) and FIG. 9 (in the context of Radio Resource Management (RRM) for connecting UE 101 to the network viaRU 306 with a MAC Scheduler 1001):

[0018] 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. 8 and 9. The PDU session is identified using GTP-U Tunnel Endpoint Identifier (TEID).

[0019] 2) The transport connection between the DU 305 and the CU-UP 304b of FIG. 9 uses a single GTP-U tunnel per DRB (see also FIG. 8 and 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 the DU and the CU-UP.

[0020] 3) Service Adaptation Protocol (SDAP): a) The SDAP 504 Layer receives downlink data from the UPF 903 across the NG- U interface (see FIG. 9). b) The SDAP 504 maps one or more QoS Flow(s) onto a specific DRB. 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.

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

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

[0023] In this section, standardized 5QI to QoS characteristics mapping will be discussed. As per 3GPP TS 23.501, the one-to-one mapping of standardized 5QI values to 5G QoS characteristics is specified in Table 1. The first column represents the 5QI value. The second column lists the different resource types, i.e., as one of non-Guaranteed Bit Rate (Non-GBR), GBR, Delay- critical GBR. The third column (“Default Priority Level”) represents the priority levelTable 1Priority5QI, for which lower the value the higher the priority of the corresponding QoS flow.The fourth column represents the Packet Delay Budget (PDB), which defines an upper bound forthe time that a packet may be delayed between the UE and the N6 termination point at the UPF. The fifth column represents the Packet Error Rate (PER). The sixth column represents the maximum data burst volume for delay -critical GBR types. The seventh column represents an averaging window for GBR, delay critical GBR types. Note that only a subset of 5QI values defined in 3GPP TS 23.501 are shown in Table 1.

[0024] For example, as shown in Table 1, 5QI value 1 is of resource type GBR with the default priority value of 20, PDB of 100ms, PER of 0.01, and averaging window of 2000 ms. Conversational voice falls under this category. Similarly, as shown in Table 1, 5QI value 7 is of resource type non-GBR with the default priority value of 70, PDB of 100ms and PER of 0.001. Voice, video (live streaming), and interactive gaming fall under this category.

[0025] In this section, Radio Resource Management (RRM) is disclosed (a block diagram for an example RRM with a MAC Scheduler is shown in FIG. 9). L2 methods (such as MAC scheduler) play a critical role in allocating radio resources to different UEs in a cellular network.

[0026] FIG. 10A shows CU-UP sending DL User Data (DUD) to DU. FIG. 10B shows flow control feedback from CU-UP to the DU. This is indicated as DL Data Delivery Status (DDDS) in FIG. 10B.

[0027] The DU can send Assistance Information Data (AID) to the CU-UP as shown in FIG. 10C and this provides radio information to CU-UP over the Fl -U interface.

[0028] A network slice is a logical network that provides specific network capabilities and network characteristics, supporting various service properties for network slice customers (e.g., as specified in 3GPP TS 28.500). A network slice divides a physical network infrastructure into multiple virtual networks, each with its own (dedicated or shared) resources and service level agreements. A Single Network Slice Selection Assistance Information (S-NSSAI) identifies a network slice in 5G systems. As per 3GPP TS 23.501, S-NSSAI is comprised of: i) a Slice / Service Type (SST), which refers to the expected Network Slice behavior in terms of features and services; and ii) a Slice Differentiator (SD), which is optional information that complements the Slice / Service type(s) to differentiate amongst multiple Network Slices of the same Slice / Service type.

[0029] The structure of S-NSSAI is shown in FIG. 11 . SST has an 8-bit field, and it may have standardized and / or non-standardized values between 0 and 255. The range of 0 to 127 corresponds to standardized SST range, and the range of 128 to 255 corresponds to operator specific range. 3GPP has standardized some SSTs, e.g., SSTs for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low Latency Communication (URLLC) and Massive Internet of Things (MIoT) slices.

[0030] UE first registers with a 5G cellular network identified by its Public Land Mobile Network Identifier (PLMN ID). The UE knows which S-NSSAIs are allowed in each registration area. It then establishes a PDU session associated with a given S-NSSAI in that network towards a target Data Network (DN), such as the internet. One or more QoS flows could be activated within this PDU session. UE can perform data transfer using a network slice for a given data network using that PDU session. A high-level view of UE establishing a PDU session with a specific DNN is shown in FIG. 12.

[0031] As shown in FIG. 12, as step 1 of establishing a PDU session, UE 101 sends a PDU Session Establishment Request (as referenced by process arrow 1401) to Access Mobility Function (AMF) 103, which PDU Session Establishment Request can include, e.g., PDU session ID, Data Network Name (DNN) and Slice ID. As step 2, the AMF 103 sends a PDU Session Resource Setup Request (as referenced by process arrow 1402) to gNB 102. As step 3, the gNB 102 sends an RRC Reconfiguration message (as referenced by process arrow 1403) to UE 101. As step 4, DRB(s) of the PDU session are established (as referenced by 1404). As step 5, UE 101 sends a RRC Reconfiguration Complete message (as referenced by process arrow 1405) to gNB 102. As step 6, gNB 102 sends a PDU Session Resource Setup Response (as referenced by process arrow 1406) to AMF 103. Subsequently, in step 7, UP data (e.g., including QFI) are exchanged among UE 101, gNB 102 and UPF 903 (as referenced by 1407).

[0032] As described in 3GPP TS 23.501, an NSSAI is a collection of S-NSSAIs. An NSSAI may be a Configured NSSAI, a Requested NSSAI or an Allowed NSSAI. There can be at most eight S-NSSAIs in Allowed and Requested NSSAIs sent in signaling messages between the UE and the Network. The Requested NSSAI signaled by the UE to the network allows the network to select the Serving AMF, Network Slice(s) and Network Slice Instance(s) for this UE. NetworkSlice Instance (NSI) consists of a set of network function instances and the required resources that are deployed to serve the traffic associated with one or more S-NSSAIs.

[0033] UE-Aggregate Maximum Bit Rate (AMBR). UE-AMBR limits the aggregate bit rate that can be expected to be provided across all non-GBR QoS flows for a UE. Uplink (UL) and Downlink (DL) UE-AMBR are specified separately for each UE. UE-AMBR is defined separately for UL and DL direction. For UL traffic for a UE, AMBR is denoted as UL UE- AMBR and for DL traffic for that UE, it is denoted as DL UE-AMBR.

[0034] 5G Standalone (5G SA) networks. Session Management Function (SMF) in the 5GC (i.e. 5G Core) retrieves DL and UL UE-AMBR from Unified Data Management (UDM) and provides this to Access and Mobility Management (AMF) in 5GC. As shown in FIG. 13, the AMF 103 communicates this UE-AMBR to gNB-CU-CP 304a of gNB using Next Generation Application Protocol (NGAP) via NG-C interface.

[0035] For 5G NR base station (i.e., for gNB), gNB-CU-CP 304a communicates DL UE-AMBR to gNB-CU-UP 304b using the El AP protocol as specified in 3GPP TS 37.483 (and as shown in FIG. 13). The Information Element to communicate DL UE-AMBR from gNB-CU-CP 304a to gNB-CU-UP 304b is denoted as id-UEDLAggregateMaximumBitRate in 3GPP TS 37.483.

[0036] For 5G NR base station (i.e., for gNB), gNB-CU-CP 304a communicates UL UL-AMBR to gNB-DU 305 using the F1AP protocol as specified in 3GPP TS 38.473 (and as shown in FIG. 13). The Information Element to communicate UL UE-AMBR from gNB-CU-CP 304a to gNB- DU 305 is denoted as id-GNB-DU-UE-AMBR-UL in 3GPP TS 38.473.

[0037] Session-AMBR. For 5G NR network, Session-AMBR limits the aggregate bit rate that can be expected to be provided across all non-GBR QoS flows for a specific PDU session. It can be defined separately for UL and DL direction. For UL traffic for a session, it is denoted as UL Session-AMBR and for DL traffic for that session, it is denoted as DL Session-AMBR. UL Session-AMBR is enforced by the UE and the UPF for UL traffic while downlink session AMBR is enforced by the UPF for DL traffic. Session AMBR is signalled to the UPF, to the UE and to the base station (i.e. 5G gNodeB). UE is provided UL Session-AMBR from the 5GC (specifically by AMF from the 5G Core Network).

[0038] Session-AMBR and UE-AMBR are not applicable for GBR QoS flows.

[0039] Data Usage report. This procedure is initiated by the gNB-CU-UP to report data volume served at the gNB-CU-UP. gNB-CU-UP will report data usage for each UE at DRB level periodically as requested by gNB-CU-CP. Each per-DRB usage report comprises DL and UL data usage within an interval given by Start time stamp and End time stamp.

[0040] Neural Networks. Basic structures and characteristics of neural networks are now 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.

[0041] RNN architectures suffer from some limitations. First, RNNs fail to store information for a long period of time and thus don’t handle situations well in which a reference to certain information stored quite a long time ago is required 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).

[0042] Long Short-Term Memory (LSTM) networks. LSTM networks are an extension of 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 comprises 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 tan h (hyperbolic tangent), LSTMs comprise three logistic sigmoid gates and one tan h layer. It should 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 tan h is in the range (-1 to 1).

[0043] Gates are provided in LSTM 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 partis 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.

[0044] A problem that currently exists with known systems is that it is not possible to enforce UE AMBR effectively for 5G standalone (and similar) architectures where there is one gNB-CU- CP per 5G SA gNB and there are multiple gNB-CU-UPs (with one or more network slices mapped to each gNB-CU-UP for resource isolation) for the same 5G gNB.

[0045] In this slice-based 5G SA architecture, each session (carrying one or more DRBs) of a 5G SA UE can belong to a different slice and traffic for each slice can be sent via a different gNB- CU-UP to achieve resource isolation. However, in this situation, it is not possible to effectively enforce UE AMBR for 5G standalone architecture with one gNB-CU-CP and multiple gNB-CU- UPs.SUMMARY

[0046] Accordingly, what is needed then is a system and method that allows for effective enforcement of UE AMBR for 5G standalone architecture where there is one gNB-CU-CP and multiple gNB-CU-UPs.

[0047] It is also desired to provide a system and method that allows for effective enforcement of UE AMBR when each session (carrying one or more DRBs) of a 5G SA UE can belong to a different slice and traffic for each slice can be sent via a different gNB-CU-UP to a single DU (and eventually to that 5G SA UE).

[0048] It is further desired to provide a system and method that allows for effective resource isolation where multiple gNB-CU-UPs have one or more network slices mapped to each gNB- CU-UP 304b and that are connected to a single gNB-CU-CP 304a.

[0049] Accordingly, in one configuration a method is provided for optimizing enforcement of UE Aggregate Maximum Bit Rate (AMBR) in a network slicing environment in 0-RAN Networks. As an example, illustrating a major problem with current systems, in oneconfiguration is that a 5G SA UE (UEx) has d number of active sessions (with each session containing one or more DRBs) corresponding to s slices, and these are mapped to c gNB-CU-UP instances. In this case, c is between 1 and s. Also, the number s is less than or equal to the number of sessions (e.g., the number d) for UEx. Thus, 0 < c < s < d.

[0050] FIG. 14 shows an example where there are three DRBs carrying DL data for UEx 101. DRB dl corresponds to session dl, slice si and DL data for this slice si is communicated using gNB-CU-UP cl 304b-l. DRB d2 and DRB d3 correspond to session denoted as d23, associated with slice s2 and the DL data for this slice s2 is communicated using gNB-CU-UP c2 304b-2.

[0051] If DL data for a UE is being communicated via one gNB-CU-UP only, DL UE AMBR can be enforced on that gNB-CU-UP. If DL data for a UE is being sent via multiple gNB-CU- UPs, an efficient method is needed to enforce DL UE AMBR in 0-RAN networks. As previously mentioned, AMBR is the maximum bit rate that an operator can configure for a user for all of their best effort services. In other words, it is a bandwidth limitation applicable to the total accumulated bandwidth for all of the non-GBR bearers a UE has in place (across all PDN connections).

[0052] In Non- Standalone (NSA) Architectures, a 4G eNodeB (eNB) and a 5G base station communicates with 4G EPC (i.e., 4G Evolved Packet Core) on one end and with NSA UE on the other end. In these architectures, 4G and 5G base stations can coordinate with each other and enforce UE AMBR for NSA UE. The method specified here addresses a different problem, namely, enforcing UE AMBR effectively for 5G Standalone (and similar) architectures where there is one gNB-CU-CP per 5G SA gNodeB and there can be multiple gNB-CU-UPs (with one or more network slices mapped to each gNB-CU-UP for resource isolation) for the same 5G gNB. In this slice based 5G SA architecture, each session (carrying one or more DRBs) of a 5G SA UE can belong to a different slice and traffic for each slice can be sent via a different gNB- CU-UPs to achieve resource isolation. A method is therefore provided to enforce UE AMBR in such slicing based 5G SA architectures for 5G SA UE.

[0053] METHOD IA In this method, each gNB-CU-UP communicates measured session AMBR data to gNB-CU-CP for the UEs for which DL data is being sent via that gNB-CU-UP. This measured data rate is communicated to a DL-UE-AMBR module at the gNB-CU-CP.

[0054] The DL-UE-AMBR module computes the aggregated DL data rate for each 5G SA UE. If the aggregated DL UE AMBR is more than the pre-specified DL UE AMBR for that UE, the DL-UE-AMBR module at the gNB-CU-CP determines the actions to be taken at each CU-UP instance and communicates these decisions to the respective gNB-CU-UP instances for each such UE.

[0055] The actions that can be taken include, for example, to direct a subset of these gNB-CU- UPs to start dropping (or delaying) DL packets. In this instance, the DL-UE-AMBR module provides a time interval and a total amount of data to be dropped (or delayed) during the time interval by the corresponding gNB-CU-UP.

[0056] When a UE is initially connected to a PDU session, the gNB-CU-CP allows the gNB- CU-UP to enforce DL AMBR (as there is only one CU-UP instance). However, when a new PDU session is established , the gNB-CU-CP will check the slice identifier and determine if a different gNB-CU-UP will serve the DRBs related to the new session. If there is a different gNB- CU-UP for the new session, gNB-CU-CP will trigger a Data Usage Report for the UE from both gNB-CU-UPs serving different bearers of the UE.

[0057] Accordingly, the gNB-CU-CP will trigger a Data Usage Report from all the gNB-CU- UPs carrying non-GBR traffic for different PDU sessions of a given 5G SA UE corresponding to different network slices (or different slice identifiers).

[0058] It should be noted that the Data Usage Report includes data volume in terms of octets (bytes), which the CU-CP converts into bits while aggregating data volume across non-GBR DRBs. Additionally, the time interval T over which UE AMBR must be enforced may comprise 2000 ms.

[0059] METHOD IB In another configuration, a new interface (i.e., H2) is provided which extends between two different instances of gNB-CU-UPs to optimize 5G SA UE AMBR-related decisions. The H2 Control plane (H2-C) allows exchange of control information between two different gNB-CU-UPs. An H2 Application Protocol (H2AP) runs over H2-C and is used to exchange parameters between different instances of gNB-CU-UPs.

[0060] In this configuration, where multiple CU-UPs are connected via the H2 interface(s) andare communicating DL data for different PDU sessions for a UE, one of the CU-UPs must be chosen as the Master CU-UP to enforce DL UE AMBR for the UE. For a given 5G SA UE receiving DL data via multiple gNB-CU-UPs, each non-Master gNB-CU-UP communicates Data Usage Reports (for non-GBR DRBs) to the master gNB-CU-UP. This data rate is aggregated at the master gNB-CU-UP for all DRBs carrying DL data for that UE. If the aggregated observed DL UE AMBR is more than the pre-specified DL UE AMBR for that UE, the DL-UE-AMBR module decides actions to be taken at each gNB-CU-UP and communicates these to the respective non-Master gNB-CU-UPs for that UE (via the H2 interface). The Master gNB-CU-UP sends a H2AP-UE- AMBR- Action message to each such non-master gNB-CU-UP for this purpose.

[0061] METHOD IC. The DL-UE-AMBR module at the gNB-CU-CP (as in Method IA) or the DL-UE-AMBR module as the Master gNB-CU-UP (as in Method IB) also considers Session AMBR when communicating decisions for DL UE AMBR enforcement to gNB-CU-UPs. In general, the sum of the (configured or allowed) session AMBRs for a UE can be greater than (configured or allowed) UE AMBR but aggregate “observed” data rate for non-GBR traffic for a UE can’t exceed (configured) UE AMBR. For example, configured session AMBR for PDU session 1 of UEg can be hl Mbps, for PDU session 2 of UEh can be h2 Mbps, (configured) UE AMBR can be h Mbps with hl + h2 > h but observed aggregate UE AMBR can’t exceed (configured) UE AMBR (in each of the DL and UL direction respectively).

[0062] In a configuration where DL data for a UE is being sent via gNB-CU-UPm and gNB-CU- UPn (with data for one PDU session via gNB-CU-UPm and data for another PDU session via gNB-CU-UPn) , gNB-CU-UPm and gNB-CU-UPn communicate data volume sent for each DRB of UEx to the DL-UE-AMBR module (at the gNB-CU-CP or at the Master gNB-CU-UP for that UE) every time period. The DL-UE-AMBR module aggregates the data volume across non-GBR DRBs of each such UE. In this case, the DL-UE-AMBR module must decide on enforcing DL UE AMBR across the two gNB-CU-UPs.

[0063] In one instance, the data volume sent on gNB-CU-UPm may exceed the DL session AMBR for PDU sessionl served by gNB-CU-UPm. In that case, the DL-UE-AMBR module sends a message to gNB-CU-UPm to drop all packets for a time interval. Alternatively, the datavolume sent on gNB-CU-UPn may be less than DL session AMBR for PDU session2 served by gNB-CU-UPn but DL-UE-AMBR module may still send a message to gNB-CU-UPn to delay a number of bytes for a time interval (if DL-UE-AMBR finds that the DL UE AMBR for that UE across all of its non-GBR DRBs is getting violated)

[0064] Accordingly, the DL session AMBR is therefore only one of the factors for enforcing DL UE AMBR where the DL-UE-AMBR module (at gNB-CU-CP or at the Master gNB-CU-UP for UEx) decides to drop or delay packets.

[0065] In one configuration a method of enforcing Aggregate Maximum Bit Rate (AMBR) for User Equipment (UE) connected to an Open Radio Access Network (0-RAN) including a gNodeB Control Unit-Control Plane (gNB-CU-CP) and a first gNB Control Unit-User Plane (gNB-CU-UP) and a second gNB-CU-UP is provided comprising the steps of: a Download UE AMBR (DL-UE-AMBR) module obtaining a measured data rate for DL data for the first gNB- CU-UP for a first Protocol Data Unit (PDU) session, and the DL-UE-AMBR module obtaining a measured data rate for DL data for the second gNB-CU-UP for a second PDU session. The method further comprising the steps of: the DL-UE-AMBR module computing an aggregated DL data rate for the UE based on the first and the second measured data rates, and the DL-UE- AMBR module determining first action to be taken at the first gNB-CU-UP and a second action to be taken at the second gNB-CU-UP based on the received measured data rates respectively and the computed aggregated DL data rate. The method still further comprises the steps of: the DL-UE-AMBR module transmitting a first control message to the first gNB-CU-UP including instructions to take the first action, and the DL-UE-AMBR module transmitting a second control message to the second gNB-CU-UP including instructions to take the second action. The method is provided such that the first and second actions are selected from the group consisting of: drop all DL packets for a time interval, drop some DL packets for a time interval, drop no packets for a time interval, delay all DL packets for a time interval, delay some DL packets for a time interval, delay no packets for a time interval, and combinations thereof.

[0066] The above-described and other features and advantages of the present disclosure will be appreciated and understood by those skilled in the art from the following detailed description, drawings, and appended claims.DESCRIPTION OF THE DRAWINGS

[0067] FIG. 1A is an overview of NG-RAN architecture showing user and control plane functions with gNB.

[0068] FIG. IB is block diagram of NG-RAN architecture showing user and control plane functions with gNB.

[0069] FIG. 2 is an overview of NG-RAN architecture showing user and control plane functions with gNB and AMF.

[0070] FIG. 3 is a block diagram of NG-RAN architecture with a set of gNBs coupled to the 5GC through an NG interface.

[0071] FIG. 4 is a block diagram of NG-RAN architecture with a set of gNBs coupled to the 5GC through an NG interface with separate CU-CP and CU-UP.

[0072] FIG. 5 is a block diagram of 5G NR illustrating an L2 data flow example.

[0073] FIG. 6 is a block diagram of 0-RAN with the various components connected via the midhaul path.

[0074] FIG. 7 is a block diagram of an example PDU session comprising multiple DRBs that each comprise multiple QoS flows.

[0075] FIG. 8 shows 3GPP 5G network architecture within the context of multiple PDU sessions with multiple DRBs and QoS flow identifiers.

[0076] FIG. 9 shows 3GPP 5G network architecture within the context of RRM for connecting UE to the network via and RU with a MAC scheduler.

[0077] FIG. 10A shows the CU-UP sending DL User Data (DUD) to the DU.

[0078] FIG. 10B shows flow control feedback from the CU-UP to the DU.

[0079] FIG. 10C shows the DU sending Assistance Information Data (AID) to the CU-UP.

[0080] FIG. 11 shows Single Network Slice Selection Assistance Information (S-NSSAI) S- NSSAI structure.

[0081] FIG. 12 shows the UE establishing a PDU session with a specific DNN.

[0082] FIG. 13 is a block diagram showing the Access and Mobility Management (AMF) communicating DL and UL UE-AMBR to gNB-CU-CP of gNB, which transmits DL UE-AMBR to gNB-CU-UP of gNB, and UL UE-AMBR gNB-DU of gNB.

[0083] FIG. 14 is a block diagram showing three DRBs carrying DL data for UE, UEx.

[0084] FIG. 15 is a block diagram showing a DL-UE-AMBR module at the gNB-CU-CP communicating for a given UE to a chosen gNB-CU-UP according to one configuration of the invention.

[0085] FIG. 16A is a block diagram showing a new interface between two different instances of gNB-CU-UPs to optimize 5G SA UE AMBR related decisions in 5G networks according to FIG. 15.

[0086] FIG. 16B is a data flow diagram showing the control plane of the new interface according to FIG. 16A.

[0087] FIG. 16C is a data flow diagram showing DL data for different PDU sessions of a UE communicated via three different gNB-CU-UPs according to FIG. 16A.

[0088] FIG. 16D is a data flow diagram showing DL data for different PDU sessions of a UE communicated via four different gNB-CU-UPs according to FIG. 16A.

[0089] FIG. 17 is a block diagram showing establishing connections between gNB-CU-UPs with Setup Requests and Setup Replies according to FIG. 16A.

[0090] FIG. 18A is a data flow diagram showing the Bearer Setup Procedure between two different gNB-CU-UPs where each gNB-CU-UP has the same gNB-CU-CP according to FIG.16 A.

[0091] FIG. 18B is a data flow diagram showing the Bearer Setup Procedure adding a thirdgNB-CU-UP where each gNB-CU-UP has the same gNB-CU-CP according to FIG. 18A.

[0092] FIG. 19A is a table showing contents of an H2AP-Data-Usage-Request message according to FIG. 20 (and FIG. 16A).

[0093] FIG. 19B is a table showing contents of H2AP-Data-U sage-Response message according to FIG. 20 (and FIG. 16A). This message also carries predicted traffic volume for each non-GBR DRB where this prediction is performed at the gNB-CU-UP and communicated to the Master gNB-CU-UP via this H2AP message.

[0094] FIG. 20 is a block diagram showing a gNB-CU-UPn acting as a Master gNB-CU-UP and hosts the DL-UE-AMBR optimization module for UE x for which DL data is being sent via gNB-CU-UPm and gNB-CU-UPn according to FIG. 15 (and FIG. 16A).

[0095] FIG. 21 is a table showing contents of a message H2AP-UE-AMBR- Action which Master gNB-CU-UP sends to non-Master gNB-CU-UP communicating action to be taken at nonMaster gNB-CU-UP for that UE.DETAILED DESCRIPTION

[0096] Various methods are now discussed for enforcing UE AMBR effectively for 5G Standalone (and similar) architectures where there is one gNB-CU-CP per 5G SA gNB and there can be multiple gNB-CU-UPs (with one or more network slices mapped to each gNB-CU-UP for resource isolation) for the same 5G gNB. In the above-described slice-based 5G SA architecture, each session (carrying one or more DRBs) of a 5G SA UE can belong to a different slice and traffic for each slice can be sent via a different gNB-CU-UP to achieve resource isolation. As such, various methods will now be discussed for enforcing UE AMBR in such slicing based 5G SA architectures for 5G SA UE.

[0097] METHOD IA In this method, each gNB-CU-UP communicates observed (or measured) session AMBR data to gNB-CU-CP (via El interface between gNB-CU-CP and gNB-CU-UP) for the UEs for which DL data is being sent via that gNB-CU-UP. This observed data rate is communicated to a module denoted as ‘DL-UE-AMBR module’ at the gNB-CU-CP.

[0098] The DL-UE-AMBR module at the gNB-CU-UP computes the aggregated DL data rate, (e g., DL UE AMBR) for each 5G SA UE. For example, if DL data for a UE is being communicated via two different gNB-CU-UPs, each gNB-CU-UP informs session data rate to the DL-UE-AMBR module at the gNB-CU-CP and the DL-UE-AMBR module at the gNB-CU- UP computes the DL UE AMBR for that 5G SA UE.

[0099] If this aggregated observed DL UE AMBR is more than the pre-specified DL UE AMBR for that UE, the DL-UE-AMBR module at the gNB-CU-CP decides about the actions to be taken at each CU-UP instance and communicates these decisions via El AP to respective gNB-CU-UP instances for each such UE.

[0100] For example, the DL-UE-AMBR module at the gNB-CU-CP can instruct a subset of these gNB-CU-UPs (for a given UE for which DL traffic is being sent via multiple gNB-CU- UPs) to start dropping (or delaying) DL packets. For this purpose, this DL-UE-AMBR module (at gNB-CU-CP) provides a time interval and total amount of data to be dropped (or delayed) in this time interval by the corresponding gNB-CU-UP.

[0101] Initially when UE is attached and a PDU session is established as shown in FIG 13, gNB-CU-CP will let gNB-CU-UP enforce DL AMBR as there is only one CU-UP instance for that UE. When a new PDU session is established, gNB-CU-CP will check the slice identifier (with which this new session is associated) and determine the gNB-CU-UP which will serve the DRBs related to the new PDU session. If this gNB-CU-UP is not same as the previous one which is being used for this UE for the earlier PDU session, gNB-CU-CP will trigger Data Usage Report for this UE from both of these gNB-CU-UPs which are serving different bearers of this UE. If this UE starts a new PDU session (i.e. third PDU session for this UE in the example considered here) corresponding to a different slice identifier and a new gNB-CU-UP is used to serve traffic for this slice identifier, gNB-CU-CP will trigger Data Usage Report for this UE from this new gNB-CU-UP too.

[0102] In general, gNB-CU-CP will trigger Data Usage Report from all the gNB-CU- UPs which are carrying non-GBR traffic for different PDU sessions of a given 5G SA UE corresponding to different network slices (or different slice identifiers).

[0103] The gNB-CU-CP triggers Data Usage Report from gNB-CU-UPs as explained above. For this purpose, gNB-CU-UP uses El AP message Data usage report to report data volume observed on each DRB. For example, gNB-CU-UP sends Data usage report for each (session of a) UE every U ms to gNB-CU-CP.

[0104] The gNB-CU-UP sends Data volume in terms of octets (bytes) in Data Usage report, CU-CP will convert data volume into bits while aggregating data volume across non- GBR DRBs.

[0105] FIG. 15 shows an example where the DL-UE-AMBR module at the gNB-CU-CP 304a communicates (UE identity, Action - delay serving packets or drop packets or no action to be done, time interval, number of bytes to be delayed or dropped as per the action) for a given UE 101 to a chosen gNB-CU-UP (e.g., 304b-l, 304b-2). Suitable objects are added in E1AP protocol for this purpose. The El AP message IES for the AMBR enforcement request message used for this purpose are as follows:• gNB-CU-CP UE E1AP ID• gNB-CU-UP UE El AP ID• Action -> ENUMERATED (Delay, Drop, keep serving packets or No action to be taken)• Time Interval• Number of bytes

[0106] UE AMBR may need to be enforced over time interval T (such as for every 2000 ms). Exchange of parameters described above (via the El interface) can happen at much shorter time interval and can happen multiple times during the time window T. For example, each CU- UP instance can provide the above described parameters every U ms to gNB-CU-CP and the DL- UE-AMBR module at the gNB-CU-CP computes the aggregated DL UE AMBR for each UE using the information received from different gNB-CU-UPs which are carrying DL data for this 5G SA UE. Here, time interval U can be much less than time interval T.

[0107] The DL-UE-AMBR module at the gNB-CU-CP next takes a set of decisions to ensure that each UE complies with the aggregate DL UE AMBR constraints for that UE. As part of this decision for a given UE, the DL-UE-AMBR module at gNB-CU-CP decides whether eachgNB-CU-UP which is carrying DL data for that UE can continue to carry data for this UE without any change or should drop certain packets or delay serving some packets for a given time interval.

[0108] Alternatively, gNB-CU-CP can analyze data reports received for this UE from each CU-UP and decide on the data volume to be accepted in remaining time interval.

[0109] Consider an example scenario where DL UE AMBR for 5G SA UE (UEx) is 10 Mbps, length of AMBR averaging window is 2000ms and DL data for this UE is being carried by two gNB-CU-UPs. Each gNB-CU-UP communicates data volume sent for each DRB of UEx to the gNB-CU-CP every time period U (e.g., reporting time period U could be equal to 100ms). The DL-UE-AMBR module at the gNB-CU-CP aggregates the data volume across non-GBR DRBs for this UE (from different gNB-CU-UPs which are carrying DL data for this UE). As DL UE AMBR for UEx is 10 Mbps, the base station is allowed to communicate 20 Mbits of DL data to this UE in 2000 ms.

[0110] If the aggregate data volume (as reported from two gNB-CU-UPs to the DL-UE- AMBR module at the gNB-CU-CP) for UEx for 10 reporting time intervals (i.e. 10 * U = 10 * 100ms) is 12 Mbits, the DL-UE-AMBR module can use various policies to decide what action (if any) to take so that the base station doesn’t end up sending more than 20 Mbits for UEx in the window of 2000 ms.

[0111] For example, the DL-UE-AMBR module at the gNB-CU-CP can decide to send a message (UE id = UEx, Action = delay, Time interval = 1000ms, Number of bytes = 4 Mbits) to each of the two gNB-CU-UPs which are carrying DL data for UEx. In this case, the DL-UE- AMBR module is telling each gNB-CU-UP that each of these can still serve 4 Mbits for this UEx during the next 1000 ms. As another example, the DL-UE-AMBR module can send a message to one gNB-CU-UP to serve 2 Mbits and other gNB-CU-UP to serve 6 Mbits during the next 1000 ms (for serving DL data for UEx).

[0112] In another example (for the above UEx), assume the aggregated DL data volume for 18-time intervals (i.e. 18 * U = 18 * 100ms = 1800 ms in this example) is 20 Mbit. In this case, the DL-UE-AMBR module at the gNB-CU-CP can send a message (UE id = UEx, Action= drop, Time interval = 200ms, Number of bytes = infinity) to both the gNB-CU-UPs carrying DL data for UEx. Here ‘Number of bytes = Infinity’ means that gNB-CU-UP needs to drop all the DL packets (corresponding to non-GBR bearers) for the next 200 ms for this UEx.

[0113] As still another example, AIML based techniques such as LSTM (Long Short- Term Memory) or Transformer based Deep Neural Network architectures can be used to predict traffic volume for each non-GBR DRB corresponding to each slice and this can be used along with other factors (or policies) to help decide part of UE AMBR to be enforced for each UE at each gNB-CU-UP over a time interval as per the above method. If this prediction is done at CULT, data usage report is enhanced to carry predicted values of data volume (along with the time interval and confidence level of this prediction) for each non-GBR DRB from gNB-CU-UP to gNB-CU-CP.

[0114] METHOD IB. In another configuration 5G SA (5G Standalone) UE 101 is supporting d active PDU sessions (e.g., with one or more DRBs per session), s slices for these d PDU sessions, and these sessions (or slices) are mapped to c gNB-CU-UPs (e.g., 304b-l, 304b- 2) corresponding to that 5G gNodeB (with 1 < c < s < d). This method chooses one gNB-CU-UP to act as Master gNB-CU-UP for taking decisions related to enforcing aggregate UE AMBR in the 5G SA network architecture. There can be a different Master gNB-CU-UP for each UE in this method.

[0115] In this case, a new interface, called H2, between two different instances of gNB- CU-UPs (e.g., 304b-l, 304b-2) is defined to optimize 5G SA UE AMBR related decisions in 5G networks. This new interface is shown in FIG. 16A.

[0116] As in FIG. 16B, the control plane of H2 interface is denoted as H2-C. Here, H2-C allows exchange of control information between two different gNB-CU-UPs (e.g., 304b-i, 304b- ii). An application protocol H2AP (H2 Application Protocol) runs over H2-C (H2 -Control plane) interface, and this is used to exchange parameters between different instances of gNB-CU-UPs. This protocol runs over Streaming Control Transmission Protocol / Internet Protocol (SCTP / IP), which is a transport layer protocol in the Internet Protocol suite that is used to transmit control plane data over a network here.

[0117] FIG. 16C shows a scenario where DL (downlink) data for different PDU sessions of a UE (corresponding to different network slices in a 5G network) is being communicated via three different CU-UPs: gNB-CU-UPm 304b-i, gNB-CU-UPn 304b-ii and gNB-CU-UPk 304b- iii. In this method, one of these CU-UPs is chosen as the Master CU-UP for enforcing DL UE AMBR for this UE. This Master CU-UP is chosen as gNB-CU-UPn in the example scenario shown in FIG. 16C.

[0118] FIG. 16D shows another example scenario where DL (downlink) data for different PDU sessions of a UE (corresponding to different network slices in a 5G network) is being communicated via four different CU-UPs: gNB-CU-UPm 304b-i, gNB-CU-UPn 304b-ii, gNB-CU-UPj 304b-iv and gNB-CU-UPk 304b-iii. In this example, gNB-CU-UPn 304b-ii is chosen as the Master gNB-CU-UP for enforcing UE AMBR for 5G SA UE 101.

[0119] ‘CU-UP x’ is denoted as CU-UPx in this document. Also, gNB-CU-UPx and CU- UPx are used interchangeably in this document.

[0120] To create a logical H2-C connection between two different CU-UPs, the first CU- UP uses an IP address of a second gNB-CU-UP to establish a SCTP connection. After that, this gNB-CU-UP (which had sent SCTP establishment request) sends H2 Setup Request to the second gNB-CU-UP and receives H2 Setup Reply as shown in FIG. 17. Alternatively, other gNB-CU-UP can also initiate H2 establishment.

[0121] If there are multiple gNB-CU-UPs as part of a 5G gNodeB, H2 interface is established between each pair of gNB-CU-CPs with each H2-C supporting bidirectional communication between a pair of gNB-CU-UPs. An example is shown in FIG. 17 where there are three gNB-CU-UPs (e.g., 304b-i, 304b-ii, 304b-iii) associated with a 5G gNodeB.

[0122] PDU session establishment procedure for 5G SA is enhanced to select the Master gNB-CU-UP for DL UE AMBR enforcement for each 5G SA UE supporting multiple PDU sessions with some of these sessions (and associated 5G slices) communicating DL data via different gNodeB-CU-UPs for that UE.

[0123] Initially when a 5G SA UE is attached and a PDU session is established as shown in FIG. 12 and FIG. 13, gNB-CU-UP (say gNB-CU-UP denoted as gNB-CU-UPn) enforces DLUE AMBR as there is only one gNB-CU-UP instance for that UE.

[0124] When a new PDU session is established, gNB-CU-CP checks the slice Id (i.e. slice identity) and determines the gNB-CU-UP which will serve the DRBs associated with this new PDU session. If this new gNB-CU-UP (denoted as gNB-CU-UPm) is not same as the previous one (i.e. gNB-CU-UPn) which was being used for this UE for the earlier PDU session, gNB-CU-CP provides the gNB-CU-UP Id of the gNB-CU-UPn as part of bearer setup procedure to gNB-CU-UPm (as shown in step 2 of FIG. 18A). Bearer Setup Procedure between gNB-CU- CP and gNB-CU-UP (using E1AP) is enhanced for this purpose.

[0125] After the bearer establishment, gNB-CU-UPm sends DL AMBR Master Selection Request to CU-UPn (as show in step 3 of FIG. 18A) and gNB-CU-UPn responds with DL AMBR Master Selection Response (as show in step 4 of FIG. 18A). In this example scenario, gNB-CU-UPm agrees to keep gNB-CU-UPn as the Master CU-UP for this UE and responds with DL UE AMBR Master Selection Acknowledgement as in step 5 of FIG. 18A. Bearer Setup Response is sent from gNB-CU-UPm to gNB-CU-CP as shown in Step 6 of FIG. 18A.

[0126] FIG. 18B shows a scenario where a third PDU session is established for this 5G SA UE. This UE already has two active PDU sessions, each belonging to a 5G network slice with DL data for one of these is sent via gNB-CU-UPn and for second one it is being sent via gNB-CU-UPm. Master gNB-CU-UP for this UE for DL UE AMBR enforcement is gNB-CU- UPn.

[0127] As shown in FIG. 18B, gNB-CU-UP selected for this third PDU session (and the corresponding 5G network slice) is gNB-CU-UPj 304b-iv. As part of message 2 of FIG. 18B, Bearer Setup Request is enhanced to communicate an identity of the existing Master gNB-CU- UP (i.e., gNB-CU-UPn 304b-ii) to gNB-CU-UPj 304b-iv. As part of message 3, 4 and 5 in FIG. 18B, gNB-CU-UPn 304b-ii and gNB-CU-UPj 304b-iv select the Master gNB-CU-UP for this UE. In this case, they agree to keep using Master gNB-CU-UPn 304b-ii as the Master gNB-CU- UP for this 5G SA UE 101. Bearer Setup Response is sent from gNB-CU-UPj 304b-iv to gNB- CU-CP 304a as shown in Step 6 of FIG. 18B.

[0128] In this method the Master gNB-CU-UP can be selected using various policies. Inone such policy, gNB-CU-CP can decide the Master gNB-CU-UP for each UE. For example, gNB-CU-CP can choose the first (or the oldest) gNB-CU-UP (which carries data traffic for the first or the oldest PDU session) of the UE as Master gNB-CU-UP. When all DRBs of the UE served by the gNB-CU-UP are released then the next available gNB-CU-UP will be chosen as Master gNB-CU-UP.

[0129] For example, UEx is served by gNB-CU-CPx. During first PDU session establishment of UEx, gNB-CU-UPn is selected. For the second PDU session gNB-CU-UPm is selected. gNB-CU-CPx will assign gNB-CU-UPn as the Master gNB-CU-UP for this UE and inform the same to gNB-CU-UPm and gNB-CU-UPn.

[0130] As another policy, gNB-CU-UPs can communicate with each other and decide the Master gNB-CU-UP for each UE. Ties can be broken by selecting the gNB-CU-UP with the higher gNB-CU-UP identifier. For example, UEx is served by gNB-CU-CPx. During first PDU session establishment of this UEx, gNB-CU-UP, denoted as gNB-CU-UPn, is selected. For the second PDU session gNB-CU-UP, denoted as gNB-CU-UPm, is selected. gNB-CU-UPn (with gNB-CU-UP Id = 10000) and gNB-CU-UPm (with gNB-CU-UP Id = 11000) communicate with each other and decide the Master gNB-CU-UP for this UE. If gNB-CU-UPm and gNB-CU-UPn both have indicated to be the Master gNB-CU-UP for UEx, gNB-CU-UPm which has higher Id can be selected as the Master gNB-CU-UP for UEx as per this example policy.

[0131] Once the Master gNB-CU-UP is selected for a 5G SA UE, that Master gNB-CU- UP asks other (non-Master) gNB-CU-UP carrying DL data for that UE to start sending data usage reports for each DRB. For this, the master gNB-CU-UP sends a H2AP-Data-Usage- Request to another (non-Master) gNB-CU-UP for that UE and provides the periodicity at which the other (non-Master) gNB-CU-UP should send data usage report for each DRN to the Master gNB-CU-UP. The master gNB-CU-UP does this with each non-Master gNB-CU-UP for that UE.

[0132] In response, the non-Master gNB-CU-UP starts sending data usage report to the Master gNB-CU-UP periodically. This (non-Master) gNB-CU-UP sends this data usage information using the H2AP-Data-U sage-Response message.

[0133] H2AP-Data-Usage_Request and H2AP-Data-Usage-Response messages are sentusing the H2AP protocol running over the H2-C interface.

[0134] A logical connection for a specific 5G SA UE over the H2-C interface between gNB-CU-UPm and gNB-CU-UPn is identified using ‘gNB-CU-UPm UE H2AP Identity’ and ‘gNB-CU-UPn UE H2AP Identity’. Here, ‘gNB-CU-UPm UE H2AP Identity’ is provided by gNB-CU-UPm to gNB-CU-UPn for this UE and ‘gNB-CU-UPn UE H2AP Identity’ is provided by gNB-CU-UPn to gNB-CU-UP m for this UE. If gNB-CU-UP n needs to provide information for this UE to gNB-CU-UP m, it uses ‘gNB-CU-UPm H2AP Identity’ to identify this UE to gNB-CU-UPm. Similarly, if gNB-CU-UPm needs to provide information for this UE to gNB- CU-UPn, it uses ‘gNB-CU-UPn H2AP Identity’ to identify this UE to gNB-CU-UPn.

[0135] When the master gNB-CU-UP (gNB-CU-UPn) for a UE sends H2AP-Data- Usage-Request to a non-master gNB-CU-UP (gNB-CU-UPm) for that UE for the first time, it also includes an identifier ‘gNB-CU-UPn UE H2AP Identity’ for this UE. When non-master gNB-CU-UP (i.e., gNB-CU-UPm in this example scenario) responds with H2AP-Data-Usage- Response message for the first time, it also adds an identifier ‘gNB-CU-UPm UE H2AP Identity’ for this UE.

[0136] FIG. 19A shows example content of the H2AP-Data-Usage-Request message. It may include the following:• Protocol version• Message category (for UE AMBR enforcement in 5G SA architectures)• Reserved bits• Message id for H2AP-Data-Usage-Request• Identity of source gNB-CU-UP (Master gNB-CU-UP in this case)• Identity of destination gNB-CU-UP• Message sequence number• Identity of the UE (or the associated H2-C logical connection) for which report is requested• Periodicity at which data report should be sent for non-GBR DRBs• A flag to indicate if data usage report is immediately or urgently needed even if a report does not need to be sent as per the periodicity of the report• Other parameters or reserved bits

[0137] FIG. 19B shows example content of the H2AP-Data-Usage-Response message. It may include the following:• Protocol version• Message category (for UE AMBR enforcement in 5G SA architectures)• Reserved bits• Message id for H2AP-Data-Usage-Response• Identity of source gNB-CU-UP• Identity of destination gNB-CU-UP (Master gNB-CU-UP in this case)• Message sequence number• Identity of the UE (or the associated H2-C logical connection) for which report is being sent• Number of DRBs for which this report is being sent• Timestamp when this data usage report is being sent• Following fields are repeated for each non-GBR DRB for that UE for which data usage report is being sent to the Master gNB-CU-UP: o DRB id for non-GBR DRB for this UE (along with other UE or session identifiers) o A field to indicate presence or absence of predicted traffic volume for this DRB o Data volume carried for this non-GBR DRB o Time interval for prediction o Confidence level of prediction• Other parameters or reserved bits

[0138] Using data usage reports received from non-master gNB-CU-UPs, the DL UE AMBR enforcement module at the master gNB-CU-UP keeps taking decisions to enforce DL UE AMBR for each UE. As discussed in the previous method, the DL UE AMBR enforcement module can use a variety of policies to make such decisions.

[0139] FIG. 20 shows an example scenario where gNB-CU-UPn 304b-ii acts as a master gNB-CU-UP and hosts the DL-UE-AMBR optimization module for UE x for which DL data isbeing sent via gNB-CU-UPm 304b-i and gNB-CU-UPn 304b-ii . For a given 5G SA UE 101 receiving DL data via multiple gNB-CU-UPs, each non-Master gNB-CU-UP keeps communicating measured data usage reports (for non-GBR DRBs) to the master gNB-CU-UP. This measured data rate (for non-GBR DRBs) is aggregated at the master gNB-CU-UP for all DRBs carrying DL data for that UE.

[0140] If this aggregated observed DL UE AMBR (for non-GBR DRBs) is more than the pre-specified DL UE AMBR for that UE, the DL-UE-AMBR module decides actions to be taken at each gNB-CU-UP and communicates these via H2 interface to the respective non-Master gNB-CU-UP for that UE. The Master gNB-CU-UP sends H2AP-UE-AMBR- Action message to non-master gNB-CU-UP for this purpose.

[0141] For example, the DL-UE-AMBR module at the Master gNB-CU-UP can decide to ask a subset of these gNB-CU-UPs (for a given UE for which DL traffic is being sent via multiple gNB-CU-UPs) to start enforcing DL UE AMBR by delaying (or dropping) DL packets. For this purpose, this DL-UE-AMBR module (at the master gNB-CU-UP) provides a time interval and total amount of data to be delayed (or dropped) in this time interval by the corresponding gNB-CU-UP.

[0142] As shown in FIG. 20 (and FIG. 21), the DL UE AMBR module at the master gNB-CU-UP communicates (UE identity, Action with action indicating to delay serving packets or to drop packets or nothing to be done, time interval, number of bytes to be delayed or dropped as per the action) for a given UE to another gNB-CU-UP.

[0143] As another policy, AIML-based techniques such as LSTM (Long Short-Term Memory) or Transformer based Deep Neural Network architectures can be used to predict traffic volume for each non-GBR DRB corresponding to each slice and this can be used along with other factors (or policies) to help decide which part of UE AMBR is to be enforced for each UE at each gNB-CU-UP over a time interval as per the above method.

[0144] If this prediction (for traffic volume of a non-GBR DRB) is done at gNB-CU-UP, then this predicted value (along with the time interval of prediction and confidence of prediction) is sent from gNB-CU-UP to the Master gNB-CU-UP via H2AP along with observed data usagefor these DRBs (as shown in FIG. 19B).

[0145] Contents of the H2AP-UE-AMBR-Action message may include (FIG. 21):• Protocol version• Message category (for UE AMBR enforcement in 5G SA architecture)• Reserved bits• Message id for H2AP-UE-AMBR-Action• Identity of source gNB-CU-UP (Master gNB-CU-UP here)• Identity of destination gNB-CU-UP• Message sequence number• Identity of the UE (or the associated H2-C logical connection) for which this Action message is being sent• Session or slice identities for this UE for which DL data is being sent via this (destination) gNB-CU-UP• Timestamp when this Action message is sent• Bitmap to indicate presence of absence of delay or drop fields (as part of this Action message)• Action (such as delay, drop or keep serving packets) for this UE at this destination gNB-CU-UP• Number of bytes to be dropped (if drop field is present)• Number of bytes to be delayed (if delayed field is present)• Time interval for dropping or delaying packets if one of the field is present• Other parameters or reserved bits

[0146] METHOD IC. As part of enforcing DL UE AMBR, the DL-UE-AMBR module at the gNB-CU-CP (as in Method IA) or the DL-UE-AMBR module as the Master gNB-CU-UP (as in Method IB) also considers Session AMBR when communicating decisions for DL UE AMBR enforcement to gNB-CU-UPs. In general, the sum of (configured) session AMBRs for a UE can be greater than (configured) UE AMBR but aggregate observed UE AMBR for non- GBR traffic can’t exceed (configured) UE AMBR

[0147] For example, assume (configured or allowed) DL UE AMBR for UE (UEx) is10Mbps and length of AMBR averaging window is 2000ms. The gNB-CU-UPm and gNB-CU- UPn are serving different PDU sessions of UEx. (Configured or allowed) DL Session AMBR of PDU session 1 (served by CU-UPm) is 4 Mbps and (configured or allowed) DL Session AMBR of PDU session 2 (served by CU-UPn) is 8 Mbps.

[0148] Both gNB-CU-UPs communicate data volume sent for each DRB of UEx to the DL-UE-AMBR module (at the gNB-CU-CP or at the Master gNB-CU-UP for that UE) every time period U ms. The DL-UE-AMBR module aggregates the data volume across non-GBR DRBs of each such UE.

[0149] The (allowed) aggregated data volume of the UEx for 18-time intervals (i.e., 18 * 100ms in this example) is 18 Mbits. The DL-UE-AMBR module must decide on enforcing DL UE AMBR across the two gNB-CU-UPs. Data volume sent on CU-UPm for UEx is 8 Mbits and on CU-UPn is 10 Mbits. In this case, for session 1 which is sending data via CU-UPm, DL Session AMBR is getting violated. For session 2, which is sending data via CU-UPn, DL Session AMBR is not getting violated. DL UE AMBR is also getting violated.

[0150] Data volume sent on gNB-CU-UPm is 8 Mbits, which is higher than DL session AMBR for PDU session 1 served by gNB-CU-UPm (for 1800 ms time period). So, the DL-UE- AMBR module sends a message (UE id = UEx, Action = drop, Time interval = 200ms, Number of bytes = infinity) to CU-UPm. Here ‘Number of bytes = Infinity’ means that gNB-CU-UPm can drop all the packets (corresponding to non-GBR bearers) for the next 200 ms for this UEx. It does this as DL session AMBR for this PDU session is getting violated. Also, UE AMBR is getting violated.

[0151] Data volume sent on gNB-CU-UPn is lOMbits, which is less than DL session AMBR for PDU session2 served by gNB-CU-UPn, so the DL-UE-AMBR module sends a message (UE id = UEx, Action = delay, Time interval = 200ms, Number of bytes = 2 Mbits) to CU-UPn. It does this as session AMBR is not getting violated for this PDU session but UE AMBR is getting violated.

[0152] In this method, the DL session AMBR is considered as one of the factors for enforcing DL UE AMBR where the DL-UE-AMBR module (at gNB-CU-CP or at the MastergNB-CU-UP for UEx) decides to drop or delay the packets.

[0153] While the present disclosure has been described with reference to one or more exemplary embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the present disclosure. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the disclosure without departing from the scope thereof. Therefore, it is intended that the present disclosure not be limited to the particular embodiment(s) disclosed as the best mode contemplated, but that the disclosure will include all embodiments falling within the scope of the appended claims.

[0154] For the sake of completeness, a list of acronyms (and corresponding definitions) is provided below:ACRONYMS:5GC: 5G Core Network5G NR: 5G New Radio5QI: 5G QoS IdentifierACK: AcknowledgementAl: Artificial IntelligenceAI / ML (or AIML): Artificial Intelligence and Machine LearningAID: Assistance Information DataAM: Acknowledged ModeAMBR: Aggregate Maximum Bit RateAPN: Access Point NameARP: Allocation and Retention PriorityBLER: Block Error RateBO: Buffer OccupancyBS: Base StationBSR: Buffer Status ReportCMS: Centralized (or Configuration) Management SystemCNN: Convolution Neural NetworkCP: Control PlaneCSI: Channel State InformationCU : Centralized UnitCU-CP: Centralized Unit - Control PlaneCU-UP: Centralized Unit - User PlaneD2-U: D2-User Plane (for D2 interface)D2-C: D2-Control Plane (for D2 interface)D2AP: D2 Application Protocol (running over the D2-C interface)DBS: Desired Buffer SizeDL: DownlinkDDDS: DL Data Delivery StatusDDR: Desired Data RateDNN: Data Network NameDNN: Deep Neural NetworkDQN: Deep Q NetworkDRB: Data Radio BearerDU: Distributed Unit eNB: evolved NodeB (or eNodeB) eNodeB: Evolved NodeB (or eNB)EPC: Evolved Packet CoreEN-DC: E-UTRAN New Radio Dual Connectivity (E-UTRA-NR Dual Connectivity)Fl-U: Fl-User PlaneFl-C: Fl -Control PlaneF1AP: Fl Application ProtocolGBR: Guaranteed Bit Rate gNB: gNodeBGTP-U: GPRS Tunnelling Protocol - User PlaneIP: Internet ProtocolLI : Layer 1L2: Layer 2L3 : Layer 3L4S: Low Latency, Low Loss and Scalable ThroughputLC: Logical ChannelLESS: Low Energy Scheduler SolutionLSTM: Long Short-Term MemoryLTE: Long Term EvolutionMAC: Medium Access ControlMDP: Markov Decision ProcessMCG: Master Cell GroupMeNB: Master eNB (or Master eNodeB)MeNB DU: DU of MeNBMeNB.CU-CP: CU-CP of MeNBMeNB.CU-UP: CU-UP of MeNBMIB : Master Information BlockML: Machine LearningMN: Master NodeMR-DC: Multi -RAT Dual ConnectivityMSS: Maximum Segment SizeMU-MIMO: Multi-User Multiple-Input Multiple-OutputNACK: Negative AcknowledgementNAS: Non-Access StratumNG-RAN: Next Generation Radio Access NetworkNR -NR DC: New Radio (5G) - New Radio (5G) Dual Connectivity (Architecture)NR-U: New Radio - User PlaneNS A: Non-Standalone ArchitectureNSI: Network Slice InstanceNSSI: Network Slice Subnet InstanceNWDAF : Network Data Analytics FunctionO-RAN: Open Radio Access NetworkOAM: Operations, Administration MaintenancePDB: Packet Delay BudgetPDCP: Packet Data Convergence ProtocolPDU : 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: Radio Quality IndicationRRC: Radio Resource ControlRRM: Radio Resource ManagementRTP: Real-Time Transport ProtocolRTCP: Real-Time Transport Control ProtocolRU: Radio UnitSCG: Secondary Cell GroupSCTP: Stream Control Transmission ProtocolSD: Slice DifferentiatorSDAP: Service Data Adaptation ProtocolSDU: Service Data UnitSession-AMBR: Per-Session Aggregate Maximum Bit RateSgNB: Secondary gNB (or Secondary gNodeB)SgNB.CU: CU of SgNBSgNB.CU-CP: CU-CP of SgNBSgNB.CU-UP: CU-UP of SgNBSgNB.DU: DU of SgNBSIB: System Information BlockSLA: Service Level AgreementSN: Secondary NodeS-NSSAI: Single Network Slice Selection AssistanceSST: Slice / Service TypeSU-MIMO: Single User Multiple-Input Multiple-OutputTB: Transport BlockTCP: Transmission Control ProtocolTEID: Tunnel Endpoint IdentifierUE: User EquipmentUE-AMBR: Per-UE Aggregate Maximum Bit RateUP: User PlaneUL: UplinkUM: Unacknowledged ModeUPF: User Plane FunctionX2-U: X2-User PlaneX2-C: X2-Control PlaneX2AP: X2 Application Protocol

Claims

CLAIMSWhat is claimed is:

1. A method of enforcing Aggregate Maximum Bit Rate (AMBR) for User Equipment (UE) connected to an Open Radio Access Network (O-RAN) including a gNodeB Control Unit- Control Plane (gNB-CU-CP) and a first gNB Control Unit-User Plane (gNB-CU-UP) and a second gNB-CU-UP, the method comprising: obtaining, by a Downlink UE AMBR (DL-UE-AMBR) module, a measured data rate for DL data for the first gNB-CU-UP for a first Protocol Data Unit (PDU) session; obtaining, by the DL-UE-AMBR module, a measured data rate for DL data for the second gNB-CU-UP for a second PDU session; computing, by the DL-UE-AMBR module, an aggregated DL data rate for the UE based on the first and the second measured data rates; determining, by the DL-UE-AMBR module, a first action to be taken at the first gNB- CU-UP and a second action to be taken at the second gNB-CU-UP based on the obtained respective measured data rates and the computed aggregated DL data rate; transmitting, by the DL-UE-AMBR module, a first control message to the first gNB-CU- UP including instructions to take the first action; and transmitting, by the DL-UE-AMBR module, a second control message to the second gNB-CU-UP including instructions to take the second action; wherein the first and second actions each include at least one of the following actions: drop all DL packets for a time interval, drop some DL packets for a time interval, drop no packets for a time interval, delay all DL packets for a time interval, delay some DL packets for a time interval, and delay no packets for a time interval.

2. The method of claim 1, wherein the DL-UE-AMBR module resides in the gNB-CU-CP, the method further comprising: when the UE is connected to a first PDU session, the gNB-CU-CP allows the first gNB- CU-UP to enforce DL AMBR.

3. The method of claim 2, the method further comprising:when the UE is connected to a second PDU session, determining by the gNB-CU-CP whether a slice identifier of the second PDU session is different than a slice identifier of the first PDU session; and when the slice identifier of the second PDU session is determined to be different than a slice identifier of the first PDU session, triggering by the gNB-CU-CP a Data Usage Report for the UE to be sent from the first gNB-CU-UP and the second gNB-CU-UP to the gNB-CU-CP for the first and second gNB-CU-UPs carrying non-GBR traffic for different sessions.

4. The method of claim 3, wherein the Data Usage Reports include data volume in terms of octets (bytes), and wherein the gNB-CU-CP converts the data volume from octets into bits while aggregating data volume across non-Guaranteed Bit Rate (Non-GBR) Data Radio Bearers (DRBs).

5. The method of claim 4, wherein the first and second gNB-CU-UPs each use E1AP message Data usage reports to report data volume observed on each DRB.

6. The method of claim 1, wherein the DL-UE-AMBR module resides in the first gNB-CU- UP, which comprises a master gNB-CU-UP, the method further comprising: providing an interface (H2 interface) comprising an H2 Control Plane (H2-C) between the first gNB-CU-UP and the second gNB-CU-UP; providing an H2 Application Protocol (H2AP) running on the H2-C; and exchanging control information and parameters between the first and second gNB-CU- UPs via the H2 interface.

7. The method of claim 6, wherein at least one of: a) the first gNB-CU-UP sends to the second gNB-CU-UP an H2AP -Data- Usage-Request message comprising at least one of: protocol version; message category indicator for UE AMBR enforcement; message identifier for H2AP-Data-Usage-Request; identity of the first gNB-CU-UP;identity of the second gNB-CU-UP; message sequence number; identity of the UE or the associated H2-C for which H2AP data usage report is requested; periodicity at which H2AP data usage report should be sent for non-GBR DRBs; and a flag to indicate whether H2AP data usage report should be sent immediately, irrespective of the periodicity at which H2AP data usage report should be sent; and b) the second gNB-CU-UP sends to the first gNB-CU-UP an H2AP-Data-Usage- Response message comprising at least one of: protocol version; message category indicator for UE AMBR enforcement; message identifier for H2AP-Data-Usage-Response; identity of the second gNB-CU-UP; identity of the first gNB-CU-UP; message sequence number; identity of the UE or the associated H2-C for which the H2AP-Data-Usage- Response is being sent; number of DRBs for which the H2AP-Data-Usage-Response is being sent; timestamp of when the H2AP-Data-Usage-Response is sent; and for each non-GBR DRB for the UE for which the H2AP-Data-Usage-Response is being sent to the first gNB-CU-UP:DRB identifier for the non-GBR DRB for the UE; a field to indicate presence or absence of predicted traffic volume for the non-GBR DRB; data volume carried for the non-GBR DRB; time interval for prediction; and confidence level of prediction.

8. The method of claim 6, wherein the first gNB-CU-UP is selected to be the master gNB-CU-UP based on the following steps: when a second PDU session is established, the gNB-CU-CP checks the slice identity of the second PDU session and determines which gNB-CU-UP will serve DRBs associated with the second PDU session; when the gNB-CU-CP determines the second gNB-CU-UP will serve DRBs associated with the second PDU session, the gNB-CU-CP provides a gNB-CU-UP ID of the first gNB-CU- UP to the second gNB-CU-UP as part of a bearer setup procedure between the gNB-CU-CP and the second gNB-CU-UP; the second gNB-CU-UP sends a DL AMBR Master Selection Request to the first gNB- CU-UP; the first gNB-CU-UP sends a DL AMBR Master Selection Response to the second gNB- CU-UP; the second gNB-CU-UP sends a DL AMBR Master Selection Acknowledgement to the first gNB-CU-UP; and the second gNB-CU-UP sends a Bearer Setup Response to the gNB-CU-CP.

9. The method of claim 6, comprising: the second gNB-CU-UP transmitting the measured data rate for DL data for the second gNB-CU-UP to the first gNB-CU-UP; the first gNB-CU-UP aggregating all DRBs carrying DL data for the UE; wherein when the aggregated DL UE AMBR is greater than a pre-specified DL UE AMBR for the UE, the DL-UE-AMBR module decides actions to be taken at the first and second gNB-CU-UPs; and the first gNB-CU-UP transmitting an H2AP-UE- AMBR- Action message via the H2 interface to the second gNB-CU-UP communicating an action to be taken at the second gNB- CU-UP.

10. The method of claim 1, wherein the 0-RAN further includes a third gNB-CU-UP, the method further comprising: obtaining, by the DL-UE-AMBR module, a measured data rate for DL data for the third gNB-CU-UP;computing, by the DL-UE-AMBR module, an aggregated DL data rate for the UE based on the first, second and third measured data rates; determining, by the DL-UE-AMBR module, a third action to be taken at the third gNB- CU-UP based on the third measured data rate and the computed aggregated DL data rate; and transmitting, by the DL-UE-AMBR module, a third control message to the third gNB- CU-UP including instructions to take the third action.

11. The method of claim 1, wherein the DL-UE-AMBR module resides in one of the gNB- CU-CP or the first gNB-CU-UP.

12. The method of claim 11, wherein the DL-UE-AMBR module resides in the gNB-CU-CP, the method further comprising: when the UE is connected to a first PDU session, the gNB-CU-CP allows the first gNB- CU-UP to enforce DL AMBR; and when the UE is connected to a second PDU session, determining by the gNB-CU-CP whether a slice identifier of the second PDU session is different than a slice identifier of the first PDU session.

13. The method of claim 12, the method further comprising: when the slice identifier of the second PDU session is determined to be different than a slice identifier of the first PDU session, triggering by the gNB-CU-CP a Data Usage Report for the UE to be sent from the first gNB-CU-UP and the second gNB-CU-UP to the gNB-CU-CP for the first and second gNB-CU-UPs carrying non-GBR traffic for different sessions.

14. The method of claim 11, wherein the DL-UE-AMBR module resides in the first gNB- CU-UP, which comprises a master gNB-CU-UP, the method further comprising: selecting the first gNB-CU-UP to be the master gNB-CU-UP based on the following steps: when a second PDU session is established, the gNB-CU-CP checks the slice identity of the second PDU session and determines which gNB-CU-UP will serve DRBs associated with the second PDU session;when the gNB-CU-CP determines the second gNB-CU-UP will serve DRBs associated with the second PDU session, the gNB-CU-CP provides a gNB-CU-UP ID of the first gNB-CU-UP to the second gNB-CU-UP as part of a bearer setup procedure between the gNB-CU-CP and the second gNB-CU-UP; the second gNB-CU-UP sends a DL AMBR Master Selection Request to the first gNB-CU-UP; the first gNB-CU-UP sends a DL AMBR Master Selection Response to the second gNB-CU-UP; the second gNB-CU-UP sends a DL AMBR Master Selection Acknowledgement to the first gNB-CU-UP; and the second gNB-CU-UP sends a Bearer Setup Response to the gNB-CU-CP.15 The method of claim 14, the method further comprising: providing an interface (H2 interface) comprising an H2 Control Plane (H2-C) between the first gNB-CU-UP and the second gNB-CU-UP; providing an H2 Application Protocol (H2AP) running on the H2-C; and exchanging control information and parameters between the first and second gNB-CU- UPs via the H2 interface.

16. The method of claim 15, comprising: the second gNB-CU-UP transmitting the measured data rate for DL data for the second gNB-CU-UP to the first gNB-CU-UP; the first gNB-CU-UP aggregating all DRBs carrying DL data for the UE; wherein when the aggregated DL UE AMBR is greater than a pre-specified DL UE AMBR for the UE, the DL-UE-AMBR module decides actions to be taken at the first and second gNB-CU-UPs; and the first gNB-CU-UP transmitting an H2AP-UE- AMBR- Action message via the H2 interface to the second gNB-CU-UP communicating an action to be taken at the second gNB- CU-UP.

17. The method of claim 11, wherein the O-RAN further includes a third gNB-CU-UP, themethod further comprising: obtaining, by the DL-UE-AMBR module, a measured data rate for DL data for the third gNB-CU-UP; computing, by the DL-UE-AMBR module, an aggregated DL data rate for the UE based on the first, second and third measured data rates; determining, by the DL-UE-AMBR module, a third action to be taken at the third gNB- CU-UP based on the third measured data rate and the computed aggregated DL data rate; and transmitting, by the DL-UE-AMBR module, a third control message to the third gNB- CU-UP including instructions to take the third action.

18. The method of claim 17, wherein the DL-UE-AMBR module resides in the gNB-CU-CP, the method further comprising: when the UE is connected to a first PDU session, the gNB-CU-CP allows the first gNB- CU-UP to enforce DL AMBR; when the UE is connected to a second PDU session, determining by the gNB-CU-CP whether a slice identifier of the second PDU session is different than a slice identifier of the first PDU session; and when the slice identifier of the second PDU session is determined to be different than a slice identifier of the first PDU session, triggering by the gNB-CU-CP a Data Usage Report for the UE to be sent from the first gNB-CU-UP and the second gNB-CU-UP to the gNB-CU-CP for the first and second gNB-CU-UPs carrying non-GBR traffic for different sessions.

19. The method of claim 17, wherein the DL-UE-AMBR module resides in the first gNB- CU-UP, which comprises a master gNB-CU-UP, the method further comprising: providing an interface (H2 interface) comprising an H2 Control Plane (H2-C) between the first gNB-CU-UP and the second gNB-CU-UP; providing an H2 Application Protocol (H2AP) running on the H2-C; and exchanging control information and parameters between the first and second gNB-CU- UPs via the H2 interface.

20. The method of claim 19, wherein the first gNB-CU-UP is selected to be the master gNB-CU-UP based on the following steps: when a second PDU session is established, the gNB-CU-CP checks the slice identity of the second PDU session and determines which gNB-CU-UP will serve DRBs associated with the second PDU session; when the gNB-CU-CP determines the second gNB-CU-UP will serve DRBs associated with the second PDU session, the gNB-CU-CP provides a gNB-CU-UP ID of the first gNB-CU- UP to the second gNB-CU-UP as part of a bearer setup procedure between the gNB-CU-CP and the second gNB-CU-UP; the second gNB-CU-UP sends a DL AMBR Master Selection Request to the first gNB- CU-UP; the first gNB-CU-UP sends a DL AMBR Master Selection Response to the second gNB- CU-UP; the second gNB-CU-UP sends a DL AMBR Master Selection Acknowledgement to the first gNB-CU-UP; and the second gNB-CU-UP sends a Bearer Setup Response to the gNB-CU-CP.

21. The method of claim 9, wherein the H2AP-UE- AMBR- Action message comprises at least one of: protocol version; message category indicator for UE AMBR enforcement; message identifier for H2AP-UE- AMBR- Action; identity of the first gNB-CU-UP; identity of the second gNB-CU-UP; message sequence number; identity of the UE or the associated H2-C for which the H2AP-UE- AMBR- Action message is being sent; session identity or slice identity for the UE for which DL data is being sent via the second gNB-CU-UP; timestamp of when the H2AP-UE-AMBR-Action message is sent; bitmap indicating presence or absence of delay or drop fields in the H2AP-UE-AMBR- Action message;specified action for the UE at the second gNB-CU-UP, the specified action comprising one of delay, drop or keep serving packets; number of bytes to be dropped, in case drop field is present; number of bytes to be delayed, in case delay field is present; time interval for dropping packets, in case drop field is present; and time interval for delaying packets, in case delay field is present.

Images