Charging sessions for low energy wireless devices

Abstract

According to an aspect, there is provided a method performed by a first node in a Radio Access Network, RAN, of a communication network. The method comprises: predicting (401), using an availability model, a pattern of transmissions of data by one or more low energy wireless devices; comparing (402) an actual pattern of data received from the one or more low energy wireless devices to the predicted pattern to determine if the one or more low energy wireless devices are transmitting data according to the predicted pattern; and if it is determined that one or more of the low energy wireless devices are not transmitting data according to the predicted pattern, triggering (403) a charging session to provide power to the one or more of the low energy wireless devices and enable data transmissions to be performed.

Description

[0001] Charging sessions for low energy wireless devices

[0002] Technical Field

[0003] This disclosure relates to low energy wireless devices, and in particular to techniques for triggering a charging session for the low energy wireless devices.

[0004] Low energy wireless devices, which are referred to herein as Zero-Energy Devices (ZEDs), are low-cost devices that wirelessly transmit information (e.g. environmental measurements) opportunistically, whenever there is available power. Low energy wireless devices are also known as Ambient Internet of Things (loT) devices.

[0005] As used herein, a low energy wireless device is considered to include “pure batteryless devices with no energy storage capability at all, and completely dependent on the availability of an external source of energy; and devices with limited energy storage capability that do not need to be replaced or recharged manually”, as described in the 3rd Generation Partnership Project (3GPP) Study Item (SI) on Ambient loT (3GPP RP-222685 by Huawei and HiSilicon).

[0006] ZEDs harvest energy from the environment to provide power to transmit and potentially also receive data. They can be very cheap, and can be deployed en masse, for example as sensors monitoring different qualities of supply chains, production lines, an outdoor environment, or smart homes, etc. Some examples of uses or opportunities for ZEDs are described in the paper “Zero- Energy Devices Empowered 6G Networks: Opportunities, Key Technologies, and Challenges” by Naser, Shimaa; Bariah, Lina; Muhaidat, Sami; Basar, Ertugrul (2022).

[0007] As noted, a ZED acts in an opportunistic manner, i.e. transmitting whenever there is power, such as the presence of a carrier wave (for backscattering), wireless power transfer (WPT), or an ambient source, such as the sun in case of solar power. As a result, the availability of power is down to the environment. For example, in case of backscattering, the presence of a carrier signal that can be absorbed, modulated, and sent back to the receiver as a modulated signal. Therefore, transmissions by ZEDs are unpredictable as they are dependent on the availability of power that is typically out of their control. As such, the use cases to which ZEDs are to be applied are seen as “best-effort” rather than “mission critical”.

[0008] There can be situations where ZEDs directly or indirectly (i.e. through a gateway) rely on grid-supplied power. There are also cases where devices have a battery and use power from the battery for transmitting and / or receiving, but batteries need to be recharged and / or eventually replaced. These types of devices are more expensive than ZEDs, as they typically have memory and processing power as well as a means of communicating to radio base stations. In addition, relying on external power from the power grid or an internal / external battery may not be feasible, reliable or cost-effective.

[0009] For instance, in disaster scenarios power from the grid is potentially not available. Devices may be used for the monitoring of water levels to provide flood alerts, or devices can be used to measure the temperature in forests to provide warnings of the presence or spread of forest fires. Thus, these devices can be part of an early warning system for dangerous situations, and enable authorities and citizens to be alerted. In another scenario, relating to private networks, an enterprise can maintain ownership of both the network and mobile devices. In such private networks, use of ZEDs that are powered in a reliable, cost-effective manner may mean a cheaper capital expense (CAPEX) and / or operating expense (OPEX) for the enterprise.

[0010] Thus, in a variety of scenarios, including regular use cases (e.g. where ZEDs are being used to monitor operations in an enterprise environment), it is important to be able to reliably receive information from deployed ZEDs, even though those ZEDs may not have reliable access their power source (e.g. light, sound, radio frequency (RF) signals, etc.).

[0011] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges.

[0012] This disclosure provides a logical entity, which is referred to herein as a Power Source Orchestrator (PSO), or more generally as a first node, that predicts a pattern of transmissions of data by low energy wireless device(s), and that triggers a charging session to provide power to the low energy wireless device(s) and enable data transmissions to be performed if the low energy wireless devices are not transmitting according to the predicted pattern.

[0013] The first node / PSO can be, or be part of, any network node in a Radio Access Network (RAN) part of a communication network. For example, the first node / PSO can be, or be part of, a base station such as a gNB, a relay node (also referred to herein as an Intermediate Node (IN)), or a User Equipment (UE).

[0014] In particular embodiments, one of the tasks of the first node / PSO can be to learn transmission patterns of ZEDs in proximity to the first node (e.g. in a cell managed by the gNB of which the first node is part). The learnt transmission patterns are to be used to detect or predict when a ZED or set of ZEDs will be transmitting data. The transmission patterns can be learnt by observing transmissions from ZEDs and analysing their periodicity. Certain embodiments provide that observing the inter-arrival times of data packets from ZEDs enables the first node / PSO to identify patterns of transmission. In some embodiments a dataset of readings (recorded transmissions) can be collected for each ZED, and the first node / PSO may train a Machine Learning (ML) model (e.g. a time series-sensitive ML model) using for example regression or a recurrent neural network (RNN), to predict when ZEDs are to transmit data. In this way, a lack of transmission(s) from the ZED(s) at the predicted time(s) can be assumed to be due to the environment not providing the ZED with enough power.

[0015] It may not always be the case that ZEDs will have an identifier or include an identifier in their transmissions, and if the first node / PSO is to be able to further identify individual ZEDs, the first node / PSO may analyse the payload and header of received data packets to identify the ZED(s) that sent them, for example using the techniques described in “Automated loT Device Identification Based on Full Packet Information Using Real-Time Network Traffic” by Yousefnezhad, N.; Malhi, A.; Framling, K., in Sensors 2021 , 21 , 2660, and in “loT Device Identification Using Directional Packet Length Sequences and 1 D-CNN” by Liu, X.; Han, Y.; Du, Y., in Sensors 2022, 22, 8337.

[0016] The first node / PSO may localise the ZED or ZEDs, i.e. determine or estimate the location(s) of the ZED(s), for example using a technology such as beamforming. This may be useful where the charging session is performed in a localised area, and so the charging session can be performed in an area corresponding to the ZED(s) that are not transmitting as predicted.

