WO2024088605A1

WO2024088605A1 - Authorizing wireless communication devices to communicate with ambient devices

Info

Publication number: WO2024088605A1
Application number: PCT/EP2023/067077
Authority: WO
Inventors: Apostolis Salkintzis; Dimitris DIMOPOULOS; Genadi Velev
Original assignee: Lenovo (Singapore) Pte. Ltd
Priority date: 2023-05-18
Filing date: 2023-06-23
Publication date: 2024-05-02

Abstract

There is provided a method in a first network function, the method comprising: receiving an AIoT connection request from a user equipment, the AIoT connection request comprising an identity of the user equipment; and sending authorization to the user equipment, the authorization authorizing the user equipment to communicate with at least one AIoT device, the authorization comprising an identity of the at least one AIoT device. The method further comprises: sending a trigger indication message to the user equipment, the trigger indication message comprising AIoT parameters required for the user equipment to communicate with the at least one AIoT of device; and receiving an AIoT relay response message from the at least one AIoT device, the AIoT relay response message relayed via the user equipment.

Description

AUTHORIZING WIRELESS COMMUNICATION DEVICES

TO COMMUNICATE WITH AMBIENT DEVICES

Field

[0001] The subject matter disclosed herein relates generally to the field of authorizing wireless communication devices to communicate with ambient devices. This document defines a first network function, a method in a first network function, a user equipment, a method in a user equipment, an AIoT device, and a method in an AIoT device.

Introduction

[0002] The “Ambient power-enabled Internet of Things” may comprise “ambient loT” devices that are able to communicate with mobile networks, such as legacy wireless communication networks, 5G networks and beyond. An “ambient loT” device is an Internet of Things (loT) device powered by harvesting energy, such as RF energy, solar energy, wind energy, etc. An ambient loT device may be battery-less and may have limited energy storage capability (e.g., using an internal capacitor).

[0003] By way of example, RF energy harvesting enables wireless loT devices to harvest energy from RF signals available in their environment, such as RF signals transmitted from mobile networks or from nearby Wi-Fi networks. RF energy harvesting is a technology that enables self-sustainable wireless loT networks.

Summary

[0004] A problem with ambient loT devices is that they are often only capable of short range transmission, and may be deployed at a location where their transmissions cannot reach a base station.

[0005] Disclosed herein are procedures for authorizing wireless communication devices to communicate with ambient devices. Said procedures may be implemented by a first network function, a method in a first network function, a user equipment, a method in a user equipment, an AIoT device, and a method in an AIoT device.

[0006] Accordingly, there is provided a first network function comprising a processor and a memory coupled with the processor, the memory comprising instructions executable by the processor to cause the first network function to: receive an AIoT connection request from a user equipment, the AIoT connection request comprising an identity of the user equipment; and send authorization to the user equipment, the authorization authorizing the user equipment to communicate with at least one AIoT device, the authorization comprising an identity of the at least one AIoT device. The first network function is further caused to send a trigger indication message to the user equipment, the trigger indication message comprising AIoT parameters required for the user equipment to communicate with the at least one AIoT of device; and receive an AIoT relay response message from the at least one AIoT device, the AIoT relay response message relayed via the user equipment.

[0007] There is further provided a method in a first network function, the method comprising: receiving an AIoT connection request from a user equipment, the AIoT connection request comprising an identity of the user equipment; and sending authorization to the user equipment, the authorization authorizing the user equipment to communicate with at least one AIoT device, the authorization comprising an identity of the at least one AIoT device. The method further comprises: sending a trigger indication message to the user equipment, the trigger indication message comprising AIoT parameters required for the user equipment to communicate with the at least one AIoT of device; and receiving an AIoT relay response message from the at least one AIoT device, the AIoT relay response message relayed via the user equipment.

[0008] There is further provided a user equipment comprising a processor and a memory coupled with the processor, the memory comprising instructions executable by the processor to cause the user equipment to: send an AIoT connection request to a first network function, the AIoT connection request comprising an identity of the user equipment; and receive authorization from the first network function, the authorization authorizing the user equipment to communicate with at least one AIoT device, the authorization comprising an identity of the at least one AIoT device. The user equipment is further caused to receive a trigger indication message from the first network function, the trigger indication message comprising AIoT parameters required for the user equipment to communicate with the at least one AIoT of device; receive an AIoT relay response message from the at least one AIoT device; and relay the AIoT relay response message to the first network function.

[0009] There is further provided a method in a user equipment, the method comprising: sending an AIoT connection request to a first network function, the AIoT connection request comprising an identity of the user equipment; and receiving authorization from the first network function, the authorization authorizing the user equipment to communicate with at least one AIoT device, the authorization comprising an identity of the at least one AIoT device. The method further comprises receiving a trigger indication message from the first network function, the trigger indication message comprising AIoT parameters required for the user equipment to communicate with the at least one AIoT of device; receiving an AIoT relay response message from the at least one AIoT device; and relaying the AIoT relay response message to the first network function.

[0010] There is further provided an AIoT device comprising a processor and a memory coupled with the processor, the memory comprising instructions executable by the processor to cause the AIoT device to: receive a trigger message transmitted from a user equipment, the trigger message comprising the identity of the AIoT device and security parameters; validate the trigger message using the security parameters and security material stored in the AIoT device; and in response to successful validation of the trigger message, transmit an AIoT relay response message to the user equipment.

[0011] There is further provided a method in an AIoT device, the method comprising: receiving a trigger message transmitted from a user equipment, the trigger message comprising the identity of the AIoT device and security parameters; validating the trigger message using the security parameters and security material stored in the AIoT device; and in response to successful validation of the trigger message, transmitting an AIoT relay response message to the user equipment.

Brief description of the drawings

[0012] In order to describe the manner in which advantages and features of the disclosure can be obtained, a description of the disclosure is rendered by reference to certain apparatus and methods which are illustrated in the appended drawings. Each of these drawings depict only certain aspects of the disclosure and are not therefore to be considered to be limiting of its scope. The drawings may have been simplified for clarity and are not necessarily drawn to scale.

[0013] Methods and apparatus for authorizing wireless communication devices to communicate with ambient devices will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 depicts an embodiment of a wireless communication system for authorizing wireless communication devices to communicate with ambient devices;

Figure 2 depicts a user equipment apparatus that may be used for implementing the methods described herein; Figure 3 depicts further details of the network node that may be used for implementing the methods described herein;

Figure 4 illustrates a system for facilitating UE relay of AIoT device data;

Figure 5 is a messaging diagram illustrating an example of a method as described herein;

Figures 6a, 6b and 6c illustrate hash functions that are implemented in the method described herein;

Figure 7 illustrates a method in a first network function;

Figure 8 illustrates a method in a user equipment; and Figure 9 illustrates a method in an AIoT device.

Detailed description

[0014] A problem with ambient loT (AIoT) devices is that they are often only capable of short-range transmission and may be deployed at a location where their transmissions cannot reach a base station.

[0015] Prior to delving further into the details of the techniques presented herein, note that, as will be appreciated by one skilled in the art, aspects of this disclosure may be embodied as a system, apparatus, method, or program product. Accordingly, arrangements described herein may be implemented in an entirely hardware form, an entirely software form (including firmware, resident software, micro-code, etc.) or a form combining software and hardware aspects.

[0016] For example, the disclosed methods and apparatus may be implemented as a hardware circuit comprising custom very-large-scale integration (“VLSI”) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed methods and apparatus may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. As another example, the disclosed methods and apparatus may include one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function.

[0017] Furthermore, the methods and apparatus may take the form of a program product embodied in one or more computer readable storage devices storing machine readable code, computer readable code, and/ or program code, referred hereafter as code. The storage devices may be tangible, non-transitory, and/ or non-transmission. The storage devices may not embody signals. In certain arrangements, the storage devices only employ signals for accessing code.

