Technical Field

The present disclosure relates to wireless communications, and in particular, to the exchange of information related to energy harvesting capabilities of wireless devices between the wireless network and an application layer.

Background

The Third Generation Partnership Project (3GPP) has developed and is developing standards for Fourth Generation (4G) (also referred to as Long Term Evolution (LTE)) and Fifth Generation (5G) (also referred to as New Radio (NR)) wireless communication systems. Such systems provide, among other features, broadband communication between network nodes, such as base stations, and mobile wireless devices (WD), as well as communication between network nodes and between WDs.

The next paradigm shift in processing and manufacturing is the Industry 4.0 in which factories are automated and made much more flexible and dynamic with the help of wireless connectivity. This includes real-time control of robots and machines using time-critical machine-type communication (cMTC) and improved observability, control, and error detection with the help of large numbers of more simple actuators and sensors (massive machine-type communication or mMTC). For cMTC support, URLLC (ultra-reliable low-latency communication) was introduced in 3GPP Release 15 (Rel 15) for both LTE (Long-Term Evolution) and NR (New Radio), and NR URLLC is further enhanced in 3GPP Release 16 within the enhanced URLLC (eURLLC) and Industrial Internet of Things (loT) work items.

For mMTC and low power wide area (LPWA) support, 3GPP introduced both Narrowband Internet-of-Things (NB-IoT) and Long-Term Evolution for Machine-Type Communications (LTE-MTC, or LTE-M) in 3GPP Release 13. These technologies have been further enhanced through releases up until and including the ongoing 3GPP Release 17 work.

NR was introduced in 3GPP Release 15 and focused on the enhanced mobile broadband (eMBB) and cMTC. However, there are still several other use cases whose requirements are higher than those of LPWA networks (i.e., LTE-M/NB-IoT) but lower than those of URLLC and eMBB. In order to support such use cases which are inbetween eMBB, URLLC, and mMTC, 3GPP has studied reduced capability NR devices (RedCap) in Release 17 (i.e., 3GPP Technical Reference 38.875 v.17.0.0). The RedCap study item in 3GPP was performed, i.e., RP-210918, "Revised WID on support of reduced capability NR devices", Nokia and Ericsson, 3GPP TSG RAN #91e. A corresponding RedCap work item was started and is expected to be finalized in September 2022. The RedCap wireless devices (i.e., User Equipment devices (UEs)) should have lower cost, lower complexity, a longer battery life and potentially a smaller form factor than legacy NR wireless device. Therefore, in 3GPP Rel 17, different complexity reduction features, such as reduced maximum wireless device bandwidth, reduced minimum number of receiver branches, reduced maximum number of downlink (DL) Multiple-Input Multiple-Output (MIMO) layers, relaxed downlink modulation order, and support of half-duplex FDD operation may be specified for RedCap wireless devices.

The discussion on potential enhancements for RedCap in 3GPP Rel 18 are ongoing in 3GPP. One of the potential enhancements is related to support of RedCap wireless devices operating on harvested energy. The energy harvesting wireless devices are getting more attention as they can be self-sufficient, "green" and environmentally friendly, and ideally able to perpetually perform operations. The source of the harvested energy may be, for example, vibration, radio waves, indoor office light, etc. A typical characteristic of energy harvesting wireless devices is that the amount of energy that is available to communicate with the network is often varying drastically over time and is more stochastic.

In general, the harvested energy cannot be used directly by wireless device in that the wireless device may need to accumulate enough energy to perform an operation, e.g., a wireless transmission. Therefore, energy harvesting wireless devices need rechargeable batteries or capacitors that can make the storage and management of the energy possible.

The capability of the energy harvesting wireless devices may vary depending on several factors, such as the energy harvesting technology, the environment where the wireless device is deployed in, the maximum amount of stored energy, the needed charging time and the form-factor of the wireless device, the signal strength in case of radio frequency (RF) harvesting, the efficiency of the harvester, the sensitivity of the harvester (i.e., the minimum power required to harvest energy), etc. As part of the future-looking 6G research a concept called 'Zero-energy Internet- of-things' (ZE-IoT) is being developed. The focus is in on loT devices of very small form factor and with ultra-low power consumption to enable operation based on both energy-harvesting and back-scattering. I.e., instead of relying on energy for communication being provided by a battery it is instead harvested from an ambient source, such as vibrations, solar power, RF, etc. (harvesting), or a charge carrier wave is provided to the device which is modulated and reflected back to a reader (back- scattering). This to enable energy autonomous operation during the lifetime of the devices without need for manual replacement or charging of batteries. Compared to existing radio access technologies this puts new requirements on the radio interface and to protocols.