[0017] As noted above, the first node / PSO triggers a charging session to provide power to the ZED(s) and enables data transmissions to be performed if the ZED(s) are not transmitting according to the predicted pattern. The first node / PSO can charge ZEDs directly (i.e. by triggering a charging session using one or more components that are part of the first node / PSO or part of the apparatus that the first node / PSO is part of) or indirectly via one or more intermediate nodes (I Ns). For example, the first node / PSO can instruct the IN to start a charging session. The IN itself may perform the charging session, or trigger the charging session via other apparatus. The charging session (whether performed by the first node / PSO, the apparatus the first node / PSO is part of, the IN, or another apparatus) may comprise using wireless power transfer (WPT), or by carrier wave for backscattering communication. The type of charging session can depend on the ZED capability, the charging / energy harvesting infrastructure, ZED negotiation (e.g. the ZED requesting energy on a dynamic basis), whether the charging session is via a network-powered source or an ambient energy source, e.g. WPT for electromagnetic waves, photovoltaic charging for light, piezoelectric charging for vibration, etc.

[0018] According to a first specific aspect, there is provided a method performed by a first node in a Radio Access Network, RAN, of a communication network. The method comprises: predicting, using an availability model, a pattern of transmissions of data by one or more low energy wireless devices; comparing an actual pattern of data received from the one or more low energy wireless devices to the predicted pattern to determine if the one or more low energy wireless devices are transmitting data according to the predicted pattern; and if it is determined that one or more of the low energy wireless devices are not transmitting data according to the predicted pattern, triggering a charging session to provide power to the one or more of the low energy wireless devices and enable data transmissions to be performed.

[0019] According to a second aspect, there is provided a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method according to the first aspect or any embodiment thereof.

[0020] According to a third aspect, there is provided a first node, configured to perform the method according to the first aspect or any embodiment thereof.

[0021] According to a fourth aspect, there is provided a first node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said first node is operative to perform the method according to the first aspect or any embodiment thereof.

[0022] Certain embodiments may provide one or more of the following technical advantage(s). In particular, the techniques described herein can increase chances of receiving timely data from low energy wireless devices regardless of the presence of power in the ambient environment.

[0023] Brief Description of the Drawings

[0024] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which:

[0025] Fig. 1 is a block diagram illustrating a system comprising a PSO according to the techniques described herein;

[0026] Fig. 2 is a signalling diagram illustrating exemplary operations performed by a PSO, and signalling between the PSO and a ZED;

[0027] Fig. 3 is a signalling diagram illustrating exemplary operations performed by a PSO, an Intermediate Node, and a ZED;

[0028] Fig. 4 is a flow chart illustrating a method of operating a first node according to the techniques described herein;

[0029] Fig. 5 shows an example of a communication system in which the techniques described herein can be used;

[0030] Fig. 6 shows a RAN node in accordance with some embodiments;

[0031] Fig. 7 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized; and

[0032] Fig. 8 is a simplified block diagram of a node according to some embodiments. Detailed Description

[0033] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0034] Fig. 1 is a block diagram illustrating a system 100 comprising a PSO 102 according to the techniques described herein. As noted above, the PSO 102 is a logical entity (which is also referred to herein as a first node), that predicts a pattern of transmissions of data by low energy wireless device(s) 104, and that triggers a charging session to provide power to the low energy wireless device(s) 104 and enable data transmissions to be performed if the low energy wireless devices 104 are not transmitting according to the predicted pattern. In the following description, the low energy wireless devices 104 are referred to as ZEDs 104.

[0035] The PSO 102 can be, or be part of, any network node in a Radio Access Network (RAN) part of a communication network. For example, the PSO 102 can be, or be part of, a base station such as a gNB, a relay node (also referred to herein as an Intermediate Node (IN)), or a User Equipment (UE).

[0036] Depending on the specific implementation of the PSO 102, the PSO 102 may be able to charge one or more of the ZEDs 104 directly (i.e. by triggering a charging session using one or more components that are part of the PSO 102 or part of an apparatus that the PSO 102 is part of) or indirectly via one or more intermediate nodes (INs). One IN 106 is shown in Fig. 1. For example, the PSO 102 can instruct the IN 106 to start a charging session. The IN 106 may perform the charging session, or trigger the charging session via another apparatus (not shown in Fig. 1). The charging session (whether performed by the PSO 102, the apparatus the PSO 102 is part of, the IN 106, or another apparatus) may comprise using wireless power transfer (WPT), or by carrier wave for backscattering communication. The type of charging session can depend on the capabilities of the ZED(s) 104, the charging / energy harvesting infrastructure, ZED negotiation (e.g. the ZED(s) 104 requesting energy on a dynamic basis), whether the charging session is via a network-powered source or an ambient energy source, e.g. WPT for electromagnetic waves, photovoltaic charging for light, piezoelectric charging for vibration, etc.

[0037] More generally, as described in the paper “Zero-Energy Devices Empowered 6G Networks: Opportunities, Key Technologies, and Challenges” referenced above, energy sources for low energy wireless devices can include any of: ambient light (e.g. direct sunlight or artificial light sources), vibrations (e.g. from a vehicle), thermal, ambient RF, dedicated RF, non-radiative coupling-based, wind / air flow and acoustic noise.

[0038] Fig. 1 shows the system 100 as comprising an IN 106 that is connected to, or otherwise in communication with, the PSO 102. However, it will be appreciated that the IN 106 is not required in all implementations, for example where the PSO 102 is able to trigger a charging session using one or more components that are part of the PSO 102 or that are part of an apparatus (e.g. a gNB) that the PSO 102 is part of. An IN 106 is an entity that has a control interface (i / f), which is a request-response type of interface for triggering charging sessions for ZEDs 104, and a charge interface which provides the energy for the charging session. In some cases an IN 106 can itself be charged via the charge interface. In some cases a series of I Ns 106 can be connected in a relay, with charging session control signals and / or power signals being transferred between I Ns 106 and then to the ZEDs 104.

[0039] The operations of the PSO 102 are shown in Fig. 1 in the form of functional blocks: a Data Receiver block 110, an Analyser block 112 and a Charge Decision Entity 114. The Data Receiver block 110 receives or observes data received from the ZEDs 104 and identifies patterns in the transmissions, e.g. a periodicity of transmission, locality (i.e. where the transmissions came from) and payload (i.e. content of the transmissions).

[0040] The Analyser block 112 trains a ML model (referred to herein as an availability model) based on the patterns identified by the Data Receiver block 110, with the availability model being trained to predict when transmissions by ZEDs 104 are expected to occur. It will be appreciated that the availability model can be trained (with suitable training data) to predict transmissions on a per- ZED basis, per group of ZEDs, per area in which ZEDs are located.

