Obtaining data from 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 determining (401), using a transmission model, a first expected time window in which data is expected to be received from a first low energy wireless device; in the absence of data from the first low energy wireless device in a first expected time window, obtaining (403) data from an alternative source of data; the alternative source being one or more other low energy wireless devices or a data generation model; and forwarding (405) the obtained data to a destination node.

Description

[0001] Obtaining data from low energy wireless devices

[0002] Technical Field

[0003] This disclosure relates to low energy wireless devices, and in particular to techniques for obtaining data when an expected data transmission from a low energy wireless device is not received.

[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.

[0005] Low energy wireless devices are also known as Ambient Internet of Things (loT) devices. The 3rd Generation Partnership Project (3GPP) has a Study Item (SI) on Ambient loT (3GPP RP- 222685 by Huawei and HiSilicon). In that SI, it is noted that:

[0006] “Most of the existing wireless communication devices are powered by battery that needs to be replaced or recharged manually. The automation and digitalization of various industries open numbers of new markets requiring new loT technologies of supporting batteryless devices with no energy storage capability or devices with energy storage that do not need to be replaced or recharged manually. The form factor of such devices must be reasonably small to convey the validity of target use cases.”

[0007] As used herein, a low energy wireless device is considered to include the types of devices that the above 3GPP SI is directed towards, namely “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”.

[0008] ZEDs can have a wide range of possible use cases. For example, one use case could be for the monitoring of forest fires, where ZEDs are placed in forests, or for detecting water levels for assessing the risks of flooding. Other use cases could involve ZEDs monitoring machinery in factories, such as those that measure the velocity of conveyor belts, measuring building occupancy to adjust air conditioning, etc.

[0009] Due to the opportunistic nature of data transmission by ZEDs, an important characteristic of ZED-reporting is the assumption that timely reception of data transmitted by these ZEDs is not guaranteed. This limits the value of ZED devices, as some use cases may require them to transmit information within time intervals where ambient power cannot be harvested by the ZED. Summary

[0010] Various approaches are being taken to reduce the amount of power required for ZEDs to transmit, or to improve the ability of the ZEDs to harvest energy from the environment, but these approaches do not address the problem where there is insufficient energy to be harvested, and therefore transmission by a particular ZED cannot occur.

[0011] These ZEDs will be transmitting their data, via a radio access network (RAN), to a particular destination node, such as a server, that collates and evaluates data from multiple ZEDs. The destination node can perform a service using the data from the ZEDs. The type of service performed can depend on the type of data the ZEDs are configured to provide. For example, a server can receive data from multiple ZEDs that measure temperature and / or air quality and are deployed in a forest. The server can analyse the data to determine which parts of the forest are on fire. Depending on the deployment scenario, it can be important for the destination node (e.g. server) to receive as complete a data set as possible, e.g. timely measurements from all, or as many, of the ZEDs as possible, despite the challenges ZEDs may have with collecting sufficient energy be able to transmit at the required or expected times.

[0012] This disclosure addresses this problem, and provides techniques for a node to obtain data when an expected data transmission from a low energy wireless device (ZED) is not received. More generally, this disclosure provides techniques for providing data from alternative data sources to a receiving device (the destination node), given unavailability of data from a source device (ZED).

[0013] The alternative source can be another ZED, in which case the node can copy data received from that other ZED and send it to the destination node as data from the ZED from which data was not received. In another approach, the alternative source can alternatively be a data generation model that can be used to generate / estimate the data that would have been received from the ZED, and the node in the RAN can send this generated data to the destination node as data from the ZED from which data was not received. Thus, data from an unavailable ZED is substituted with data from another (similar) ZED, or substituted with synthetic (generated) data.

[0014] The node can be any node in data path between the ZED and destination (e.g. server) for the data. Preferably the node is in the RAN of a communication network, as the techniques make use of information about the RAN and / or ZEDs, although it is also possible for the node to be implemented outside of the RAN (e.g. in a core network) provided it has access to the information it needs to perform the disclosed techniques.

[0015] Embodiments provide that the node in the RAN is a physical node or a logical function in the RAN, for example a logical node in a gNB in a 5thGeneration (5G) / New Radio (NR) network, or a logical node in a base station / RAN node in a future 6thGeneration (6G) network. It will be appreciated that the techniques can be applied in the RAN by any type of node in the RAN, such as a centralised unit (CU), a distributed unit (DU), a baseband unit, a switch unit, or a RAN Intelligent Controller (RIC) in an Open-RAN (O-RAN) deployment. This node / logical function is named “Routing Update Function” (RUF) in this disclosure.

[0016] In various embodiments, the node is able or configured to: identify unavailability of one or more ZEDs by learning patterns of transmission, and then identify whether an expected transmission does not happen at the expected time, based on the learnt patterns; identify an alternative source of data, given the unavailability of a ZED (i.e. lack of data at the expected time from the ZED). This alternative source of data can be, for example, one or more other ZEDs (each referred to as a “delegate”), or a data generation model that is used to generate the data; and forward / send the generated data or delegate ZED-produced data toward its final destination.

[0017] With the disclosed techniques, situations where one or more low energy wireless devices / ZEDs are unavailable can be compensated for, either due to no / insufficient ambient power to be harvested or due to malfunction, by selecting another ZED to transmit in its place and / or provide generated data. The techniques can therefore provide a guarantee of transmission of data toward the destination node (e.g. server), even if the original ZED is not available due to malfunction or lack of ambient power.

[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: determining, using a transmission model, a first expected time window in which data is expected to be received from a first low energy wireless device; in the absence of data from the first low energy wireless device in the first expected time window, obtaining data from an alternative source of data; with the alternative source being one or more other low energy wireless devices or a data generation model; and forwarding the obtained data to a destination node.

[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 for use in a communication network, the first node configured to perform the method according to the first aspect or any embodiment thereof. According to a fourth aspect, there is provided a first node for use in a communication network, the 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.

[0021] Brief Description of the Drawings

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

[0023] Fig. 1 is a signalling diagram illustrating training of a transmission model;

[0024] Fig. 2 is a signalling diagram illustrating an embodiment where data from a delegate ZED is used;

[0025] Fig. 3 is a signalling diagram illustrating an embodiment where data from a data generation model is used;

[0026] Fig. 4 is a flow chart illustrating a method in accordance with some embodiments;

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

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

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

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

[0031] Detailed Description

[0032] 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.

[0033] As noted above, techniques are provided for a node (referred to as RUF) to obtain data when an expected data transmission from a low energy wireless device (ZED, Ambient loT device) is not received, and in particular data is obtained from alternative data sources. The alternative source can be another ZED, in which case the RUF can copy data received from that other ZED and send it to the destination node as data from the ZED from which data was not received. In another approach, the alternative source can alternatively be a data generation model that can be used to generate / estimate the data that would have been received from the ZED, and the RUF can send this generated data towards the destination node as data from the ZED from which data was not received. Thus, data from an unavailable ZED is substituted with data from another (similar) ZED, or substituted with synthetic (generated) data. The destination node can perform a service using the data from the ZEDs. The data received by the destination node over time will include data in expected data transmissions (i.e. data that is received at expected time(s) from expected ZED(s)), along with data from the alternative data source described if the RUF does not receive data at the expected time(s) from one or more of the ZEDs. The type of service performed by the destination node can depend on the type of data the ZEDs are configured to provide. The data may comprise measurements of one or more parameters, for example relating to a state of the environment in which the ZED(s) are deployed, and the destination node can provide, adjust or configure a service based on these measurements.

[0034] The signalling diagrams in Figs. 1-3 illustrate the signalling between, and process steps performed by, a ZED 101 (which is also referred to as a “first” ZED) and a node 102 in the form of a RUF. While these figures only show the signalling between a node 102 and a single ZED 101 , it will be appreciated that in practice the node 102 will perform the illustrated signalling and processing with respect to multiple (e.g. several tens, hundreds, or thousands) ZEDs 101. The ZED 101 may be for use in measuring one or more parameters relating to a state of an environment in which the ZED 101 is deployed. The environment could be a domestic, commercial or industrial environment.

[0035] The signalling diagram in Fig. 1 illustrates the training of a transmission model that can be used to predict when a transmission from a ZED is expected. The signalling diagram in Fig. 2 illustrates embodiments where data from a delegate ZED is used as a substitute, and the signalling diagram illustrated in Fig. 3 illustrates alternative embodiments where data from a data generation model is used as a substitute.

[0036] The process 110 in Fig. 1 is considered to be a ‘background task / process’, meaning that it is a task that is performed continuously / periodically / on a loop while ZEDs 101 are being used. The process 110 is for training the transmission model.

[0037] In this process 110, the RUF 102 receives or intercepts data packets (shown as Message 112) from ZEDs 101 with certain payloads (illustrated as “value”). The payload of message 112 may be one or more measurements of a parameter that is monitored by ZED 101 . For example, ZED 101 may monitor the ambient temperature, and the message 112 can comprise one or more measurements of temperature.

[0038] In step 114 the RUF 102 records information about the received data packet, such as the time of packet reception, and an identifier of the ZED (if available). The recorded information can be stored in a local buffer or memory of the RUF 102.

[0039] Further optional information that can be recorded can include the “value” in the message 112. Information on the values in messages from the ZED 101 can be used by the RUF 102 to train a data generation model as used in the embodiment shown in Fig. 3.

[0040] The RUF 102 can also record information on the location of the ZED 101 (which can be expressed at different levels of granularity, e.g. on a cell level, or on a beam level using information from a beamforming manager (BFM) in case beamforming is used, etc.). The information on ZED location can be used as one of the parameters / features a clustering algorithm used in the embodiment shown in Fig. 2 where a delegate ZED is identified.

[0041] The identifier of a ZED may comprise a device class (e.g. A, B or C), the type of energy harvested by the device (e.g., radio frequency (RF) backscatter, solar, wind, light, etc.), a type / size of energy storage capacity of the device (such as super capacitor capability, etc.), and the type of parameter being reported (e.g., temperature, humidity, etc.).

[0042] After recording the required information, the RUF 102 forwards the data packet / message 112 through the RAN towards the final destination (e.g. a server).

[0043] At a suitable time, which can be after a defined amount of time (K) elapses, when a defined number of messages (M) have been received, or when the buffer / memory has enough data, the RUF 102 can perform the training process 118 to train the transmission model. The transmission model is trained to predict a time window in which data is expected to be received from the ZED 101. The transmission model can be a time-series predictor such as a regression model or a long-short term memory (LSTM) recurrent neural network (RNN) or similar, and can preferably be a sequence-to-sequence model. In the present context, this means that given a sequence of incoming messages from a ZED, the model can predict when future messages will be received. The transmission model can be intermittently / periodically retrained throughout the lifetime of the RUF 102, in case new transmission patterns and / or new ZEDs necessitate this retraining.

[0044] The RUF 102 may train respective transmission models for each ZED 101 in the network, with each trained using stored records relating to the messages 112 from the respective ZED 101.

[0045] In a particular embodiment of process 118 illustrated in Fig. 1 , in process 118 the RUF 102 retrieves all the stored records or a subset X of the stored records from the buffer (step 120), splits the retrieved records into a training data set / list and a test data set / list (step 122), and trains the transmission model using supervised learning techniques and the training data set / list.

[0046] Once the transmission model is trained, the transmission model is used to predict time windows in which data is expected to be received from the ZED 101. If data is not received in a predicted / expect time window, then the method in Fig. 2 or Fig. 3 can be used to determine substitute data.

[0047] In Fig. 2, a process 210 - which is another background task - is performed in which the RUF 102 creates or updates profile information for the ZED 101 based on messages 212 sent by the ZED 101. These messages 212 are the same types of messages as message 112 in Fig. 1. The profile for the ZED 101 is created or updated in step 214 based on these messages 212, and the profile can include information such as an identifier of the ZED 101 (if available), a location of the ZED, the “value” (payload) in the message 212 (or a probability value distribution of the payload values), the destination of the message 212 (e.g. a server IP address), and information identifying or defining the transmission model applicable to the ZED 101.

[0048] Process 216 runs in a loop (i.e. repeats) for the multiple ZEDs using the RAN, and process 216 includes the RUF 102 using the transmission model for ZED 101 to predict one or more time windows in which data is expected to be received from the ZED 101 (step 218). Process 216 can be run periodically or in response to a trigger from an external event.

[0049] If the RUF 102 does not receive data (a message) from the ZED 101 (“first ZED”) in the expected time window as indicated by the transmission model, then the RUF 102 performs process 220 of looped process 216 to determine an alternative source (an alternative ZED) for the data.

[0050] In step 222 of process 220, the profiles for the different ZEDs are clustered using a clustering algorithm, for example using K-means clustering, or similar. The clustering can be performed based on any one or more of the characteristics in the ZED profiles, such as location, transmission / traffic patterns, ZED mobility, resource demands and priority.

[0051] In step 224 the RUF 102 selects another ZED that is in the same cluster as first ZED 101 (the ZED that data has not been received from in the predicted time window). The selected ZED is referred to as “targetZED”. When targetZED transmits a new message (shown as message 226), the RUF 102 can ‘copy’ (duplicate) the message 226, and change the source and the destination information in the message 226 to the source and destination applicable to the first ZED 101 (step 228). The RUF 102 then transmits that copied message to the destination node (step 230). In this way, the destination node does not experience missing data for the first ZED 101 , and is not otherwise aware that the RUF 102 has substituted in data from another ZED.

[0052] Although the clustering step 222 is shown in Fig. 2 as being performed once data has not been received from the first ZED 101 in the expected time window, it will be appreciated that the clustering step 222 can be performed once enough ZED profiles have been created / updated, and before missing data / messages occur.

[0053] In a modified approach to that shown in Fig. 2, rather than just select a single ZED to provide the substitute data for the first ZED 101 , step 224 can comprise selecting / identifying multiple ZEDs from the cluster associated with the first ZED 101. In a first case, having selected multiple ZEDs, the RUF 102 may receive messages 226 from each of them (or from multiples ones of the ZEDs in a time window), and determine an ‘average payload’ (e.g. an average of the measurements across the multiple payloads) to use as the substitute data sent on behalf of the first ZED 101. This first case provides a way to increase the accuracy of substitute data compared to just selecting a single ZED. In a second case, multiple ZEDs are selected from the cluster in case each of these individually do not transmit messages at a rate required by the RUF 102 to use them as substitute data for the first ZED 101 .

[0054] In the embodiment shown in Fig. 3, a process 310 is performed in which substitute data is generated using a data generation model. The RUF 102 receives messages 312 from the ZED 101 , and stores information relating to the messages 312 in a buffer or memory (step 314). The information relating to each message 312 can be an identifier for the ZED 101 , and a value / payload of the message 312. The messages 312 can be the same type of messages as message 112 in Fig. 1.

[0055] In step 316, the RUF 102 trains a data generation model using the information stored in the buffer in step 314. That is, the data generation model is trained using the stored ZED identifier- payload / value pairs (tuples), which form a training dataset. In some embodiments of the training, the data generation model is trained to learn a probability value distribution of the payload / values and generate new values across this distribution when requested. In some embodiments, the data generation model is a Generative Adversarial Network (GAN).

[0056] Although not shown as a background task in Fig. 3, steps 312-316 can be performed as a background task.

[0057] In step 318 the RUF 102 uses the transmission model for ZED 101 to predict one or more time windows in which data is expected to be received from the ZED 101. Step 318 can be run periodically or in response to a trigger from an external event.

[0058] If the RUF 102 does not receive data (a message) from the ZED 101 (“first ZED”) in the expected time window as indicated by the transmission model, then the RUF 102 performs process 320 in which the RUF 102 uses the trained data generation model to generate substitute data for the first ZED 101 (step 322).

[0059] The RUF 102 generates a message to send to the destination node that includes the generated data (payload), and indicating the source and destination applicable to the first ZED 101. The RUF 102 then transmits that message to the destination node (step 324). In this way, the destination node does not experience missing data for the first ZED 101 , and is not otherwise aware that the RUF 102 has substituted in data generated by a data generation model.

[0060] In a further embodiment, the RUF 102 may be able to make use of both the delegate ZED embodiment and the data generation model embodiment. That is, if a first ZED 101 does not send data at an expected time, the RUF 102 can select both a ZED delegate, and use the data generation model to generate data. This can be useful where, for example, ZED delegates for a first ZED 101 have profiles that indicate through the transmission model profile information that data from that delegate ZED is sparsely available, not matching the normal availability of the data from the first ZED 101. In this case, the RUF 102 may decide to supplement the data provided by the delegate ZED(s) with data from the data generation model.

[0061] Fig. 4 is a flow chart illustrating a method according to various embodiments performed by a first node, e.g. the RUF 102. The first node can be in, or part of, the RAN of a communication network. 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.

[0062] In step 401, the first node determines a first expected time window in which data is expected to be received from a first low energy wireless device. The expected time window is determined using a transmission model. The first low energy wireless device can be a wireless device that is configured to collect energy from its environment and use that energy for transmission of data. The first low energy wireless device can be an Ambient loT device.

[0063] The transmission model may be a time-series prediction model, a regression model, or a LSTM recurrent neural network.

[0064] The transmission model may have been trained (by the first node) to predict one or more time windows in which data is expected to be received from the first low energy wireless device. This training can be performed using timing information relating to a time of receipt of previous data from the first low energy wireless device.

[0065] In step 403, in the absence of data from the first low energy wireless device in the first expected time window, the first node obtains data from an alternative source of data. The alternative source is one or more other low energy wireless devices, or a data generation model.

[0066] The first node then forwards the obtained data to a destination node (step 405). The destination node may be in the RAN, in a core network part of the communication network, or may be external to the communication network, such as a server.

[0067] In some embodiments, the alternative source is one or more other low energy wireless devices. In these embodiments, step 403 can comprise identifying at least a second low energy wireless device to receive the data from. Step 403 can then comprise the first node receiving data from at least the second low energy wireless device. In step 405 the first node can then forward the data received from the second low energy wireless device to the destination node. The data can be forwarded in a first data packet that indicates the source of the data as the first low energy wireless device. The data is also forwarded in a second data packet to a destination node applicable to the second low energy wireless device, with that data packet indicating the source of the data as the second low energy wireless device. That is, in addition to the first node copying the data for use in a data packet purporting to be from the first low energy wireless device, the first node forwards the data from the second low energy wireless device to its destination node in the usual way.

[0068] In some embodiments, the first node can store respective profiles for a plurality of low energy wireless devices that communicate with the first node. In this case, step 403 can comprise identifying the second low energy wireless device as a low energy wireless device that has a similar profile to the first low energy wireless device. In particular embodiments, the profiles can be clustered into a plurality of clusters (e.g. using a data clustering algorithm), and the second low energy wireless device can be identified as a device with a profile in the same cluster as the profile of the first low energy wireless device.

[0069] A profile for a low energy wireless device can include any one or more of: a location of the device; a destination node for data from the device; a type of device; a traffic pattern of data transmissions from the device; a mobility pattern of the device; a resource demand pattern of the device; a priority of the device; a transmission plan for data transmissions by the device; and a distribution of data transmitted by the device.

[0070] In some embodiments, the alternative source is the data generation model. In these embodiments, step 403 can comprise generating data for the first low energy wireless device using the data generation model. In step 405 the first node can then forward the generated data to the destination node. The data can be forwarded in a first data packet that indicates the source of the data as the first low energy wireless device.

[0071] The method performed by the first node may further comprise the first node generating the data generation model from data previously received from the first low energy wireless device.

[0072] The data generation model may comprise a probability value distribution generated from data previously received from the first low energy wireless device. In some embodiments, the data generation model is a Generative Adversarial Network, GAN.

[0073] The first node can perform the method in Fig. 4 and as described above for a plurality of low energy wireless devices.

[0074] 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.

[0075] 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- Cll 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 O-2 interface defined by the O-RAN Alliance or comparable technologies.

[0076] 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.

[0077] Unless otherwise indicated, the general term ‘network node’ as used herein refers to access network nodes 510 and core network nodes 508, and the techniques described herein can be implemented in either type of node. 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.

[0078] 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.

[0079] 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 (AUSF), 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).

[0080] 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.

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

[0082] 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.

[0083] 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.

[0084] 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).

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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) node that performs the techniques described herein.