The incorporation of ultra-low power devices in 3GPP, e.g., based on energy harvesting or back-scattering, requires substantial changes both to the air interface, procedures and protocols. The application layer would typically be unaware of the type of connectivity used, i.e., it would behave the same no matter if a device is connected using wired ethernet, wireless Wi-Fi, 3GPP radio access, etc. However, if the device is operating on harvested energy it puts certain bounds on the traffic that the device can cope with. For example, the energy consumption for data transmission to and from the device cannot be larger than the energy harvested from the environment during the same amount of time.

Summary

Various embodiments described in the present disclosure provide for a means by which the core network of a wireless network can exchange information with an application layer in the cloud and on the User Equipment device (UE) itself so that the application layer and the core network can optimally control the power management of the UE and wireless network to extend battery life and useful operating time of the UE. When the application layer is informed of the energy harvesting capabilities and parameters of the devices, it can optimize the traffic and communications and configure applications in a way which the device can manage given its energy source constraints, for example how often periodic sensor data can be reported.

One of the advantages of the methods disclosed herein is that with knowledge about the capabilities and limitations of the energy source (e.g., energy-harvesting), the application layer can better adjust not to trigger transmissions, requests, retransmissions, etc. when the UE cannot handle them and therefore avoid causing unnecessary traffic and signaling overhead in the network.

In an embodiment, a method of operation of a core network node of a wireless network is provided. The method can include sending or receiving energy harvesting information to or from an application server, the energy harvesting information comprising information about one or more energy harvesting related capabilities of a particular UE hosting an associated application client, wherein the energy harvesting information is used by a receiving entity of the application server or the core network node to control a communication to the UE to match an energy harvesting capability of the UE based on the energy harvesting information.

In another embodiment, a core network node of a wireless network for exchanging energy harvesting information can be provided where the core network node includes processing circuitry that is configured to cause the core network node to perform various operations. The operations can include sending or receiving energy harvesting information to or from an application server, the energy harvesting information comprising information about one or more energy harvesting related capabilities of a particular UE hosting an associated application client, wherein the energy harvesting information is used by a receiving entity of the application server or the core network node to control a communication to the UE to match an energy harvesting capability of the UE based on the energy harvesting information.

In another embodiment, method of operation of an application server to perform an energy management modification can be provided. The method can include sending to or receiving from a core network node energy harvesting information comprising information about one or more energy harvesting related capabilities of a particular UE hosting an associated application client, wherein the energy harvesting information is used by a receiving entity of the application server or the core network node to control a communication to the UE to match an energy harvesting capability of the UE based on the energy harvesting information.

In another embodiment, an application server can be provided to perform an energy management modification. The application server can include processing circuitry to perform various operations which can include sending or receiving from a core network node energy harvesting information comprising information about one or more energy harvesting related capabilities of a particular UE hosting an associated application client wherein the energy harvesting information is used by a receiving entity of the application server or the core network node to control a communication to the UE to match an energy harvesting capability of the UE based on the energy harvesting information.

Brief Description of the Drawings

The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

Figure 1 illustrates one example of a cellular communications system according to some embodiments of the present disclosure;

Figures 2 and 3 illustrate example embodiments in which the cellular communication system of Figure 1 is a Fifth Generation (5G) System (5GS);

Figure 4 illustrates an exemplary wireless communication system that can exchange energy harvesting information with an application layer according to some embodiments of the present disclosure;

Figure 5 illustrates a graph depicting data traffic limitations profiles for devices operating on harvested energy according to some embodiments of the present disclosure.

Figure 6 illustrates a message sequence chart for exchanging energy harvesting information between a wireless communication system and an application layer according to some embodiments of the present disclosure;

Figure 7 is a schematic block diagram of a network node according to some embodiments of the present disclosure;

Figure 8 is a schematic block diagram that illustrates a virtualized embodiment of the network node of Figure 7 according to some embodiments of the present disclosure;

Figure 9 is a schematic block diagram of the network node of Figure 7 according to some other embodiments of the present disclosure;