[0041] The Charge Decision Entity 114 receives predictions by the availability model, compares the predictions to the transmissions, or patterns of transmissions received from the ZEDs 104, and takes a decision on whether the ZEDs 104 (or some of the ZEDs 104) should be charged. In particular, if transmissions are expected from one or more ZEDs 104 but are not received, it may be that the ZEDs 104 do not have sufficient power available from the environment or from their limited energy storage capability, and so the Charge Decision Entity 114 decides to trigger a charging session for those ZEDs 104. The Charge Decision Entity 114 can send a control signal to a suitable IN 106 that will perform the charging session, or, for example where an IN 106 is not present in the system 100, the Charge Decision Entity 114 can trigger or perform the charging session directly.

[0042] In some cases there may be multiple I Ns 106 in the system 100, in which case the Charge Decision Entity 114 can determine an appropriate IN 106 to use for the charging session.

[0043] I Ns 106 and PSOs 102 are logical entities and can be implemented in a number of different types of apparatus, and different types of charging session can be used to charge the ZEDs 104, depending on the capabilities of the ZEDs 104. Table 1 shows some potential use case implementations of the PSO 102, and IN 106 in a mobile communication network, and these use cases are described further below.

[0044] Table 1

[0045] Use Case 1 : qNB / eNB for wireless charging - The first use case considers PSOs 102 embedded in gNBs or eNBs that have the capacity for wireless charging, for example using WPT or using carrier waves and backscattering. WPT can be achieved, for example, via means of beamforming (see for example the paper “Beamforming Design of the Wireless Power Transfer System into Multiple loT Sensors” by Changyoung An et al., 2022 24thInternational Conference on Advanced Communication Technology (ICACT)). Optionally, one or more I Ns 106 can also be present.

[0046] While the ZEDs 104 are a type of user equipment (UE), in some implementations other UEs (e.g. regular UEs, or UEs that are not low energy wireless devices) can be the INs 106. The UEs / INs 106 require connectivity to the gNB to receive a trigger for a charging session. The UEs / INs 106 can also charge nearby ZEDs 104, for example using the sidelink (SL) spectrum. Several embodiments are possible in this use case.

[0047] In some embodiments, INs can be unmanned aerial vehicles (UAVs) that are tasked to fly to, and charge, nearby devices (e.g. sidelink (SL) spectrum could either be allocated directly by the UE or indirectly from the gNB when there is a need to keep track of spectrum allocation from the network as opposed to doing that opportunistically). In other embodiments, INs 106 may include static structures such as Reconfigurable Intelligent Surfaces (RISs) or Repeaters.

[0048] Use case 2: charging in indoor environments using light or audio - In contrast to macrocells (gNB / eNB) and outdoor areas of Use Case 1 , another use case can relate to indoor environments, where PSOs 102 could be embedded in small cells and can charge ZEDs 104 using light or sound. This could be applicable to enterprise networks, e.g., private 4G / 5G / 6G deployments in factories, warehouses, mines, etc. In these environments, infrastructure supplying ambient power, such as microphones or light sources (e.g. spotlights) can be controlled by the PSO 102. An example could be small cells such as the Ericsson Radio Dot, which also have a control interface to power sources, as small cells are typically installed close to the source of power. In this case, the PSO 102 could itself have an integrated control circuit to control the power sources, or, in another embodiment, the PSO 102 could also signal an IN 106 to power up the ZEDs 104. In this case the controller that is able to turn a power source (e.g. a speaker or a light) on or off may be a separate system that also has UE capabilities.

[0049] Use case 3: charging using vibrations or wind in logistics / supply chain scenarios or autonomous vehicle traffic - Other use cases include using vibrations to power up ZEDs 104. These use cases can be applicable both to enterprise solutions and private 5G networks, where enterprises own and control both the UE and network infrastructure, and also to public networks. In both cases, the idea is to take advantage of vehicle traffic and vibrations caused by the vehicles or air flow / wind as vehicles pass by.

[0050] For example, consider automated guided vehicles (AGVs) such as logistic robots in warehouses. These robots may have ZEDs 104 on them or at their surroundings, powered by vibrations (e.g. of piezoelectric nature), with the vibrations generated by AGV movement. In this case, the AGV can be thought as an IN 106, and the PSO 102 can either be embedded in the AGV or be external to it (e.g. embedded in a gNB / eNB, or elsewhere). The PSO 102 can instruct the AGV to move, and from its movement and vibrations caused, it can charge the ZEDs 104 that are either on it, or at the infrastructure (e.g. piezo-electric sensors on the floor).

[0051] In another example, autonomous vehicles on the road can ‘charge’ roadside ZEDs 104 that have wind turbines or are, or have, infrastructure under the roads such as piezo-electric sensors. A control method may coordinate oncoming traffic to perform a charging session, such as instructing vehicles to pass by or over these ZEDs 104 slower or quicker depending on the charge requirements.

[0052] Fig. 2 is a signalling diagram illustrating exemplary operations performed by a PSO 102, and signalling between the PSO 102 and a ZED 104. The operations and signalling in Fig. 2 relate to the training of the availability model.

[0053] At any given point in time, as shown by signals 211 , the PSO 102 may receive data transmissions from a ZED 104. Where the PSO 102 is, or is implemented in, a base station such as a gNB, the data transmissions (which are also referred to as data packets) will have been sent by the ZED 104 over the air interface to the base station, and then they are relayed through the communication network to the relevant destination (e.g. a server). The PSO 102 can observe the transmissions as they are received at the base station. Where the PSO 102 is, or is implemented in, a node other than a base station, the PSO 102 may receive information on the data transmissions received by the base station from the ZEDs 104.

[0054] In either case, in step 212 the PSO 102 stores information about the received data packets, and optionally additional metadata, in an internal buffer or memory of the PSO 102. From this data the PSO 102 is able to identify patterns in the transmissions. The information that can be stored may comprise, but is not limited to:

[0055] Data packet headers such as an identifier of the ZED 104 that transmitted the packet, the time-to-live (TTL), the destination of the packet, a protocol identifier, a version identifier and the length of the payload; the payload itself (in case the payload is not encrypted); the time of reception of the data packet; the location of the ZED 104 that transmitted the packet. The location could be determined by means of beamforming (i.e. the direction can be determined by the direction of the beam used by the ZED 104, and the distance between the base station and ZED 104 determined from the signal strength). The location can be expressed in different terms, e.g. geographical coordinates, a Cartesian distance from a fixed point of reference (e.g. the PSO 102), as shown in Table 2 below. The location may also include a height dimension (elevation degree).

[0056] Table 2: Received values