[0089] 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).

[0090] 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).

[0091] 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).

[0092] 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.

[0093] 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 to perform the methods as described with reference to any of Figs. 1-4.

[0094] 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.

[0095] 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.

[0096] 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.

[0097] 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.

[0098] 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).

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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.

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

[0104] 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 0-2 interface.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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.

[0110] Fig. 8 is a simplified block diagram of a node 800 according to various embodiments that can be used to implement one or more of the techniques described herein. As noted above, the node 800 may be any node in data path between a ZED and a destination (e.g. server) for data from the ZED. The node may be in the RAN of a communication network, or outside of the RAN, e.g. in a core network. In particular embodiments, the 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 node 800 may be a CU, a DU, a baseband unit, a switch unit, or a RIC.

[0111] The node 800 comprises processing circuitry (or logic) 801. It will be appreciated that the node 800 may comprise one or more virtual machines running different software and / or processes. The 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.

[0112] The processing circuitry 801 controls the operation of the 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 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 node 800.

[0113] The 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.

[0114] 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.

[0115] The 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 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.

[0116] 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.

[0117] 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.

[0118] 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: determining (401), using a transmission model, a first expected time window in which data is expected to be received from a first low energy wireless device; in the absence of data from the first low energy wireless device in the first expected time window, obtaining (403) data from an alternative source of data; wherein the alternative source is one or more other low energy wireless devices or a data generation model; and forwarding (405) the obtained data to a destination node.