Figure 10 is a schematic block diagram of a User Equipment (UE) device according to some embodiments of the present disclosure;

Figure 11 is a schematic block diagram of the UE of Figure 10 according to some other embodiments of the present disclosure; and Figure 12 is a schematic block diagram of an application server according to some embodiments of the present disclosure.

Detailed Description

The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

Communication Device: As used herein, a "communication device" is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehiclemounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.

User Equipment Device (UE): One type of UE is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a UE include, but are not limited to: a UE in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device. Such UEs may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The UE may be a portable, hand-held, computer-comprised, or vehiclemounted mobile device, enabled to communicate voice and/or data via a wireless connection. The UEs described and disclosed herein include energy harvesting functionalities and/or capabilities.

Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

Note that, in the description herein, reference may be made to the term "cell"; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

Various embodiments described in the present disclosure provide for a means by which the core network of a wireless network can exchange information with an application layer in the cloud and on the User Equipment device (UE) itself so that the application layer and the core network can optimally control the power management of the UE and wireless network to extend battery life and useful operating time of the UE. When the application layer is informed of the energy harvesting capabilities and parameters of the devices, it can optimize the traffic and communications and configure applications in a way which the device can manage given its energy source constraints, for example how often periodic sensor data can be reported.

To achieve longer range than for backscattering communication solutions, such as RFID, battery-less devices will have to rely on active transmission and reception, in which case energy storage in the UE is required, e.g., a re-chargeable battery or supercapacitor charged by energy harvesting. The energy harvesting may require long periods, during which the device may be energy depleted and cannot transmit or receive data. For this type of devices, it is therefore beneficial for the overall service and performance to know better when the device is expected to be available. One of the advantages of the methods disclosed herein is that with knowledge about the capabilities and limitations of the energy source (e.g., energy-harvesting), the application layer can better adjust not to trigger transmissions, requests, retransmissions, etc. when the UE cannot handle them and therefore avoid causing unnecessary traffic and signaling overhead in the network.

Already today there is some support in mobile device operating systems (OS) for local Application Programming Interfaces (APIs) in the UE, linking Application and Modem information/behavior. For example, it can be configured if apps should only send data when the UE is in a "connected" mode to avoid triggering unnecessary transitions to "connected" for power saving purposes (i.e., for push notification etc.). The intention here is to expand this functionality to provide further information to the application layer about whether the UE is operating using energy-harvesting, the energy storage capacity, the energy-harvesting capabilities, etc. In this way the application layer can make conscious decisions taking this information in to account, not to trigger data transmissions and requests when the UE cannot communicate (causing unnecessary signaling overhead and interference in the network). The APIs mentioned above refer to informing the application layer in the UE, but the intention here is also to be able to provide information in general about energy-harvesting parameters from the 3GPP network to the application layer, also up to the server in the cloud on top of the 3GPP Core Network (CN).

Figure 1 illustrates one example of a cellular communications system 100 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 100 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC) or an Evolved Packet System (EPS) including an Evolved Universal Terrestrial RAN (E-UTRAN) and an Evolved Packet Core (EPC). In this example, the RAN includes base stations 102-1 and 102-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC) and in the EPS include eNBs, controlling corresponding (macro) cells 104-1 and 104-2. The base stations 102- 1 and 102-2 are generally referred to herein collectively as base stations 102 and individually as base station 102. Alternatively, base station 102 can also be referred to as a RAN network node 102. Likewise, the (macro) cells 104-1 and 104-2 are generally referred to herein collectively as (macro) cells 104 and individually as (macro) cell 104. The RAN may also include a number of low power nodes 106-1 through 106-4 controlling corresponding small cells 108-1 through 108-4. The low power nodes 106-1 through 106-4 can be small base stations (such as pico or femto base stations) or remote radio heads (RRHs), or the like that consume less power than a predefined power threshold. Notably, while not illustrated, one or more of the small cells 108-1 through 108-4 may alternatively be provided by the base stations 102. The low power nodes 106-1 through 106-4 are generally referred to herein collectively as low power nodes 106 and individually as low power node 106. Likewise, the small cells 108-1 through 108-4 are generally referred to herein collectively as small cells 108 and individually as small cell 108. The cellular communications system 100 also includes a core network 110, which in the 5G System (5GS) is referred to as the 5GC. The base stations 102 (and optionally the low power nodes 106) are connected to the core network (node) 110.