[0057] At a particular time, e.g. after a certain amount of time elapses since a previous training / updating of the availability model, or in response to an external event, the PSO 102 retrieves the stored transmission data from the buffer / storage (step 213) and in step 214 trains the availability model to predict future transmissions by the ZED(s) 104.

[0058] Two techniques for building / training the availability model to predict ZED transmission patterns are provided below.

[0059] Method 1 : Clustering of ZEDs to areas, then predicting transmission patterns per “area” instead of individual ZEDs - This first method is applicable to charging session / charging methods that target areas rather than individual ZEDs. Examples of these charging methods include wireless charging through backscattering of carrier waves - but not through a laser - or using a light source or using an audio source. When storing the information about the received data transmissions, the PSO 102 can group the information per area. For example, consider the following data packets originating from ZEDs 104 clustered as shown in Table 3 below. It should be noted that the content of Table 3 is just an example and shows an exemplary clustering of the information in Table 2. It will be appreciated that in principle different combinations of the data mentioned above can be used.

[0060] Table 3: Values stored in internal buffer of PSO after clustering

[0061] I n Table 3 the Location - which can also be thought of as an area that can be charged using a configuration at the PSO 102 - can be, for example, split into 12 areas, each 30° wide, using the PSO 102 (e.g. gNB) as a reference itself. In this case, different phase shifted beams from an antenna controlled by the PSO 102 could be used to charge ZEDs 104 or I Ns 106 in these 12 areas. The morphology and number of areas and size of these areas can be dependent on the type of mechanism used to charge the ZEDs 104 or I Ns 106.

[0062] Table 3 illustrates a segmentation based on radians from the base station / PSO 102, which is what a device with beamforming capabilities and wireless power transfer would use (i.e. according to Use Case 1 in Table 1 above). In another example of Table 1 where wireless power transfer happens using light sources, the segmentation can be based on the area that spotlights in the ceiling or on the walls can cover. In another example of Table 1 where charging is conducted through vibrations, the areas can be based on the degree of the vibrations from the movement of the AGV. The availability model itself can have as input a sequence of data entries each including one or more of the data fields shown in Table 3, i.e. location, timestamp, destination. The trained availability model generates a list (pattern) of predicted transmissions expected in an area during an upcoming time period. The location can be optional, as the only parameters required are an indication of the location of the ZED 104 and the timestamp. Assuming that the availability model is a classifier model, such predictions by the availability model could, for example, be split as follows:

[0063] [A, 0-10min], [A, 10-20m], [A 20-30m], [B 0-10m], ... . [L 0-10min], [L 10-20min], [L 20-30min] (1)

[0064] In this case there are 12 areas (A to L), each with three classes, and each class indicating the possibility of receiving messages in the next 10 minutes (0-10min), 10 minutes after that (10- 20min) and 10 minutes after that (20-30min). The classes can further be split by the number of messages expected to be received. Therefore a sequence-to-sequence ML model, such as a recurrent neural network (RNN), can be trained in such a way that given a sequence of timesensitive data such as that shown in Table 3, it can predict future demand (transmission patterns) in locations using classes such as those shown in equation (1).

[0065] This method should work well for ZEDs 104 that use techniques such as wireless power transfer that take advantage of charge in the environment.

[0066] In addition, the clustering of transmissions can be performed based on use cases. For example, ZEDs 104 with the same use cases (e.g. measuring temperature), applications, or deployments can be grouped together.

[0067] The prediction sequence in equation (1) is referred to as the availability plan. The PSO 102 can renew the availability plan periodically by using the availability model to make a new prediction.

[0068] The PSO 102 can compare the predicted transmission pattern (e.g. the availability plan in equation (1)) to actual data transmissions by the relevant ZED(s) 104. If there is a mismatch, or a sufficient mismatch, in one or more locations where the mismatch is detected, then the PSO 102 can trigger a charging session for the ZEDs 104 in this / these location(s). The comparison of the predicted transmission pattern to actual data transmissions can comprise comparing the timings / time periods that transmissions are predicted to be received according to the predicted transmission pattern to the time(s) of receipt of actual data transmissions. A mismatch may be found if no transmission is received at a predicted time / time period, or if the time difference between receiving an actual data transmission and the predicted time / time period too large (e.g. for a ZED that typically transmits multiple times per second, a too large time difference could be 50 milliseconds or more). While the comparison may take into account individual transmissions and determine a mismatch on a per transmission basis, it is alternatively possible for the comparison to determine a mismatch after observing a series of predicted / actual data transmissions. For example, the comparison may only determine a mismatch or sufficient mismatch with the predicted transmission pattern if there is at least a certain number of predicted transmissions in the pattern where no actual data transmission is received, or the actual data transmissions are delayed compared to the predictions. The ‘certain number’ may be evaluated with respect to a time period, so for example a mismatch could be found in there are at least 20 individual data transmissions mismatches within a 1 second period.

[0069] The first node / PSO may analyse the payload and header of received data packets to identify the ZED(s) that sent them, for example using the techniques described in “Automated loT Device Identification Based on Full Packet Information Using Real-Time Network Traffic” by Yousefnezhad, N.; Malhi, A.; Framling, K., in Sensors 2021 , 21 , 2660, and in “loT Device Identification Using Directional Packet Length Sequences and 1 D-CNN” by Liu, X.; Han, Y.; Du, Y., in Sensors 2022, 22, 8337.

[0070] Method 2: Identifying individual ZEDs - In the second method for building / training the availability model to predict ZED transmission patterns, instead of grouping of ZEDs 104 in a particular area, the model predicts ZED transmission patterns on a per-ZED basis. In some cases the ZEDs 104 may have individual identifiers (e.g. an International Mobile Subscriber Identity (IMSI)), and may include this identifier in their transmissions (e.g. in a header of the data packet). In this case, the training data for the availability model needs to include the identifiers of the ZEDs 104 to enable the received transmissions to be grouped by ZED 104. If the ZEDs 104 do not have identifiers, do not include the identifiers in their transmissions, or the training data otherwise does not include the identifiers, then the information about the transmissions needs to be evaluated in order to indirectly identify the ZEDs 104.

[0071] The PSO 102 may analyse the payloads and headers of received data packets to identify the ZED(s) that sent them, for example using the techniques described in “Automated loT Device Identification Based on Full Packet Information Using Real-Time Network Traffic” by Yousefnezhad, N.; Malhi, A.; Framling, K., in Sensors 2021 , 21 , 2660, and in “loT Device Identification Using Directional Packet Length Sequences and 1 D-CNN” by Liu, X.; Han, Y.; Du, Y., in Sensors 2022, 22, 8337. More generally, identification of individual ZEDs 104 could be performed using a combination of the information available, such as the destination, payload and time of transmission. For example, if the destination is always the same (or belongs to the same subnet), if the payload follows the same probability value distribution (which could mean that the same quality is monitored and reported by a ZED 104), and if the time between transmissions has some pattern such as stable periodicity, then transmissions of a particular ZED 104 can be obtained. Consider, for example, the information about received ZED transmissions shown in Table 4 below.