2. The method as claimed in claim 1 , wherein the data comprises one or more measurements of one or more parameters.

3. The method as claimed in claim 1 or 2, wherein the data comprises one or more measurements of one or more parameters relating to a state of the environment in which the first low energy wireless device is deployed.

4. The method as claimed in any of claims 1-3, wherein the alternative source is one or more other low energy wireless devices, and wherein the step of obtaining (403) comprises identifying at least a second low energy wireless device to receive the data from.

5. The method as claimed in claim 4, wherein the step of obtaining (403) further comprises receiving data from at least the second low energy wireless device.

6. The method as claimed in claim 5, wherein the step of forwarding (405) comprises: forwarding the data received from the second low energy wireless device to the destination node in a first data packet that indicates the source of the data as the first low energy wireless device.

7. The method as claimed in claim 6, wherein the step of forwarding (405) comprises: forwarding the data received from the second low energy wireless device to the destination node in a second data packet that indicates the source of the data as the second low energy wireless device.

8. The method as claimed in any of claims 4-7, wherein the method further comprises: storing respective profiles for a plurality of low energy wireless devices that communicate with the first node, the plurality of low energy wireless devices including the first low energy wireless device; and wherein the step of identifying comprises identifying the second low energy wireless device as a low energy wireless device that has a similar profile to the first low energy wireless device.