The base stations 102 and the low power nodes 106 provide service to UEs 112-1 through 112-5 in the corresponding cells 104 and 108. The UEs 112-1 through 112-5 are generally referred to herein collectively as UEs 112 and individually as UE 112.

In an embodiment, the core network 110 may also communicate with an application server 114 is associated with an application layer 116. The application server 114 can also communicate with a UE (e.g., UE 112-3) either via the RAN or via a separate communication network. The separate communication network is not disclosed in figure 1, but it should be understood that such system is needed between the application server and the UE if communication is made other than by the RAN.

Figure 2 illustrates a wireless communication system represented as a 5G network architecture composed of core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point/interface. Figure 2 can be viewed as one particular implementation of the system 100 of Figure 1. In an embodiment, Figure 2 provides a representation of the core network 110 that can exchange information with an application layer 116 and application server 114 in the cloud and on the UE 112 so that the application server 114 and the core network 110 can optimally control the power management of the UE 112 and wireless network to extend battery life and useful operating time of the UE 112. When the application server 114 is informed of the energy harvesting capabilities and parameters of the UE 112, it can optimize the traffic and communications and configure applications in a way which the UE 112 can manage given its energy source constraints, for example how often periodic sensor data can be reported.

Seen from the core network side, the 5GC Network Functions (NFs) shown in Figure 2 include a Network Slice Selection Function (NSSF)202, an Authentication Server Function (AUSF)204, a Unified Data Management (UDM) 206, the Access and Mobility Function (AMF) 200, a Session Management Function (SMF) 208, a Policy Control Function (PCF) 210, and an Application Function (AF) 212. The AMF 200 can communicate with the application server 114 via am internet/public cloud/private cloud and envisioned to be using standard IP protocol to transport the information securely. The AMF 200 can communicate with the application server 114 using Namf_EventExposure service via the Network Exposure Function (NEF) 300 depicted in Figure 3.

Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE 112 and AMF 200. The reference points for connecting between the AN 102 and AMF 200 and between the AN 102 and UPF 214 are defined as N2 and N3, respectively. There is a reference point, Nil, between the AMF 200 and SMF 208, which implies that the SMF 208 is at least partly controlled by the AMF 200. N4 is used by the SMF 208 and UPF 214 so that the UPF 214 can be set using the control signal generated by the SMF 208, and the UPF 214 can report its state to the SMF 208. N9 is the reference point for the connection between different UPFs 214, and N14 is the reference point connecting between different AMFs 200, respectively. N15 and N7 are defined since the PCF 210 applies policy to the AMF 200 and SMF 208, respectively. N12 is required for the AMF 200 to perform authentication of the UE 112. N8 and N10 are defined because the subscription data of the UE 112 is required for the AMF 200 and SMF 208.

The 5GC network aims at separating User Plane (UP) and Control Plane (CP). The UP carries user traffic while the CP carries signaling in the network. In Figure 2, the UPF 214 is in the UP and all other NFs, i.e., the AMF 200, SMF 208, PCF 210, AF 212, NSSF 202, AUSF 204, and UDM 206, are in the CP. Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.

The core 5G network architecture is composed of modularized functions. For example, the AMF 200 and SMF 208 are independent functions in the CP. Separated AMF 200 and SMF 208 allow independent evolution and scaling. Other CP functions like the PCF 210 and AUSF 204 can be separated as shown in Figure 2. Modularized function design enables the 5GC network to support various services flexibly.

Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the CP, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The UP supports interactions such as forwarding operations between different UPFs.

Figure 3 illustrates a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points/interfaces used in the 5G network architecture of Figure 2. However, the NFs described above with reference to Figure 2 correspond to the NFs shown in Figure 3. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In Figure 3, the service based interfaces are indicated by the letter "N" followed by the name of the NF, e.g., Namf for the service based interface of the AMF 200 and Nsmf for the service based interface of the SMF 208, etc. The NEF 300 and the NRF 302 in Figure 3 are not shown in Figure 2 discussed above. However, it should be clarified that all NFs depicted in Figure 2 can interact with the NEF 300 and the NRF 302 of Figure 3 as necessary, though not explicitly indicated in Figure 2. In an embodiment, the NEF 300 can also by the function of the core network 110 that is used to communicate with the application server 114.

