Patent Application
20250175835
This disclosure is directed generally to wireless communications, and particularly to a method, device, and system for resource status request and report in a wireless network.
Energy efficiency is a key performance index in the wireless communication network. Controlling power consumption and reducing energy cost is critical for developing and deploying a wireless communication network. Energy saving technology plays an essential role in achieving this goal. From a User Equipment (UE) perspective, UE battery life has great impact on user experience. From a network perspective, energy consumption is a key factor to consider for improving investment efficiency for operators. It is beneficial to have the capability to dynamically control the power consumption of various network elements and/or UEs yet still meet a performance requirement.
This disclosure is directed to a method, device, and system for saving network element power consumption in a wireless network.
In some embodiments, a method performed by a first Network Element (NE) in a wireless network is disclosed. The method may include: transmitting a first message to a second NE in the wireless network, the first message comprising a request for resource status information, wherein the request applies to at least one of the following levels: a beam level; a carrier level; a cell level; a network slice level; or a frequency range level.
In some embodiments, a method performed by a first Network Element (NE) in a wireless network is disclosed. The method may include: receiving a first message from a second NE in the wireless network, the first message comprising a request for resource status information, wherein the request applies to at least one of the following levels: a beam level; a carrier level; a cell level; a network slice level; or a frequency range level.
In some embodiments, there is network element comprising a processor and a memory, wherein the processor is configured to read code from the memory and implement any methods recited in any of the embodiments.
In some embodiments, a computer program product comprising a computer-readable program medium code stored thereupon, the code, when executed by a processor, causing the processor to implement any method recited in any of the embodiments.
The above embodiments and other aspects and alternatives of their implementations are described in greater detail in the drawings, the descriptions, and the claims below.
The gNB 124 may include a central unit (CU) and at least one distributed unit (DU). The CU and the DU may be co-located in a same location, or they may be split in different locations. The CU and the DU may be connected via an F1 interface. Alternatively, for an eNB which is capable of connecting to the 5G network, it may also be similarly divided into a CU and at least one DU, referred to as ng-eNB-CU and ng-eNB-DU, respectively. The ng-eNB-CU and the ng-eNB-DU may be connected via a W1 interface.
The wireless communication network 100 may include one or more tracking areas. A tracking area may include a set of cells managed by at least one base station. For example, tracking area 1 labeled as 140 includes cell 1, cell 2, and cell 3, and may further include more cells that may be managed by other base stations and not shown in
The wireless communication network 100 may be implemented as, for example, a 2G, 3G, 4G/LTE, or 5G cellular communication network. Correspondingly, the base stations 122 and 124 may be implemented as a 2G base station, a 3G NodeB, an LTE eNB, or a 5G NR gNB. The UE 160 may be implemented as mobile or fixed communication devices which are capable of accessing the wireless communication network 100. The UE 160 may include but is not limited to mobile phones, laptop computers, tablets, personal digital assistants, wearable devices, Internet of Things (IoT) devices, MTC/eMTC devices, distributed remote sensor devices, roadside assistant equipment, XR devices, and desktop computers. The UE 160 may also be generally referred to as a wireless communication device, or a wireless terminal. The UE 160 may support sidelink communication to another UE via a PC5 interface.
In some example implementations, as shown in
In an O-RAN deployment, similar information exchange procedure between gNB-CU and gNB-DU may be used for information exchange between RIC (e.g., non-RT RIC, or near-RT RIC) and O-CU, between RIC and O-DU, between Operation and Maintenance function/entity (OAM) and DU, or between OAM and CU.
While the description below focuses on cellular wireless communication systems as shown in
The electronic device 200 may also include system circuitry 204. System circuitry 204 may include processor(s) 221 and/or memory 222. Memory 222 may include an operating system 224, instructions 226, and parameters 228. Instructions 226 may be configured for the one or more of the processors 221 to perform the functions of the network node. The parameters 228 may include parameters to support execution of the instructions 226. For example, parameters may include network protocol settings, bandwidth parameters, radio frequency mapping assignments, and/or other parameters.
Referring to
Referring to
Energy consumption has become a key part of the operators' operating expenses (OPEX). In wireless networks, significant energy consumption comes from the radio access network and in particular from the hardware circuitries such as Active Antenna Unit (AAU), Radio Unit (RU), Remote Radio Unit (RRU), Power Amplifier (PA), and the like.
Usually, to save power consumption of a radio access (e.g. the gNB power consumption), the network equipment (e.g. cell, carrier, channel, slot, symbol, etc.) are dynamically shutoff during the light load duration with the condition that user experience (e.g. user perceived throughput, latency, UE power consumption, etc.) are not impacted.
In the wireless network, one mechanism for saving network energy consumption is to aggregate or transfer partial or all load from one network element to another network element and shutoff partial or all of relevant resources and their corresponding hardware circuitry. For example, multiple RAN nodes (e.g., gNBs, eNBs, or ng-eNBs, or a combination thereof) may interact with each other so each node may acquire a snapshot of resource status in other nodes. The resources may include: cell, carrier, beam, network slice, Bandwidth Part (BWP), bandwidth represented by a frequency range, slot, or symbol. With this snapshot, a RAN node may make a more informed decision, for example, when attempting to transfer certain traffic or service to another RAN node, and achieving a higher successful transfer rate while maintaining the service requirement such as a Quality of Service (QOS) requirement. As some load is offloaded, it is possible for the RAN node to dynamically shutdown certain resources and their corresponding hardware circuitry, to save energy. Load aggregation may be implemented in various levels corresponding to different granularities. For example, a whole carrier may be shutdown, if the traffic supported by the carrier may be covered by another carrier in another RAN node. For another example, a beam may be shutdown, if another beam may be utilized for offloading the traffic. For another example, an under-used frequency range may be shutdown, e.g., a frequency range not used by any UEs, to save the operating cost of related hardware. Therefore, it is important for the RAN nodes to be able to request and report resource status with each other. It is also important to implement the resource status exchange that covers different levels, such as cell level, carrier level, beam level, BWP level, slot/symbol level, etc.
Not only the resource status information may be exchanged between RAN nodes, it may also be exchanged between gNB-CU and gNB-DU. In an O-RAN deployment, the resource status information may also be exchanged between a RIC and an O-CU or an O-DU.
RAN node 1 may initiate the resource status reporting procedure by sending a resource status request message to RAN node 2 requesting RAN node 2 to start a measurement and report back measurement result. The RAN node 1 may include one of: a gNB, an eNB, an ng-eNB, or a gNB-CU. The RAN node 2 may include one of: a gNB, an eNB, an ng-eNB, or a gNB-DU. If an O-RAN is deployed in the wireless network, the RAN node 1 may further include a RIC, or an Operation and Maintenance (OAM) entity, and the RAN node 2 may further include a RIC, an O-CU, or an O-DU.
The resource status request may indicate a desired level for the report. The desired level may include at least one of:
For example, the beam level may apply to a report which targets resources per beam in a cell, or per beam identified in the resource request message, etc.
In one implementation, the level may be combined. For example, a desired level may include per carrier per cell, so the report may target carriers in a particular cell, or carriers in a list of cells. A level may also be a conditional level, for example, per cell that is used as a Primary cell, or a Secondary cell. An example list of desired levels is listed below:
The resource status request may apply to different types of resources, i.e., resources in different categories. The resource category may include at least one of:
Further, a resource status request may combine the resource category, and a desired level. Using “a number of active UEs” as a resource category, different combinations may be made. Various sample combinations are listed below:
In one implementation, the number of active UEs may be measured as the mean number of UEs in a beam, a carrier, or a cell, during a reporting periodicity, for which there is data available for uplink (UL) transmission (e.g., UL Data Radio Bearers (DRBs)), or there is data available for downlink (DL) transmission (e.g., DL DRBs), or both.
In one implementation, the number of active UEs may be measured as the maximum number of UEs in a beam, a carrier, or a cell, during a reporting periodicity, for which there is data available for uplink (UL) transmission (e.g., UL DRBs), or there is data available for downlink (DL) transmission (e.g., DL DRBs), or both.
In one implementation, a resource usage such as a UL GBR PRB usage, may be represented by one of: a resource occupied rate; or a resource un-occupied rate.
In one implementation, in the resource status request, a cell may be identified by a cell identifier, such as a New Radio Cell Global Identifier (NR CGI); a carrier may be identified by a carrier index; and a beam may be identified by its associated SSB index.
In one implementation, the resource request may target a list of objects, for example, by using an SSB index list (to represent a list of beams), a carrier index list (to represent a list of carriers), or a cell list (to represent a list of cells).
In one implementation, if the desired level is a network slice level, a per slice configuration may additionally be requested and be used to help assuring a dynamic Service Level Agreement (SLA) requirement.
In one implementation, if the desired level is a frequency range level, the frequency range may also be specified in the request. The requested frequency range may be configurable via, for example, additional signaling.
In one implementation, the RAN node 1 may request the resource status report to be sent in different manners. For example, the request may include an on-demand type. In this case, the RAN node 2 responds with a resource measurement result in one shot. The request may also include a conditional report type (event report type or triggered report type). In this case, the RAN node 2 sends the resource measurement result only when a condition is met or a threshold is reached. The condition or the threshold may be predetermined, and may be configurable. The request may also include a periodic report type. In this case, the RAN node 2 periodically sends the resource measurement result following a periodicity. The periodicity may be predetermined, and may be configurable.
RAN node 2, upon receiving the resource status request, determines that it supports measuring, collecting, or reporting partial or all the resource status information requested by the RAN node 1. RAN node 2 may reply with an acknowledgement to the RAN node 1.
In one implementation, if the resource status request is of on-demand type, the RAN node 2 may reply back with resource status information as requested. The resource status information may be sent in the same acknowledgement message, or via another message.
In one implementation, if the resource status request is of conditional report type, RAN node 2 will send resource status information to RAN node 1, if the report condition is met, or the threshold is reached. The resource status information may be sent via another message, which will be described in detail in later section.
In one implementation, if the resource status request is of periodic report type, RAN node 2 will send resource status information to RAN node 1 periodically. The resource status information may be sent via another message, which will be described in detail in later section.
In this embodiment, an error condition is encountered. Referring to
In this embodiment, RAN node 2 determines that it is not capable of measuring, collecting, or reporting partial or all the resource status information as requested by RAN node 1. The RAN node 2 may response to the request with a failure and a cause of the failure. For example, the cause may be partial of the resource status information is not supported, or all of the resource status information is not supported. The response may also include a list of resources and/or levels that RAN node 2 does not support.
This embodiment may serve as a continuation of embodiment 1. RAN node 2 receives a resource status request from RAN node 1, and RAN node 2 is capable of supporting the request. As described above, the resource status request may include a list of various resources combined with a corresponding level. For example, the request may include resource such as “number of active UEs”, and a corresponding level may include one of: per beam, per cell that is used as a Pcell, per beam per cell that is used as a Pcell, per carrier, per carrier per cell that is used as a Pcell, per carrier per beam per cell that is used as a Pcell, etc. the cell(s), and/or the carrier(s) may be explicitly specified in the request message.
Referring to
After receiving the resource status request message, RAN node 1 may start to measure or collect resource status information as requested. RAN node 2 may then send a resource status update message to RAN node 1, to report back the resource status information.
In one implementation, the resource status request is on-demand report type, then the resource status update message will be one shot.
In one implementation, the resource status request is conditional report type, then RAN node 2 check report condition and/or the threshold. If the report condition is met and/or the threshold is reached, the RAN node 2 may send the resource status update to RAN node 1.
In one implementation, the resource status request is periodic report type, RAN node 2 may send the resource status update periodically, following a predetermined and adjustable periodicity.
As an example, the resource status update may include:
For another example, the resource status update may include:
For another example, the resource status update may include:
For another example, the resource status update may include:
In one implementation, for the measurement result in the resource status update, a cell may be identified by a cell identifier, such as a NR CGI; a carrier may be identified by a carrier index; and a beam may be identified by its associated SSB index.
In one implementation, the measurement result may target a list of objects, for example, by using an SSB index list (to represent a list of beams), a carrier index list (to represent a list of carriers), or a cell list (to represent a list of cells).
Based on updated resource status information, RAN node 1 may now determine whether certain traffic or service may be aggregated/transferred, either within RAN node 1 itself, or to another RAN node. After traffic or service being transferred, RAN node 1 may further shutdown corresponding resources, and hardware circuitries; or RAN node 1 may switch its power saving mode, for example, to a deep sleep mode.
The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.
Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment/implementation” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment/implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.
In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and”, “or”, or “and/or,” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a,” “an,” or “the,” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for the existence of additional factors not necessarily expressly described, again, depending at least in part on context.
Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.
Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/CN2022/088620 | 4/22/2022 | WO |