[0018] Any combination of one or more computer readable medium may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing the code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0019] More specific examples (a non-exhaustive list) of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (“RAM”), a read-only memory (“ROM”), an erasable programmable read-only memory (“EPROM” or Flash memory), a portable compact disc read-only memory (“CD-ROM”), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store, a program for use by or in connection with an instruction execution system, apparatus, or device.

[0020] Reference throughout this specification to an example of a particular method or apparatus, or similar language, means that a particular feature, structure, or characteristic described in connection with that example is included in at least one implementation of the method and apparatus described herein. Thus, reference to features of an example of a particular method or apparatus, or similar language, may, but do not necessarily, all refer to the same example, but mean “one or more but not all examples” unless expressly specified otherwise. The terms “including”, “comprising”, “having”, and variations thereof, mean “including but not limited to”, unless expressly specified otherwise. An enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms “a”, “an”, and “the” also refer to “one or more”, unless expressly specified otherwise.

[0021] As used herein, a list with a conjunction of “and/ or” includes any single item in the list or a combination of items in the list. For example, a list of A, B and/ or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. As used herein, a list using the terminology “one or more of’ includes any single item in the list or a combination of items in the list. For example, one or more of A, B and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. As used herein, a list using the terminology “one of’ includes one, and only one, of any single item in the list. For example, “one of A, B and C” includes only A, only B or only C and excludes combinations of A, B and C. As used herein, “a member selected from the group consisting of A, B, and C” includes one and only one of A, B, or C, and excludes combinations of A, B, and C.” As used herein, “a member selected from the group consisting of A, B, and C and combinations thereof’ includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C.

[0022] Furthermore, the described features, structures, or characteristics described herein may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the disclosure. One skilled in the relevant art will recognize, however, that the disclosed methods and apparatus may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well- known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the disclosure.

[0023] Aspects of the disclosed method and apparatus are described below with reference to schematic flowchart diagrams and/or schematic block diagrams of methods, apparatuses, systems, and program products. It will be understood that each block of the schematic flowchart diagrams and/ or schematic block diagrams, and combinations of blocks in the schematic flowchart diagrams and/or schematic block diagrams, can be implemented by code. This code may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions /acts specified in the schematic flowchart diagrams and/or schematic block diagrams.

[0024] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function/ act specified in the schematic flowchart diagrams and/or schematic block diagrams.

[0025] The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer implemented process such that the code which executes on the computer or other programmable apparatus provides processes for implementing the functions /acts specified in the schematic flowchart diagrams and/ or schematic block diagram.

[0026] The schematic flowchart diagrams and/ or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods, and program products. In this regard, each block in the schematic flowchart diagrams and/or schematic block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of the code for implementing the specified logical function(s). [0027] It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated Figures.

[0028] The description of elements in each figure may refer to elements of proceeding Figures. Like numbers refer to like elements in all Figures.

[0029] Figure 1 depicts an embodiment of a wireless communication system 100 for authorizing wireless communication devices to communicate with ambient devices. In one embodiment, the wireless communication system 100 includes remote units 102 and network units 104. Even though a specific number of remote units 102 and network units 104 are depicted in Figure 1, one of skill in the art will recognize that any number of remote units 102 and network units 104 may be included in the wireless communication system 100. The wireless communication system may comprise a wireless communication network and at least one wireless communication device. The wireless communication device is typically a 3GPP User Equipment (UE). The wireless communication network may comprise at least one network node. The network node may be a network unit. [0030] In one embodiment, the remote units 102 may include computing devices, such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle onboard computers, network devices (e.g., routers, switches, modems), aerial vehicles, drones, or the like. In some embodiments, the remote units 102 include wearable devices, such as smartwatches, fitness bands, optical head-mounted displays, or the like. Moreover, the remote units 102 may be referred to as subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, UE, user terminals, a device, or by other terminology used in the art. The remote units 102 may communicate directly with one or more of the network units 104 via UL communication signals. In certain embodiments, the remote units 102 may communicate directly with other remote units 102 via sidelink communication.

[0031] The network units 104 may be distributed over a geographic region. In certain embodiments, a network unit 104 may also be referred to as an access point, an access terminal, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, a device, a core network, an aerial server, a radio access node, an AP, NR, a network entity, an Access and Mobility Management Function (“AMF”), a Unified Data Management Function (“UDM”), a Unified Data Repository (“UDR”), a UDM/UDR, a Policy Control Function (“PCF”), a Radio Access Network (“RAN”), an Network Slice Selection Function (“NSSF”), an operations, administration, and management (“OAM”), a session management function (“SMF”), a user plane function (“UPF”), an application function, an authentication server function (“AUSF”), security anchor functionality (“SEAF”), trusted non-3GPP gateway function (“TNGF”), an application function, a service enabler architecture layer (“SEAL”) function, a vertical application enabler server, an edge enabler server, an edge configuration server, a mobile edge computing platform function, a mobile edge computing application, an application data analytics enabler server, a SEAL data delivery server, a middleware entity, a network slice capability management server, or by any other terminology used in the art. The network units 104 are generally part of a radio access network that includes one or more controllers communicab ly coupled to one or more corresponding network units 104. The radio access network is generally communicably coupled to one or more core networks, which may be coupled to other networks, like the Internet and public switched telephone networks, among other networks. These and other elements of radio access and core networks are not illustrated but are well known generally by those having ordinary skill in the art.

[0032] In one implementation, the wireless communication system 100 is compliant with New Radio (NR) protocols standardized in 3GPP, wherein the network unit 104 transmits using an Orthogonal Frequency Division Multiplexing (“OFDM”) modulation scheme on the downlink (DL) and the remote units 102 transmit on the uplink (UL) using a Single Carrier Frequency Division Multiple Access (“SC-FDMA”) scheme or an OFDM scheme. More generally, however, the wireless communication system 100 may implement some other open or proprietary communication protocol, for example, WiMAX, IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, Bluetooth®, ZigBee, Sigfox, LoraWAN among other protocols. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0033] The network units 104 may serve a number of remote units 102 within a serving area, for example, a cell or a cell sector via a wireless communication link. The network units 104 transmit DL communication signals to serve the remote units 102 in the time, frequency, and/ or spatial domain.

[0034] Figure 2 depicts a user equipment apparatus 200 that may be used for implementing the methods described herein. The user equipment apparatus 200 is used to implement one or more of the solutions described herein. The user equipment apparatus 200 is in accordance with one or more of the user equipment apparatuses described in embodiments herein. In particular, the user equipment apparatus 200 may comprise a user equipment as described herein, including a remote unit 102 and a user equipment 410 and 510 as described herein. The user equipment apparatus 200 includes a processor 205, a memory 210, an input device 215, an output device 220, and a transceiver 225.

[0035] The input device 215 and the output device 220 may be combined into a single device, such as a touchscreen. In some implementations, the user equipment apparatus 200 does not include any input device 215 and/ or output device 220. The user equipment apparatus 200 may include one or more of: the processor 205, the memory 210, and the transceiver 225, and may not include the input device 215 and/ or the output device 220.

[0036] As depicted, the transceiver 225 includes at least one transmitter 230 and at least one receiver 235. The transceiver 225 may communicate with one or more cells (or wireless coverage areas) supported by one or more base units. The transceiver 225 may be operable on unlicensed spectrum. Moreover, the transceiver 225 may include multiple UE panels supporting one or more beams. Additionally, the transceiver 225 may support at least one network interface 240 and/ or application interface 245. The application interface(s) 245 may support one or more APIs. The network interface(s) 240 may support 3GPP reference points, such as Uu, Nl, PC5, etc. Other network interfaces 240 may be supported, as understood by one of ordinary skill in the art.