Some properties of the NFs shown in Figures 2 and 3 may be described in the following manner. The AMF 200 provides UE-based authentication, authorization, mobility management, etc. A UE 112 even using multiple access technologies is basically connected to a single AMF 200 because the AMF 200 is independent of the access technologies. The SMF 208 is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF 214 for data transfer. If a UE 112 has multiple sessions, different SMFs 208 may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF 212 provides information on the packet flow to the PCF 210 responsible for policy control in order to support QoS. Based on the information, the PCF 210 determines policies about mobility and session management to make the AMF 200 and SMF 208 operate properly. The AUSF 204 supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM 206 stores subscription data of the UE 112. The Data Network (DN), not part of the 5GC network, provides Internet access or operator services and similar.

An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

Figure 4 illustrates an exemplary embodiment where the core network 110 and the application layer 116 at an application server 114 and an application layer 406 at the UE 112 can exchange energy harvesting information about the energy harvesting capabilities and parameters of the UE 112. The UE 112 can be a mobile device, Internet of Things (IOT) device, reduced capability (RedCap) device, Zero Energy (ZE) device or low energy device that can employ energy harvesting (e.g., from induction, backscatter, vibrations, light, thermal gradients, and even from radio frequency waves in order) to partially supplement or fully power the UE 112. The UE 112 can include a battery or capacitor or other device in which to store the energy and use the energy for transmissions to and from the RAN network node 102 or other communications sources.

In an embodiment, the UE 112 can report the energy harvesting information to the Core Network node 110 via the RAN node 102. The Core Network node 110 can then provide the information to application layer 116 at application server 114, and application layer 116 can use the information to optimize the operation of the application to conserve power by modifying or regulating the size and frequency of transmissions, grouping data transmissions and etc.

In an embodiment, the energy harvesting information from the UE 112 is sent from the UE 112 to the application layer 406 or 116 when the UE 112 makes an initial registration with the core network 110. This allows a smooth registration process and easy deployment of UEs while ensuring that the application layer 116, 406 has correct information on the UE energy / transmission capabilities, allowing the application to optimize the performance accordingly. In one embodiment of the present disclosure, the UE reports the energyharvesting capability and parameters to the network. In the most plausible implementation as part the existing UE capability reporting framework, i.e., reporting UE capabilities to the network upon initial registration and attach to the network, which are then stored with the UE context in the core network 110, specifically the energy harvesting information is stored in the AMF 200. The UE energy-harvesting capability and parameters can be any combination of the following:

• Indication that the UE is operating using energy-harvesting.

• Type of energy storage, e.g., re-chargeable lithium battery or supercapacitor.

• Capacity of the energy storage [Wh].