[0072] Table 4: Received values (alternative example)

[0073] The information in Table 4 can be reduced to the following ZED profiles:

[0074] Table 5: Individual ZED profiles

[0075] In this case the periodicity is not static as in Table 5, and the availability model can be used to predict the probability value distributions of ZED transmissions, e.g. “normal distribution with mu = 0.12 and sigma = 0.32”.

[0076] Table 5 in this method is the availability plan. Similar to Method 1 , the PSO 102 compares this output of the availability model to actual traffic being received from ZEDs 104. If the actual traffic from the ZED 104 does not match or sufficiently match the expected traffic according to the availability plan, then a charging session is triggered for that ZED 104.

[0077] Fig. 4 is a signalling / sequence diagram illustrating the operations of a PSO 102, ZED 104 and IN 106 in more detail. The operations in the PSO 102 are split across the Data Receiver 110, Analyser 112 and Charge Decision Entity 114.

[0078] The process starts using a trigger sent to the PSO 102 by a third party (this trigger is not shown in Fig. 4). The triggering condition could, for example, be a PSO-internal or external periodical check, or a check according to a probability value distribution, e.g. normal distribution. It can also get triggered due to an event, for example by a third-party, such as an operations support system (OSS), for example Ericsson Network Manager (ENM).

[0079] Once the process has started, the PSO 102 receives data transmissions 311 from one or more ZEDs 104 so that it can provide some type of inferencing and output predicted transmission patterns. The time allowed for transmission data collection can be set by design and can be bounded by use-case requirements, or set by the user, etc.

[0080] If no data is retrieved from one or more ZEDs 104 in the amount of time allotted for data collection, then the Charge Decision module Entity 114 of the PSO 102 can assume that the ZED(s) 104 do not have sufficient power to perform transmissions, and therefore start a charging session.

[0081] If at least some transmissions are received from the one or more ZEDs 104 in the amount of time allotted, then this data is forwarded 312 to the Analyser 112, and the Analyser 112 uses this data with the availability model for time-series prediction of a transmission pattern in an upcoming time period (step 313). Step 313 provides a predicted availability plan, as described above. The availability plan is sent to the Charge Decision Entity 114 (signal 314), and the Charge Decision Entity 114 monitors the transmissions from the ZED(s) 104 over a period of time to determine if they match, or sufficiently match, the predicted transmissions according to the availability plan (step 315). It is not required for the PSO 102 to exhaust the full time period covered by the availability plan (e.g. all 30 minutes of the availability plan in equation (1) above) in order to provide a decision on whether the data transmissions are occurring as predicted or not.

[0082] If in step 315 the Charge Decision Entity 114 determines that a charging session should be triggered, the PSO 102 can start charging the ZEDs 104. The decision to charge can use the part of the availability plan which was found to be mismatched as a reference, as that part can indicate the area in which the charging session should happen.

[0083] Charging can be performed through one or more INs 106, as shown by signals 316, 317 and 318, or directly between the PSO 102 and the ZEDs 104, as shown by signal 319. In the former case, a control signal 316 can be sent to an IN 106 (located in the area indicated by the availability plan) to trigger the IN 106 to charge the ZEDs 104 in its vicinity. In some cases the control signal 316 can be broadcast to the IN 106. The IN 106 can then perform the charging of the ZED(s) 104, as shown by charge signal 318.

[0084] In embodiments where the IN 106 also needs to be charged in order to provide the charging session, the Charge Decision Entity 114 can sent a charge signal 317 to the charge interface of the IN 106 so that the IN 106 charges. The IN 106 can then perform the charging of the ZED(s) 104, as shown by charge signal 318.

[0085] In the case where the charging is performed directly between the PSO 102 and the ZEDs 104, the PSO 102 sends a charge signal 319 to the ZED(s) 104.

[0086] In an extension to the above embodiments, provisioning can be made for destructive interference in power signals used to charge ZEDs. In the case of backscatter-based communication, when the emitted carrier signal and the backscattered signal from a backscatterbased ZED add destructively at the receiver, the charging through the IN 106 or direct charging from the PSO 102 will not be enough for to receive data from the ZED 104. In this case, the PSO 102 can instruct or trigger two or several I Ns 106 in the vicinity of the backscatter- based ZED 104 to transmit a carrier wave with different phase shifts, or request the ZED 104 to add a random phase shift to the backscattered signal to overcome the destructive interference.

[0087] In another extension to the above embodiments, INs to use for a charging session can be selected based on capability. In a network, there can be various types of devices with different capabilities in terms of processing, battery lifetime, number of antennas, and receiver architectures, etc., that could be used as an IN 106 for a charging session. The gNB / PSO 102 can select INs 106 based on their capabilities in order to assist charging ZEDs 104. In one embodiment, the gNB / PSO 102 selects a set of devices (e.g. ‘more capable’ devices) to charge (e.g. using beamforming / power transfer) and then instructs them to charge other battery-limited ZEDs. This can be useful as power transfer can be more efficient / feasible for ‘more capable’ devices (processing capabilities, multi-antenna, etc). Also, those devices have an incentive to charge others.

[0088] Fig. 4 is a flow chart illustrating a method of operating a first node in a Radio Access Network (RAN) according to various embodiments. The first node may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0089] In step 401 , the first node predicts a pattern of transmissions of data by one or more low energy wireless devices using an availability model. The low energy wireless devices may be wireless devices that are configured to collect energy from their environment and use that energy for transmission of data. A low energy wireless device may be an Ambient loT device.

[0090] In step 402, the first node compares an actual pattern of data received from the one or more low energy wireless devices to the predicted pattern to determine if the one or more low energy wireless devices are transmitting data according to the predicted pattern.

[0091] In step 403, if it is determined that one or more of the low energy wireless devices are not transmitting data according to the predicted pattern, then the first node triggers a charging session to provide power to the one or more of the low energy wireless devices and enable data transmissions to be performed.

[0092] After triggering the charging session, the first node may receive data from the one or more low energy wireless devices (e.g. if the charging session was successful). The first node can forward the received data to a destination node (e.g. a server).

[0093] Triggering a charging session in step 403 can comprise sending an instruction to a charging device to perform a charging session for the one or more low energy wireless devices that are not transmitting data according to the predicted pattern. The charging device may be internal to, or part of, the first node. Alternatively, the charging device may be external to, or separate from, the first node.