[0037] The processor 205 may include any known controller capable of executing computer-readable instructions and/ or capable of performing logical operations. For example, the processor 205 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. The processor 205 may execute instructions stored in the memory 210 to perform the methods and routines described herein. The processor 205 is communicatively coupled to the memory 210, the input device 215, the output device 220, and the transceiver 225. [0038] The processor 205 may control the user equipment apparatus 200 to implement the user equipment apparatus behaviors described herein. The processor 205 may include an application processor (also known as “main processor”) which manages application-domain and operating system (“OS”) functions and a baseband processor (also known as “baseband radio processor”) which manages radio functions.

[0039] The memory 210 may be a computer readable storage medium. The memory 210 may include volatile computer storage media. For example, the memory 210 may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/ or static RAM (“SRAM”). The memory 210 may include non-volatile computer storage media. For example, the memory 210 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. The memory 210 may include both volatile and non-volatile computer storage media.

[0040] The memory 210 may store data related to implement a traffic category field as described herein. The memory 210 may also store program code and related data, such as an operating system or other controller algorithms operating on the apparatus 200. [0041] The input device 215 may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. The input device 215 may be integrated with the output device 220, for example, as a touchscreen or similar touch-sensitive display. The input device 215 may include a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/ or by handwriting on the touchscreen. The input device 215 may include two or more different devices, such as a keyboard and a touch panel.

[0042] The output device 220 may be designed to output visual, audible, and/ or haptic signals. The output device 220 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 220 may include, but is not limited to, a Liquid Crystal Display (“LCD”), a Light- Emitting Diode (“LED”) display, an Organic LED (“OLED”) display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another, non-limiting, example, the output device 220 may include a wearable display separate from, but communicatively coupled to, the rest of the user equipment apparatus 200, such as a smart watch, smart glasses, a heads-up display, or the like. Further, the output device 220 may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0043] The output device 220 may include one or more speakers for producing sound. For example, the output device 220 may produce an audible alert or notification (e.g., a beep or chime). The output device 220 may include one or more haptic devices for producing vibrations, motion, or other haptic feedback. All, or portions, of the output device 220 may be integrated with the input device 215. For example, the input device 215 and output device 220 may form a touchscreen or similar touch-sensitive display. The output device 220 may be located near the input device 215.

[0044] The transceiver 225 communicates with one or more network functions of a mobile communication network via one or more access networks. The transceiver 225 operates under the control of the processor 205 to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor 205 may selectively activate the transceiver 225 (or portions thereof) at particular times in order to send and receive messages.

[0045] The transceiver 225 includes at least one transmitter 230 and at least one receiver 235. The one or more transmitters 230 may be used to provide uplink communication signals to a base unit of a wireless communication network. Similarly, the one or more receivers 235 may be used to receive downlink communication signals from the base unit. Although only one transmitter 230 and one receiver 235 are illustrated, the user equipment apparatus 200 may have any suitable number of transmitters 230 and receivers 235. Further, the trans mi tter(s) 230 and the receiver(s) 235 may be any suitable type of transmitters and receivers. The transceiver 225 may include a first transmitter/receiver pair used to communicate with a mobile communication network over licensed radio spectrum and a second transmitter/receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum.

[0046] The first transmitter/ receiver pair may be used to communicate with a mobile communication network over licensed radio spectrum and the second transmitter/ receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum may be combined into a single transceiver unit, for example a single chip performing functions for use with both licensed and unlicensed radio spectrum. The first transmitter/receiver pair and the second transmitter/receiver pair may share one or more hardware components. For example, certain transceivers 225, transmitters 230, and receivers 235 may be implemented as physically separate components that access a shared hardware resource and/ or software resource, such as for example, the network interface 240.

[0047] One or more transmitters 230 and/ or one or more receivers 235 may be implemented and/ or integrated into a single hardware component, such as a multitransceiver chip, a system-on-a-chip, an Application-Specific Integrated Circuit (“ASIC”), or other type of hardware component. One or more transmitters 230 and/ or one or more receivers 235 may be implemented and/ or integrated into a multi-chip module. Other components such as the network interface 240 or other hardware components/ circuits may be integrated with any number of transmitters 230 and/ or receivers 235 into a single chip. The transmitters 230 and receivers 235 may be logically configured as a transceiver 225 that uses one more common control signals or as modular transmitters 230 and receivers 235 implemented in the same hardware chip or in a multi-chip module.

[0048] Figure 3 depicts further details of the network node 300 that may be used for implementing the methods described herein. The network node 300 may be one implementation of an entity in the wireless communication network, e.g. in one or more of the wireless communication networks described herein. The network node 300 may comprise a first network function as described herein, including a network unit 104 and an AIoT function 424 and 524 as described herein. The network node 300 includes a processor 305, a memory 310, an input device 315, an output device 320, and a transceiver 325. [0049] The input device 315 and the output device 320 may be combined into a single device, such as a touchscreen. In some implementations, the network node 300 does not include any input device 315 and/ or output device 320. The network node 300 may include one or more of: the processor 305, the memory 310, and the transceiver 325, and may not include the input device 315 and/ or the output device 320.

[0050] As depicted, the transceiver 325 includes at least one transmitter 330 and at least one receiver 335. Here, the transceiver 325 communicates with one or more remote units 200. Additionally, the transceiver 325 may support at least one network interface 340 and/ or application interface 345. The application interface(s) 345 may support one or more APIs. The network interface(s) 340 may support 3GPP reference points, such as Uu, Nl, N2 and N3. Other network interfaces 340 may be supported, as understood by one of ordinary skill in the art.

[0051] The processor 305 may include any known controller capable of executing computer-readable instructions and/ or capable of performing logical operations. For example, the processor 305 may be a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or similar programmable controller. The processor 305 may execute instructions stored in the memory 310 to perform the methods and routines described herein. The processor 305 is communicatively coupled to the memory 310, the input device 315, the output device 320, and the transceiver 325.

[0052] The memory 310 may be a computer readable storage medium. The memory 310 may include volatile computer storage media. For example, the memory 310 may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/ or static RAM (“SRAM”). The memory 310 may include non-volatile computer storage media. For example, the memory 310 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. The memory 310 may include both volatile and non-volatile computer storage media.

[0053] The memory 310 may store data related to establishing a multipath unicast link and/ or mobile operation. For example, the memory 310 may store parameters, configurations, resource assignments, policies, and the like, as described herein. The memory 310 may also store program code and related data, such as an operating system or other controller algorithms operating on the network node 300.

[0054] The input device 315 may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. The input device 315 may be integrated with the output device 320, for example, as a touchscreen or similar touch-sensitive display. The input device 315 may include a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/ or by handwriting on the touchscreen. The input device 315 may include two or more different devices, such as a keyboard and a touch panel.

[0055] The output device 320 may be designed to output visual, audible, and/ or haptic signals. The output device 320 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 320 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another, non-limiting, example, the output device 320 may include a wearable display separate from, but communicatively coupled to, the rest of the network node 300, such as a smart watch, smart glasses, a heads-up display, or the like. Further, the output device 320 may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0056] The output device 320 may include one or more speakers for producing sound. For example, the output device 320 may produce an audible alert or notification (e.g., a beep or chime). The output device 320 may include one or more haptic devices for producing vibrations, motion, or other haptic feedback. All, or portions, of the output device 320 may be integrated with the input device 315. For example, the input device 315 and output device 320 may form a touchscreen or similar touch-sensitive display. The output device 320 may be located near the input device 315.

[0057] The transceiver 325 includes at least one transmitter 330 and at least one receiver 335. The one or more transmitters 330 may be used to communicate with the UE, as described herein. Similarly, the one or more receivers 335 may be used to communicate with network functions in the PLMN and/ or RAN, as described herein. Although only one transmitter 330 and one receiver 335 are illustrated, the network node 300 may have any suitable number of transmitters 330 and receivers 335. Further, the transmitter(s) 330 and the receiver(s) 335 may be any suitable type of transmitters and receivers.