• Type of energy harvester or capability of the energy harvester, (e.g. solar energy harvester with classification 10 pW - 50 pW, or RF harvester with 'up to 10 pW).

In an embodiment, the energy harvesting information can be sent from the UE 112 to the core network 110, and specifically, the AMF 200 via an Application Programming Interface (API) specifically e.g., via a global network platform (GNP). The API would take the energy harvesting information required in the UE context as input parameters (provided by the AP server) to the AMF 200 or a new translator function will then translate the input and put it into the correct format for storing in the AMF 200 the UE context (now including the energy harvesting information). Alternatively, the translator function is located in the application server 114 and sends the UE context information using IP to the AMF 200 which can then be able to read and accordingly update the UE context.

In other embodiments, the application layer 116 can provide the energy harvesting information to the Core Network node 110. The application layer 116 can receive the energy harvesting information from the UE 112 via the application layer 406 at the UE 112. In a primary embodiment, the application server 114 can receive the energy harvesting information from the UE 112 through a high protocol layer via the RAN 102 and core network 110, but the packets of information conveyed via the application layer is encapsulated, where the RAN 102 and core network 110 do not have access to the energy harvesting information. In a secondary embodiment, the energy harvesting information can be provided to the application server 114 via a separate physical/wireless communication link 408 other than via the wireless communication network of the core network node 110 and the RAN 102.

In an embodiment, the UE 112's hardware capabilities can be registered in the application. This could for example be upon initial power on or when the application is first started in the UE 112 (e.g., a printable is printed on a storage container for food and the application is tailored to track the food quality). In this case the manufacturer may directly register the hardware capabilities of the UE 112 in the application that will track the food quality during e.g., transport. Alternatively, APIs are introduced for the application to get information about the energy storage from the hardware, e.g., if the device is operating using energy-harvesting, backscattering, etc. The device hardware capabilities are then sent from the application layer 406 in the UE 112 to the application layer 116 in the network (application server 114) as illustrated in Figure 4. The device energy storage capabilities are then signaled to the Core Network 110 from the application layer 116 in the application server 114, avoiding the need to send the additional information in the initial registration message, and hence reducing the amount of data needed.

In one embodiment of the intention, the 3GPP network, based on the above UE capabilities and/or subscription information about the energy-harvesting or the energy storage, provides information to the application-layer, either in the UE or in the cloud (server). In an embodiment, the energy harvesting information can be provided via an API specified e.g., via a global network platform. The API can take the energy harvesting information required in the UE context as input parameters (provided by the AP server) the AMF 200 or a new translator function will then translate the input and put it into the correct format for storing in the UE context (now including the energy harvesting information). Alternatively, the translator function is located in the application server 114 and sends the RAN UE context information using IP and the AMF 200 will then be able to read and accordingly update the UE context. The information can consist of any of the following:

Any of the reported UE energy-harvesting capabilities or parameters (see above).

Any subscription information related to energy-harvesting or the energy storage. • Estimated energy consumed per byte of transmission, or per transmission/reception attempt, with potential differentiation for uplink and downlink.

• Transmitter and receiver on-time per data transmission (i.e., average Rx/Tx time per transmission of a certain data size).

• Energy-harvesting communication limitation information. o E.g., data inter-arrival time (i.e., frequency) and data size when communication energy (Tx/Rx) for data transmission is equal to the harvested energy. o Possibly different curves/profiles for this energy consumption break-even can be standardized and just an index signaled to Application-layer.

In a 3GPP network internal embodiment, the above information is used within the 3GPP network for traffic control to adapt to the UE 112's energy-harvesting capabilities . For example, downlink transmissions can be buffered/accumulated in the CN 110, and uplink transmission in the higher-layers of the UE 112, until the UE 112 is expected to have enough energy to perform the data transmission or reception procedure. (Note that this embodiment cannot provide any understanding in the application-layer on why the UE 112 becomes unreachable, and new requests and data would still be generated).

In another embodiment, a new capability is introduced to the Monitoring capability in the scope of NEF 300. This new Monitoring capability enables exposure of the above-mentioned UE 112 energy-harvesting capability and parameters. This Monitoring capability is defined as a new event for monitoring capability, from the 5GS/5GC, e.g., a new event that AMF 200 can expose using Namf_EventExposure service via the Network Exposure Function (NEF) to AF 212. One example of the event definition is provided below.

Figure 5 illustrates a graph 500 depicting data traffic limitations profiles for devices operating on harvested energy according to some embodiments of the present disclosure. In an embodiment, based on the energy harvesting rate of the UE 112 and the energy storage capabilities of the UE 112 some data traffic or transmissions may not be feasible, depending on the energy available. The graph depicts a curve that is based on the energy harvesting rate where communications below (502) a given data size and frequency are possible, while communications above (504) the given data size and frequency are not possible. The core network 110 can determine the curve based upon information about the power requirements of transmissions to the UE 112 (e.g., based on signal strength, distance from RAN network node 102) etc., and the core network 110 can provide the curve and associated information to the application layer 116 in order for the application layer 116 to determine how best to optimize data transmissions, in size and frequency, to the UE 112.

Figure 6 illustrates a message sequence chart for exchanging energy harvesting information between a wireless communication system and an application layer according to various embodiments of the present disclosure. It is to be appreciated that one or more of the steps in the message sequence chart can occur independently of other steps in the message sequence chart and that different embodiments can combine different steps from the message sequence chart in Figure 6.

In one optional embodiment, at step 602, the RAN node 102 can provide the energy harvesting information that the RAN node 102 received from the UE during registration of the UE with the network, to the core network node 110.

In an embodiment, at step 604, the core network node 110 can provide the energy harvesting information associated with a UE (e.g., UE 112) to an application layer 116 of an application server, wherein the energy harvesting information can facilitate an energy management modification associated with the application layer. I In an embodiment, the energy management modification can also be performed by the core network 110. The energy management modification can be used to control a communication to the UE 112 to match an energy harvesting capability of the UE based on the energy harvesting information. For example, the energy management modification can include delaying a communication to the UE 112 from either application server 114 or the radio access network until energy harvested by the UE 112 is sufficient to transmit or receive the communication. In an embodiment, the core network node 110 can provide the energy harvesting information to the application layer 116 associated with the application server via a Network Exposure Function 300 of the core network.

In other embodiments, at step 606, the core network node 110 can provide the energy harvesting information associated with the UE 112 to an application layer 406 associated with the UE 112. In an embodiment, the core network node 110 provides the energy harvesting information to the application layer 406 via the radio access network node 102.

In an embodiment, prior to providing the energy harvesting information to either the application layer 406 or the application layer 116, the core network node 110 can receive the energy harvesting information from RAN node 102 where the UE reported the energy harvesting information to the RAN node 102 previously.

In an embodiment, the energy harvesting information can include energy harvesting capabilities and parameters information comprising one or more of the following: an indication that the UE 112 is performing energy harvesting; a type of energy storage of the UE 112; a capacity of the energy storage of the UE 112; a type of energy harvester of the UE 112; or an energy harvesting rate of the UE 112.

The energy harvesting information can also include subscription information associated with the UE 112 relating to energy harvesting or energy storage; estimated energy consumed by the UE 112 for a predetermined transmission size for at least one of an uplink transmission or a downlink transmission; a UE 112 transmitter and UE 112 receiver on-time per data transmission or data transmission attempt; or an estimated transmission frequency and transmission size that corresponds to an energy consumption that is less than or equal to harvested energy. In an embodiment, the information can be estimated before providing the energy harvesting information to the application server 114 or application layer 116.

In another embodiment, at step 608, the core network node 110 can receive the energy harvesting information from the application layer 116 associated with the application server. The application layer 116 received the energy harvesting information directly from the application layer 406 of the UE 112 either via the wireless communication system of the RAN node 102 and the core network node 110 or via another communication system. Based on the energy harvesting information, at step 610 the core network node 110 can determine and implement a type of network operation to perform such as grouping batching data transmissions to the UE 112, based on the current estimated energy/ power available to the UE 112, setting QoS or other parameters associated with the UE 112 based on the energy harvesting information. In an embodiment, at step 612, the core network node 110 can send information about the network operation to be implemented to the RAN node 102.

Figure 7 is a schematic block diagram of a network node 700 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 700 may be, for example, the core network node 110, a base station 102 or 106 or a network node that implements all or part of the functionality of the base station 102 or gNB described herein. As illustrated, the network node 700 includes a control system 702 that includes one or more processors 704 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 706, and a network interface 708. The one or more processors 704 are also referred to herein as processing circuitry. In addition, the network node 700 may include one or more radio units 710 that each includes one or more transmitters 712 and one or more receivers 714 coupled to one or more antennas 716. The radio units 710 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 710 is external to the control system 702 and connected to the control system 702 via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) 710 and potentially the antenna(s) 716 are integrated together with the control system 702. The one or more processors 704 operate to provide one or more functions of a network node 700 as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 706 and executed by the one or more processors 704.