[0094] In some cases, the charging session is to be performed per low energy wireless device that is not transmitting data according to the predicted pattern. Alternatively, the charging session is to be performed in an area in which the one or more low energy wireless devices that are not transmitting data according to the predicted pattern are located.

[0095] The charging session may comprises or involve any of: illuminating a low energy wireless device with light; transmitting a RF signal to, or in the direction of, the low energy wireless device; moving the low energy wireless device; applying pressure to the low energy wireless device; applying an air flow to the low energy wireless device; applying heat to the low energy wireless device; and applying sound energy to the low energy wireless device.

[0096] The data that the low energy wireless devices transmit, or are to transmit, can comprise one or more measurements of one or more parameters. In particular, the data can comprise measurements of one or more parameters relating to the environment in which the one or more low energy wireless devices are deployed.

[0097] The availability model may predict any of: (i) a pattern of transmissions of data per low energy wireless device; (ii) a pattern of transmissions of data per group of low energy wireless devices; or (iii) a pattern of transmissions of data per area in which one or more low energy wireless devices are located.

[0098] The predicted pattern of transmissions may comprise any of: (i) predicted timings for one or more transmissions of data; (ii) a probability value distribution for transmissions of data per low energy wireless device; or (iii) a probability value distribution for transmissions of data per area in which one or more low energy wireless devices are located.

[0099] In some embodiments, the first node can train the availability model to predict the patterns of transmissions of data by the one or more low energy wireless devices. The training of the availability model can be based on information relating to previous transmissions of data by the one or more low energy wireless devices.

[0100] In embodiments where the availability model predicts a pattern of transmissions of data per area in which one or more low energy wireless devices are located, training the availability model can comprise: grouping or clustering low energy wireless devices into one or more areas based on the information. Then, for each area, the availability model is trained to provide a predicted pattern of transmissions of data for that area using the information relating to previous transmissions of data by the one or more low energy wireless devices in that area.

[0101] The information relating to previous transmissions of data can comprise times of receipt of the data transmissions from the one or more low energy wireless devices. The information relating to previous transmissions of data may additionally comprises any one or more of, per previous data transmission: a time at which the data was transmitted by the low energy wireless device; information from a header of a packet in which the data was transmitted; an identifier of the low energy wireless device that transmitted that data; a destination of the data; a time-to-live, TTL, of the packet; a protocol identifier; a version identifier; a length of a payload in which the data is contained; the data; and a location of the low energy wireless device that transmitted the data.

[0102] Fig. 5 shows an example of a communication system 500 in which the techniques described herein can be used. In the example, the communication system 500 includes a telecommunication network 502 that includes an access network 504, such as a radio access network (RAN), and a core network 506, which includes one or more core network nodes 508. The access network 504 includes one or more access network nodes, such as access network nodes 510a and 510b (which are interchangeably referred to as RAN network nodes 510 herein), or any other similar 3rdGeneration Partnership Project (3GPP) access node or non-3GPP access point (AP). Moreover, as will be appreciated by those of skill in the art, a RAN network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 502 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 502 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 502, including one or more network nodes 510 and / or core network nodes 508.

[0103] Examples of an ORAN network node include an open radio unit (0-Rll), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O- CU user plane (O-CU-UP), a RAN intelligent controller (RIC) (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1 , F1, W1 , E1 , E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O-RAN Alliance or comparable technologies.

[0104] The access network nodes 510 facilitate direct or indirect connection of wireless devices (also referred to interchangeably herein as user equipment (UE)), such as by connecting UEs 512a, 512b, 512c, and 512d (one or more of which may be generally referred to as UEs 512) to the core network 506 over one or more wireless connections. The access network nodes 510 may be, for example, access points (APs) (e.g. radio access points), base stations (BSs) (e.g. radio base stations, Node Bs, evolved Node Bs (eNBs) and New Radio (NR) NodeBs (gNBs)). Any of the UEs 512a, 512b, 512c, and 512d can be a ZED / Ambient loT device. The first node / PSO 102 provided by the techniques described herein can be implemented as, or as part of, a node in the RAN 504, such as an access network node 510.

[0105] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 500 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 500 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0106] The wireless devices / UEs 512 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 510 and other communication devices. Similarly, the access network nodes 510 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 512 and / or with other network nodes or equipment in the telecommunication network 502 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 502.

[0107] In the depicted example, the core network 506 connects the access network nodes 510 to one or more hosts, such as host 516. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 506 includes one more core network nodes (e.g. core network node 508) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the wireless devices / UEs, access network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 508. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (ALISF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0108] The host 516 may be under the ownership or control of a service provider other than an operator or provider of the access network 504 and / or the telecommunication network 502, and may be operated by the service provider or on behalf of the service provider. The host 516 may host a variety of applications to provide one or more services. Examples of such applications include the provision of live and / or pre-recorded audio / video content, data collection services, for example, retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0109] In the present disclosure, host 516 may be the (final) destination node for the data collected and transmitted by the ZEDs 512.

[0110] As a whole, the communication system 500 of Fig. 5 enables connectivity between the wireless devices / UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2ndGeneration (2G), 3rdGeneration (3G), 4thGeneration (4G), 5thGeneration (5G) standards, or any applicable future generation standard (e.g. 6thGeneration (6G)); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0111] In some examples, the telecommunication network 502 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 502 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 502. For example, the telecommunications network 502 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive Internet of Things (loT) services to yet further UEs.

[0112] In some examples, the UEs 512 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 504 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 504. Additionally, a UE may be configured for operating in single- or multi-radio access technology (RAT) or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved- UTRA (UMTS Terrestrial Radio Access) Network) New Radio - Dual Connectivity (EN-DC).

[0113] In the example illustrated in Fig. 5, a hub 514 is provided that communicates with the access network 504 to facilitate indirect communication between one or more UEs (e.g. UE 512c and / or 512d) and access network nodes (e.g. access network node 510b). In particular implementations, UEs 512C and 512D could be ZEDs, and the hub 514 is configured to perform the techniques described herein if data is not received from one or more of the ZEDs 512.

[0114] In some examples, the hub 514 may be a controller, router, a content source and analytics node, or any of the other communication devices described herein regarding UEs. For example, the hub 514 may be a broadband router enabling access to the core network 506 for the UEs. As another example, the hub 514 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 510, or by executable code, script, process, or other instructions in the hub 514. As another example, the hub 514 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 514 may be a content source. For example, for a UE that is a Virtual Reality VR headset, display, loudspeaker or other media delivery device, the hub 514 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 514 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 514 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy Internet of Things (loT) devices.