[0058] In the context of Release 19, the 3GPP SAI working group has been diligently working on a study item focused on “Ambient power-enabled Internet of Things” as documented in TR 22.840 vl.1.0, March 2023. The primary objective of this study is to define the service requirements for mobile networks, particularly 5G and beyond, in order to effectively support communication with “ambient loT” devices. These ambient loT devices are a new class of Internet of Things (loT) devices that are powered by harvesting energy from various sources such as RF energy, solar energy, wind energy, and more. Distinct from traditional loT devices, ambient loT devices typically have limited energy storage capabilities; they may be battery less and often utilize an internal capacitor for energy storage. In the context of 3GPP specifications, harvesting RF energy from transmissions made by the network itself is the most interesting harvesting scenario. Although, harvesting energy from other sources, such as Wi-Fi transmissions is also possible.

[0059] RF energy harvesting enables ambient loT devices to harvest energy from RF signals available in their environment, such as RF signals transmitted from mobile networks or from nearby Wi-Fi networks. RF energy harvesting is a promising technology that enables self-sustainable wireless loT networks.

[0060] In order for an ambient loT device to transmit data, it must first receive an RF signal that provides sufficient energy to power it. This RF signal is commonly referred to as a trigger signal or trigger message. The trigger message can be sent by either a gNB or a user equipment (UE) in close proximity to the ambient loT device.

[0061] When a gNB sends the trigger message, it may face challenges in providing enough energy to the ambient loT device via its transmissions. This is due to its typically large distance from the device. As a result, the communication may be less effective, and the ambient loT device may not receive adequate power to operate and transmit data. [0062] On the other hand, should a UE send the trigger message then, as the UE can be in close proximity with the ambient loT device, the ambient loT device can obtain the necessary energy more effectively. Once the ambient loT device receives sufficient energy from the trigger message, it can respond by transmitting a data message back to the UE. The UE then relays this data to the mobile core network, ensuring seamless communication and integration of the ambient loT device with the network.