Figure 8 is a schematic block diagram that illustrates a virtualized embodiment of the network node 700 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures. Again, optional features are represented by dashed boxes. As used herein, a "virtualized" network node is an implementation of the network node 700 in which at least a portion of the functionality of the network node 700 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node 700 may include the control system 702 and/or the one or more radio units 710, as described above. The control system 702 may be connected to the radio unit(s) 710 via, for example, an optical cable or the like. The network node 700 includes one or more processing nodes 800 coupled to or included as part of a network(s) 802. If present, the control system 702 or the radio unit(s) are connected to the processing node(s) 800 via the network 802. Each processing node 800 includes one or more processors 804 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 806, and a network interface 808.

In this example, functions 810 of the network node 700 described herein are implemented at the one or more processing nodes 800 or distributed across the one or more processing nodes 800 and the control system 702 and/or the radio unit(s) 710 in any desired manner. In some particular embodiments, some or all of the functions 810 of the network node 700 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 800. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 800 and the control system 702 is used in order to carry out at least some of the desired functions 810. Notably, in some embodiments, the control system 702 may not be included, in which case the radio unit(s) 710 communicate directly with the processing node(s) 800 via an appropriate network interface(s).

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of network node 700 or a node (e.g., a processing node 800) implementing one or more of the functions 810 of the network node 700 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory). Figure 9 is a schematic block diagram of the network node 700 according to some other embodiments of the present disclosure. The network node 700 includes one or more modules 900, each of which is implemented in software. The module(s) 900 provide the functionality of the network node 700 described herein. This discussion is equally applicable to the processing node 800 of Figure 8 where the modules 900 may be implemented at one of the processing nodes 800 or distributed across multiple processing nodes 800 and/or distributed across the processing node(s) 800 and the control system 702.