[0115] The hub 514 may have a constant / persistent or intermittent connection to the network node 510b. The hub 514 may also allow for a different communication scheme and / or schedule between the hub 514 and UEs (e.g. UE 512c and / or 512d), and between the hub 514 and the core network 506. In other examples, the hub 514 is connected to the core network 506 and / or one or more UEs via a wired connection. Moreover, the hub 514 may be configured to connect to a Machine-to-Machine (M2M) service provider over the access network 504 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 510 while still connected via the hub 514 via a wired or wireless connection. In some embodiments, the hub 514 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 510b. In other embodiments, the hub 514 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 510b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0116] Fig. 6 shows an access network node 600 or RAN network node 600 in accordance with some embodiments. In particular, the access network node 600 or RAN network node 600 can be the node that performs the techniques described herein, or the access network node 600 or RAN network node 600 can host or comprise the (logical or physical) first node that performs the techniques described herein.

[0117] As used herein, access network node or RAN network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other RAN network nodes or equipment or core network nodes, in a telecommunication network. Examples of access network nodes include, but are not limited to, access network nodes such as APs (e.g. radio access points), base stations (BSs) (e.g. radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), Open RAN (O-RAN) nodes or components of an O- RAN node (e.g., O-RU, O-DU, O-CU).

[0118] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A RAN network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node), and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0119] Other examples of access network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g. Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0120] The RAN network node 600 includes processing circuitry 602, a memory 604, a communication interface 606, and a power source 608, and / or any other component, or any combination thereof. The RAN network node 600 may be composed of multiple physically separate components (e.g. a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the RAN network node 600 comprises multiple separate components (e.g. BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the RAN network node 600 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g. separate memory 604 for different RATs) and some components may be reused (e.g. a same antenna 610 may be shared by different RATs). The RAN network node 600 may also include multiple sets of the various illustrated components for different wireless technologies integrated into RAN network node 600, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within RAN network node 600.

[0121] The processing circuitry 602 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other RAN network node 600 components, such as the memory 604, to provide network node 600 functionality. For example, the processing circuitry 602 may be configured to cause the RAN network node, or a logical node implemented in the RAN network node to perform the method described with reference to Fig. 4.

[0122] In some embodiments, the processing circuitry 602 includes a system on a chip (SOC). In some embodiments, the processing circuitry 602 includes one or more of radio frequency (RF) transceiver circuitry 612 and baseband processing circuitry 614. In some embodiments, the radio frequency (RF) transceiver circuitry 612 and the baseband processing circuitry 614 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 612 and baseband processing circuitry 614 may be on the same chip or set of chips, boards, or units.

[0123] The memory 604 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 602. The memory 604 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 602 and utilized by the RAN network node 600. The memory 604 may be used to store any calculations made by the processing circuitry 602 and / or any data received via the communication interface 606. In some embodiments, the processing circuitry 602 and memory 604 is integrated.

[0124] The communication interface 606 is used in wired or wireless communication of signalling and / or data between network nodes, the access network, the core network, and / or a UE. As illustrated, the communication interface 606 comprises port(s) / terminal(s) 616 to send and receive data, for example to and from a network over a wired connection.

[0125] The communication interface 606 also includes radio front-end circuitry 618 that may be coupled to, or in certain embodiments a part of, the antenna 610. Radio front-end circuitry 618 comprises filters 620 and amplifiers 622. The radio front-end circuitry 618 may be connected to an antenna 610 and processing circuitry 602. The radio front-end circuitry may be configured to condition signals communicated between antenna 610 and processing circuitry 602. The radio front-end circuitry 618 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 618 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 620 and / or amplifiers 622. The radio signal may then be transmitted via the antenna 610. Similarly, when receiving data, the antenna 610 may collect radio signals which are then converted into digital data by the radio front-end circuitry 618. The digital data may be passed to the processing circuitry 602. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0126] In certain alternative embodiments, the access network node 600 does not include separate radio front-end circuitry 618, instead, the processing circuitry 602 includes radio front-end circuitry and is connected to the antenna 610. Similarly, in some embodiments, all or some of the RF transceiver circuitry 612 is part of the communication interface 606. In still other embodiments, the communication interface 606 includes one or more ports or terminals 616, the radio front-end circuitry 618, and the RF transceiver circuitry 612, as part of a radio unit (not shown), and the communication interface 606 communicates with the baseband processing circuitry 614, which is part of a digital unit (not shown).

[0127] The antenna 610 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 610 may be coupled to the radio front-end circuitry 618 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 610 is separate from the network node 600 and connectable to the RAN network node 600 through an interface or port.

[0128] The antenna 610, communication interface 606, and / or the processing circuitry 602 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 610, the communication interface 606, and / or the processing circuitry 602 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0129] The power source 608 provides power to the various components of RAN network node 600 in a form suitable for the respective components (e.g. at a voltage and current level needed for each respective component). The power source 608 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 600 with power for performing the functionality described herein. For example, the RAN network node 600 may be connectable to an external power source (e.g. the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 608. As a further example, the power source 608 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0130] Embodiments of the RAN network node 600 may include additional components beyond those shown in Fig. 6 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the RAN network node 600 may include user interface equipment to allow input of information into the RAN network node 600 and to allow output of information from the RAN network node 600. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the RAN network node 600.

[0131] Fig. 7 is a block diagram illustrating a virtualization environment 700 in which functions implemented by some embodiments may be virtualized.

[0132] In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein as performed by the node in the RAN may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 700 hosted by one or more of hardware nodes, such as a hardware computing device that operates as an access network node, a hub (e.g. hub 514), a core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g. a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 700 includes components defined by the Open-RAN (O-RAN) Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface.

[0133] Applications 702 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 700 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0134] Hardware 704 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 706 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 708a and 708b (one or more of which may be generally referred to as VMs 708), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 706 may present a virtual operating platform that appears like networking hardware to the VMs 708.

[0135] The VMs 708 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 706. Different embodiments of the instance of a virtual appliance 702 may be implemented on one or more of VMs 708, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0136] In the context of NFV, a VM 708 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 708, and that part of hardware 704 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 708 on top of the hardware 704 and corresponds to the application 702.

[0137] Hardware 704 may be implemented in a standalone network node with generic or specific components. Hardware 704 may implement some functions via virtualization. Alternatively, hardware 704 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 710, which, among others, oversees lifecycle management of applications 702. In some embodiments, hardware 704 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signalling can be provided with the use of a control system 712 which may alternatively be used for communication between hardware nodes and radio units.