[0063] This approach, where UEs are utilized for triggering communication with and empowering nearby ambient loT devices, is supported by the service requirements defined by SAI. One relevant requirement in TR 22.840 vl.1.0 (March 2023) specifies that “The 5G system shall support to authorize a UE to obtain device information of an Ambient loT device.” However, how a UE is authorized to obtain information from (or to trigger) an ambient loT device, as well as how this information is relayed to the core network and how it is authenticated, are not specified. There is presented herein a solution that fulfils this requirement. [0064] The applicant has filed International Patent Application PCT/EP2023/ 057551 (applicants reference: SMM920220274-WO-PCT) which describes onboarding ambient devices in a wireless communication network, and International Patent Application PCT/EP2023/057552 (applicants reference: SMM920220275-WO-PCT which describes transmission requirements of ambient devices in a wireless communication network, both of which are incorporated herein by reference. Those earlier patent applications specify enhancements to the 5G network architecture and procedures for enabling onboarding and communication with AIoT devices. Building on those earlier applications, there is presented herein a scenario wherein a UE is authorized and employed to trigger communication with one or more AIoT devices and to relay the AIoT data message to the mobile core network.

[0065] Figure 4 illustrates a system 400 for facilitating UE relay of AIoT device data. The system 400 comprises a UE 410, a 5G core 420, and at least one AIoT device 430. The 5G core 420 comprises an AIoT function 424 and a second network function 422. The second network function 422 may comprise an Access and Mobility management Function (AMF) or a User Plane Function (UPF). The at least one AIoT device 430 may comprise four AIoT devices as illustrated by way of example in figure 4. The example arrangement shown in figure 4 comprises a first AIoT device Al (431), a second AIoT device A2 (432), a third AIoT device Bl (433) and a fourth Alot device B2 (434). The AIoT devices may be grouped. In the example of figure 4, a first AIoT group A (436) comprises the first AIoT device Al (431) and the second AIoT device A2 (432). A second AIoT group B (438) comprises the third AIoT device Bl (433) and the fourth Alot device B2 (434) .

[0066] The user equipment 410 may comprise any user equipment as described herein, including a remote unit 102, user equipment apparatus 200, and a user equipment 510 as described herein.

[0067] The “AIoT Function” (AIoTF) 424 is a new network function in the 5G core network architecture (introduced in the Applicant’s earlier patent applications PCT/EP2023/057551 (SMM920220274-WO-PCT) and PCT/EP2023/057552 (SMM920220275-WO-PCT) mentioned above. The AIoTF is a network function that implements the necessary functionality in order to enable the 5G network to support communication with AIoT devices. There is presented herein a new method to be implemented by the AIoTF 424, the method allowing the AIoTF 424 to authorize UEs to communicate with individual AIoT devices or group of AIoT devices. [0068] The AIoT function 424 may comprise a first network function as described herein, including a network unit 104, a network node 300 and an AIoT function 524 as described herein.

[0069] A 5G network includes the 5G Core (5GC) 420 and a 5G radio access composed of multiple base stations, referred to as gNBs or eNBs, not shown in figure 4. The UE 410 communicates with the 5GC 420 via at least one base station. The 5GC 420 architecture is enhanced to support the aforementioned AIoT Function (AIoTF) 422.

[0070] The User Equipment (UE) 410 is enhanced to support RF energy emission with specific characteristics (i.e., frequency band, power, duration), tailored to suit energy harvesting by nearby AIoT devices.

[0071] There is presented herein a method for enabling authorized UEs to communicate with AIoT devices and to relay their data towards the mobile network. The AIoT data relay procedure enables the network to support communication of (individual or groups of) AIoT devices via UEs acting as relay nodes. UEs emit RF energy which can be harvested by nearby AIoT devices enabling the AIoT devices to transmit their message back to the UE. The UE may then relay the transmitted AIoT device message to the 5G network. The AIoT message may comprise data. Where the AIoT device comprises a sensor, the data may be a sensor reading taken by the sensor.

[0072] The identity of the UE that relayed the message is known to the network and this information may be used to provide a reward to the UE by the network for their assistance. The procedure presented herein enables indirect communication of AIoT devices with the 5G network via assisting UEs. This is advantageous since AIoT devices’ direct communication with the 5G network might not be feasible given the various stringent requirements such devices exhibit, i.e., no or limited power storage, limited transmission distance and limited energy harvesting distance. By way of example, the energy harvesting distance and AIoT transmission distance may be around 50 to 70 metres Line-of-Sight (LoS).

[0073] Figure 5 is a messaging diagram illustrating an example of a method 500 as described herein. For simplicity, only the important messages are discussed below while other messages which are not important for explaining the method are skipped. The method 500 is performed by a UE 510, a 5G Core 520, and at least one AIoT device 530. [0074] As shown in figure 5, the 5G core 520 comprises an AIoT function 524 and a second network function 522. The second network function 522 may comprise an Access and Mobility management Function (AMF) or a User Plane Function (UPF). The at least one AIoT device 530 may comprise a plurality of AIoT devices, and these may be grouped. For example, the plurality of AIoT devices may comprise a group of AIoT devices labelled AIoT Group A. Each AIoT device 530 has a cryptographic key stored thereon. The cryptographic key may comprise a Group Key where the AIoT device belongs to a group. Each AIoT device 530 has a unique private key stored thereon, the unique private key also known to the AIoTF 524.

[0075] The user equipment 510 may comprise any user equipment as described herein, including a remote unit 102, user equipment apparatus 200, and a user equipment 410 as described herein. The AIoT function 524 may comprise any first network function as described herein, including a network unit 104, a network node 300 and an AIoT function 424 as described herein.

[0076] The method 500 enables AIoT devices to harvest energy and transmit their message, as well as guarantee that their message will reach the 5G network even in cases where the AIoT devices are deployed far from the 5G network’s gNBs and/ or in non- LoS scenarios, enabling essentially any AIoT device operator to deploy and operate their AIoT devices almost anywhere.

[0077] For simplicity, the procedure below presents the steps involved in energizing and relaying the message of a single AIoT device 530. However, it is noted that similar steps can be applied for relaying messages of a plurality (or a group) of AIoT devices.

[0078] In overview, byway of steps 571, 572 and 573 the UE 510 establishes a connection with an AIoTF 524 in the mobile network 520. This connection is required for authorizing the UE 510 and subsequently enabling it to trigger communication with one or more AIoT devices 530 in the vicinity of the UE 510. The UE 510 triggers communication with an AIoT device or with an AIoT group of devices by transmitting a message (at step 578) that contains important parameters received from AIoTF. Without these parameters the UE cannot trigger communication with AIoT devices. This authorization step thus provides security in the system.

[0079] As mentioned above the second network function 522 may comprise an Access and Mobility management Function (AMF) or a User Plane Function (UPF). Communication between the UE 510 and the AIoTF 524 may take place over the userplane (i.e., via a UPF) or over the control-plane (i.e., via an AMF). Both options are feasible routes for deploying the method presented herein. Whether the communication between the UE 510 and the AIoTF 524 takes place over the user-plane (i.e., via a UPF) or over the control-plane (i.e., via an AMF) is an implementation detail. [0080] When communication over the user-plane is employed, the UE 510 needs to know an address for the AIoTF 524, such as an IP address or a URI. This address information may be provisioned to the UE 510 or may be discovered by the UE 510 using existing DNS mechanisms. In this case, all data messages between the UE 510 and the AIoTF 524 go through a UPF 522 in the mobile network and security is provided via existing security mechanisms, such as IPsec, TLS/SSL, etc.

[0081] When communication over the control-plane is employed, data messages between the UE 510 and the AIoTF 524 are embedded in NAS messages and are transmitted via the existing N1 signaling connection between the UE 510 and the AMF 522. The “payload container type” field in each NAS message is populated with a new value which indicates that the NAS message carries an AIoT message and should be forwarded by the AMF 522 to the AIoTF 524. On the UE side, the value of the “payload container type” field indicates to the NAS stack in the UE 510 to forward the embedded AIoT message to an AIoT application or service component. In this case, security is provided by reusing the existing security mechanisms over the N1 signaling connection.

[0082] The method 500 begins at 571, where the UE 510 sends an “AIoT Connection Request” message to AIoTF 524 (either via the user-plane or via the control-plane) which contains a “UE identity”, such as SUP I, MSISDN, etc. This message is sent by the UE 510 in order to establish a logical connection with the AIoTF 524 and to obtain authorization to communicate with AIoT devices and relay their messages.

[0083] At 572, mutual authentication between the UE 510 and AIoTF 524 takes place by using means already available in the art. This step is primarily needed when communication over the user-plane is employed but it is optional in case communication over control-plane is employed, because the UE 510 has already been authenticated before establishing the N1 signaling connection.

[0084] At 573, upon successful connection between the UE 510 and the AIoT 524 (and authentication, if required), the AIoTF 524 responds to the UE 510 with an “AIoT Connection Accept” message which encapsulates “Authorization Info”, such as the identity of the at least one AIoT device 530 that the UE is now authorized to communicate with. The “Authorization Info” may comprise “AIoT Group IDs”, i.e., the identity of one or more groups of AIoT devices that the UE 510 is now allowed to communicate with. [0085] At 575, after the UE 510 is authorized (in steps 571-573) to communicate with the at least one AIoT device, which may comprise certain AIoT groups, the UE 510 may decide to initiate communication with at least one of these AIoT devices. 575 is not a necessary step and maybe omitted from method 500. In this example we will consider the UE communicating with a group of AIoT devices 530, AIoT Group A. This decision may be arrived at by UE implementation or by the user of the UE 510. Before the UE 510 can communicate with AIoT Group A, it needs to obtain important AIoT parameters from the AIoTF 524 for this group. Without these parameters communication with this group is not feasible. For this purpose, the UE sends a “Trigger Request” message to the AIoTF 524, indicating the UE 510 is willing to communicate with a specific AIoT device group, i.e., AIoT Group A. Note that step 575 is optional and is required only when the UE itself decides to initiate communication with AIoT devices.

[0086] At 576a, the AIoTF 524 determines AIoT parameters. The AIoT Parameters may include any combination of the Token, Nonce and Transmission Parameters (TxParams). TxParams indicate to the UE a definition of the trigger message. For example, the TxParams may define the frequency, power, or modulation type, of the trigger message.

[0087] At 576b, the AIoTF 524 sends a “Trigger Indication” message to the UE 510 to provide AIoT parameters required for the UE 510 to communicate with the at least one AIoT device 530, in this case AIoT Group A. This message can be sent as a response to a “Trigger Request” sent in step 575 or may be sent autonomously by AIoTF when it requires the UE 510 to communicate with a certain AIoT group. Hence step 575 is optional. For example, the AIoTF 524 may determine, based on the location of the UE 510, that the UE 510 is in the vicinity of one or more AIoT devices 530 belonging to AIoT Group A and the AIoTF may elect to trigger the UE 510 to communicate with these AIoT devices 530 and relay their messages to AIoTF 524. The trigger Indication message may comprise an indication of the AIoT Group, in this example AIoT Group A, and may also include a Token, a Nonce, and TxParams.

[0088] A role of the AIoT parameters is to make sure that only authorized UEs can wake up and trigger AIoT devices 530 to transmit their data. UEs or other devices that do not possess these parameters can transmit trigger messages to empower AIoT devices but the AIoT device will not respond to the trigger messages because they will be considered invalid. [0089] The AIoT parameters provided by the AIoTF 524 include the following:

• TxParams: These transmission parameters are to be used by the UE 510 for transmitting the trigger message. These may include e.g., the RF frequency, power, modulation type, etc.

• Token: This is a security parameter that is validated by the AIoT devices 530 receiving the trigger message. When an AIoT device 530 considers the token invalid, it ignores the trigger message and does not transmit its data. The Token can be derived using a Hash function as shown in figure 6a. The Group Key for AIoT Group A is a security key that is stored in the AIoTF and in all AIoT devices belonging to AIoT Group A. The UE or any other third party cannot possess this key.

• Nonce: This is a random value used to avoid replay attacks. The AIoT device 530 stores a record of the received Nonce values and uses them to detect repeated messages with the same Nonce. If a message with a repeated Nonce is received, it is discarded as a potential replay attack.

[0090] At 578, the UE 510 transmits a trigger message, called “AIoT Relay Request”, including an AIoT group identity, e.g., AIoT Group A. The purpose of this message is to wake up all nearby AIoT devices 530 belonging to AIoT Group A and enable them to transmit their data back to the UE 510. This trigger message is transmitted using the TxParams received in step 576 and contains both the Token and the Nonce provided by AIoTF 524.

[0091] At 580, each AIoT device 530 in the vicinity of the UE 510 harvests RF energy from the transmitted trigger message and wakes up to process the information in this message. Any AIoT devices that receive the trigger message but that do not have an identity matching the identity listed in the trigger message (in this example, those AIoT devices not belonging to AIoT Group A) will ignore the message and will go back to sleep. In contrast, all nearby AIoT devices identified in the trigger message will validate the received trigger message. The trigger message may be validated by validating the Token contained therein using the Group Key that is internally stored in these devices and the received Nonce. This validation is performed using the hash function illustrated in Figure 6b. If the Derived Token is the same as the Token in the received trigger message (“AIoT Relay Request”), then the trigger message is considered valid and the AIoT device may respond by transmitting a response message including its data. If, however, the Derived Token is not the same as the received Token, then the trigger message is considered invalid, and it is ignored without transmitting a response. Note that the Token received by an AIoT device 530 may be thought of as allowing the AIoT device 530 to authenticate both the UE 510 which sent it the Token and the AIoTF 524 which generated the Token.

[0092] At 582, at least one AIoT device 530 belonging to Group A (e.g., device Al), and which successfully validated the trigger message, responds by transmitting “AIoT Relay Response” message. The “AIoT Relay Response” message may comprise data from the AIoT device 530. In the example shown in method 500, only AIoT device Al decides to respond. This might be because only this device has fresh data to send. In general, however, all AIoT devices in the vicinity of UE belonging to Group A can respond. By way of example, there may be implemented some additional requirement such as ‘an AIoT device should only respond if it has new data to send since the last transmission’, but this is an implementation detail.

[0093] At 582, the AIoT device Al 530 responds to the received trigger message (“AIoT Relay Request”) by transmitting an “AIoT Relay Response” message which includes its identity (“AIoT device ID”), its own data (“AppData”), and a message authentication code (“MAC”). The “AppData” is an optional parameter that contains data available in device Al, which can be measurements obtained from a sensor. Such measurements may comprise as temperature, humidity, pressure, or any other information available in the device. Typically, this data must be forwarded to an Application Function (e.g., outside the mobile network) that can process and store this data. Note also that “AppData” can be encrypted using security information only available in the Application Function and, thus, may not be readable by either the UE 510 or the 5GC 520.

[0094] The message authentication code (“MAC”) is used to verify the authenticity of the “AIoT Relay Response” and to make sure that only authentic responses are accepted and forwarded by the mobile network. The MAC may be used by the AIoTF to validate the integrity of the message and to validate the identity of the source AIoT device. The hash operation X shown in figure 6c can be used for generating the MAC value, which reuses the received Nonce and Token, but also uses a unique private key stored in device Al 530. This private key is also known in AIoTF 524, which can validate the MAC and confirm whether it was created by the authentic device Al 530 or not. Note that, essentially, the MAC value is used to authenticate the AIoT device 530, in a similar way as the Token is used to authenticate the AIoTF 524. [0095] At 583, the UE 510 relays the message received in step 582 to the AIoTF 524 within a “Trigger Response” message. The UE 510 merely relays this message and makes no attempt to locally validate or process this message. The Trigger Response message comprises the AIoT device identity (“AIoT device ID”), the AIoT data (“AppData”), and a message authentication code (“MAC”).

[0096] At 585, the AIoTF 524 receives the AIoT relayed message and validates the MAC value using the private key of device Al, a copy of which is stored in AIoTF 524. The validation uses hash operation X shown in figure 6c. If the validation succeeds, then the data in the “Trigger Response” message is considered authentic (i.e., generated from the authentic device Al 530) and unaltered. As a consequence, the AIoTF 524 forwards the received “AIoT device ID” and “AppData” to the Application Function associated with device Al 530. If, however, the MAC validation fails, the AIoTF 524 discards the received data. If valid, the AppData is verified to be genuine and unaltered, and if a UE reward scheme is in place, the UE can be rewarded, or at least a record made that the UE will be rewarded.

[0097] Note that AIoTF 524 validates the received MAC by deriving its own MAC value using the device information stored in the AIoTF and by examining whether the MAC value derived by AIoTF matches the received MAC. If they match, the received message is considered authentic.

[0098] Figure 6a shows a hash function for deriving the Token, which is a security parameter that is validated by the AIoT devices receiving the trigger message. The Token is derived by the AIoTF by performing hash function A on the nonce and the Group Key, the nonce is an AIoT parameter provided to the AIoT device by the AIoTF, the Group Key is stored locally in both the AIoTF and the AIoT device.

[0099] Figure 6b shows a hash function for validating the Token, which is a security parameter that is validated by the AIoT devices receiving the trigger message. The Token must be successfully validated by the AIoT device before it will transmit its data to the UE. The received Token is validated by the AIoT device by performing hash function A on the received nonce and the locally stored Group Key, if the locally derived Token matches the received Token then the received Token is successfully validated by the AIoT device.

[0100] Figure 6c shows a hash function X used by the AIoT device to generate a message authentication code (“MAC”). Hash operation X reuses the received Nonce and Token, but also uses the unique private key stored in the AIoT device. The AIoT device includes the derived MAC value in the “AIoT Relay Response” it sends to the UE.

[0101] The same hash function X is used by the AIoTF to verify the authenticity of the “AIoT Relay Response” received from the AIoT device via a relaying UE. Hash operation X is used for generating a MAC value, which reuses the received Nonce and Token, but also uses a copy of the unique private key stored in the AIoTF. The MAC value generated by the AIoTF is compared to the MAC value received in the “AIoT Relay Response” message, and if the MAC values match then the “AIoT Relay Response” is authenticated.

[0102] Accordingly, there is provided a first network function comprising a processor and a memory coupled with the processor, the memory comprising instructions executable by the processor to cause the first network function to: receive an AIoT connection request from a user equipment, the AIoT connection request comprising an identity of the user equipment; and send authorization to the user equipment, the authorization authorizing the user equipment to communicate with at least one AIoT device, the authorization comprising an identity of the at least one AIoT device. The first network function is further caused to send a trigger indication message to the user equipment, the trigger indication message comprising AIoT parameters required for the user equipment to communicate with the at least one AIoT of device; and receive an AIoT relay response message from the at least one AIoT device, the AIoT relay response message relayed via the user equipment.

[0103] As such, only authorized user equipment can wake up and trigger AIoT devices to transmit their data. User equipment or other devices that are not authorized by the first network function will not possess the AIoT parameters, and so while able to transmit messages to an AIoT device, the AIoT device will not respond to any such message.

[0104] The trigger indication essentially enables (or triggers) the UE to start communicating with the AIoT device. In response to receiving the trigger indication, the UE may immediately (or intermittently) broadcast one or more relay request messages. The trigger indication may itself power nearby AIoT devices and trigger them to respond. Alternatively, nearby AIoT devices may have harvested power from other sources, store energy in a local energy storage component, and then use this stored energy to power a transmission sent in response to the trigger indication. [0105] The identity of the at least one AIoT device may comprise an identity of a group of AIoT devices. The trigger indication may be sent in response to a trigger request message received from the user equipment.

[0106] The first network function may be further caused to determine, based on the user equipment location, that the user equipment is in the vicinity of the at least one AIoT devices and sending a trigger indication message to the user equipment as a result of determining that the user equipment is in the vicinity of the at least one AIoT device. [0107] The AIoT parameters comprise any combination of: transmission parameters; a token; or a nonce. The transmission parameters may indicate how the AIoT relay request message should be transmitted, e.g., frequency, bandwidth, power, modulation, etc. However, transmission parameters may be predefined, in which case the AIoT parameters need not include transmission parameters.

[0108] Figure 7 illustrates a method 700 in a first network function, the method 700 comprising: receiving 710 an AIoT connection request from a user equipment, the AIoT connection request comprising an identity of the user equipment; and sending 720 authorization to the user equipment, the authorization authorizing the user equipment to communicate with at least one AIoT device, the authorization comprising an identity of the at least one AIoT device. The method 700 further comprises: sending 730 a trigger indication message to the user equipment, the trigger indication message comprising AIoT parameters required for the user equipment to communicate with the at least one AIoT of device; and receiving 740 an AIoT relay response message from the at least one AIoT device, the AIoT relay response message relayed via the user equipment.

[0109] In certain embodiments, the method 700 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0110] Accordingly, only authorized user equipment can wake up and trigger AIoT devices to transmit their data. User equipment or other devices that are not authorized by the first network function will not possess the AIoT parameters, and so while able to transmit messages to an AIoT device, the AIoT device will not respond to any such message.

[0111] The trigger indication essentially enables (or triggers) the UE to start communicating with the AIoT device. In response to receiving the trigger indication, the UE may immediately (or intermittently) broadcast one or more relay request messages. The trigger indication may itself power nearby AIoT devices and trigger them to respond. Alternatively, nearby AIoT devices may have harvested power from other sources, store energy in a local energy storage component, and then use this stored energy to power a transmission sent in response to the trigger indication.

[0112] The identity of the at least one AIoT device may comprise an identity of a group of AIoT devices. The trigger indication may be sent in response to a trigger request message received from the user equipment.

[0113] The method may further comprise determining, based on the user equipment location, that the user equipment is in the vicinity of the at least one AIoT devices and sending a trigger indication message to the user equipment as a result of determining that the user equipment is in the vicinity of the at least one AIoT device.

[0114] The AIoT parameters may comprise any combination of: transmission parameters; a token; or a nonce. The transmission parameters may indicate how the AIoT relay request message should be transmitted, e.g., frequency, bandwidth, power, modulation, etc. However, transmission parameters may be predefined, in which case the AIoT parameters need not include transmission parameters.

[0115] There is further provided a user equipment comprising a processor and a memory coupled with the processor, the memory comprising instructions executable by the processor to cause the user equipment to: send an AIoT connection request to a first network function, the AIoT connection request comprising an identity of the user equipment; and receive authorization from the first network function, the authorization authorizing the user equipment to communicate with at least one AIoT device, the authorization comprising an identity of the at least one AIoT device. The user equipment is further caused to receive a trigger indication message from the first network function, the trigger indication message comprising AIoT parameters required for the user equipment to communicate with the at least one AIoT of device; receive an AIoT relay response message from the at least one AIoT device; and relay the AIoT relay response message to the first network function.

[0116] Accordingly, only authorized user equipment can wake up and trigger AIoT devices to transmit their data. User equipment or other devices that are not authorized by the first network function will not possess the AIoT parameters, and so while able to transmit messages to an AIoT device, the AIoT device will not respond to any such message.

[0117] An AIoT device is a device that harvests energy from its surroundings. Such energy harvesting may comprise receiving electromagnetic radiation. An AIoT device does not receive electrical power from an external connection such as by wire or by a replaceable battery. An AIoT device source as described herein may only communicate with the UE after harvesting RF energy.

[0118] Ambient Internet of Things AIoT devices are defined by 3GPP with reference to an ecosystem of a large number of objects in which every item is connected into a wireless sensor network using low-cost self-powered sensor nodes. Example applications of Ambient loT include making supply chains for food and medicine more efficient and sustainable, protecting from counterfeiting and delivering the data required for advanced transportation and smart city initiatives.

[0119] The identity of the at least one AIoT device may comprise an identity of a group of AIoT devices.

[0120] The user equipment may be further arranged to send a trigger request message to the first network function, wherein the trigger indication message is received in response to the trigger request message.

[0121] The trigger request message may comprise at least one identifier of at least one AIoT device for which the user equipment is willing to relay messages from. The at least one identifier may comprise a group identity, the group identity corresponding to a plurality of AIoT devices.

[0122] The AIoT parameters comprise any combination of: transmission parameters; a token; or a nonce.

[0123] The user equipment may be further arranged to transmit a trigger message to the at least one AIoT device, the trigger message comprising the identity of the at least one AIoT device. The trigger message may comprise an AIoT Relay Request message. The trigger message may be sent using the AIoT parameters.

[0124] The trigger message may be transmitted using the transmission parameters and the trigger message comprises the token and the nonce.

[0125] The trigger indication essentially enables (or triggers) the UE to start communicating with the AIoT device. In response to receiving the trigger indication, the UE may immediately (or intermittently) broadcast one or more relay request messages. The trigger indication may itself power nearby AIoT devices and trigger them to respond. Alternatively, nearby AIoT devices may have harvested power from other sources, store energy in a local energy storage component, and then use this stored energy to power a transmission sent in response to the trigger indication. [0126] Figure 8 illustrates a method 800 in a user equipment, the method 800 comprising: sending 810 an AIoT connection request to a first network function, the AIoT connection request comprising an identity of the user equipment; and receiving 820 authorization from the first network function, the authorization authorizing the user equipment to communicate with at least one AIoT device, the authorization comprising an identity of the at least one AIoT device. The method 800 further comprises receiving 830 a trigger indication message from the first network function, the trigger indication message comprising AIoT parameters required for the user equipment to communicate with the at least one AIoT of device; receiving 840 an AIoT relay response message from the at least one AIoT device; and relaying 850 the AIoT relay response message to the first network function.

[0127] In certain embodiments, the method 800 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0128] Accordingly, only authorized user equipment can wake up and trigger AIoT devices to transmit their data. User equipment or other devices that are not authorized by the first network function will not possess the AIoT parameters, and so while able to transmit messages to an AIoT device, the AIoT device will not respond to any such message.