9. The method as claimed in claim 8, wherein the method further comprises: clustering the profiles into a plurality of clusters; and wherein the step of identifying comprises identifying the second low energy wireless device as a low energy wireless device with a profile in the same cluster as the profile of the first low energy wireless device.

10. The method as claimed in claim 8 or 9, wherein a profile for a low energy wireless device comprises any one or more of: a location of the low energy wireless device; a destination node for data from the low energy wireless device; a type of low energy wireless device; a traffic pattern of data transmissions from the low energy wireless device; a mobility pattern of the low energy wireless device; a resource demand pattern of the low energy wireless device; a priority of the low energy wireless device; a transmission plan for data transmissions by the low energy wireless device; and a distribution of data transmitted by the low energy wireless device.

11. The method as claimed in any of claims 1-3, wherein the alternative source is the data generation model, and wherein the step of obtaining (403) comprises generating data for the first low energy wireless device using the data generation model.

12. The method as claimed in claim 11 , wherein the step of forwarding (405) comprises: forwarding the generated data to the destination node in a first data packet that indicates the source of the data as the first low energy wireless device.

13. The method as claimed in claim 11 or 12, wherein the data generation model is a Generative Adversarial Network, GAN.

14. The method as claimed in any of claims 11-13, wherein the method further comprises: generating the data generation model from data previously received from the first low energy wireless device.

15. The method as claimed in any of claims 11-14, wherein the data generation model comprises a probability value distribution generated from data previously received from the first low energy wireless device.

16. The method as claimed in any of claims 1-15, wherein the transmission model is a timeseries prediction model, a regression model, or a long-short term memory, LSTM, recurrent neural network.

17. The method as claimed in any of claims 1-16, wherein the transmission model is trained to predict one or more time windows in which data is expected to be received from the first low energy wireless device.

18. The method as claimed in claim 17, wherein the transmission model is trained using timing information relating to a time of receipt of previous data from the first low energy wireless device.

19. The method as claimed in any of claims 1-18, 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.

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

21. The method as claimed in any of claims 1-20, wherein the first node further performs the method for a plurality of low energy wireless devices.

22. The method as claimed in any of claims 1-21 , wherein the obtained data is forwarded to the destination node for use by the destination node in performing a service based on the obtained data.

23. 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 claims 1-21.

24. A first node for use in a communication network, the first node configured to perform the method of any of claims 1-21.

25. A first node for use in a communication network, the first node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said node is operative to perform the method of any of claims 1-21.

Images