This application is a national U.S. patent application claiming foreign priority to Indian Patent Application number 202321063542, filed on Sep. 21, 2023, the entirety of which is incorporated herein by reference.
The present disclosure is related to 5G (e.g., New Radio (NR)) wireless networks, and relates more particularly to optimizing Bandwidth Part (BWP) management for 5G wireless networks.
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 106 (gNodeB) are shown in
NG-Radio Access Network (NG-RAN) architecture from 3GPP TS 38.401 is shown in
In this section, an overview Layer 2 (L2) of 5G NR will be provided. L2 of 5G NR is split into the following sublayers (in accordance with 3GPP TS 38.300):
1) Medium Access Control (MAC): The MAC sublayer offers Logical Channels (LCs) to the RLC sublayer. This MAC layer runs a MAC scheduler to schedule radio resources across different LCs (and their associated radio bearers).
2) Radio Link Control (RLC): The RLC sublayer offers 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.
3) Packet Data Convergence Protocol (PDCP): The PDCP sublayer offers Radio Bearers (RBs) to the SDAP sublayer. There are two types of Radio Bearers: Data Radio Bearers (DRBs) for data, and Signaling Radio Bearers (SRBs) for control plane.
4) Service Data Adaptation Protocol (SDAP): The SDAP offers QoS Flows to the 5GC (5G Core). This sublayer provides mapping between a QoS flow and a DRB. It marks QoS Flow Id in DL (downlink) as well as UL (uplink packets).
In the following sections, downlink (DL) and uplink (UL) physical channels and signals are discussed. A DL physical channel corresponds to a set of resource elements carrying information originating from higher layers. The following downlink physical channels are defined (see, e.g., 3GPP TS 38.211): 1) Physical Broadcast Channel (PBCH) is used to carry MIB; 2) Physical Downlink Control Channel (PDCCH) transfers Downlink Control Information (DCI), which is used by the Base Station packet scheduler to allocate both uplink and downlink resources (i.e., PUSCH and PDSCH resources, respectively) (note that DCI can also be used to provide uplink power control commands, configure the slot format, BWP switching, and to indicate that pre-emption has occurred); 3) Physical Downlink Shared Channel (PDSCH) is the physical downlink channel that carries user data.
An uplink (UL) physical channel corresponds to a set of resource elements carrying information originating from higher layers. The following uplink physical channels are defined (see, for example, 3GPP TS 38.211): 1) Physical Uplink Shared Channel (PUSCH) is the physical uplink channel that carries user data; 2) Physical Uplink Control Channel (PUCCH) is used to transport UCI (Uplink Control Information), for example, HARQ feedback, Channel State Information (SCI), and Scheduling Request (SR); and 3) Physical Random-Access Channel (PRACH) is used to carry random access preamble from UE 101 towards gNB 106.
Downlink reference signals include the following: 1) Channel State Information Reference Signal (CSI-RS) is used by the UE 101 to measure and report channel quality, for example, Channel Quality Indicator (CQI) reports; 2) Demodulation reference signal (DMRS) is specific to each UE 101 and is used to estimate the radio channel; and 3) Phase Tracking Reference Signal (PTRS), the main function of which is to track the phase of the Local Oscillator at transmitter and receiver.
Uplink reference signals include the following: 1) Demodulation reference signal (DMRS) is specific to each UE 101 and is used to estimate the radio channel; 2) Phase Tracking Reference Signal (PTRS), the main function of which is to track the phase of the Local Oscillator at transmitter and receiver; and 3) Sounding Reference Signal (SRS) is a reference signal for Uplink (i.e., transmitted by UE) so that gNB 106 can perform channel quality estimation for uplink.
Regarding subcarrier spacing (SCS), multiple Orthogonal Frequency Division Multiplexing (OFDM) numerologies (μ) are supported in NR, and subcarrier spacing of, for example, 15, 30, 60, 120 and 240 KHz are supported. Table 1 below provides information on numerologies supported in NR and cyclic prefix used for each numerology.
The 5G spectrum resources defined in the 3GPP protocol can be divided into two frequency ranges, FR1 and FR2: 1) FR1 includes Sub-6 Ghz bands (examples: 3500 MHz band (n78), 3700 MHz band (n77)); 2) FR2 includes frequencies above 24 GHZ, and is commonly referred to as millimeter wave (mmWave) (example: 24.25-27.5 GHz band (n257)).
Open Radio Access Network (O-RAN) is based on disaggregated components that are connected through open and standardized interfaces based on 3GPP NG-RAN. An overview of O-RAN with disaggregated RAN CU 151 (Centralized Unit), DU 152, and RU (Radio Unit), near-real-time Radio Intelligent Controller (near-RT RIC) 160 and non-RT RIC 161 is illustrated in
As shown in
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 could support eight cells (with eight cells in each sector on different frequency bands). One CU-CP (CU-Control Plane) can support multiple DUs 152 and thus multiple cells. For example, a CU-CP can support 1,000 cells and around 100,000 User Equipments (UEs 101). Each UE 101 can support multiple Data Radio Bearers (DRB) and there can be multiple instances of CU-UP (CU-User Plane) to serve these DRBs. For example, each UE 101 can support 4 DRBs, and 400,000 DRBs (corresponding to 100,000 UEs 101) can be served by five CU-UP instances (and one CU-CP instance).
The DU 152 can be located in a private data center, or it could be located at a cell-site. The CU 151 can also be in a private data center or even hosted on a public cloud system. The DU 152 and CU 151, which are typically located at different physical locations, can be tens of kilometers apart. The CU 151 communicates with a 5G core system, which can also be hosted in the same public cloud system (or could be hosted by a different cloud provider). A RU (Radio Unit) is located at a cell-site and communicates with the DU 152 via a front-haul (FH) interface.
The E2 nodes (CU 151 and DU 152) are connected to the near-real-time RIC 160 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 160. The application or service at the near-real-time RIC 160 that deploys the control actions and policies to the RAN are called xApps. The near-real-time RIC 160 is connected to the non-real-time RIC 161 using the A1 interface.
The E2 interface specifications facilitate the following: 1) connectivity between Near-RT RIC 160 and E2 Node supplied by different vendors; 2) exposure of selected E2 Node data (e.g., configuration information (cell configuration, supported slices, PLMNs, and the like), network measurements, context information, and the like) towards the Near-RT RIC 160; and 3) enabling the Near-RT RIC 160 to control selected functions on the E2 Node. The functions of the E2 interface are grouped into the following categories: 1) Near-RT RIC 160 services; 2) Near-RT RIC 160 support functions; and 3) O-RAN-specified E2 service models. These categories of functions will be discussed below.
Regarding Near-RT RIC 160 services, the Near-RT RIC 160 can use the following RIC services provided by an E2 node:
Near-RT RIC 160 support functions include: 1) Interface Management (E2 Setup, E2 Reset, E2 Node Configuration Update, E2 Removal, Reporting of General Error Situations); and 2) Near-RT RIC 160 Service Update, that is, an E2-Node-initiated procedure to inform Near-RT RIC 160 of changes to the list of supported Near-RT RIC 160 services and mapping of services to functions.
Regarding O-RAN-specified E2 service models, a given RAN function offers a set of services to be exposed over the E2 (REPORT, INSERT, CONTROL and/or POLICY) using E2AP. These services are offered using following service models:
In this section, PDU sessions, DRBs, and quality of service (QOS) flows will be discussed. In 5G networks, PDU connectivity service is a service that provides exchange of PDUs between a UE 101 and a data network identified by a Data Network Name (DNN). The PDU Connectivity service is supported via PDU sessions that are established upon request from the UE 101. 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 5QI (5G QoS Identifier). A PDU session has of the following: Data Radio Bearer that is between UE 101 and CU 151 in RAN; and an NG-U GTP tunnel that is between CU 151 and UPF (User Plane Function) in the core network.
The following should be noted for 3GPP 5G network architecture:
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 2A and Table 2B (which is a continuation of Table 2B) and the accompanying Notes shown below. The first column represents the 5QI value. The second column lists the different resource types, i.e., as one of Non-GBR, GBR, Delay-critical GBR. The third column (“Default Priority Level”) represents the priority level Priority5QI, for which the 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 for the time that a packet can be delayed between the UE 101 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 averaging window for GBR, delay critical GBR types.
For example, as shown in Table 2A, 5QI value 1 is of resource type GBR with the default priority value of 20, PDB of 100 ms, PER of 0.01, and averaging window of 2000 ms. Conversational voice falls under this category. Similarly, as shown in Table 2A, 5QI value 7 is of resource the Non-GBR with the default priority value of 70, PDB of 100 ms and PER of 0.001. Voice, video (live streaming), and interactive gaming fall under this category.
In this section, Bandwidth Part (BWP) is discussed. A BWP is a set of contiguous Common Resource Blocks. A BWP can include all Common Resource Blocks within the channel bandwidth, or a subset of Common Resource Blocks. Common Resource Blocks are the set of Resource Blocks which occupy the channel bandwidth. There is a set of Common Resource Blocks for each subcarrier spacing. A UE 101 can be configured with up to four bandwidth parts in the downlink, with a single downlink bandwidth part being active at a given time. The UE 101 is not expected to receive PDSCH, PDCCH, or CSI-RS (except for RRM) outside an active bandwidth part. A UE 101 can be configured with up to four bandwidth parts in the uplink, with a single uplink bandwidth part being active at a given time. If a UE 101 is configured with a supplementary uplink, the UE 101 can be additionally configured with up to four bandwidth parts in the supplementary uplink, with a single supplementary uplink bandwidth part being active at a given time. The UE 101 does not transmit PUSCH or PUCCH outside an active bandwidth part. For an active cell, the UE 101 does not transmit SRS outside an active bandwidth part. A UE 101 can complete measurements outside the active bandwidth part, but this can require the use of Measurement Gaps.
Each BWP has specific physical characteristics including frequency location, bandwidth, SCS, and cyclic prefix. UE 101 configuration needs to convey at least the physical characteristics of the associated BWP. The IE BWP is used to configure generic parameters of a bandwidth part, as follows:
The field “locationAndBandwidth” indicates the frequency domain location and bandwidth of this BWP. The value of the field “locationAndBandwidth” is interpreted as resource indicator value (RIV) as defined in TS 38.214, with assumptions as described in TS 38.213, clause 12, i.e., setting NBWPSize=275. A RIV corresponds to a starting virtual resource block (RBstart) and a length in terms of contiguously allocated resource blocks LRBs, i.e.,
In this section, different types of BWP (e.g., initial BWP, first active DL/UL BWP, and default BWP) are discussed. The initial (DL and UL) BWPs are used at least for initial access before radio resource control (RRC) connection is established. An initial BWP has index zero and is referred to as BWP #0. To access the system, the UE 101 needs to further read system information block 1 (SIB1), which carries important information including the initial DL/UL BWP configuration. The initialDownlinkBWP parameter structure can also be provided to the UE 101 using dedicated signaling. The first active (DL and UL) BWPs can be configured for primary Cell (PCell) or a secondary cell (SCell). The first active DL and UL BWPs are the active DL and UL BWPs upon RRC configuration (or reconfiguration) for a PCell or activation of a SCell.
For a serving cell, the network can configure the UE 101 with a BWP inactivity timer. UE 101 can switch its active BWP to a default BWP to save power when BWP inactivity timer expires. If a default BWP is not configured, the UE 101 uses the initial DL BWP as the default DL BWP. For unpaired spectrum, when the UE 101 switches its active DL BWP to the default DL BWP, the active UL BWP is also switched accordingly since the BWP switching for TDD is common for both DL and UL. For each serving cell, the network configures at least an initial downlink bandwidth part and one (if the serving cell is configured with an uplink) or two (if using supplementary uplink (SUL)) initial uplink bandwidth parts. Furthermore, the network can configure additional uplink and downlink bandwidth parts for a serving cell.
In this section, BWP switching, activation and deactivation are discussed. Different mechanism for BWP switching include: RRC Reconfiguration BWP Switch; DCI-Based BWP Switch; and Timer-Based BWP Switch.
The BWP switching for a Serving Cell is used to activate an inactive BWP and deactivate an active BWP one at a time. UE 101 completes the switch of active DL and/or UL BWP within the required BWP switch delay. BWP switch delay requirements are listed in Table 3 below (e.g., based on 3GPP TS 38.133) for both DCI-based switch and timer-based BWP switch.
Note 1
As per 3GPP TS 38.306, the following UE 101 capabilities are considered by gNB 106: bwp-DiffNumerology; bwp-SameNumerology; bwp-WithoutRestriction; bwp-SwitchingDelay; and Supported Bandwidth.
As explained above in discussing the BWP concept in 5G NR, the UE 101 is not required to transmit or receive any signal outside the frequency range of the active BWP. A gNB 106 configures a UE 101 with a set of BWPs and can potentially switch BWP as and when needed. When the number of UEs handled by a gNB 106 is less, BWP configuration and switching can be done by static policies, but when the number of UEs 101 handled by a gNB 106 becomes very high, static policies are not beneficial. Optimal selection of BWPs for a cell and for each UE 101 enables energy savings both at the gNB 106 and at each UE 101.
In general, BWP management is done so as to address the following aspects:
In this section, conventional approaches for BWP management are discussed. 3GPP TR 38.864 describes two methods for BWP management to improve network energy saving in frequency domain; 1) Adaptation of bandwidth part of UE(s) within a carrier; and 2) Adaptation of bandwidth of UE(s) within a BWP. In addition, a third approach, Cell-level BWP configuration from near-RT RIC 160, can be utilized.
1) Adaptation of bandwidth part of UE(s) within a carrier: The dynamic adaptation of transmit (Tx) BW of gNB 106 radio frequency (RF) by BWP switching in a cell could achieve network energy saving. This method supports enhancements to enable UE-group-common or cell-specific BWP configuration and/or switching. The main benefit compared to other conventional BWP switch schemes is signaling overhead reduction. For SPS PDSCH reception, type-2 CG PUSCH transmission, and SP-CSI reporting on PUSCH, once BWP is switched, they should be reactivated by activation DCI. This method also supports enhancements to enable SPS PDSCH reception/Type-2 CG PUSCH transmission/SP-CSI reporting on PUSCH without reactivation after the BWP switching.
The above method (adaptation of BWP of UE(s) within a carrier) tries to achieve network energy saving by enabling UE-group-common or cell-specific BWP configuration and/or switching. This can be beneficial in some cases, but it will impact QoS performance of the UEs in that common group because different UEs can have different service requirements. Having a common BWP configuration/switching for a group of UEs will impact UE 101 energy saving because some of the UEs can be served with BWP having less bandwidth than BWP chosen by UE-common-group signaling. For example, let's assume: i) BWP (Id1, 50 MHz, SCS—15 KHz) is currently active for 10 UEs; and ii) 9 out of 10 UEs can be served with 10 MHz, and 1 UE 101 has a requirement of 40 MHz. In the above method, the network may just deactivate 10 MHz and signal all the UEs to adapt to 40 MHz. This will not help in UE 101 power saving because the 9 out of 10 UEs can operate with 10 MHz bandwidth, but UE 101 adapts to a 40 MHz bandwidth.
2) Adaptation of bandwidth of UE(s) within a BWP: This method supports enhancements to enable group-common signaling to adapt the bandwidth of active BWP and continue operating in same BWP. Some frequency resources within the active BWP can be deactivated. In this method, one needs to select a number of frequency resources and part of BWP resources which needs to be deactivated. All the UEs in that BWP will have to adapt the bandwidth of active BWP informed by group-common signaling. This may help in network energy saving to some extent, but this approach does not necessarily result in UE 101 power/energy saving. For one scenario given in 3GPP TR 38.864, severe throughput loss is observed along with increase in overall power consumption when operating bandwidth is reduced. This is due to reduction of maximum throughput of the UEs 101 and the resulting delay in completing the transmissions to the UEs 101. The longer activity in time domain results in power consumption which exceeds the amount of power saving from using less bandwidth (and transmit power).
3) Cell-level BWP configuration from near-RT RIC 160: E2SM-CCC specification (O-RAN.WG3.E2SM-CCC-R003-v01.01) has a provision for exposing and controlling cell-level BWP configuration for near-RT RIC 160 from E2 nodes. E2 REPORT services can be used to expose node-level and cell-level configuration information. E2 CONTROL services can be used to initiate control and/or configuration of node-level and cell-level parameters (including BWP). However, there is no provision for UE-level BWP configuration and dynamically updating the active BWP for each UE.
Accordingly, it would be advantageous to provide a system and method to achieve optimized management of BWPs in 5G networks.
Accordingly, described herein are implementations of a system and method to optimize management of BWPs in 5G networks.
According to an example method, a BWP analytics module (e.g., hosted in DU 152, CU 151, RIC server, OAM server, or an analytics server) analyzes various traffic parameters, channel conditions, and BWP parameters to perform dynamic BWP management in the network.
According to an example sub-variant of Method 1 (Method 1A), one or more of the following parameters (among others) are analyzed by the BWP analytics module at the near-RT-RIC 160 server to find the optimal set of BWPs:
According to an example sub-variant of Method 1 (Method 1B), one or more of the following parameters (among others) are analyzed by the BWP analytics module at the at the gNB-DU 152 to find the optimal set of BWPs:
According to an example sub-variant of Method 2 (Method 2A), the BWP analytics module (e.g., at near-RT RIC 160 or gNB-DU 152) can i) periodically analyze, for example, PRB utilization difference, delay violation percentage, throughput performance, and/or interference levels of each BWP to classify each BWP, and ii) periodically analyze, for example, PRB utilization, throughput, and/or delay requirements of each UE 101 into one of several classifications.
According to an example sub-variant of Method 2 (method 2B), the BWP analytics module will dynamically select BWPs per a given cell and the active BWP of a UE 101 in the given cell based on UE 101 performance in its current active BWP.
According to an example sub-variant of Method 2 (method 2C), the BWP analytics module will address a sub-optimal BWP performance scenario by selectively offloading the UEs 101 in each BWP to other BWPs, as needed, that is, providing optimization at cell-level (gNB 106 level) by distributing UEs across BWPs in the cell.
For this application the following terms and definitions shall apply:
The term “network” as used herein includes both networks and internetworks of all kinds, including the Internet, and is not limited to any particular type of network or inter-network.
The terms “first” and “second” are used to distinguish one element, set, data, object or thing from another, and are not used to designate relative position or arrangement in time.
The terms “coupled”, “coupled to”, “coupled with”, “connected”, “connected to”, and “connected with” as used herein each mean a relationship between or among two or more devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, and/or means, constituting any one or more of (a) a connection, whether direct or through one or more other devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, or means, (b) a communications relationship, whether direct or through one or more other devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, or means, and/or (c) a functional relationship in which the operation of any one or more devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, or means depends, in whole or in part, on the operation of any one or more others thereof.
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.
In example embodiments of the systems and methods according to the present disclosure, BWP analytics module analyzes various traffic parameters, channel conditions, and BWP parameters to implement dynamic BWP management in the network. The BWP analytics module can be hosted, e.g., in gNB 106 (DU 152 or CU 151), at an RIC server, or as a separate OAM or analytics server. For the following description, assume BWPset(t)={BWP0, BWP1 . . . , BWPm}, where BWPi, i=0, 1, 2 . . . , m, are the BWPs configured per cell at gNB-DU 152 at a given point of time. For example, an initial BWP can be denoted as BWP0, and one other BWP, e.g., BWP1, can act as an active BWP for UEs in DL and UL.
In an example embodiment of the method (“Method 1”) according to the present disclosure, the BWP analytics module can be located at either non-real-time (non-RT) RIC 161 or near-real-time (near-RT) RIC 160. Depending on the use case, a network operator can decide to use non-RT 161 or near-RT RIC 160. For the non-RT RIC 161 case, various performance parameters are communicated from gNB 106 to non-RT RIC 161 for analysis (e.g., as described below in connection with Method 2) and decisions are communicated to gNB 106 via the O1 interface.
In a first sub-variant of example Method 1 (Method 1A), a near-RT RIC 160 subscribes to the following performance measurements from the DU, as illustrated in
The above-listed performance measurement parameters are measured or computed every measurement interval T, and communicated from the DU 152 to the near-RT-RIC 160 server. Alternatively, these parameters could be communicated to the near-RT-RIC 160 server based on some specified events. Along with the above parameters, current BWP information of the cell and BWP configured for each UE 101 are communicated to the near-RT-RIC 160 server, and these parameters are analyzed at the near-RT-RIC 160 server for the BWP analytics module to determine the optimal set of BWPs. For finding the optimal set, the near-RT-RIC 160 server estimates the thresholds (e.g., as explained in connection with Method 2A below) for the performance measurements based on current BWP information and channel conditions. When the reported performance measurements exceed these threshold values, the BWP analytics module can perform various optimizations. After this, the near-RT-RIC 160 sends the updated BWP set to DU using E2 Control service.
In a second sub-variant of example Method 1 (Method 1B), the BWP analytics module hosted at the gNB-DU 152 analyzes the following performance measurements and BWP information already present at DU 152 to perform BWP management:
In a second example embodiment of the method (“Method 2”) according to the present disclosure, the BWP analytics module performs BWP analytics to categorize the BWPS. According to a first sub-variant of Method 2 (Method 2A), BWP data analysis and classification for gNB 106 UE 101 are provided. BWP's physical characteristics, for example, frequency location, bandwidth, and SCS can be dynamically configured. The number of BWPs per cell and active BWP of each UE 101 are updated dynamically to enable optimal performance for the network and UE 101. The BWP analytics module, e.g., hosted at the near-RT RIC 160 or at the gNB-DU 152, analyzes the performance measurements and the BWP information received, and the BWP analytics module estimates BWP and UE-level thresholds. These thresholds are used to optimally select an active BWP for the UE 101. The BWP analytics module periodically analyzes, for example, every n milliseconds (e.g., n=100 ms), the PRB utilization, delay violation, throughput performance, and/or interference levels of each BWP. The BWP analytics module categorizes the BWPs based on the values of these parameter factors (e.g., BWP PRB utilization factor).
In this section, BWP classification (from gNB 106 point of view) is described.
In this section, classification of UE 101 by considering its current active BWPs is described. BWP analytics module periodically analyzes, for example, every n milliseconds (for example, n=100 ms), PRB utilization, throughput, and delay requirements of each UE 101 and classify the UEs into following classes:
In addition, for each interval of n ms, e.g., n=100 ms, BWP analytics module analyzes the performance measurements and classify UEs 101 as follows:
The above-described classifications are summarized in Table 4 below.
The thresholds for PRB utilization, throughput, and delay requirements to determine UE 101 BWP class can be optimized in an iterative approach, for example, using BWP switching failure counters, as explained below.
BWP switching failure counters, which are counters provided in the present disclosure to help manage BWP performance in the cellular system, include the following:
According to a second sub-variant of Method 2 (Method 2B), dynamic selection of BWPs per cell and BWPs per UE 101 in the DU 152 are provided. Assume BWPset(t)={BWP0, BWP1 . . . , BWPm}, where BWPi, i=0, 1, 2 . . . , m are the BWPs configured at a given point of time per cell at gNB-DU 152. The initial BWP can be used as default BWP or BWPset can contain a BWP (e.g., with small bandwidth) which can be configured as default BWP. A UE 101 can be configured with up to 4 downlink BWPs per carrier (cell) and up to 4 uplink BWPs per carrier. A gNB-DU 152 selects up to or at most 4 BWPs from BWPset for each UE. For initial selection and configuration, one of the BWPs is selected such that the BWP in BWPset having a bandwidth equal to the maximum channel bandwidth supported by the UE 101 (provided the maximum channel bandwidth supported by UE 101 is less than the actual channel bandwidth). If UE's maximum supported bandwidth is greater than the actual channel bandwidth, then a BWP with maximum bandwidth in BWPset will be selected.
Method 2B provides dynamically selecting BWPs per cell and the active BWP of a UE 101 in that cell based on UE 101 performance in its current active BWP. Based on the BWP and UE 101 classification methods mentioned in Method 2A, every n*t second and for each BWP, the BWP analytics module will check the number of UEs 101 per each BWP class to implement the following actions:
Based on the percentage of UEs in each class in each BWP and actions specified for each class, the BWP analytics module can execute the following steps every n*t second as needed:
When UE 101 is configured with Configured grant or SPS resources in the current active BWP, the BWP analytics module ensures that the new active BWP selected has enough resources to support configured grant or SPS. If none of the other BWPs has enough resources for configured grant or SPS, the UE's active BWP should not be switched.
Some examples showing actions taken by BWP analytics module running at near-RT RIC 160 or gNB-DU 152 are given below:
A) Example I: Assume that BWPset is supporting following bandwidths: {15 MHz, 25 MHZ, 30 MHz, 50 MHz, 60 MHz}. After analyzing various performance measures communicated from each UE, the BWP analytics module finds that a set of UEs in BWP Id 3 (e.g., BWP Id3, Width=60 MHz, SCS=15 KHz) are classified as resource light and it is estimated that these UEs can be served with BWP of 40 MHz BW. The BWP analytics module decides to add a new BWP entry in BWPset with a bandwidth of 40 MHz (if this is not already part of the BWPset). After that, this new BWP can be configured for these UEs, and the UEs will be switched to this new BWP.
B) Example II: A UE 101 with 5QI2 (packet delay budget: 200 ms) is configured with BWP Id 1 (e.g., BWP Id1, Width=50 MHz, SCS=15 KHz) and this UE 101 is experiencing overall delay of 220 ms, but it is getting good throughput. The UE 101 is classified as resource-delay-intensive. In this case, the BWP analytics module decides to add a new BWP, e.g., BWP Id6 (with width=50 MHz, SCS=30 KHz) with higher SCS, and this BWP Id6 is configured for that UE. Alternatively, the BWP analytics module modifies the existing BWP Id1 (i.e., BWP Id1, Width=50 MHz, SCS modified to 30 KHz), and the updated configuration needs to be sent to all the UEs configured with this BWP.
According to a third sub-variant of Method 2 (Method 2C), distribution of UEs across BWPs is provided. In an example scenario, each cell in gNB-DU 152 has multiple BWPs, and each BWP has multiple active UEs. In this scenario, BWP performance is not good due to following reasons: 1) sometimes UEs 101 in a particular BWP can experience less throughput (or high latency) due to bad channel conditions in that BWP, i.e., BWP is congested; 2) BWP can be overloaded with UEs 101 more than it can serve; and 3) interference levels of PRBs in a BWP are very high, which will reduce the overall throughput of the BWP. Method 2C provides a solution to address the above problems by using the BWP classification mentioned in Method 2A and optimizing BWP's performance by offloading the UEs 101 in each BWP to other BWPs as needed.
Assume BWPset={BWP0, BWP1 . . . , BWPm} where BWPi, i=0, 1, 2 . . . , m are the BWPs configured per cell at gNB-DU 152. As mentioned in connection with Method 2A, BWPs is classified as overloaded/underloaded, congested/uncongested, and the like. The BWP analytics module can offload UEs in one BWP to other appropriate BWPs (based on UE 101 capabilities) whenever needed. Some example cases are described below.
Example I: A first BWP (BWP Id1, Width=20 MHz, SCS=15 KHz) has 10 UEs. A second BWP (BWP Id2, Width=30 MHz, SCS=15 KHz) has 5 UEs. Assume that BWP Id1 is classified as overloaded for consecutive time intervals, in which case the BWP analytics module will offload some of the UEs from this BWP Id1 to another appropriate BWP (e.g., BWP Id2 in this case).
Example II: In another example, UEs in a BWP (BWP Id1, Width=20 MHz, SCS=15 KHz) are experiencing high packet delay, i.e., BWP is classified as congested. In this case, the BWP analytics module can offload some of the UEs to different BWP with higher SCS.
Example III: If interference levels in a BWP are above a certain threshold (e.g., as described in connection with Method 2A), the BWP analytics module modifies the BWP configuration of the BWP, either by shifting the location of BWP (i.e., start RB) or by reducing the BWP width (that is, number of RBs). The BWP analytics module can even offload some of the UEs in this BWP to another suitable BWP to avoid scheduling UEs 101 with PRBs having high interference.
By distributing UEs 101 across BWPs periodically, the overall performance of the cell can be improved. If PRB utilization and/or the number of active UEs 101 are low across BWPs in the cell, BWP analytics module can move all the UEs 101 (based on QoS requirements) gradually to a single BWP having sufficient bandwidth. This enables the network to save energy/power by operating in narrow bandwidth (compared to cell bandwidth) and handling a smaller number of BWPs (scheduling complexity decreases).
In short, Method 2B performs optimizations at BWP-level by optimizing BWP configuration and switching decisions based on UE 101 performance. Method 2C performs optimization at cell-level (gNB 106 level) by distributing UEs across BWPs in the cell. These proposed methods consider PRB utilization, throughput, packet delay/latency, and so on, in addition to having cell and UE-level context (current BWP configuration and UE 101 capabilities), to perform BWP management in an improved way. In the above-described methods, one of the criteria for selection of the UEs 101 that need to be offloaded can be bwp-SwitchingDelay capability of the UEs, type1 UEs 101 can be preferred for offloading, as their BWP Switching delay will be less.
In addition to above, the following should be noted for energy saving of gNodeB and UE 101 in connection with the above-described methods. The disclosed methods optimize BWP configuration and dynamic switching to address network as well as UE 101 energy savings. At the same time, the disclosed methods also consider QoS aspects of different applications.
For power saving in connection with UE 101, the following can be implemented:
For power saving in connection with gNB 106, the gNB 106 can potentially shut down (or lower frequency of) some of its cores if BWP selection and management is done efficiently (e.g., when we can handle all UEs with suitable BWPs in x MHz where spectrum is for y MHz (with x<y)).
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. For example, although the example methods have been described in the context of 5G cellular networks, the example methods are equally applicable for 6G and other similar wireless networks in which BWP concept is applicable. 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.
For the sake of completeness, a list of abbreviations used in the present specification is provided below:
Number | Date | Country | Kind |
---|---|---|---|
202321063542 | Sep 2023 | IN | national |