[0129] An AIoT device is a device that harvests energy from its surroundings. Such energy harvesting may comprise receiving electromagnetic radiation. An AIoT device does not receive electrical power from an external connection such as by wire or by a replaceable battery. An AIoT device source as described herein may only communicate with the UE after harvesting RF energy.

[0130] Ambient Internet of Things AIoT devices are defined by 3GPP with reference to an ecosystem of a large number of objects in which every item is connected into a wireless sensor network using low-cost self-powered sensor nodes. Example applications of Ambient loT include making supply chains for food and medicine more efficient and sustainable, protecting from counterfeiting and delivering the data required for advanced transportation and smart city initiatives.

[0131] The identity of the at least one AIoT device comprises an identity of a group of AIoT devices. [0132] The method may further comprise sending a trigger request message to the first network function, wherein the trigger indication message is received in response to the trigger request message.

[0133] The trigger request message may comprise at least one identifier of at least one AIoT device for which the user equipment is willing to relay messages from. The at least one identifier may comprise a group identity, the group identity corresponding to a plurality of AIoT devices.

[0134] The AIoT parameters may comprise any combination of: transmission parameters; a token; or a nonce.

[0135] The method may further comprise transmitting a trigger message to the at least one AIoT device, the trigger message comprising the identity of the at least one AIoT device.