Figure 10 is a schematic block diagram of a UE 1000 according to some embodiments of the present disclosure. As illustrated, the UE 1000 includes one or more processors 1002 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1004, and one or more transceivers 1006 each including one or more transmitters 1008 and one or more receivers 1010 coupled to one or more antennas 1012. The transceiver(s) 1006 includes radio-front end circuitry connected to the antenna(s) 1012 that is configured to condition signals communicated between the antenna(s) 1012 and the processor(s) 1002, as will be appreciated by on of ordinary skill in the art. The processors 1002 are also referred to herein as processing circuitry. The transceivers 1006 are also referred to herein as radio circuitry. In some embodiments, the functionality of the UE 1000 described above may be fully or partially implemented in software that is, e.g., stored in the memory 1004 and executed by the processor(s) 1002. Note that the UE 1000 may include additional components not illustrated in Figure 10 such as, e.g., one or more user interface components (e.g., an input/output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and/or the like and/or any other components for allowing input of information into the UE 1000 and/or allowing output of information from the UE 1000), a power supply (e.g., a battery and associated power circuitry), etc.

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the UE 1000 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory). Figure 11 is a schematic block diagram of the UE 1000 according to some other embodiments of the present disclosure. The UE 1000 includes one or more modules 1100, each of which is implemented in software. The module(s) 1100 provide the functionality of the UE 1000 described herein.

Figure 12 is a schematic block diagram of an application server 114 according to some embodiments of the present disclosure. As illustrated, the application server 114 includes one or more processors 1202 (e.g., CPUs, ASICs, FPGAs, and/or the like) and memory 1204. The processors 1002 are also referred to herein as processing circuitry. In some embodiments, the functionality of the application server 114 described above may be fully or partially implemented in software that is, e.g., stored in the memory 1204 and executed by the processor(s) 1202. Note that the application server 114 may include additional components not illustrated in Figure 12 such as, e.g., one or more user interface components (e.g., an input/output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and/or the like and/or any other components for allowing input of information into the application server 114 and/or allowing output of information from the application server 114), a power supply (e.g., a battery and associated power circuitry), etc.

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the application server 114 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).

• 3GPP Third Generation Partnership Project

• 5G Fifth Generation

• 5GC Fifth Generation Core

• 5GS Fifth Generation System

• AF Application Function

• AMF Access and Mobility Function

• AN Access Network

• AP Access Point

• ASIC Application Specific Integrated Circuit

• AUSF Authentication Server Function

• CPU Central Processing Unit

• DCI Downlink Control Information

• DN Data Network

• DSP Digital Signal Processor

• eNB Enhanced or Evolved Node B

• EPS Evolved Packet System

• E-UTRA Evolved Universal Terrestrial Radio Access

• FPGA Field Programmable Gate Array gNB New Radio Base Station gNB-DU New Radio Base Station Distributed Unit

HSS Home Subscriber Server loT Internet of Things

IP Internet Protocol

LTE Long Term Evolution

MAC Medium Access Control

MME Mobility Management Entity

MTC Machine Type Communication

NEF Network Exposure Function

NF Network Function

NR New Radio

NRF Network Function Repository Function

NSSF Network Slice Selection Function

OTT Over-the-Top

PC Personal Computer

PCF Policy Control Function

PDSCH Physical Downlink Shared Channel

P-GW Packet Data Network Gateway

PRS Positioning Reference Signal

QoS Quality of Service

RAM Random Access Memory

RAN Radio Access Network

ROM Read Only Memory

RP Reception Point

RRH Remote Radio Head

RTT Round Trip Time

SCEF Service Capability Exposure Function

SMF Session Management Function

TCI Transmission Configuration Indicator

TP Transmission Point

TRP Transmission/Reception Point

UDM Unified Data Management • UE User Equipment

• UPF User Plane Function

Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.