[0138] Fig. 8 is a simplified block diagram of a first node 800 according to various embodiments that can be used to implement one or more of the techniques described herein. As noted above, the first node 800 may be, or be part of, a node in the RAN of a communication network. The node in the RAN may be any of a UE, a base station, eNB, gNB, etc. In particular embodiments, the first node 800 is a physical node or a logical function in the RAN, for example hub 514 in Fig. 5, a logical node in a gNB in a 5G / NR network, or a logical node in a base station / RAN node in a 6G network. The first node 800 may be, or be part of, a CU, a DU, a baseband unit, a switch unit, or a RIC.

[0139] The first node 800 comprises processing circuitry (or logic) 801 . It will be appreciated that the first node 800 may comprise one or more virtual machines running different software and / or processes. The first node 800 may therefore comprise, or be implemented in or as one or more servers, switches and / or storage devices and / or may comprise cloud computing infrastructure that runs the software and / or processes.

[0140] The processing circuitry 801 controls the operation of the first node 800 to implement the methods described herein. The processing circuitry 801 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the first node 800 in the manner described herein. In particular implementations, the processing circuitry 801 can comprise a plurality of software and / or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the first node 800.

[0141] The first node 800 also comprises a communications interface 802. The communications interface 802 is for use in enabling communications with other network nodes, computers, servers, etc. For example, the communications interface 802 can be configured to transmit to and / or receive from other nodes, requests, acknowledgements, information, data, signals, or similar. The communications interface 802 can use any suitable communication technology.

[0142] The processing circuitry 801 may be configured to control the communications interface 802 to transmit to and / or receive from other nodes, etc. requests, acknowledgements, information, data, signals, or similar, according to the methods described herein.

[0143] The first node 800 may comprise a memory 803. In some embodiments, the memory 803 can be configured to store program code that can be executed by the processing circuitry 801 to perform the methods described herein in relation to the first node 800. Alternatively or in addition, the memory 803 can be configured to store any requests, acknowledgements, information, data, signals, or similar that are described herein. The processing circuitry 801 may be configured to control the memory 803 to store such information therein.

[0144] Although the computing devices described herein (e.g. UEs, RAN network nodes, core network node, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0145] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device- readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0146] The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the scope of the disclosure. Various exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

Claims

Claims1. A method performed by a first node in a Radio Access Network, RAN, of a communication network, the method comprising: predicting (401), using an availability model, a pattern of transmissions of data by one or more low energy wireless devices; comparing (402) an actual pattern of data received from the one or more low energy wireless devices to the predicted pattern to determine if the one or more low energy wireless devices are transmitting data according to the predicted pattern; and if it is determined that one or more of the low energy wireless devices are not transmitting data according to the predicted pattern, triggering (403) a charging session to provide power to the one or more of the low energy wireless devices and enable data transmissions to be performed.

2. The method of claim 1, wherein triggering (403) a charging session comprises sending, to a charging device, an instruction to perform a charging session for the one or more low energy wireless devices that are not transmitting data according to the predicted pattern.

3. The method as claimed in claim 2, wherein the charging device is internal to, or part of, the first node.

4. The method as claimed in claim 2, wherein the charging device is external to, or separate from, the first node.

5. The method as claimed in any of claims 1-4, wherein the charging session is to be performed per low energy wireless device that is not transmitting data according to the predicted pattern.

6. The method as claimed in any of claims 1-4, wherein the charging session is to be performed in an area in which the one or more low energy wireless devices that are not transmitting data according to the predicted pattern are located.

7. The method as claimed in any of claims 1-6, wherein the charging session comprises any of: illuminating a low energy wireless device with light;• transmitting a radio frequency, RF, signal to, or in the direction of, the low energy wireless device;• moving the low energy wireless device;• applying pressure to the low energy wireless device;• applying an air flow to the low energy wireless device;• applying heat to the low energy wireless device; and• applying sound energy to the low energy wireless device.

8. The method as claimed in any of claims 1-7, wherein the data comprises one or more measurements of one or more parameters.

9. The method as claimed in any of claims 1-8, wherein the data comprises one or more measurements of one or more parameters relating to the environment in which the one or more low energy wireless devices are deployed.

10. The method as claimed in any of claims 1-9, wherein the method further comprises: after triggering the charging session, receiving data from the one or more low energy wireless devices.

11. The method as claimed in claim 10, wherein the method further comprises: forwarding the received data to a destination node.

12. The method as claimed in any of claims 1-11 , wherein the availability model predicts (i) a pattern of transmissions of data per low energy wireless device; (ii) a pattern of transmissions of data per group of low energy wireless devices; or (iii) a pattern of transmissions of data per area in which one or more low energy wireless devices are located.

13. The method as claimed in any of claims 1-12, wherein the predicted pattern of transmissions comprises (i) predicted timings for one or more transmissions of data; (ii) a probability value distribution for transmissions of data per low energy wireless device; or (iii) a probability value distribution for transmissions of data per area in which one or more low energy wireless devices are located.

14. The method as claimed in any of claims 1-13, wherein the method further comprises:training the availability model to predict a pattern of transmissions of data by one or more low energy wireless devices, wherein the availability model is trained based on information relating to previous transmissions of data by the one or more low energy wireless devices.

15. The method as claimed in claim 14, wherein the information relating to previous transmissions of data comprises times of receipt of the data from the one or more low energy wireless devices.

16. The method as claimed in claim 15, wherein the information relating to previous transmissions of data further comprises any one or more of, per previous data transmission:• a time at which the data was transmitted by the low energy wireless device;• information from a header of a packet in which the data was transmitted;• an identifier of the low energy wireless device that transmitted that data;• a destination of the data;• a time-to-live, TTL, of the packet;• a protocol identifier;• a version identifier;• a length of a payload in which the data is contained;• the data; and• a location of the low energy wireless device that transmitted the data.

17. The method as claimed in any of claims 14-16, wherein the availability model predicts a pattern of transmissions of data per area in which one or more low energy wireless devices are located, and wherein training the availability model comprises: grouping or clustering low energy wireless devices into one or more areas based on the information; and for each area, training the availability model to provide predicted pattern of transmissions of data for that area using the information relating to previous transmissions of data by the one or more low energy wireless devices in that area.

18. The method as claimed in any of claims 1-17, wherein a low energy wireless device is a wireless device that is configured to collect energy from its environment and use that energy for transmission of data.

19. The method as claimed in any of claims 1-18, wherein a low energy wireless device is an Ambient Internet of Things, loT, device.

20. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of the claims 1-19.

21. A first node, configured to perform the method of any of claims 1-19.

22. A first node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said first node is operative to perform the method of any of claims 1-19.

Images