[0136] The trigger message may comprise an AIoT Relay Request message. The trigger message may be sent using the AIoT parameters. The trigger message may be transmitted using the transmission parameters and the trigger message comprises the token and the nonce.

[0137] The trigger indication essentially enables (or triggers) the UE to start communicating with the AIoT device. In response to receiving the trigger indication, the UE may immediately (or intermittently) broadcast one or more relay request messages. The trigger indication may itself power nearby AIoT devices and trigger them to respond. Alternatively, nearby AIoT devices may have harvested power from other sources, store energy in a local energy storage component, and then use this stored energy to power a transmission sent in response to the trigger indication.

[0138] There is further provided an AIoT device comprising a processor and a memory coupled with the processor, the memory comprising instructions executable by the processor to cause the AIoT device to: receive a trigger message transmitted from a user equipment, the trigger message comprising the identity of the AIoT device and security parameters; validate the trigger message using the security parameters and security material stored in the AIoT device; and in response to successful validation of the trigger message, transmit an AIoT relay response message to the user equipment.

[0139] Accordingly, only authorized user equipment can wake up and trigger AIoT devices to transmit their data. User equipment or other devices that are not authorized by the first network function will not possess the AIoT parameters, and so while able to transmit messages to an AIoT device, the AIoT device will not respond to any such message.

[0140] The AIoT device may wake up by harvesting energy from the received trigger message. The step of receiving the trigger message may comprise waking up by harvesting energy from the trigger message. Where an AIoT device has not harvested enough energy to transmit an AIoT relay response message to the user equipment, the AIoT device does not transmit an AIoT relay response message to the user equipment. [0141] The security parameters may comprise a token and a nonce. Validating the trigger message may comprise applying a hash function using the nonce and the security material stored in the AIoT device. The security material may be a Group Key.

[0142] The relay response message may comprise data and the AIoT relay response message may be transmitted in response to harvesting enough energy from the trigger message.

[0143] The data may be AIoT data. The data may be encrypted. The data may comprise a sensor reading.

[0144] The AIoT device may be further arranged to ignore the trigger message in response to unsuccessful validation of the trigger message.

[0145] Figure 9 illustrates a method 900 in an AIoT device, the method 900 comprising: receiving 910 a trigger message transmitted from a user equipment, the trigger message comprising the identity of the AIoT device and security parameters; validating 920 the trigger message using the security parameters and security material stored in the AIoT device; and in response to successful validation of the trigger message, transmitting 930 an AIoT relay response message to the user equipment.

[0146] In certain embodiments, the method 900 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0147] Accordingly, only authorized user equipment can wake up and trigger AIoT devices to transmit their data. User equipment or other devices that are not authorized by the first network function will not possess the AIoT parameters, and so while able to transmit messages to an AIoT device, the AIoT device will not respond to any such message.

[0148] The AIoT device may wake up by harvesting energy from the received trigger message. The step of receiving the trigger message may comprise waking up by harvesting energy from the trigger message. Where an AIoT device has not harvested enough energy to transmit an AIoT relay response message to the user equipment, the AIoT device does not transmit an AIoT relay response message to the user equipment. [0149] The security parameters may comprise a token and a nonce. Validating the trigger message may comprise applying a hash function using the nonce and the security material stored in the AIoT device. The security material may be a Group Key.

[0150] The AIoT relay response message may comprise data and the AIoT relay response message may be transmitted in response to harvesting enough energy from the trigger message. The data may be AIoT data. The data may be encrypted. The data may comprise a sensor reading.

[0151] The method may further comprise, in response to unsuccessful validation of the trigger message, ignoring the trigger message.

[0152] There are presented herein technical enhancements to 5G networks and UE devices that enable them to support ambient loT (AIoT) devices. This includes enablement of AIoT devices’ indirect communication with a 5G network through a UE operating as a relay node. The arrangements presented herein may facilitate a UE creating a persistent connection with an AIoTF. A UE acting as a relay node is thus able to energize AIoT devices and relay their messages via the wireless communication network back to an application function. The arrangements presented herein allow for UEs to relay messages of specific individual AIoT devices or groups of AIoT devices. There is further described the concept of rewarding UEs for the activation of AIoT devices and their relay assisting services. Furthermore, strong authentication principles for safeguarding the steps of the above procedure are presented.

[0153] There is provided herein a network node (such as an AIoTF) in a wireless communication network, comprising: a processor; and a memory coupled with the processor, the processor configured to cause the network node to: receive a first request message that requests to enable communication with an ambient loT device, wherein the first request message contains an identity of the ambient loT device, a first identity of a provisioning server (AITS) and a second identity of an ambient loT server (AIoT AS); retrieves configuration information for the ambient loT device from the first provisioning server; create a context for the ambient loT device based on the retrieved configuration information and based on information in the first request message; receive a first uplink message from the ambient loT device (via one or more gNBs); validates the authenticity of the first uplink messages using information in the created context; and forwards the first uplink message upon successful validation of authenticity to the ambient loT server. The first request message may additionally comprise a location of the ambient loT device and a token specific to the ambient loT device.

[0154] It should be noted that the above-mentioned methods and apparatus illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative arrangements without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

[0155] Further, while examples have been given in the context of particular communication standards, these examples are not intended to be the limit of the communication standards to which the disclosed method and apparatus may be applied. For example, while specific examples have been given in the context of 3GPP, the principles disclosed herein can also be applied to another wireless communication system, and indeed any communication system which uses routing rules.

[0156] The method may also be embodied in a set of instructions, stored on a computer readable medium, which when loaded into a computer processor, Digital Signal Processor (DSP) or similar, causes the processor to carry out the hereinbefore described methods.

[0157] The described methods and apparatus may be practiced in other specific forms. The described methods and apparatus are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A first network function comprising: a processor; and a memory coupled with the processor, the memory comprising instructions executable by the processor to cause the first network function to: receive an AIoT connection request from a user equipment, the AIoT connection request comprising an identity of the user equipment; send authorization to the user equipment, the authorization authorizing the user equipment to communicate with at least one AIoT device, the authorization comprising an identity of the at least one AIoT device; send a trigger indication message to the user equipment, the trigger indication message comprising AIoT parameters required for the user equipment to communicate with the at least one AIoT of device; and receive an AIoT relay response message from the at least one AIoT device, the AIoT relay response message relayed via the user equipment.

2. The first network function of claim 1, wherein the identity of the at least one AIoT device comprises an identity of a group of AIoT devices.

3. The first network function of claim 1 or 2, wherein the trigger indication is sent in response to a trigger request message received from the user equipment.

4. The first network function of any of claims 1 to 3, wherein the first network function is further caused to determine, based on the user equipment location, that the user equipment is in the vicinity of the at least one AIoT devices and sending a trigger indication message to the user equipment as a result of determining that the user equipment is in the vicinity of the at least one AIoT device.

5. The first network function of any of claims 1 to 4, wherein the AIoT parameters comprise any combination of: transmission parameters; a token; or a nonce.

6. A user equipment comprising: a processor; and a memory coupled with the processor, the memory comprising instructions executable by the processor to cause the user equipment to: send an AIoT connection request to a first network function, the AIoT connection request comprising an identity of the user equipment; receive authorization from the first network function, the authorization authorizing the user equipment to communicate with at least one AIoT device, the authorization comprising an identity of the at least one AIoT device; receive a trigger indication message from the first network function, the trigger indication message comprising AIoT parameters required for the user equipment to communicate with the at least one AIoT of device; receive an AIoT relay response message from the at least one AIoT device; and relay the AIoT relay response message to the first network function.

7. The user equipment of claim 6, wherein the identity of the at least one AIoT device comprises an identity of a group of AIoT devices.

8. The user equipment of claim 6 or 7, further arranged to send a trigger request message to the first network function, wherein the trigger indication message is received in response to the trigger request message.

9. The user equipment of claim 8, wherein the trigger request message comprises at least one identifier of at least one AIoT device for which the user equipment is willing to relay messages from.

10. The user equipment of any of claims 6 to 9, wherein the AIoT parameters comprise any combination of: transmission parameters; a token; or a nonce.

11. The user equipment of any of claims 6 to 10, further arranged to transmit a trigger message to the at least one AIoT device, the trigger message comprising the identity of the at least one AIoT device.

12. The user equipment of any of claims 10 and 11, wherein the trigger message is transmitted using the transmission parameters and the trigger message comprises the token and the nonce.

13. An AIoT device comprising: a processor; and a memory coupled with the processor, the memory comprising instructions executable by the processor to cause the AIoT device to: receive a trigger message transmitted from a user equipment, the trigger message comprising the identity of the AIoT device and security parameters; validate the trigger message using the security parameters and security material stored in the AIoT device; and in response to successful validation of the trigger message, transmit an AIoT relay response message to the user equipment.

14. The AIoT device of claim 13, further arranged to, upon receiving the trigger message, harvest energy from the trigger message.

15. The AIoT device of claim 14, wherein the energy harvested from the trigger message is used to power the AIoT device.

16. The AIoT device of any of claims 13 to 15, wherein the security parameters comprise a token and a nonce.

17. The AIoT device of claim 16, wherein validating the trigger message comprises applying a hash function using the nonce and the security material stored in the AIoT device.

18. The AIoT device of any of claims 13 to 17, wherein the AIoT relay response message comprises data and wherein the AIoT relay response message is transmitted in response to harvesting enough energy from the trigger message.

19. The AIoT device of any of claims 13 to 18, further arranged to, in response to unsuccessful validation of the trigger message, ignore the trigger message.