Method and apparatus for operating a wireless device

Abstract

This invention describes an apparatus and method for tag communication adapted to: - receiving a request message in a request burst, - determining the number of slots and slot number of the request message, - determining an identity or a random number, - select a slot number to deliver a reply message, - cause the transmission of a reply message after the end of the request message in the selected slot.

Description

[0001] METHOD AND APPARATUS FOR OPERATING A WIRELESS DEVICE

[0002] FIELD OF THE INVENTION

[0003] This invention relates to methods, apparatuses, and systems for operating a wireless device such as a user equipment or an ambient loT tag or a backscattering device in a wireless system such as a cellular system, a Wi-Fi network or the like. The embodiments of this invention may be for example applied to 3GPP systems, such as 5G or 6G, or to other wireless networks, including Wi-Fi.

[0004] BACKGROUND OF THE INVENTION

[0005] In conventional wireless networks, for example in cellular networks, a primary station serves a plurality of secondary stations located within a cell served by this primary station. Wireless communication from the primary station towards each secondary station is done on downlink channels. Conversely, wireless communication from each secondary station towards the primary station is done on uplink channels. The wireless communication can include data traffic (sometimes referred to User Data), and control information (also referred sometimes as signalling). This control information typically comprises information to assist the primary station and / or the secondary station to exchange data traffic (e.g. resource allocation / requests, physical transmission parameters, information on the state of the respective stations).

[0006] In the context of cellular networks as standardized by 3GPP, the primary station is referred to a base station, or a gNodeB (or gNB) in 5G (NR) or an eNodeB (or eNB) in 4G (LTE). The eNB / gNB is part of the Radio Access Network RAN, which interfaces to functions in the Core Network (CN). In the same context, the secondary station corresponds to a mobile station, or a User Equipment (or a UE) in 4G / 5G, which is a wireless client device or a specific role played by such device. The term “node” is also used to denote either a UE or a gNB / eNB.

[0007] Additionally, for example, in the case of PC5 interface or Side link communication, it is possible to have Direct communication between secondary stations, here UEs. It is then also possible for UEs to operate as Relays to allow for example out of coverage UEs to get an inter-mediate (or indirect) connection to the eNB or gNB. To be able to work as a relay, a UE may use discovery messages to establish new connections with other UEs.

[0008] Therefore, the role of a relay node has been introduced in 3GPP This relay node is a wireless communication station that includes functionalities for relaying communication between a primary station, e.g. a gNB and a secondary station, e.g. a UE. This relay function for example allows to extend the coverage of a cell to an out-of-coverage (OoC) secondary station. This relay node may be a mobile station or could be a different type of device. In the specifications for 4G, the Proximity Services (ProSe) functions are defined inter aha in TS 23.303, and TS 24.334 to enable - amongst others -connectivity for the cellular User Equipment (UE) that is temporarily not in coverage of the cellular network base station (eNB) serving the cell. This particular function is called ProSe UE-to- network relay, or Relay UE for short. The Relay UE relays application and network traffic in two directions between the OoC UE and the eNB. The local communication between the Relay UE and the OoC UE is called device-to-device (D2D) communication or Sidelink (also known as PC5) communication in TS 23.303 and TS 24.334. Once the relaying relation is established, the OoC-UE is, e.g., IP or Layer 2 connected via the Relay UE and acts in a role of “Remote UE”. This situation means the Remote UE has an indirect network connection to selected functions of the Core Network as opposed to a direct network connection to all Core Network functions that is the normal case.

[0009] Further, it has been introduced the role of a UE to UE relay node, i.e., a relay node relaying the communication between two UE devices. The relay node relays the communications between UE devices. UEs may connect to the core network through a base station when in-coverage. In such relay scenarios, the relay devices may receive and store some information for some time before forwarding it towards the target device. This information that may be stored and forwarded may be discovery messages received from a source UE whereby the relay UE may release them at some point of time later. This information that may be stored and forwarded may be a SIB that may contain a timestamp.

[0010] Furthermore, cellular networks are evolving to enable more mobile access devices such as satellites, unmanned aerial vehicles, buses or trains that are capable of storing data for some time before forwarding it further. An example relates to a satellite that receives and stores certain data when it is close to a terrestrial gateway and only releases it when the receiving party becomes in coverage. Such mobile access devices may work in a transparent manner or in a re-generative manner. In a transparent mode, the mobile access device acts as a reflector / smart repeater that retransmits the communication sent by, e.g., a gateway, e.g., a Non-Terrestrial Network gateway, towards a UE. In a regenerative mode, the mobile access device works as a base station and is able to setup a connection with a UE. In store and forward mode, the mobile access device may be able to cache same data obtained from the UE or NTN gateway, and transmit it when it is within communication range of the receiver.

[0011] Current cellular systems are evolving to support communication with resource constrained devices such as ambient loT tags that may also communicate via backscattering. There are multiple challenges to make it feasible due to reduced capabilities of such devices. For instance, a challenge in this context is how to enable multiple access to a multitude of tags that seek access to or through the network over a shared medium, e.g. to minimize conflicts of multiple devices accessing the medium at the same time. Many other challenges exist, e.g., regarding resource allocation or secure communication.

[0012] SUMMARY OF THE INVENTION

[0013] An aim of the invention is to address problems arising when enabling communication with resource constrained devices such as ambient loT tags, e.g., by providing, among others, solutions for efficient multiple access.

[0014] This is enabled by the methods and apparatuses defined in the appended claims.

[0015] In accordance with a current definition of the invention, in accordance with a first aspect of the invention, it is proposed a method for operating a device in low power communication, the method comprising receiving at the device a request message in a first request burst, wherein the request message includes an indication of a number of slots in the first request burst, selecting by the device a transmission slot number; transmitting by the device the reply message after the end of the request message in a slot corresponding to the selected transmission slot number.

[0016] In a first variant of the first aspect, the selecting of the transmission slot number includes determining an apparatus identifier or a random number, selecting the transmission slot number on the basis of at least the number of slots and on the random number or the apparatus identifier, and wherein the transmitting the reply message is performed within the first request burst.

[0017] In accordance with a second variant of the first aspect or of the first variant, the request message includes a request slot number indication indicative of a request slot number, the request slot number being the slot number within the first request burst in which the request message has been sent, and the selecting the transmission slot number is performed on the basis of the request slot number indication. In accordance with a third variant of the first aspect or its variants, the method comprises maintaining a count value of a number of subsequent received request messages, and triggering the step of transmitting the reply message on the basis of the count value.

[0018] In accordance with a fourth variant of the first aspect or its variants, the transmitting the reply message in the selected slot number includes backscattering the reply message in a received illuminating signal.

[0019] In accordance with a fifth variant of the first aspect or any of its variants, the reply message includes at least one or more of the following:

[0020] - data obtained from a sensor,

[0021] - an apparatus identifier,

[0022] - a status of the device including one or more of an energy status, an indication that the device has more data to transmit, an amount of data, an amount of data to be transmitted by the device.

[0023] In accordance with a sixth variant of the first aspect or any of its variants, each transmission slot is divided into one or more subslots; wherein the indication of the number of slots in the first request burst comprises an indication of slots and / or subslots; wherein the selecting of a transmission slot includes selecting a selected transmission subslot number; and wherein the transmitting the reply message includes transmitting in the selected transmission subslot number.

[0024] In accordance with a seventh variant of the first aspect or any of its variants, a transmission slot and / or transmission subslot comprises time and frequency resources used to multiplex reply messages in time and / or frequency. Furthermore, the indication of the number of slots in the first request burst may indicate one of:

[0025] - a total number of slots / subslots, and available time slots / subslots;

[0026] - a total number of slots / subslots, and available frequency slots / subslots;

[0027] - one or more available time slots / subslots and frequency slots / subslots.

[0028] In accordance with an eighth variant of the first aspect or any of its variants, the request message comprises one or more received identifiers, and the method comprises determining that the one or more received identifiers matches one or more stored identifiers, and wherein the step of transmitting the reply message in the slot / subslot corresponding to the selected transmission slot / subslot number is conditioned to the result of the determining.

[0029] In accordance with a ninth variant of the first aspect or any of its variants, the method comprises receiving a second request message upon or following transmission of the reply message, wherein the second request message indicates the allocation of a contention-free slot for a subsequent communication, and the second request message is transmitted in the first request burst or in a second request burst.

[0030] In accordance with a tenth variant of the first aspect or any of its variants, the method comprises obtaining a random number or identity value equal to or greater than the number of slots, applying a function, wherein said function takes as input the random number or identity value and uniformly selects a slot and / or subslot. Optionally, the number of slots may be given by the number of time resources times the number of frequency resources.

[0031] In accordance with an eleventh variant of the first aspect or any of its variants, the request message comprises one or more authentication values, and the method comprises determining an apparatus identifier or a random number and transmitting the reply message in the slot / subslot corresponding to the selected transmission slot / subslot number provided that the one or more authentication values can be successfully verified. Furthermore, the device may be in a temporary disabled state.

[0032] In accordance with a twelfth variant of the first aspect or its variants, the request message comprises a first freshness parameter, and the method comprises the device determining a second freshness parameter, obtaining an authentication value, and transmitting the freshness parameter and authentication value in the reply message. Additionally, the method may comprise one or more of:

[0033] - deriving a session key upon determining an indication in the request message requiring the derivation of the session key, and using the session key to security process a command in a subsequent access round and / or slot, wherein the subsequent slot and / or subslot are contention-free slots and / or subslots;

[0034] - deriving an intermediate verification value and transmitting the intermediate verification value in the reply message.

[0035] In accordance with a second aspect of the invention, it is proposed an apparatus for low power communication, the apparatus comprising a receiver, a transmitter, a controller, and a memory storing instructions which, when executed, cause the apparatus to: receive a request message in a first request burst, wherein the request message includes an indication of a number of slots in the first request burst, select a transmission slot number; transmit the reply message after the end of the request message in the slot corresponding to the selected transmission slot number.

[0036] Furthermore, this apparatus may be included in an ambient loT tag or a low power device.

[0037] In accordance with a third aspect of the invention, it is proposed a method for a multiple access procedure, comprising selecting by a device a number slots nO for a request burst, transmitting a first request burst comprising nO slots, each slot including a request message.

[0038] In accordance with a fourth aspect of the invention, it is proposed a method for a multiple access procedure comprising: selecting by a device a number of slots nO for a request burst, transmitting a first request burst comprising nO slots, each slot including a request message, and each request message including a slot number indication indicative of the current slot number within the first request burst in which each request message is transmitted.

[0039] In accordance with a fifth aspect of the invention, it is proposed a method for a multiple access procedure comprising: selecting by a device a number of slots nO for a request burst, transmitting a first request burst comprising nO slots, each slot comprising one or more subslots, and each slot being preceded by a request message, receiving one or more replies from one or more responding devices in the subslots.

[0040] In accordance with a sixth aspect of the invention, it is proposed a method for a multiple access procedure comprising: receiving assistance information to perform an inventory procedure wherein the assistance information includes at least an indication of the number of devices in the inventory procedure, selecting a number of slots nO for a first request burst, sending a request message to a base station to reserve communication resources to perform the inventory procedure with nO slots, and transmitting the first request burst in the resources allocated by the base station, wherein the first request message comprises nO slots, each slot comprising one or more subslots, and each slot being preceded by a request message.

[0041] In accordance with a seventh aspect of the invention, it is proposed a method for a multiple access procedure, comprising:

[0042] - transmitting a first request burst to two or more devices, wherein the first request burst comprises nO slots,

[0043] - receiving at least a first reply from a first device in a contention-based slot during the first request burst, wherein the first reply from the first device comprises a random identifier,

[0044] - transmitting a second request burst comprising nl slots indicating at least a first contention-free slot for the first device and the first identifier received from the first device, and

[0045] - receiving a second reply from the first device in the indicated contention-free slot. In accordance a variant of the third to the seventh aspects of the invention, the method comprises monitoring the reception of one or more reply messages from one or more low-power devices in the time resources subsequent to the request message in each of the slots.

[0046] In accordance with another variant, a slot comprises one or more subslots and a reply message can fit within a subslot.

[0047] In accordance with another variant, the method comprises transmitting an illuminating signal subsequent to some or each request message.

[0048] In accordance with another variant, the method comprises monitoring for the reception of one or more reply messages from one or more devices in time and / or frequency resources subsequent to the request message in each of the slots.

[0049] In accordance with another variant, the method comprises

[0050] - determining an indication in a reply message from a first device, wherein the indication indicates that the device has more data to transmit and / or that the first device has a low energy status, and

[0051] - transmitting a subsequent request message allowing the first device to perform the data transmission.

[0052] In another variant, the method comprises

[0053] - determining the need to transmit a second request burst,

[0054] - selecting the number of slots nl of the second request burst, and

[0055] - transmitting the second request burst with nl slots.

[0056] Optionally, the determining of the need to transmit the second request burst and / or the selecting of the number of slots nl includes estimating the number of devices seeking access based on at least one of:

[0057] - a number of collisions per slot,

[0058] - a number of slots without reply, and / or

[0059] - a number of slots in the first request burst in the first request burst.

[0060] In still another variant, the first request burst and / or the second request burst contain at least one contention free slot. In accordance with another variant, the method comprises receiving a first reply from a responding device to a first request message in a contention slot and a second reply by the responding device to a second request message in a contention-free slot.

[0061] In accordance with another variant, the method comprises adjusting the duration of a slot and / or subslot upon determining the presence of a reply message in the slot and / or subslot.

[0062] In accordance with another variant, the method comprises sending a request message to a base station to reserve communication resources to perform the multiple access procedure.

[0063] Optionally, the method may also comprise receiving a configuration message from the base station with the reserved communication resources to perform the multiple access procedure.

[0064] In accordance with another variant, the method comprise receiving assistance information from a network or application function wherein the assistance information comprises one or more of:

[0065] - an estimated number of devices seeking access;

[0066] - one or more long-term identifiers;

[0067] - configuration parameters indicative implicitly or explicitly of one or more device types and / or communication parameters including one or more of timing values, TR2D_max value, supported multiple access procedures, supported parameters in the multiple access procedures;

[0068] - a configuration determining the conditions to send a request message and / or retry sending a request message to a device.

[0069] In accordance with another variant, the method comprises receiving assistance information from a communication device (NF / AF) wherein the assistance information comprises one or more of:

[0070] - one or more intermediate verification values;

[0071] - one or more authentication values associated with the request message to be sent to one or more devices; receiving one or more reply messages and verifying the one or more reply messages based on one or more the intermediate verification value or on the authentication values, forwarding the reply messages to the network or application function based on the result of the verification.

[0072] In another variant, the method comprises storing a long-term identifier associated to a user subscription, and the user subscription is linked to the ownership of at least a first device, and one or more of the following apply to the device:

[0073] - the device is authorized to send a request burst to at least the first device;

[0074] - the device is authorized to retrieve the position of at least the first device;

[0075] - the device is authorized to perform a command on at least the first device.

[0076] In another variant, the method comprises: starting a timer upon transmission of a first request message, and transmitting a second request message if the device does not receive any reply message before the timer reaches a threshold time.

[0077] In another variant of all the previous aspects or their variants, a request message comprises one or more of:

[0078] - a preamble,

[0079] - the number of slots in the request burst in which the request message is transmitted,

[0080] - a slot number indication indicative of the current slot number within the request burst in which the request message is transmitted,

[0081] - a time delay parameter,

[0082] - a device identifier,

[0083] - an identifier identifying a group of devices,

[0084] - an indication on whether the slot includes an illuminating signal or not,

[0085] - time and / or frequency resource information of one or more illuminating signals (i.e. carrier wave(s) externally provided), a request (session) identifier,

[0086] - information acknowledging the reception status of the reply messages from devices, and / or

[0087] - specific request data, etc.

[0088] Furthermore, the information acknowledging the reception status of the reply messages from first devices may comprise an information set for each first devices having provided a reply message, wherein each information set comprises a random identifier provided by each first devices in the reply message and an indication of the slot / subslot used by the first device to transmit the reply message carrying the random identifier.

[0089] In another variant, the apparatus is part of a User Equipment or a base station.

[0090] In accordance with an eighth aspect of the invention, it is proposed an apparatus to perform a multiple access procedure, comprising a receiver, a transmitter, a controller, and a memory storing instructions which, when executed, cause the apparatus to:

[0091] - select a number of slots nO for a request burst,

[0092] - transmit a first request burst comprising nO slots, each slot including a request message.

[0093] In accordance with a ninth aspect of the invention, it is proposed an apparatus to perform a multiple access procedure, comprising: a receiver, a transmitter, a controller, and a memory storing instructions which, when executed, cause the apparatus to:

[0094] - select a number of slots nO for a request burst,

[0095] - transmit a first request burst comprising nO slots, each slot including a request message, and each request message including a slot number indication indicative of the current slot number within the first request burst in which each request message is transmitted. In accordance with a tenth aspect of the invention, it is proposed an apparatus to perform a multiple access procedure, comprising: a receiver, a transmiter, a controller, and a memory storing instructions which, when executed, cause the apparatus to:

[0096] - select a number of slots nO for a request burst,

[0097] - transmit a first request burst comprising nO slots, each slot comprising one or more subslots, and each slot being preceded by a request message,

[0098] - receive one or more replies from one or more devices in the subslots.

[0099] In accordance with an eleventh aspect of the invention, it is proposed an apparatus to perform a multiple access procedure, comprising: a receiver, a transmiter, a controller, and a memory storing instructions which, when executed, cause the apparatus to:

[0100] - receive assistance information to perform an inventory procedure wherein the assistance information includes at least an indication of the number of devices in the inventory procedure,

[0101] - select a number of slots nO for a first request burst,

[0102] - send a request message to a base station to reserve communication resources to perform the inventory procedure with nO slots, and

[0103] - transmit the first request burst in the resources allocated by the base station, wherein the first request message comprises nO slots, each slot comprising one or more subslots, and each slot being preceded by a request message.

[0104] In accordance with a twelfth aspect of the invention, it is proposed an apparatus to perform a multiple access procedure, comprising: a receiver, a transmiter, a controller, and a memory storing instructions which, when executed, cause the apparatus to:

[0105] - transmit a first request burst to two or more devices, wherein the first request burst comprises nO slots,

[0106] - receive at least a first reply from a first device in a contention-based slot during the first request burst, wherein the first reply from the first device comprises a random identifier,

[0107] - transmit a second request burst comprising nl slots indicating at least a first contention free slot for the first device and the first identifier received from the first device, and

[0108] - receive a second reply from the first lower device in the indicated contention free slot.

[0109] In accordance with a thirteenth aspect of the invention, it is proposed an apparatus for secure communication with a second device, the apparatus comprising:

[0110] - a processor,

[0111] - a transceiver,

[0112] - a storage unit storing a symmetric key, wherein the storage unit includes instructions which, when executed, cause the apparatus to

[0113] - receive a request message including an indication of a security procedure,

[0114] - determine a number of parameters required to perform the security procedure,

[0115] - obtain the parameters required to perform the security procedure by executing a cryptographic function taking as input the symmetric key, and

[0116] - send a reply message to perform the security procedure based on the obtained parameters.

[0117] In accordance with a fourteenth aspect of the invention, it is proposed a method for secure communication between a first device and a second device, the method comprising:

[0118] - receiving, by the first device, a request message including an indication of a security procedure,

[0119] - determining, by the first device, a number of parameters required to perform the security procedure, - obtaining, by the first device, the parameters required to perform the security procedure by executing a cryptographic function, and

[0120] - sending, by the first device, a reply message to perform the security procedure based on the obtained parameters.

[0121] Optionally, the method may comprise one or more of:

[0122] - receiving an explicit indication in the request message about the required parameters to perform the security procedure;

[0123] - receiving the indication in the request message about the required parameters to perform the security procedure, and obtaining the required parameters to perform the security procedure based on the indication and a stored configuration or profile;

[0124] - receiving an indication in the request message about the parameter size to perform the security procedure;

[0125] - using an extensible output function as cryptographic function to obtain the parameters;

[0126] - using ASCON in extensible output function mode as cryptographic function to obtain the parameters;

[0127] - sending, the reply message upon obtaining an authentication value indicated as a required parameter to perform the security procedure and verifying the authentication value.

[0128] In accordance with a fifteenth aspect of the invention, it is proposed a computer program for device communication, wherein the program comprises instructions for implementing the method of any of the above mentioned aspects.

[0129] It shall be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or above embodiments with the respective independent claim.

[0130] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

[0131] BRIEF DESCRIPTION OF THE DRAWINGS

[0132] In the following drawings: Fig. 1 is a block diagram schematically representing the system components according to an embodiment of the invention,

[0133] Fig. 2 is a time chart schematically representing messages and signals according to some aspects of the invention,

[0134] Fig. 3 is a time chart schematically representing information transferred in the messages according to an aspect of the invention,

[0135] Fig. 4 is a communication exchange chart schematically representing message interaction between reader and tags according to an embodiment,

[0136] Fig. 5 is a communication exchange chart schematically representing a procedure to retrieve data from multiple tags,

[0137] Fig. 6 is a block diagram schematically representing a synchronization signal used to activate a tag,

[0138] Fig. 7 is a communication exchange chart schematically representing a procedure to deliver or retrieve data from a tag,

[0139] Fig. 8 is a communication exchange chart schematically presenting procedures in a system using tags, and

[0140] Fig 9a and 9b are two communication exchange charts schematically representing a procedure to retrieve data from multiple or a single tag,

[0141] Fig. 10 is a communication exchange chart schematically representing a request burst starting with a request / paging message and followed by n contention-based slots,

[0142] Fig. 11 is a block diagram schematically representing an Ambient Internet of Things system,

[0143] Fig. 12 is a communication exchange diagram schematically representing a request burst starting with a request / paging message and followed by n contention-based slots and m contention- free slots,

[0144] Fig. 13 is a communication exchange diagram schematically representing a communication exchange chart schematically representing a procedure to retrieve data from a single tag,

[0145] Fig. 14 is a communication exchange diagram schematically representing a communication exchange within a contention-based slot, Fig. 15 is a communication exchange diagram schematically representing a communication exchange within a contention-free slot,

[0146] Fig. 16 is a block diagram schematically representing the messages exchanged in multiple request burst rounds, each request burst using contention-based and contention free slots,

[0147] Fig. 17 is a message flow illustrating security procedures that may be applicable, e.g., to the communication exchange diagram of Fig. 13;

[0148] Fig. 18 represents TDMA / FDMA signalling according to some embodiments in the invention;

[0149] Fig. 19 represents TDMA / FDMA signalling with segmentation according to some embodiments; and

[0150] Fig. 20 represents TDMA / FDMA signalling with segmentation according to some embodiments.

[0151] DETAILED DESCRIPTION OF EMBODIMENTS

[0152] Embodiments of the present invention are now described based on a cellular communication network environment, such as 5G or 6G. However, the present invention may also be used in connection with other wireless technologies, and in particular to the connection setup of devices trying to access a wireless network. Atypical example is a cellular network, for example a 5G network, possibly including some relay nodes. These relay nodes may be implemented by UEs, such as Sidelink compatible UEs which can operate as relay nodes, or by other types of repeaters.

[0153] Throughout the present disclosure, the abbreviation “gNB” (5G terminology) or “BS” (base station) or the term “access device” is intended to mean a wireless access device such as a cellular base station or a Wi-Fi access point or a ultrawide band (UWB) personal area network (PAN) coordinator. The gNB may consist of a centralized control plane unit (gNB-CU-CP), multiple centralized user plane units (gNB-CU-UPs) and / or multiple distributed units (gNB-DUs). The gNB is part of a radio access network (RAN), which provides an interface to functions in the core network (CN). The RAN is part of a wireless communication network. It implements a radio access technology (RAT). Conceptually, it resides between a communication device such as a mobile phone, a computer, or any remotely controlled machine and provides connection with its CN. The CN is the communication network’s core part, which offers numerous services to customers who are interconnected via the RAN. More specifically, it directs communication streams over the communication network and possibly other networks. Furthermore, the terms “base station” (BS) and “network” may be used as synonyms in this disclosure. This means for example that when it is written that the “network” performs a certain operation it may be performed by a CN function of a wireless communication network, or by one or more base stations that are part of such a wireless communication network, and vice versa. It can also mean that part of the functionality is performed by a CN function of the wireless communication network and part of the functionality by the base station.

[0154] This invention is illustrated in the context of an ambient loT system comprising at least a reader and an ambient loT device (also known as an ambient loT tag) and communicating wirelessly.

[0155] The reader refers to one or more devices used to interact with and communicate with the ambient loT tag, it may be, e.g., a base station or access device (i.e. primary station), or a user equipment (UE) (i.e. secondary station) or other type of intermediate device or a combination of them. This means that the reader may be a distributed system having two or more devices.

[0156] The ambient loT tag, or tag, is a resource constrained device. TR 38.848 identifies three potential classes of tags, Class A, devices communicating via backscattering, but without energy storage, Class B, devices communicating via backscattering, and with energy storage, and Class C, devices capable of active signal generation for communication.

[0157] Different communication topologies are feasible (e.g. as illustrated in TR 38.848). For instance, the reader and tag may interact directly with each other wherein the reader may be a base station. In another instance, the reader may be a UE, and the base station is used to drive the communication (e.g., by sending a request signal, sending an illuminating signal for backscattering) and a UE is used to support the communication (e.g., by sending an illuminating signal for backscattering, receiving a backscattered signal).

[0158] The reader may be connected to a telecommunication’s core network providing different services such as subscription information, mobility management, security and so on. The reader may also have access (via the CN) to an application function. The application function may need access to information from the tags.

[0159] Fig. 1 schematically describes different components of the system according to different embodiments of the invention. A base station or access device 100 can communicate with ambient loT tags 101 and a user equipment (UE) 102. The communication between base station 100 and ambient loT tags may be directly involving both request messages to and reply messages from the ambient loT tags. Additionally, base station 100 may coordinate with the UE 102 so that one of the devices sends request messages and another device receives reply messages from the ambient loT tags 101. The base station 100 may also use UE 102 as intermediate device to communicate with the ambient loT device. The base station communicates with the core network (CN) 103 of a telecommunication system. An application function (AF) 104 or network function (NF) can exchange information of the ambient loT tags through the CN 103.

[0160] The invention considers that the reader sends a request message and optionally, followed by an illuminating signal (e.g. carrier wave externally provided) such as single-tone sinusoidal continuous wave (CW) or sends the illuminating signal in parallel to the request message.. The request message and illuminating signal may be transmitted once or multiple times, each time with slightly different contents. The request message may request the tag (or a plurality of them) to retrieve some data from the tag, e.g., an identifier (e.g., in an inventory procedure) or sensed data, which is known as Device Originated - Device Terminated Triggered (DO-DTT), or the request message may request the tag (or a plurality of them) to perform some operation, e.g. writing configuration data, actuating the actuator, enabling / disabling some functionality, which is known as Device Terminated (DT) for command use case. The illuminating signal is sent with the purpose of providing a tag a signal to backscatter information back. The set of all transmitted request messages / illuminating signals is denoted as a request burst. Each pair of request message / illuminating signal or request message / reply time is denoted as a slot.

[0161] This access procedure resembles therefore a slotted aloha procedure.

[0162] Fig. 5 describes a procedure for accessing the information of a multiplicity of tags 501 by reader 500 based on some of embodiments in the invention. In a case, message 502 can represent or serve as a synchronization signal / paging message / scheduling message / request message that may be used to get the tags synchronized or initiate the random access procedure. This signal may be transmitted on demand, e.g., when an application or the core network requires performing an inventory request of an application or determining the presence of a tag. This signal may be broadcasted in a broadcast channel, and / or a channel for control signalling / user traffic from reader to the tag, e.g. PRDCH (Physical R2D (Reader to Device) Channel). This signal may be a preamble as part of or as the request message. This message may contain an identifier such as a service identifier identifying the inventory that is requested or the tag that is being requested, or a command that is requested for a tag to execute. Upon reception of this signal 502, and if the signal is acceptable by tag 501, the tag may actively reply or backscatter signal 503. Since multiple tags may reply, tags may perform a multiple -access and / or random access procedure in signal 503, e.g., as described in embodiments in this invention. Signal 502 may be a request burst if tags do need to be provisioned with an external timing source for a time-division multiple access, or may include a single request message followed by an illuminating signal or lack of it and / or (or whereby an illuminating signal is transmitted in parallel to the request message). Over this illuminating signal or lack of it, multiple tags may perform multiple access, based on slotted Aloha as in some embodiments of the invention. Signal 503 may include a preamble including a preamble or random identifier, etc. Signal 504 may be used to acknowledge signal 503, and this is done, e.g., by including, e.g., the random identifier used in previous step to acknowledge which tag wins the contention of random access. In a subsequent step 505, the tag can reply with its own identifier (e.g., EPC as in RFID). Finally, in step 506, the reader may confirm.

[0163] The above procedure refers mainly to the procedure between reader and tag. However, communication is also required between tag and / or core network and / or application.

[0164] An architecture of the form shown in Fig. 11 is used. The AIoT Devices talk to an AIoT Reader, the AIoT reader may be a base station or a UE. In turn, the AIoT Reader talks to a network entity that, for the purpose of this disclosure, is referred to as the AIoT Application or, more simply, the network. It is convenient to make some assumptions about the relationship between these three components. The AIoT Application may communicate with AIoT devices via any AIoT Reader in range of the AIoT devices. To this end, the AIoT Application may store information about the likely (network) location of AIoT devices in terms of the AIoT Readers most likely to be in range of the AIoT devices. Alternatively, the AIoT reader may announce its presence (on behalf of the AIoT application), requesting tags to communicate. The AIoT Reader may act as an interface between the AIoT device and the AIoT Application that is essentially transparent to data and commands transferred between the AIoT Application and the AIoT device. The AIoT Reader may handle all communications across the air interface and, to this end, may store data and commands temporarily while executing a service request. It is not required nor assumed to retain any information about the AIoT devices outside the service requests. It is assumed that security is handled in end-to-end fashion between AIoT devices and the AIoT Application; any AIoT Reader used by the AIoT Application is assumed to be authenticated by the network and may be trusted implicitly by the AIoT devices.

[0165] In the context of this patent application, the term AIoT Application may be replaced by AIOTF or other Network Function (NF) within the core network that manages AIoT operations. In addition, the term AIoT Application may be replaced by Application Function (AF) that may operate inside the Core Network or outside of the Core Network and that may indirectly (e.g. through NEF) use a network function in the core network for managing the Ambient loT devices and handling communicating (e.g. at NAS layer) with the Ambient loT devices.

[0166] Next, different embodiments of the invention illustrate how the different parts of the system may operate.

[0167] Section: R1 - Request messages / Request bursts / Multiple access This embodiment of the invention considers that the reader sends a request message and optionally, followed by an illuminating signal (e.g. carrier wave externally provided) such as singletone sinusoidal continuous wave (CW). The request message and illuminating signal may be transmitted once or multiple times, each time with slightly different contents. The request message may request the tag (or a plurality of them) to retrieve some data from the tag, e.g., an identifier or sensed data, which is known as Device Originated - Device Terminated Triggered (DO-DTT), or the request message may request the tag (or a plurality of them) to perform some operation, e.g. writing configuration data, actuating the actuator, enabling / disabling some functionality, which is known as Device Terminated (DT) for command use case. The illuminating signal is sent with the purpose of providing a tag a signal to backscatter information back. The set of all transmitted request messages / illuminating signals is denoted as a request burst. Each pair of request message / illuminating signal or request message / reply time is denoted as a slot.

[0168] A request burst may serve as a synchronization signal for tags to synchronize on the downlink direction with the reader, e.g. UE and / or base station. Since backscatter tag uses backscatter communication and it is always triggered by the carrier wave and can reflect the backscattered information back to the reader almost instantly or with very short delay, there is no need of uplink synchronization for the backscatter tags to operate.

[0169] Fig. 2 schematically illustrates exemplary signals and messages described. A request burst 204 is firstly sketched comprising four slots, each slot including a request message 200 and an illuminating signal 201. The second slot is indicated by means of 203. A second request burst 205 is also sketched, in this case each slot includes a request message 200 and a lack of illuminating signal 202. The contents of 200, 201 and 202 are further described below. A request message 200 may include multiple message fields 2001, 2002, 2003, 2004, 2005 that may refer to, e.g., a preamble, the number of slots in the request burst (in which the request message is transmitted), the slot number (occupied by the request message in the request burst), whether the slot includes an illuminating signal or not, and specific request data. The illuminating signal 201 may be a continuous wave, e.g., a sinusoidal wave of a given frequency. Finally, the lack of illuminating signal 202 refers to the lack of an illuminating signal or transmission.

[0170] This embodiment of the invention considers that the tag may use backscatter communication or active signal generation for communication to reply back to the request of a reader to retrieve information. A tag only capable of backscatter communication will only be using backscattering communication and reply to a request message followed by an illuminating signal (e.g. carrier wave externally provided), e.g., class A or class B devices as per TR 38.848. The illuminating signal may also be received in parallel to the request message. A tag capable of backscatter and active signal generation for communication may use backscattering or active signal generation for communication to reply.

[0171] The request message may be modulated over the same illuminating signal (e.g., a sinusoidal wave) or it may be modulated over a different type of signal, e.g., multiple carriers using a more complex modulation scheme than use by the tag to reply.

[0172] In an embodiment that may be combined with other embodiments or used independently, the / one request message includes one or more fields of:

[0173] - a preamble,

[0174] - the number of slots in the request burst (in which the request message is transmitted),

[0175] - the slot number (occupied by the request message in the request burst),

[0176] - a time delay parameter,

[0177] - a device identifier,

[0178] - an identifier identifying a group of devices,

[0179] - whether the slot includes an illuminating signal or not,

[0180] - the time and / or frequency resource information of one or more illuminating signals (i.e. carrier wave(s) externally provided),

[0181] - a request (session) identifier,

[0182] - information acknowledging the reception status of the reply messages from tags,

[0183] - specific request data, etc.

[0184] Other fields may be included, e.g., based on different embodiments of the invention.

[0185] As a matter of clarification, this means that request messages in a request burst may not include exactly the same fields.

[0186] These fields may be in general classified as header fields (e.g., slot number) and payload fields (e.g., request data). The preamble message may allow the tag to synchronize with the transmitted request message.

[0187] In a further related embodiment that may be combined with other embodiments or used independently, the request (session) identifier may be used by tags / devices receiving the message to not reply to a request message including the same session identifier multiple times, e.g., in a multiple round procedure. The session ID may be determined by the AF or NF or a reader.

[0188] In a further related embodiment that may be combined with other embodiments or used independently, the request message may also include one or more of the following:

[0189] - a length parameter indicating the length of the request message, e.g., in number of bits or bytes. This may be useful when the request message includes data of variable length for one or more tags,

[0190] - a length parameter indicating the length of the subsequent illuminating signal (or lack of it) so that the tag knows how much data it can transmit / backscatter and / or when illuminating signal (e.g. carrier wave externally provided) will be available for backscatter communication,

[0191] - a counter or timestamp,

[0192] - service or network identifier,

[0193] - a command identifier, e.g. requesting device identifier, reading data from the tag, writing data to the tag, confirmation of the reception of a reply message from the tag.

[0194] In a further related embodiment that may be combined with other embodiments or used independently, the preamble may include an initial part and a second part and a third part, the initial part and the third part are featured by the absence of transmission so that the tag can make sure that it is not subject to interferences while the second part is featured by a wave form encoding the transmission of a well-known bit sequence, e.g., encoding an alternating bit sequence of Os and Is as a clock sequence so that the tag can synchronize. Furthermore, the tag may only process the signal / preamble / request if one or more of the following conditions applies:

[0195] - the first and third part are interference free / do not contain any peaks indicating the transmission of a symbol / do not contain information and / or

[0196] - the second part allows the tag to synchronize its internal clock till a given accuracy and / or

[0197] - the received signal exhibits certain features, e.g., the signal strength achieves a minimum threshold or is stable (i.e., there is no more than a given percentage in variation in the symbols in the second part) along the second part and / or

[0198] - the average signal strength in the second part is a factor x stronger than the average signal strength in the first and / or third parts.

[0199] In some configurations, only the first part and the second part may be present. In other configurations only the second part may be present. In a further related embodiment that may be combined with other embodiments or used independently, the preamble may also contain an indication of the service, node, network, ... to which the request message belongs. This allows a tag to only process the message if the message is intended for the tag. For instance, the second part may consist of the well-known sequence xor-ed with said indication, e.g., the identifier of the service to which the request message belongs. The service identifier may be shorter than the whole second part, e.g., the second part may be n2 = 30 bits long and the service identifier may be only nl = 10 bits long so that the second part may be, e.g. : when the service identifier corresponds to 111111111 h.

[0200] 101010101010101010100101010101

[0201] This can allow the tag to not only synchronize the clock but also only further process the message if the message is intended to it (or has an indication that the message is intended to it).

[0202] In a further related embodiment that may be combined with other embodiments or used independently, the preamble may also include some capabilities to correct errors or detect errors, e.g., when the preamble includes an indication of the service for which the request message is intended so that tag is capable of detecting an error even if the clock is not perfectly synchronized. This may be done by means of a CRC.

[0203] In a further related embodiment that may be combined with other embodiments or used independently, the synchronization sequence used in the preamble is used to identify the service for which the request message is intended. Different synchronization sequences are allocated for different services so that the preamble fulfils two purposes, synchronization and determining whether the message is intended for the tag or not.

[0204] In a further related embodiment that may be combined with other embodiments or used independently, the request message may include one or more fields of information common to all tags or a group of tags, e.g., a service identifier.

[0205] In a further related embodiment that may be combined with other embodiments or used independently, the request message may include one or more fields of information dedicated to one tag or a group of tags.

[0206] Fig. 6 shows a specific example of such a preamble that contains a guard field at the beginning and end of the preamble that may correspond to the first and third part in above embodiment, a synchronization sequence, an ID field that may be a service ID or network ID or application ID. In a specific configuration of the embodiments in this invention, the request burst contains a single request message.

[0207] In an embodiment that may be combined with other embodiments or used independently, the reader sends a request burst at time tO with nO slots that includes the slot number and number of slots in each request message within the request burst, e.g., as illustrated next for this request burst with two slots. This is illustrated in Fig. 3 where a request burst 302 including two slots 303. Each slot may include a request message 300 and / or an illuminating signal 301. Each request message may include two fields, a first field including the slot number where the request message is located and a second field including the number of slots in the request burst 302. In this example, the first request message includes fields { 1,2} and the second request message includes fields {2,2}.

[0208] In an embodiment that may be combined with other embodiments or used independently, the request message may serve as a slot announcement message in an asynchronous system, where a master node “(e.g. AIOTF or base station controlling multiple readers, or a reader itself) may use the slot number to provide a common reference time to other nodes (e.g., ambient loT devices or tags) which may not have accurate clock. In such a system, a reader may use the request message to announce the current slot number of the system and such slot number may serve as a common clock for all tags in the system. As an example of this embodiment, the slot number may be an integer with a pre-defined maximum value S and the slot number may increase by a value (e.g. 1) every time a new request message is sent and the slot number may wrap around to an initial value which is less than the pre-defined maximum value S (e.g. 0 or 1) when the slot number exceeds the pre-defined maximum value S minus 1. A base station controlling multiple readers may also determine such a common reference time and provide it to, e.g., a number of UE readers under its control. Multiple UE readers may then use a same reference time when interacting with the tags, e.g., when transmitting request burst(s) and / or receiving reply messages.

[0209] Note that the slot number may play a similar role as or be the system frame number (SFN) as in 4G or 5G. In 5G, a base station broadcasts regularly synchronization signals containing the Master Information Block (MIB) in the physical broadcast channel (PBCH). The current SFN is included in the synchronization signals, the 6 most significant bits are included in the MIB and the 4 least significant bits are included in other fields of the synchronization signals. The SFN is therefore 10 bits long, and a new SFN is issued every 10 milliseconds so that an SFN is repeated every 10.24 seconds. There are a total of two to the power of 10 different SFNs, i.e., 1024. The slot number and number of slots described in this application in other embodiments may play a similar as the number of slots and the total number of SFNs. In fact, in a particular embodiment that may be combined with other embodiments or used independently, the slot number corresponds to the SFN and the request message may be (part of) a MIB.

[0210] In an embodiment that may be combined with other embodiments or used independently, when the tag receives the request burst, the tag can determine in which slot to transmit back its answer based on:

[0211] - as a deterministic function of a preconfigured ID, e.g., ID modulo nO. - by picking up a number m at random, e.g., m is between k and nO, and selecting m as the transmission slot.

[0212] In particular, a node picking up a given slot will reply at the end of the request message transmitted in that slot, i.e., after the request message, using the illuminating signal (if it is using backscattering device) or using active signal generation for communication if capable of it.

[0213] In another embodiment that may be combined with other embodiments or used independently, tags that have a clock, or have energy storage to sustain a clock for some time / a longer period of time may perform time-division multiple access within the illuminating signal 201 or lack of it 202 (as per Fig. 2) following a request message, e.g., based on aloha or slotted aloha. In this embodiment, the reader can divide the time interval corresponding to the illuminating signal or lack of it, i.e., the slot time, into several subslots, e.g., X subslots, with X greater or equal than 1, and may inform the tags about the number of subslots, subslot duration in the illuminating signal (or lack of it) in a request message. The tags that have a clock can synchronize their clocks with the reader's clock using the request message as a reference point. Then, the tags can randomly select one of the subslots to send their reply messages, either by backscattering or active signal generation for communication. This way, the tags can reduce the probability of collisions and increase the efficiency of the multiple access. This may be considered as a TDMA approach within the overall request burst structure. The reader can also adjust the number of subslots based on the feedback from the previous iterations, as described above.

[0214] In an embodiment that may be combined with other embodiments or used independently, a tag may only transmit in the first part of a (sub)slot, e.g., if a (sub)slot is t microseconds, then the tag may only transmit in the first s microseconds, s<t. The last part of the (sub)slot (t-s microseconds long) is a guard period to account for the propagation time from tag to reader so that the response of a tag in a (sub)slot does not interfere with the response of another tag in the subsequent subslot or request message. The parameter s may be preconfigured or included in the preamble. This guard period may also be present between an illuminating signal 201 (or lack of it 202) in slot i and the request message 200 in the subsequent slot i+1 as per Fig. 2. This way, the reader can avoid overlapping of the request message and the reply messages from different tags, which may cause interference and corruption of the data. The reader can also adjust the duration of the slots and the guard periods based on the feedback from the previous iterations, as described above.

[0215] As a clarification, in a request burst there may be multiple request messages / slots, and each slot may be divided into subslots. Prior to each slot there may be a request message, i.e., a message from the reader to the AIoT devices. The number of slots may be called G. Each slot may be divided into K = X* Y subslots, where X may refer to time units (TDMA within a slot) and Y may refer to Y frequency units (FDMA within a slot) so that within a slot there are X*Y subslots (within a slot). The total number of subslots (access opportunities) may be denoted N = G* K = G*X*Y in a request burst. The number of subslots (access opportunities) within a slot may be X*Y and this may be a set of subslots (access opportunities). The request messages may include fields providing input to the AIoT devices. The subslots after a request message may provide contention-based or contention- free occasions to AIoT devices.

[0216] Section: R1 - Further details of signals used for request message / burst

[0217] In an embodiment that may be combined with other embodiments or used independently, the request burst may be transmitted as part of the synchronization signals or as a special type of synchronization signal or a wake up signal or a paging message or a scheduling message transmitted by a base station or UE.

[0218] In an embodiment that may be combined with other embodiments or used independently, the illuminating signal may be a single-tone carrier wave or multi-tone carrier wave. This illuminating signal may overlay / co-exist with OFDMA resource structure, and share the spectrum with legacy 4G / 5G communications by the frequency domain multiplexing with guard bands configured to isolate the carrier wave transmissions and legacy OFDMA transmissions in the resource structure. In an example, the reader may transmit a request message in OFDMA format at the beginning of each slot. This request message may contain information such as the slot identifier, the carrier frequency and duration of the illuminating signal, and the tag identifier or group identifier for the tags that are expected to reply in the slot or in the request burst. The tag may decode the request message by using an OFDMA receiver and demodulator, which may be implemented by a simple correlator circuit or a more sophisticated digital signal processor (DSP). If the tag recognizes its identifier or group identifier in the request message, it may prepare to reply by backscattering the subsequent illuminating signal. The illuminating signal may be a sinusoidal wave corresponding to a carrier of the OFDMA modulation, which may have a different frequency or use the same frequency than the request message. The tag may modulate its information on the sinusoidal wave by switching its antenna impedance between different states, such as short and open circuits, which creates reflections of the illuminating signal. The reader may detect these reflections by using a matched filter or a correlation receiver, and demodulate the tag's information by using a threshold detector or a maximum likelihood decoder.

[0219] In an embodiment that may be combined with other embodiments or used independently, the transmitted signals / waves, e.g., single-tone carrier wave or multi-tone carrier wave, may use frequency hopping to shift the transmission frequency according to a pre-determined pseudo-random 1 pattern in the time domain / each slot or a few slots, for the purpose of interference minimization, optimize the power spectral density of the waveform in the analogue domain from the transmitter, and serve different tags configured at different carrier wave frequencies.

[0220] For example, when a tag receives an illuminating signal in slot i, it may reply with a backscatter modulation on a frequency that depends on the slot identifier i and potentially on an identifier assigned or determined by the tag. This allows the reader to differentiate the reply messages from different tags and slots by using frequency-domain filters or fast Fourier transform (FFT) operations. The tag may also use a pseudo-random hopping pattern based on its identifier to choose the reply frequency, which can improve the robustness against interference and eavesdropping. This may be combined with other embodiments, e.g., the one illustrated by means of Fig. 2 wherein a tag may receive a request (burst) and pickup a slot number at random, and the slot number may determine both time and frequency resources. For instance, if there are 16 time slots, and 4 possible frequency shifts, a tag may determine a random number R between 0 and 63, and determine the time slot as R modulo 16 and the frequency shift as the integer division of R divided by 4.

[0221] In an embodiment that may be combined with other embodiments or used independently, the single-tone carrier wave or multi-tone carrier wave transmitted from the reader or carrier wave node may use beam sweeping to multiplex over space domain (and / or frequency / time domain jointly) to serve tags located at different directions of the reader. Usually the reader is equipped with more complex radio capabilities and multiple antenna arrays / panels, which allows it to exploit the spatial multiplexing effectively on the transmitter side, while the tag is a very low complexity and low cost device and usually only has one receiver antenna to receive the beam swept signals from the reader from a particular direction. For instance, the reader may be an access device (reader TX) such as a base station that distributes the synchronization burst. The reader may also obtain from UEs (reader RXs) to receive the replies from the tags. The reader TX may transmit the request burst through different beams to cover a given area. The transmitted signal may be identical in all beams, in particular, transmitted in the same frequency band, with a difference in certain parameters that may be used to configure the answer of the tags. For instance, the request messages may include a field that refers to the frequency shift when backscattering back the illuminating signal. Tags receiving the request burst through different beams may obtain a different frequency shift (encoded in the request messages of the corresponding request burst). Based on i, different tags in different areas apply a different frequency that allow, e.g., minimizing interferences.

[0222] Section: Rl- determining number of devices still seeking access In an embodiment that may be combined with other embodiments or used independently, the reader can monitor (1) whether there are collisions when the answers are received from the tags and / or (2) how many slots are not used. Here, with slots it is meant the usage of the (lack of) illuminating signal after the request message to transmit a message back to the reader. Both (1) and (2) allow the reader to determine / estimate the number of tags that are willing to answer / require multiple access. Based on the estimated / determined number of tags that still need to provide an answer / send a reply message, the reader can decide to transmit at time t1 a new request burst with n1 slots. If the reader noticed many collisions / requests, then n1 can be increased. If the reader noticed just a few collisions, n1 can be decreased. This approach allows a reader to start with a small nO and rapidly adjust it up or down to retrieve the information of many tags.

[0223] This is illustrated in Fig. 4 where 400 refers to the reader and 401 refers to one of a plurality of tags. Messages 402, 404, and 406 represent three request bursts transmitted by 400. 403, 404, and 405 represent three sets of (backscattered) replies.

[0224] Other methods of estimating the number of devices may be advantageous, particularly when it is necessary to provide an estimate of the total number of devices. In the embodiments below, the use of the Poisson distribution is assumed but other distributions may be more appropriate in some circumstances.

[0225] In a first variant (embodiment E18A) that may be combined with other embodiments or used independently, the reader may offer many times more slots than the expected number of devices: the more slots available, the greater the proportion of devices that will succeed with contention. Offering 16x as many slots as expected devices, for example, should allow 97% of addressed devices to respond successfully. The reader may therefore simply estimate the total number of devices by counting the number of responses and, if desired, making a correction based on the ratio of slots used versus the expected number of devices.

[0226] In a second variant (embodiment E18B) that may be combined with other embodiments or used independently, the reader offers a number of slots, for example, approximately as many slots as the expected number of devices, and counts the number of successful responses. The ratio of successful devices and slots will be a function of the total number of devices. However, since this curves peaks at 1 / e, there will in general be two possibilities for the total number of devices. To disambiguate, the reader may run a second round with a different number of slots, say, twice as many or half as many slots as the previous round. The reader arranges for all devices to re-access regardless of whether they were successful in the previous round. The results from said second round may be used to determine which of the two possibilities is correct, and thus, determine, e.g., how many devices are seeking access. Based on this, further rounds can be executed with the corresponding / suitable parameters, e.g., according to other embodiments.

[0227] In a third variant (embodiment E19C) that may be combined with other embodiments or used independently, the reader offers a number of slots, for example, approximately as many slots as the expected number of devices, and records the number, nl, of and the identities of successful devices. It then runs a second round, arranging for all devices to re-access regardless of whether they were successful in the previous round and determines the number, n2, of and the identities of successful devices. It can then calculate the proportion, p21, of devices recorded in the second round that were also recorded in the first round. If one can assume that this sampling is essentially random then p21 is approximately nl / T, where T is the total number of devices, the number of devices recorded in the first round divided by said proportion is approximately the total number of devices. The reader may also derive pl2, the proportion of devices recorded in the first round that also appear in the second round, and calculate n2 / pl2 to derive a second approximation of T that could be combined with the first.

[0228] In a fourth variant (E19D) that may be combined with other embodiments or used independently, the reader determines the number of devices that should have access (M) and the number of devices that may remain without access (e.g., K = k*M) with 0<k<l after some time. M may be a value provided to the reader, e.g., by a CN NF or AF in a request sent to the reader, e.g., an inventory request. The reader is then required to perform s rounds, where 1 - (l-0,36)As > k, where each round i, with i=0,..., s-1 may have as many slots as the number of devices that still require access in that round, e.g., M* ( 1 -0,36)Ai with i=0,..., s-1. Here, 0,36 represents the success probability of transmission, and this success probability is such when the number of devices attempting to access equals the number of available slots. In an option, instead of using the theoretical value M* ( 1 -0,36)Ai of the number of devices that still seek access in round i, the reader may use as number of slots the actual number of devices that still require access.

[0229] Various refinements and combinations can be envisaged. For example, the methods used in the second (E18B) and third (E19C) variants could be run three or more times to improve the accuracy of the approximation. In the third variant, multiple runs may allow a number of proportions to be calculated and combined or averaged to reduce estimation error.

[0230] The methods in the second (E18B) and third (E18C) variants may be combined, such that the first round uses k slots and the second round, say, 2k slots, as per the second embodiment, with the approximation methods of both embodiments being deployed and the final result being a weighted average.

[0231] For instance, methods in the second (E18B) and fourth (E18D) variants may be combined, such that variant E18B is used to determine how many devices seek access, and variant E18D is used to optimize the overall number of rounds and number of slots per round.

[0232] Having derived an approximate number of devices, another method, for example the first variant, could then be deployed as a cross-check.

[0233] In a variation of all of the preceding embodiments, the reader may also take into account the number of empty slots and / or number of slots in which collisions are detected. On the assumption that all devices respond, the number of empty slots and the number of collisions are also functions of the number of devices and the number of available slots. Assuming the use of Poisson statistics, the relative proportions will in general correspond to a particular ratio of slots and devices.

[0234] Section: R1 - multiple access (MA) techniques

[0235] In an embodiment that may be combined with other embodiments or used independently, a protocol or procedure as illustrated in Fig. 4 in the context of a multiple access technique based on time division may also be applicable to other multiple access techniques, e.g., frequency division or code division. The logic of such a procedure is that in each iteration of the protocol (e.g., step 402 in Fig. 4), the reader attempts to obtain answers from a plurality of tags and uses specific parameters for the protocol for the expected number of tags. Based on the number of replies, the reader can readjust the parameters. For instance, if a frequency division technique is used, in the first iteration the reader may allow tags to select an amount nO of different frequency carriers fO,...fhO-l, in the second iteration the reader may allow tags to select an amount nl of different frequency carriers f0,...fnl-l. If nO or nl is chosen larger, then the number of iterations decreases, and thus, the latency to retrieve the information of N tags (obtain the answers from N tags) decreases. This is achieved at the expense of more resources. If nO or nl is chosen smaller, then the amount of resources decreases but the latency increases.

[0236] In the context of frequency, the frequency shift may be the result of a given frequency shift and / or a combination of chip length and line code generation, i.e., how many chips are used to spread a symbol. For instance, a bit of information may be spread using chip sequences using 1 chip, 2 chips, 4 chips, 8 chips, etc. that may lead to an equivalent” frequency increase of a factor 2x, 4x, 8x, and thus, a frequency shift. The available frequency shifts and / or the available combinations of chip length / line code generation may be (pre-) configured in the tags (e.g., as a look up table) and / or signalled to the tags (e.g., by indicating which entries in a look up table are applicable for the current communication). Furthermore, as already illustrated in other embodiments, the total number of frequencies / codes available in a given request (burst) may also be signalled in a similar way the number of slots in a request (burst) is signalled.

[0237] In the context of CDMA, orthogonal (chip) sequences may be used. This may also allow two devices to use two orthogonal (chip) sequences so that the reader can receive two messages from the two devices simultaneously.

[0238] It is to be noted that the procedures may apply in particular to the uplink (i.e., from AIoT device / tag to reader) when many devices may need to reply and these procedures may allow the reader to provide them with multiple access. In the downlink (i.e., from reader to AIoT device / tag), some of the MA procedures may be less suitable, e.g., the most constraint devices may only be able to use TDMA while more power devices (e.g., class C) may be able to use FDMA and / or CDMA. When a device performs MA in the uplink (e.g., in message 503 / 905 upon reception of message 502 / 904), the reader may receive this MA message, and when replying in the downlink (e.g., message 504 / 906), the reader may then use only TDMA (e.g., for more resource constraint devices ) or TDMA and FDMA and CDMA (for more powerful devices) wherein the reader may pick up / select timeslots and / or frequencies and / or codes that are related the timeslots and / or frequencies and / or codes in the uplink. For instance, it may use the same frequency / code in the downlink as selected in the uplink or may indicate new resources.

[0239] For instance, assume a combined time / frequency / code multiple access procedure extending the one illustrated by means of Fig. 2 wherein multiple tags may receive a request (burst) and pick up a slot number at random, and the slot number may determine both time and frequency and code resources. For instance, if there are 16 time slots, and 4 possible frequency shifts, and 16 possible codes, a tag may determine a random number R between 0 and 1023, and determine the slot (i.e., time resources / frequency shift / code identity) from it. For instance, the time slot may be obtained as R modulo 16 and the code identity to use may be obtained as (R ID 16) modulo 16, and the frequency shift as R ID 256 where A ID B refers to the integer division of A / B. The above approach to determine time, frequency, and code resources ensures an equal distribution in the selection of time, frequency, and code resources by generating a random number in the support of available time resources / frequency resources / codes and deriving from it time resources / frequency resources / codes in a uniform manner. This is feasible because the amount of time resources and frequency resources and codes is a power of 2. If any of them (i.e., amount of time resources, frequency resources, codes) is not a power of 2, then the total number of possible slots k (amount of time resources (T) TIMES frequency resources (F) TIMES codes (C) will not be a power of two T x F x C = k so that the selection of a slots in a uniform manner may require a bit more complex function. An option may be to generate a random number that is between 0 and the next power of 2 (after k) minus 1, and reject values when they are between k-1 and the next power of 2 (after k) minus 1. After rejection, the values are uniformly distributed, and then time / frequency / code resources can be derived, in a similar way. Note that the amount of time resources, frequency resources, etc may have been named X or Y in other parts of this invention, however, this is clarified in the specific embodiments of the invention.

[0240] The above approach may have a high rejection sampling, e.g., when k = 16* 18*5 = 1280, the next power of 2 (after k) is 2048, so approximately 3 / 8 of the values is rejected. This increases the energy consumption of the devices, although this may be a simpler function to implement. To improve rejection sampling, random number between 0 and a higher power of two minus 1 (e.g., 2Am-l, with m=16) may be obtained, and numbers only rejected if they are between Q=k*(2Am / k) and 2Am-l, where “ / ” refers to the integer division. Non-rejected random values can be used to derive time / frequency / code resources uniformly. This can be done by taking a non-rejected value, dividing it by Q, and then using a similar approach as above to determine the time / frequency / code resources.

[0241] It is to be noted that selecting the right number of slots is very important when performing an inventory (sending one or more burst of request messages) of N nodes. If the number of slots is not equal to N, the performance degrades. However, not all N values will be a power of two (since usually power of two are easier to sample in a uniform manner). Thus, it may be required to signal some values, e.g., Q, to the tags (e.g., implicitly or explicitly) so that they can apply a suitable function. It is to be noted that if the numbers are not sampled uniformly, some devices may have higher / lower chances to access the medium.

[0242] In an embodiment that may be combined with other embodiments or used independently, the reader may need to inform the tag not only about the total number of slots in a request burst, but it may need to inform the tag about how those slots are composed, i.e., which slots are due to different MA technologies, e.g., when multiple MA technologies are used, e.g., TDMA and FDMA. The reason is that the tag may need to determine, e.g., the temporal slot and frequency slot, e.g., when TDMA and FDMA are used, and for this, the number of time and frequency slots need to be known to the tag. For instance, if the total number of slots is 512, the 512 slots may be obtained in, e.g., 10 different combinations, as shown below, when powers of two are used. Thus, the request messages (e.g., a paging message) may include, implicitly or explicitly, the number of slots according to the MA technologies used in the request burst.

[0243] It is to be noted, that the above combinations may also be communicated by means of a codebook, e.g., the “Combination #” field may be transmitted to identify the number of slots in the different MA technologies. For instance, a field in the request message may include a 4 bit field including “Combination #5" so that the tag determines that the request burst includes 32 time slots, each time slot including 16 frequency slots. A tag may then need to obtain a random number to pick up a time slot, and a frequency slot.

[0244] It is to be noted that in the specific case of FDMA, the number of frequencies may be n = 2k + 1 since the frequency of the illuminating signal may not be shifted (+1) and the frequency of the illuminating signal may be shifted up and down. Thus, n is not a power of two. Picking up a frequency slot in a uniform manner may require a logic as above, e.g., given a b-bit random number r, a function f() is applied to r to obtain r’ that is uniformly distributed between 0 and 2k. Function f() may involve rejection sampling as in other embodiments. Alternatively, one of the frequencies that may be used, is not used, in order to facilitate the logic to pick up a frequency slot in a uniform manner. For instance, the frequency of the illuminating signal is always frequency shifted. This serves two purposes. First, it does not interfere with the illuminating signal transmitted by the reader; and second, the generation of a random frequency slot is easier. If this is done, the total number of frequency slots is 2k. Ideally, k is also a power of two so that the total number of frequency slots is a power of two, so that again, the choice of a random frequency slot can be done in an efficient manner.

[0245] It is to be noted that the frequency shift may be the result of a combination of chip length and line code generation, i.e., how many chips are used to spread a symbol. For instance, a bit of information may be spread using chip sequences using 1 chip, 2 chips, 4 chips, 8 chips,..., k chips etc. For similar reasons as explained above, it is beneficial if k is chosen a power of two, i.e., k = 2At, and the number of frequency slots can be encoded as the t = log2(k) value for a more efficient / compact representation. For instance, if the maximum number of chips is 256, and thus, the number of slots is 256, it is encoded as 8, and can be transmitted with three bits. In general, it is beneficial to choose the number of slots s in time, code, frequency,... as a power of two, and transmit log2(s) as the identifier.

[0246] In an embodiment that may combined with other embodiments or used independently, CDMA is used for multiple access wherein the spreading code, e.g., for the reader to device transmissions in Msg2 (i.e., 504 in Fig. 5), is a function of the random ID. This is advantageous because it allows increasing the downlink / uplink capacity.

[0247] In general, it is described an apparatus for communicating by means of a low power device, such as a tag, the apparatus comprising a receiver configured for receiving a request message in a request burst, wherein the request message includes an indication of a number of slots in the request burst, a controller coupled to the receiver configured to determine an apparatus identifier or a random number, the controller being arranged to select a transmission slot number to deliver a reply message within the request burst, wherein the transmission slot number is selected on the basis of at least the number of slots and on the random number or the apparatus identifier; a transmitter coupled to the controller to transmit the reply message after the end of the request message in the slot corresponding to the selected transmission slot number, wherein the slot is defined to be as a combination of time, frequency, and code resources and wherein the time, frequency, and code resources are determined from the identity or the random number.

[0248] In general, the apparatus may be adapted to obtain a random number or identity equal or greater than the number of slots given by the number of time resources times the number of frequency resources times the number of codes, and applying a function that takes as input the random number or identity and uniformly selects a slot given by time, frequency and code resources.

[0249] Section: R1 - Further details request message / burst

[0250] In a further related embodiment that may be combined with other embodiments or used independently, the request identifier or request session identifier that may be included in the request message may be used by tags / devices receiving the request message to not reply to a request message including the same session identifier multiple times. For instance, all request messages in request bursts 402, 404, 406 may include the same request identifier so that if a first tag managed to get access in the request burst 402 (e.g., to provide its identifier in an inventory use case), the first tag does not attempt to gain access again in the second request burst 404. Additionally or alternatively, a tag may start a timer when it gains access (e.g., in request burst 402) and it may not attempt to gain access again for a given predefined time that may be embedded in the tag logic or may have been transmitted in the request message.

[0251] In a further related embodiment that may be combined with other embodiments or used independently, a field of information acknowledging the reception status of reply messages from tags may be included in the request message to indicate to the tags whether the reply messages from tags have been successfully received or not.

[0252] An embodiment of the present invention that may be combined with other embodiments or used independently may include an additional condition to terminate the iterative multiple access procedure, such as when a timeout expires or when x% of the N devices have provided an answer. For example, the reader may set a timer after each request burst and wait for a predetermined period of time before transmitting the next request burst. If no reply messages are received within the timer period, the reader may assume that there are no more tags to be queried and stop the iteration. Alternatively, the reader may keep track of the number of reply messages received from the tags and compare it with a threshold value based on the estimated total number of tags. If the number of reply messages reaches or exceeds the threshold value, the reader may conclude that most of the tags have been found and stop the iteration.

[0253] Once the iterative multiple access procedure stops, the remaining devices may be queried individually by the reader. For example, the reader may transmit another request burst that includes the identifiers of the tags that did not reply in the previous iterations. The tags that receive their own identifiers may then reply with their information or status. Alternatively, the reader may send a message to a user, an application, or a core network with the identities of the tags that could not be found. The user, application, or core network may then decide whether to initiate another round of multiple access or take other actions.

[0254] Thus, in general, it is described an apparatus for multiple access adapted to: select a number nO of resources (slots, frequency carriers, codes, etc) for a request burst, transmit a first request burst comprising or indicating nO resources, where each resource may include a request message. The apparatus may optionally transmit by means of a transmitter an illuminating signal subsequent to some or each request message. The apparatus for multiple access may be adapted to monitor for the reception of one or more reply messages from one or more low power device such as a tag in the time or frequency resources subsequent to the request message. The apparatus may include a controller that is adapted to determine the need to transmit a further request burst and select the number of resources nl of the further request burst, and transmit the further request burst with involving the number nl of resources. In an embodiment that may be combined with other embodiments or used independently, the duration of the illuminating signal may be adapted to the duration of the reply messages that are expected by the tags.

[0255] In an embodiment that may be combined with other embodiments or used independently, there is a transmission gap between the end of the illuminating signal at the end of slot i and the start of the new request message at the beginning of slot i+I . This ensures that the reply message of a tag in slot i does not overlap with the transmission of the new request message in slot i+I.

[0256] In an embodiment that may be combined with other embodiments or used independently, a reader uses a time delay parameter included in the request message to indicate a given time delay that should be applied by the tags, where the delay may be the one indicated in the request message or device specific or determined by the device given the input time delay parameter. The device may then transmit / backscatter after waiting the determined delay.

[0257] In an embodiment that may be combined with other embodiments or used independently, a reader may include an identifier in the request message so that a tag or a set of tags can determine whether they are requested to transmit or backscatter. For instance, the identifier may be the identity of a tag, so that if the tag has that identifier, then the tag is requested to reply. For instance, it may be an identifier range so that devices within the identifier range are requested to reply.

[0258] In an embodiment that may be combined with other embodiments or used independently, a reader may include dedicated time slot, frequency carrier and / or codes information in the request message for a tag with a specific identifier so that a tag or a set of tags which has that identifier can determine to use the dedicated time slot, frequency carrier and / or codes to transmit or backscatter a reply message.

[0259] Section: R1 - Procedures using TDMA and FDMA, e.g., TDMA in downlink and FDMA in uplink using slots and subslots

[0260] In an embodiment that may be combined with other embodiments or used independently, TDMA and FDMA are used for the communication between a reader and multiple AIoT devices. Time Division Multiple Access (TDMA) may be employed for communication from the reader to the device (R2D) in the downlink, while Frequency Division Multiple Access (FDMA) may be utilized for communication from the device to the reader (D2R) in the uplink. This configuration is particularly advantageous for optimizing resource allocation and managing communication in environments with varying device capabilities. In the downlink direction, the reader communicates with the devices using TDMA, e.g., within a single slot. This entails dividing the available time into distinct time subslots, as per other embodiments, each allocated to a different device. Here is how the process may be structured. The above procedure may be used in the transmission by the reader of MsgO (signal 502 in Fig. 5) and / or Msg2 (signal 504 in Fig. 5) wherein MsgO plays the role of request message, and reception by the reader of Msg 1 (signal 503 in Fig. 5).

[0261] 1. The reader may send a (request) message, indicating the commencement or continuation of communication and specifying the time subslots allocated for each device. This request message may be one or multiple Msg2 multiplexed in time within a slot transmitted upon the reception of multiple Msgl (e.g., FDMA multiplexed). The order in which the Msg2 are ordered in the slot may indicate the allocated resources for subsequent communications.

[0262] 2. Each device may receive the transmitted message(s) (e.g., Msg2) and determine its assigned resources, e.g., time, e.g., slot or subslot, based on the information provided by the reader.

[0263] 3. During its designated resources, e.g., time, e.g., slot or subslot, each device may listen for communication from the reader. The reader transmits messages sequentially within the slot, in subslots, ensuring that each device receives its respective message without overlap.

[0264] 4. The reader may include parameters such as time delay or identifier within the (request) message, allowing the devices to accurately synchronize and respond within their allocated slot / subslot.

[0265] This method ensures efficient utilization of (time) resources and minimizes the risk of collision or interference between messages.

[0266] In the uplink direction, devices communicate with the reader using FDMA (next to TDMA as explained in other embodiments). This involves dividing the available frequency spectrum into multiple channels, with each device transmitting on a distinct frequency. The process may be as follows:

[0267] 1. The reader may transmit an initial message, e.g., a request message (e.g., 502 in Fig. 5) playing the role of paging message.

[0268] 2. Each device may select a frequency channel randomly or based on pre-assigned parameters to transmit its answer, e.g., an initial message (Msgl, e.g., signal 503 in Fig. 5).

[0269] 3. Multiple devices may transmit their messages in parallel, each on its chosen frequency channel, thereby reducing the likelihood of collision. This FDMA transmission may happen in a subslot.

[0270] 4. The reader may receive these messages and identify the frequency channels used by each device. The reader then sends one or more acknowledgments (Msg2, i.e., 504 in Fig. 5) in the time domain only, addressing all devices that transmitted in the previous slot. These Msg2 may be transmitted by means of TDMA in multiple subslots. The acknowledgment message (Msg2) may include the random identifiers received from each device (Msgl) along with the corresponding frequency channels. This allows the reader to uniquely identify and respond to each device's transmission.

[0271] By using FDMA in the uplink, the system can accommodate a larger number of devices simultaneously, as each device operates on a different frequency channel, thereby optimizing the overall communication efficiency.

[0272] Fig. 18 illustrates a communication strategy as per some embodiments wherein 1804 may refer to an initial request message, e.g., starting a request burst. 1804 may play the role of MsgO or Msg 502 in Fig. 5. 1804 may be followed by a transmission slot 1805. Multiple pairs of request message / transmission slot form a request burst 1806. Transmission slot 1805 may be divided into multiple subslots. After 1804 (possibly directly after, e.g. without any other message in-between), a first subslot may be used by one or multiple devices to transmit multiple messages 1802 by means of FDMA. Additionally or alternatively more than one subslot may be used for gathering messages 1802 in a TDMA fashion. The set of multiple messages 1802 is denoted by 1800. Message 1802 may be equivalent to Msgl or 503 in Fig. 5. Afterwards, a set 1801 of messages 1803 is transmitted. A message 1803 may correspond to Msg 2 or signal 504 in Fig. 5. This set 1801 is transmitted by means of TDMA in multiple subslots or it may be transmitted as a single message 1803 aggregating the response contents to multiple devices in a bigger slot / subslot. At this point, a new slot may start (e.g., if a new request message 1804, is transmitted), or another set 1800 of answers from the devices (e.g., a set of Msg3, i.e., signal 505 in Fig. 5) may be transmitted (denoted in Fig. 18 as 1800-2) optionally followed by another set 1801 of answers (e.g., Msg 4 or signal 506 in Fig. 5) from the reader (denoted in Fig. 18 as 1801-2).

[0273] In a related embodiment that may be combined with other embodiments or used independently, the frequency channel used in set 1800 may indicate the subslot in which the tag is expected to receive an answer. For instance, if M frequency slots F0,...,FM-l may be used, and m frequency are actually used, f0,...,fin-l, then the tag using fO is allocated the first time subslot in set 1801, tag using fl is allocated the second time subslot in set 1802, and so on. A tag choosing F0 to transmit 1802 in set 1800 may know that it will be allocated the first subslot to transmit 1803 in set 1801 (if its message 1802 goes through, i.e., is received correctly).

[0274] In a related embodiment that may be combined with other embodiments or used independently, a message, e.g., 1803, transmitted in a given subslot includes - explicitly — an identifier representing the subslot to which it is responding, e.g., message 1803 includes an identifier identifying message 1802. In some cases, this explicit identifier may only be included in case the random ID carried in the message, e.g., 1803, e.g., Msg2 is duplicated, i.e., two different devices used the same random ID when transmitting message 1802, i.e., Msgl. In some cases and for efficiency, it may be enough to use only an index as identifier to disambiguate, e.g., for two devices that used the same random ID, use either FDMA index or TDMA index since at least one of them must be different.

[0275] In a related embodiment that may be combined with other embodiments or used independently, the time ordering in set of answers 1801-1 (i.e., which subslot is used to transmit a message 1803 for a specific tag), may implicitly indicate which frequency resources a tag may need to use in a subsequent set of answers 1800-2.

[0276] In a related embodiment that may be combined with other embodiments or used independently, set 1800-1 is used to perform random -access by means of frequency slots within a timeslot of the overall request burst. Only a subset of the frequency slots may be used / occupied. Thus, if there is a subsequent set 1800-2 within the same time slot 1805, the frequency used by the tags in 1800-2 may be allocated in different ways: a) Each tag may use when transmitting its message in set 1800-2 the same frequency slot that it used when transmitting its previous message in set 1800-1. This simplifies the transmission logic. b) The reader may wish to reduce the spectrum, so that if m frequency slots were used, out of M, then the allowed frequency slots / frequency range is reduced from f0,..., fin-1, with all frequency slots being next to each other. This reduces bandwidth consumption. c) The reader may wish to reduce interferences between frequency slots, and if m out of M frequency slots were used in set 1800-1, integer_part_of(M / m)=c the frequency slots in set 1800-2 may be such that f_0, f_c, f_2c,... This is advantageous because it increases the frequency difference between the frequency slots, reducing interferences.

[0277] In a related embodiment that may be combined with other embodiments or used independently, a subslot may refer to the time duration of 1800, or the time duration of 1801, or the time duration of 1803. Subslots may have a minimum / maximum time duration. For instance, message 1800 may be allocated the maximum time duration since the reader may not know how long those messages are, but some subslots may have a variable duration, for instance, if a subslot refers to the time duration of 1803, 1801 may end as soon as a minimum subslot duration has expired if there are no answers 1803 to be transmitted in set 1801.

[0278] In a related embodiment that may be combined with other embodiments or used independently, it is to be considered that messages 1803 within 1801 are transmitted by the reader, and thus, they may include the slot number and / or the subslot number and / or time reference to the main request message that provides the timing for the overall request burst. This supports the time synchronization of the AIoT devices. For instance, an AIoT device may use this time reference included in some of the messages included within a slot to keep track of the time and determine when its selected slot is coming. Furthermore, messages 1803 in set 1801 may include a decreasing subslot number so that tags may know when a new block of answers 1800 (denoted in Fig. 18 as 1800-2) may be triggered, i.e., the AIoT devices are required to respond when the decreasing subslot number reaches a value, e.g., 0.

[0279] In a related embodiment that may be combined with other embodiments or used independently, it is to be considered that it may be advantageous if the number of frequency slots in set 1800 is such that it “fits” the number of subsequent subslots allocated in set 1801. In particular, in slotted aloha, occupancy of slots is optimal when the number of slots corresponds to the number of devices seeking access, and then around 37% of the frequency slots in set 1800 will be occupied. Thus, if X time subslots are allowed / allocated to set 1803, and there are L devices seeking access, set 1800 should have L / X frequency slots. In general, there may be a relationship between the number of timeslots, the number of frequency slots, and the number of subslots, and some of the parameters may be derived from each other. For instance, if the reader indicates the number of frequency slots and time (sub)slots, e.g., in Msg 0, the tag may determine the number X of subslots as a function of the number of frequency slots. This is advantageous to reduce the signalling overhead.

[0280] In a related embodiment that may be combined with other embodiments or used independently, the reader indicates the number of frequency slots and time (sub)slots, e.g., in a request message, e.g., Msg 0. The reader may do this in a request message, e.g., in the initial service request, and / or each paging message and / or each access opportunity message. The reader may inform, e.g., about the TDMA slots (how many slots are in a request burst), TDMA subslots (how many subslots are in a TDMA slot), TDMA subslot length, FDMA slots (how many frequency slots are in a TDMA (sub)slot), FDMA slot spacing. This configuration may also be done implicitly, e.g., by initial configuration of devices. In an example, it may set maxima or set defaults that can be modified using the explicit signalling. It an example, it may set maxima by device capabilities.

[0281] In a related embodiment that may be combined with other embodiments or used independently, the reader may learn and / or know device capabilities, e.g., of the devices in this area and / or that it is requested to communicate with. This may be done implicitly in some applications. In other applications, a device may signal its capabilities, perhaps on request (e.g., a field in R2D message requesting device capabilities), particularly where mixed devices are present. For example, making an inventory of medical equipment in a facility room - devices might come from different sources with different capabilities. Capabilities may be included, e.g., in Msg 1, e.g., in signal 503 in Fig. 5.

[0282] In a related embodiment that may be combined with other embodiments or used independently, the request message and / or messages from reader to device may be transmitted at a first frequency, the carrier wave from reader to device may be transmitted at a second frequency, devices (AIoT tags) may be adapted to monitor request messages and / or messages at the first frequency, and devices (AIoT tags) may be adapted to transmit / backscatter back using the carrier wave at the second frequency.

[0283] These capabilities and operation may be advantageous because, e.g.:

[0284] They allow the reader to distribute information (e.g., request messages slot number) while devices send replies in parallel.

[0285] Some devices (DI) may be FDMA capable and other devices (D2) may only be TDMA capable. Upon transmission of a first message, e.g., request message, e.g., MsgO, e.g., 502 in Fig. 5, the reader may receive in several subslots si, s2, s3,... (after request message) answers from devices D2 at the second frequency, and receive in the first subslot si, FDMA multiplexed, up to k answers from devices D 1 that backscatter back the carrier wave at the second frequency in up to k different frequencies, different from the first and second frequencies. The answers may be Msgl, e.g., Signal 503 in Fig. 5. Since the reader communicates with the devices at the first frequency, the reader may start answering back (e.g., with Msg2, e.g., signal 504 in Fig. 5) to the devices that successfully transmitted as soon as in subslot s2.

[0286] In a related embodiment that may be combined with other embodiments or used independently, number of access occasions required can be reduced by allowing subslots. In some cases, not all parameters need to be explicitly communicated, but some of them may be implicit. For instance, if the total number of occasions is k and there are tl time slots, and t2 subslots per time slot, the device may derive that there are fl = k / (tl*t2) frequency slots.

[0287] Section: R1 - asymmetrical usage of TDMA / FDMA in the downlink (Reader to Device (R2D)) and in the uplink (Device to Reader (D2R))

[0288] In some scenarios, the uplink may be able to use TDMA and FDMA, while the downlink may only be able to use TDMA. For instance, as already indicated above, some of the MA procedures may be less suitable, e.g., the most constraint devices may only be able to use TDMA while more power devices (e.g., class C) may be able to use FDMA and / or CDMA. When a device performs MA in the uplink (e.g., in message 503 / 905 upon reception of message 502 / 904), the reader may receive this MA message, and when replying in the downlink (e.g., message 504 / 906), the reader may then use only TDMA (e.g., for more resource constraint devices ) or TDMA and FDMA and CDMA (for more powerful devices) wherein the reader may pick up / select timeslots and / or frequencies and / or codes that are related the timeslots and / or frequencies and / or codes in the uplink. For instance, it may use the same frequency / code in the downlink as selected in the uplink or may indicate new resources. This is further elaborated according to the following embodiments.

[0289] In an embodiment that may be combined with other embodiments or used independently, a device (AIoT tag) may send Msgl / signal 503 as per Fig. 5 or signal 905 as per Fig. 9 including its random identifier. This Msg 1 may be transmitted in a random slot, and the random slot may be a combination of time and frequency. One or more devices may then send such a Msgl in the same time resources, but in different frequencies. The reader has to then send Msg2 / signal 504 as per Fig. 5 or signal 905 as per Fig. 9. The reader transmits Msg2 in the time domain only, replying to all devices. Reader should transmit the receive random identifiers from each of the receive Msg 1 including an identifier indicating the frequency in which it was transmitted. This allows reducing the probability of a random identifier collision. In other words, Msg2 may include:

[0290] Fl, IDI, F2,ID2;...;FN, IDN where Fi, IDi identify a given ambient loT device by the concatenation of Fi (frequency resources) and IDi (identifier). Multiple (Fi, IDi) are concatenated in Msg2.

[0291] In general, a combined second message (e.g., Msg2) transmitted by means of a first set of MA techniques (e.g., one or more of TDMA, FDMA, CDMA, OFDMA,...) replying to one or more first messages (e.g., Msgl) transmitted in a second set of MA techniques (e.g., one or more of TDMA, FDMA, CDMA, OFDMA,...) may include and identifier for each the first messages and an indication of the MA resources used for the transmission of each first message with said identifier.

[0292] In a related embodiment that may be combined with other embodiments or used independently, Msg2 may include:

[0293] F(F1, IDI), F(F2,ID2);...; F(FN, IDN)

[0294] In other words, instead of explicitly transmitting the pair Fi, IDi, where Fi refers to the MA resources used for the transmission of IDi in a first message, and IDi refers to the identifier transmitted in the first message, a function F() of Fi, IDi is used, e.g., F() may be the scrambling of IDi with Fi. A benefit of this embodiment is the more compact representation of Fi and IDi.

[0295] In a related embodiment that may be combined with other embodiments or used independently, Msg2 may include only the identities IDi in the received Msgl except in the case of an identity collision. In this case, both the identity IDi and Fi (MA resources used for the transmission of IDi in a first message) are transmitted. In an embodiment that may be combined with other embodiments or used independently, when the reader detects an identifier collision between two AIoT devices, the reader assigns a different ID to one of the devices. For instance, if ID1 and ID2 are equal, ID1 transmitted by a first AIoT device in frequency F 1 and ID2 transmitted by a second AIoT device in frequency F2, the reader may assign a different ID2’ to the second device in Msg2. The assignment may be done by including ID2’ in Msg2.

[0296] Fl, ID1; F2,ID2, ID2’;...;FN, IDN

[0297] In some scenarios, the number X of Msgl (e.g., signal 503 in Fig. 5) that may follow a request message may be determined or indicated by a request message. This means that a request message may be used to indicate multiple time and / or frequency slots. However, it is not clear how a reader should choose X. Thus, in an embodiment that may be combined with other embodiments or used independently, the value of X may be determined by the expected message sizes of Msgl, Msg2, Msg3 and Msg4 (i.e., signals 503, 504, 505, and 506 in Fig. 5) because X determines how many messages Msgl (or Msg2, or Msg3, or Msg4) may be transmitted one after another. In some applications, e.g., inventory, where only the device identities are collected, X may be larger, e.g., 4, while in other applications where commands are exchanges X may need to be smaller, e.g., 2, so that, e.g., 2 messages Msg4 can be transmitter one after another. This may be determined based on a configuration / policy in the reader that determines the value of X based on the expected / known message sizes, and X is common for all messages, Msgl, Msg2, Msg3, Msg4...).

[0298] In an embodiment that may be combined with other embodiments or used independently, the concatenation or combined transmission of Msg4 (i.e., signals 506 in Fig. 5) from reader to device may have a size that is greater than the concatenation or combined transmission of Msg2 (i.e., signals 504 in Fig. 5). Both Msg2 and Msg4 from reader to device may only be transmitted multiplexed in the time domain while messages Msgl and Msg3 may be transmitted multiplexed in time and frequency domains. This can mean that the concatenation and / or combined transmission of Msg4 may be too long, for an initially selected X value. To address this issue, one or more of the following techniques may be applied:

[0299] Multiple Msg4 may be transmitted one after another, each Msg4 addressing a different AioT device,

[0300] Msg4 may include the resource allocation for the data reception when the data to be received exceeds a threshold or a maximum transmission time, e.g., a contention free slot may be indicated.

[0301] A reader, e.g., MAC layer, may prioritize the transmission of certain Msg4s according to different criteria, such as message size, energy levels, etc. For instance, a reader may have received X Msg3 in time / frequency resources and the reader may need to transmit the corresponding responses of Msg4. Which Msg4 is transmited first or which sets of Msg4 are transmited together depends on the energy levels of the AIoT devices (as reported by them) or the message sizes, etc.

[0302] Section: R1 - Adjustable reply message reception window

[0303] In an embodiment that may be combined with other embodiments or used independently, a reader may configure the reply message reception window at an initial value wO, and keep track of the number of reply messages received from the tags for a predefined period of time (e.g. a certain number of request bursts configured by higher layer), where the reply message reception window is the time window a reader will listen to the reply message(s) from tags after sending a request message. Upon a condition, the reader may increase the reception time window of reply message(s) from tags by delta_w to wl, and keep track of the number of reply messages received from the tags for a predefined period of time, where the condition may be the absolute number of reply messages from tags is below a threshold value, or the utilization of the slots / subslots in a request burst is below a threshold value. The reader may continue the procedure iteratively until either a predefined maximum reply message reception time window value is reached or the number of responded tags exceeds a threshold value based on the estimated total number of tags.

[0304] In a variant of the embodiment, the initial reception time window of the reply message(s) from tags wO may be determined by a preconfigured value, or the channel estimation of interference level in the system, or a history reply message reception time window value with good response rate from the tags.

[0305] In a variant of the embodiment, the reader may decrease the reception time window of reply message(s) from tags by delta_w to w2, if the reader detects the collision rate of tags exceeds a threshold value, or the utilization of the slots / subslots in a request burst is above a threshold value.

[0306] Section: R1 - Transmit power ramped request messages I request bursts

[0307] In an embodiment that may be combined with other embodiments or used independently, a reader may start to transmit the request messages at an initial transmit power pO, and keep track of the number of reply messages received from the tags for a predefined period of time (e.g., a certain number of request bursts configured by the higher layer). Upon a condition, the reader may ramp up the transmit power of the request message by delta_p to pl, and keep track of the number of reply messages received from the tags for a predefined period of time, where the condition may be the absolute number of reply messages from tags is below a threshold value, or the utilization of the slots / subslots in a request burst is below a threshold value. The reader may continue the procedure iteratively until either the maximum transmit power allowed by the regulation for the request message is reached or the number of responded tags exceeds a threshold value based on the estimated total number of tags.

[0308] In a variant of the embodiment, the initial transmit power of the request message pO may be determined by a preconfigured value, or the channel estimation of interference level in the system, or a history transmit power value with good response rate from the tags.

[0309] In a variant of the embodiment, the reader may ramp down the transmit power of the request message by delta_p to p2, if the reader detects the collision rate of tags exceeds a threshold value, or the utilization of the slots / subslots in a request burst is above a threshold value.

[0310] In an embodiment that may be combined with other embodiments or used independently, a reader may send the control signalling to the carrier wave node to transmit the carrier wave at an initial power cw_p0, and keep track of the number of reply messages received from the tags for a predefined period of time. Upon a condition, the reader may send the control signalling to the carrier wave node to ramp up the transmit power of the carrier wave by delta_cw_p to cw_pl, and keep track of the number of reply messages received from the tags for a predefined period of time, where the condition may be the absolute number of reply messages from tags is below a threshold value, or the utilization of the slots / subslots in a request burst is below a threshold value. The reader may continue the procedure iteratively until either the maximum transmit power allowed by the regulation for the carrier wave is reached or the number of responded tags exceeds a threshold value based on the estimated total number of tags.

[0311] In a variant of the embodiment, the initial transmit power of the carrier wave cw_p0 may be determined by a preconfigured value, or the channel estimation of interference level in the system, or a history transmit power value with good response rate from the tags.

[0312] In a variant of the embodiment, the reader may ramp down the transmit power of the carrier wave by delta_cw_p to cw_p2, if the reader detects the collision rate of tags exceeds a threshold value, or the utilization of the slots / subslots in a request burst is above a threshold value.

[0313] Section: R1 - Data fragmentation / Data aggregation / Error correction In an embodiment that may be combined with other embodiments or used independently, a tag may transmit or backscatter a reply message that includes a flag indicating "more data". This flag may signal to the reader that the tag has additional data to transmit that could not fit in the current reply message. For example, the tag may have multiple readings from different sensors or a long history of readings that exceed the capacity of the reply message. When the reader receives this flag, the reader knows that it has to request again the same tag to further obtain its data. In this embodiment, the tag may also include a counter or identifier to identify the message reply, so that the reader can distinguish between different reply messages from the same tag and avoid duplication or confusion.

[0314] In an embodiment that may be combined with other embodiments or used independently, a reader may keep requesting a tag that has sent a reply message with a "more data" flag until the reader receives a reply message without this flag or a certain condition is met. The condition may be a timeout, i.e., the reader waits for a predetermined period of time after sending the last request, and if no reply is received, it stops requesting the tag. Alternatively, the condition may be a maximum number of requests, i.e., the reader sends a predefined number of requests to the tag, and if no reply is received, it stops requesting the tag. The reader may use the counter or identifier included in the reply messages to track the progress of the data transmission from the tag and avoid duplication or confusion. This embodiment may enable the reader to retrieve all the data from the tag efficiently and reliably.

[0315] In an embodiment that may be combined with other embodiments or used independently, a tag may transmit or backscatter a reply message that includes a flag indicating “insufficient energy to transmit or backscatter”. This flag may signal to the reader that the tag has data to transmit or reflect but the energy in the energy storage of the tag may not be sufficient to transmit or backscatter a complete reply message including all the data to transmit or reflect from the tag. For example, the tag may need extra time to harvest energy from ambient sources to fully charge the energy storage of the tag. In addition to the “insufficient energy to transmit or backscatter” flag in the reply message, the tag may further include the information of the expected time until tag may be (sufficiently charged and) ready to transmit or backscatter a complete reply message. When the reader receives this flag, the reader knows that it has to request again the same tag to further obtain its data in a future time. The flag may also refer to the amount of data to transmit so that the reader can allocate sufficient resources to transmit the data and / or power the tag. As an example of this embodiment, the tag may also include a counter or identifier to identify the message reply, so that the reader can distinguish between different reply messages from the same tag and avoid duplication or confusion.

[0316] In an embodiment that may be combined with other embodiments or used independently, a tag may transmit or backscatter a reply message that includes information or indication such as a flag indicating “a later time to request again”. This flag may signal to the reader that the tag has some operation to perform, such as collecting sensor data, executing an actuating command, charging energy storage, and reply data may be ready at a later time (the later time may possibly not be specified by the flag), and reader needs to request the data at the signalled later time. When the reader receives this information, the reader knows that it has to request again the same tag to further obtain its data at the signalled later time. The “later time” information may be a counter value, a timestamp, or the number of slots from the transmission of this reply message or a predetermined time. The information may also refer to the amount of data to transmit so that the reader can allocate sufficient resources to transmit the data and / or power the tag. The information may further include a field indicating the reason (such as sensor reading, command actuation, energy storage charging, etc.) to request read back at a later time again. As an example of this embodiment, the tag may also include a counter or identifier to identify the message reply, so that the reader can distinguish between different reply messages from the same tag and avoid duplication or confusion.

[0317] In an embodiment that may be combined with other embodiments or used independently, a tag may transmit or backscatter a reply message that includes scheduling assistance information which can be used by the reader in scheduling, such as channel state information, received request message signal strength, energy storage charging level, user data length, a preferred slot to transmit the user data by the tag etc.. When the reader receives this scheduling assistance information, the reader may use this information to adjust the parameters of transmitter, receiver or carrier wave generation characteristics. In an example of this embodiment, the reader may use this information to adjust the transmit power of the request message, or the transmit power of carrier wave, or the reception time window of reply messages from tags.

[0318] In an embodiment that may be combined with other embodiments or used independently, a tag may include a flag indicating whether the transmitted data belongs to a blob of data that is going to be fragmented. This flag may signal to the reader that the tag has a large amount of data to transmit that cannot fit in a single reply message. For example, the tag may have a sensed data that exceeds the capacity of the reply message. When the reader receives this flag, the reader knows that it has to request again the same tag to obtain the next fragment of the data. In this embodiment, the tag may also include a sequence number or identifier to identify the order of the fragments, so that the reader can reassemble them correctly and detect any missing or duplicated fragments. This embodiment may enable the reader to retrieve large blobs of data from the tag efficiently and reliably.

[0319] In an embodiment that may be combined with other embodiments or used independently, a reader may include an identifier or counter in its request message to identify the request. The tag may receive the request message and include the same identifier or counter in its reply message, so that the reader knows which request the tag is replying to. The tag may only reply to a request message that includes a suitable identifier or counter, e.g., the counter may be incremented by one after each fragment of a long message is transmitted, and the tag may only reply to a request message if the request message includes a counter that is one higher than the currently stored counter. This embodiment may enable the reader to avoid confusion or duplication when requesting data from multiple tags or requesting fragmented data from a single tag.

[0320] In an embodiment that may be combined with other embodiments or used independently, a reader may include an increasing counter or timestamp in its request message to indicate the freshness of the request. The tag may receive the request message and compare the counter or timestamp in the request message with a locally stored counter or timestamp. The tag may only reply to the request message if the difference between the counter or timestamp in the request message and the locally stored counter or timestamp exceeds a predetermined threshold. This embodiment may prevent the tag from sending (duplicated) data multiple times in response to repeated requests from the same or different readers. The tag may update its locally stored counter or timestamp after replying to a request message or after a certain period of time.

[0321] In an embodiment that may be combined with other embodiments or used independently, the reply from a tag may include a preamble similar to the one described in other embodiments for the request message transmitted by the reader. For instance, the reader may need the preamble to synchronize to the specific clock used by the tag.

[0322] In an embodiment that may be combined with other embodiments or used independently, the reply from a tag may include a postamble, i.e., a bit string used to indicate the end of the reply from the tag (or reply message). In some cases, the tag may be adapted to (1) determine the need of transmission of and (2) transmit the postamble when some conditions are met, e.g., the energy level is below a given threshold (e.g, 1%), the quality of the illuminating signal is dropping, etc. For instance, the tag may have determined that its occasion to reply to a request (burst) is in a given slot index. When its turn arrives (i.e., the slot arrives), the tag may start transmitting its reply message, and in the event that some conditions are met, the tag may transmit the postamble. In some cases, the transmitted postamble may also include / be an indication to communicate the event of an early postamble transmission and / or the cause.

[0323] In an embodiment that may be combined with other embodiments or used independently, a tag may be involved in a communication procedure to transmit some data, however, during the transmission, the energy budget goes below a given threshold. In this event, one or more or a combination of following steps may apply:

[0324] The tag may send an indication of the abrupt disruption of the communication, The tag (or reader) may send an indication of transmission by segmentation (is allowed), in this case, the tag may transmit a long message as shorter messages,

[0325] The tag may resume the communication of the rest of the data when energy is available,

[0326] The tag may not remove that data to be transmitted or mark data as communicated as long as the whole data message has not been transmitted and / or a confirmation message has been received,

[0327] The tag may resend the whole data when energy is available,

[0328] The reader may discard any data that is only partially received,

[0329] The reader may keep data that is partially received, by policy / configuration and / or an indication of abrupt disruption of the communication is received,

[0330] The reader may reassemble two segments of a message (whose transmission was disrupted due to lack of energy) once the complementary data / message segment is received,

[0331] The reader may have a policy determining when disrupted communication may be stored and when it may not be stored.

[0332] In general, it is described an apparatus wherein the transmitter is adapted to send the reply message by a. backscattering the reply message in a received illuminating signal, or b. transmitting the reply message, in the selected slot number.

[0333] This apparatus is further configured with a set of conditions for early postamble transmission during the sending of the reply message and wherein the apparatus is adapted to: check whether one or more of the conditions are met, and upon positive check, trigger the earlier transmission of a postamble before all the contents of the reply message are transmitted, wherein the transmitted postamble may indicate the event of an early postamble transmission and / or the cause thereof.

[0334] The reader, upon reception of a reply message with an indication of an early postamble transmission may adapt its transmission schedule and / or parameters in a suitable manner. For instance, the reader may perform one or more of the following actions: store the first partial tag reply till a second tag reply is received, and use the first partial tag reply and a second tag reply to obtain a final tag reply of better quality (e.g., by a soft combination of the received symbols), trigger a new request (burst) for the tag, adjust communication parameters (e.g., transmission direction, signal strength of the illuminating signal, etc) to increase the probability of correct reception.

[0335] In some situations, a first type of tags may have limited amount of resources to support certain hardware functionalities, e.g., interleaving or error correction (e.g., FEC) or CRC; however a second type of tags may have enough amount of resources for those functionalities, e.g., interleaving or error correction or CRC. This leads to different issues, for instance, first, the reply messages from the tags of the first type may be more prone to errors; second, a reader may need to process messages in a different way depending on the type of tag it is addressing. This leads to the following embodiments:

[0336] In an embodiment that may be combined with other embodiments or used independently, a tag of a first type that always delivers the same message content (e.g., its identifier) stores the identifier in a specific manner dependent on the functionalities that cannot be realized, e.g., interleaved manner and / or with error correction and / or CRC, so that this prestored information can be directly sent over the air without further processing. The receiver can then process the message transmitted by a tag of a first type using the functionalities that a tag of the first type cannot support, e.g., error correction and the deinterleaver, as it does with messages originated from tags of a second type. This embodiment may simplify the design and operation of the tags of the first type by avoiding the need to perform those unsupported functionalities (e.g., interleaving or error correction) on the fly, and may also improve the reliability and accuracy of the reception of their messages. This embodiment also allows for a more uniform processing of messages by the receiver / reader.

[0337] In an embodiment that may be combined with other embodiments or used independently, the tag may indicate its type in a header or a flag field of its reply message, so that the receiver can apply the appropriate processing techniques accordingly, e.g., when interleaving / error correction is only applied to a fraction of the reply message or it is not applied at all in the messages created by a tag of a first type but it is applied by a tag of a second type. Alternatively, the receiver may try to decode the reply message using both methods (e.g., with and without interleaving) and select the one that produces a valid output.

[0338] In an embodiment that may be combined with other embodiments or used independently, a tag of a first type that has limited resources for certain functionalities, e.g., interleaving or error correction or CRC, generates and / or stores the message in, e.g., two different forms: a first form without interleaving and error correction, and a second form with interleaving and error correction. The tag can send the message in either form depending on an indication from the reader or its context. For instance, the reader may initially try to receive the message in its first form, which is shorter and requires less processing by the tag. However, if the message is corrupted or unreadable, the reader may request the tag to resend the message in its second form, which is more reliable and robust against errors. The tag may only transmit or backscatter the message in its second form if it has enough energy to do so, or if it receives a specific command from the reader. In an embodiment that may be combined with other embodiments or used independently, a tag of a first type that implements certain hardware functionalities, e.g., interleaver and error correction, but only applies them when requested by the reader or dependent on its context, e.g., energy level. The tag may store the message in a raw form without any processing, and perform the processing on the fly only when needed. For instance, the reader may send a request burst with a flag indicating whether it expects the reply message to be interleaved and / or error corrected or not. The tag may check the flag and apply the corresponding processing before sending or backscattering the reply message. Alternatively, the tag may decide to apply the processing based on its own context, e.g., its energy level, channel quality, or distance from the reader. The tag may send the message in a more reliable form if it has enough energy or if it detects a poor channel condition or a large distance. The tag may indicate how the message is encoded. The reader may adapt its decoding method accordingly, e.g., based on the indication or by trying both methods (with and without processing) and selecting the one that produces a valid output. This embodiment may allow for a more flexible and efficient use of the tag resources, as well as a better adaptation to the communication environment.

[0339] A tag may adjust its communication parameters based on the quality of the channel. Tags may not have the capabilities to determine the channel quality based on traditional reference signals, thus, it is not clear how a tag may select communication parameters. In an embodiment that may be combined with other embodiments or used independently, the tag may estimate the channel quality based on one or more or a combination of the following metrics of the received request message:

[0340] - signal to noise ratio,

[0341] - (number of) detected errors,

[0342] - bit error rate in a well-known sequence in the request message (e.g., preamble),

[0343] Based on the estimated channel quality, the tag may select the most suitable communication parameters for its subsequent reply message. For instance, if the tag detected no errors in the request message, the tag may choose to send the reply message without any error correction or CRC (so that its transmission requires less energy) while if the tag detected many errors, the tag may apply error correction or CRC to increase the reliability of its reply message (at the cost of energy). The tag may also adjust other parameters such as modulation scheme, repetition rate, or interleaving depth based on the channel quality. The tag may indicate how the reply message is encoded in a header or a preamble, so that the reader can decode it correctly. Alternatively, the reader may try different decoding methods and select the one that produces a valid output. This embodiment may allow the tag to optimize its energy consumption and improve its performance depending on the channel conditions.

[0344] Section: R1 - counter encoding and update

[0345] An AIoT device may keep a counter, and the counter may be used in a protocol, e.g., a security protocol as in other embodiments. However, updating a b bit counter may require updating b bits and this may be a too energy consuming operation, e.g., when updating the counter value in nonvolatile memory (NVM). To overcome this issue, in an embodiment that may be combined with other embodiments or used independently the counter may be transmitted in Gray format and / or stored in Gray format in NVM so that a single bit needs to be updated. When the Gray encoded counter is used for replay protection, the tag may be adapted to check that the currently stored counter by the tag plus 1, 2,... up to a K equals the received Gray encoded code. The value K may be at least 1. When the counter value is received in binary, the tag may be adapted to convert the counter into Gray code and store the Gray encoded value. To save resources, the counter value may be transmitted in Gray format. Although transforming between a normal encoding and gray encoding is a relatively simple transformation, transferring the number in gray format may reduce resource requirements.

[0346] Section: R2 - MAIN Application in a random-access procedure

[0347] Fig. 5 describes a procedure for accessing the information of a multiplicity of tags 501 by reader 500 based on some of previous embodiments. In a case, message 502 can represent or serve as a synchronization signal / paging message / scheduling message that may be used to get the tags synchronized or initiate the random access procedure. This signal may be transmitted on demand, e.g., when an application or the core network requires performing an inventory request of an application or determining the presence of a tag. This signal may be broadcasted in a broadcast channel, and / or a channel for control signalling / user traffic from reader to the tag, e.g. PRDCH (Physical R2D (Reader to Device) Channel). This signal may be a preamble as part of or as the request message described in previous embodiments. This message may contain an identifier such as a service identifier identifying the inventory that is requested or the tag that is being requested, or a command that is requested for a tag to execute. Upon reception of this signal 502, and if the signal is acceptable by tag 501, the tag may actively reply or backscatter signal 503. Since multiple tags may reply, tags may perform a multiple -access and / or random access procedure in signal 503, e.g., as described in embodiments in this invention. Signal 502 may be a request burst if tags do need to be provisioned with an external timing source for a time-division multiple access, or may include a single request message followed by an illuminating signal or lack of it (element 201 in Fig. 2). Over this illuminating signal or lack of it, multiple tags may perform multiple access, based on slotted Aloha as in other embodiments. Signal 503 may include a preamble as described in previous embodiments including a preamble or random identifier, etc. Signal 504 may be used to acknowledge signal 503, and this is done, e.g., by including, e.g., the random identifier used in previous step to acknowledge which tag wins the contention of random access. In a subsequent step 505, the tag can reply with its own identifier (e.g., EPC as in RFID). Finally, in step 506, the reader confirms. In an embodiment that may be combined with other embodiments or used independently, upon reception of the request message MsgO (signal 502 in Fig. 5), one or more tags 501 may determine a one-shot reply is expected by the reader 500 and may backscatter or transmit the reply message(s) Msgl (signal 503 in Fig. 5). Then the reader 500 may send a request message Msg2 (signal 504 in Fig. 5) to confirm the successful reception of reply message(s) Msgl from one or more tags, and the procedure ends for the tags 501 whose one-shot reply has been successfully acknowledged by the reader 500. This relates to messages 904, 907, and 909 in Fig. 9b.

[0348] In a variant of the embodiment, the reader 500 may start a timer when it starts to listen to reply message(s) Msgl from one or more tags, and if a reply message Msgl is received before the timer expires, the reader may stop the timer and transmit a new request message Msg2 to confirm the successful reception of Msgl; in other case, if a reply message Msgl is not received until the timer expires, the reader may transmit a new request message MsgO to start a new round.

[0349] In an embodiment that may be combined with other embodiments or used independently, upon reception of the request message MsgO (signal 502 in Fig. 5), one or more tags 501 may determine multiple messages may need to be exchanged with the reader 500 and may backscatter or transmit the reply message(s) Msgl (signal 503 in Fig. 5) to initiate the contention based random access procedure, and the Msgl may include the device identifier of the tag 501, or a random identifier, and / or the first part of the data traffic. Upon reception of one or more reply message(s) Msgl from the tag(s) 501, the reader 500 may determine and select one tag as the winner of the contention by some criteria such as the QoS class of the service, identifier of the tag, receiving signal strength etc., and send request message Msg2 (signal 504 in Fig. 5) to indicate the tag which wins the contention for random access and a temporary session identifier assigned by the reader 500 to the winning tag. Upon reception of Msg2, the winning tag may use the allocated session identifier to send the reply message Msg3 (signal 505 in Fig. 5) which confirms the successful reception of Msg2 and includes the data traffic from the tag. In the following communication with the winning tag, the session identifier may be used to do the contention free message exchange between the reader and the winning tag until the reader completes the session with the winning tag. Note that signal 504 may be a request message including information acknowledging the reception status of the reply messages from tags (i.e., signal 503). For instance, it may be a field including the random identifier sent by the tag in signal 503.

[0350] Finally, in step 506, the reader may acknowledge success or indicate failure. In the former case, the device needs to take no further part in the process. In the latter case, or if neither message is received, the device may make another attempt in the subsequent Aloha round. In an embodiment, step 506 can be merged with step 502 of the next Aloha slot; that is, the request message announcing a new slot may also carry an acknowledgment field for the previous slot's step 505. In some cases, this acknowledgment may be explicit (e.g., a flag in the request message announcing the next message). In some cases, this acknowledgment may be implicit to the reception of a subsequent request message. In some cases, the request message may indicate (explicitly or implicitly) a failed reception showing that the previous message was not received. The AIoT device may interpret the reception of the next request message as an acknowledgment when the request message is received within a time window (e.g., from the transmission of the last message or from the beginning of the slot) since this indicates to the AIoT device that the reader has already received the previous message and thus is sending the next request message to start the next slot). The AIoT device may interpret the reception of the next request message as an non-acknowledgment when the request message is received once a time window has expired (e.g., from the transmission of the last message or from the beginning of the slot) since this indicates to the AIoT device that the reader was waiting for the previous message and is sending the next request message to start the next slot once a timer (of the duration of the time window) has expired.

[0351] Section: R2- contents of Msg2 (signal 504 in Fig. 5)

[0352] In the following, some of the contents of Msg2 are detailed as illustrated in different embodiments of this invention, in particular, it may contain one or more of: a disambiguation field for intra-access opportunity collision handling: When more than one device responding in the same slot / access opportunity on different subslots choose the same random ID for Msgl (signal 503 in Fig. 5), the disambiguation field may carry the FDMA or TDMA subslot index used by the device for which this Msg2 is targeted.

[0353] - a Random ID - an AS ID type field, e.g., (1) None: No AS ID is assigned - device can forget Random ID after the access opportunity ends; (2) random ID: Device should use Random ID as AS ID; and (3) AS ID: Device should use AS ID assigned by Reader (used to resolve inter- and intra-access opportunity collisions)

[0354] - AS ID persistence field, (1) device retains AS ID for duration of service request and deletes it thereafter or (2) semi-permanent: device retains AS ID across service requests

[0355] - AS ID, if the reader assigns AS ID, this field is present.

[0356] Section: R2 - ID size in contention-based random access

[0357] A Reader, wanting to address a plurality of tags may send a group address and operate a random access procedure based on slotted aloha as described elsewhere in this disclosure. Tags are informed of the number of slots available and select one at random to contend for access to the Reader. In an optimal arrangement, the Reader may arrange for a slotted aloha round containing approximately as many slots as there are tags addressed by the group address (bearing in mind that the number of tags may be less than the number of tag addresses available within the group address). This arrangement theoretically minimises the number of slots contended for by more than one tag and the number of slots contented for by no tags and resulting in a proportion of approximately 1 / e (-0.36) slots contended for by one tag exactly. In general, if there are M tags and N slots, each slot may be contended by M / N devices.

[0358] In a typical arrangement, a tag contending for a slot sends a first message (‘Msg 1 ’) comprising a first identifier that may be chosen at random by the tag. This message may be 503 in Fig. 5. If the reader receives Msgl, it sends a second message (‘Msg2’) comprising at least a copy of the first identifier to inform the tag that it has been successful. This message may be 504 in Fig. 5. Further dialogue can take place according to the application requirements. If two or more tags contend for the same slot, Msg2 from the reader will confirm which, if any, tag ‘won’ the slot. (In certain arrangements, it may be possible for more than one tag to succeed but this has no impact on the present discussion). Messages 503 may be sent in a subsequent round or after the slotted aloha procedure finishes. However, in this case, since tags are choosing identifiers at random, the length of the identifier must be sufficient to avoid a significant chance that two or more tags choose the same identifier. A common proposal for length is 16 bits, giving 65536 possible identifiers. However, to keep the probability of collision below 1%, only 37 tags can be trusted to generate a random identifier per round. To support more tags, one must use a longer identifier or accept a higher collision rate. Both options are problematic for a resource-constrained system. A way round this is to note that, in slotted aloha, only a small number of tags contend for each slot. Thus, instead of transmitting Msg2 / 504 after the slotted Aloha procedure finishes, the ID assignment by means of Msg2 / 504 should be performed within the same slot. Assuming an optimal arrangement in Slotted Aloha, as described earlier, it can be shown that there is a less than 1% chance that five or more tags will contend for the same slot. Thus, to a good approximation, when the ID assignment is done within the slot, we only need to consider up to four tags when determining the probability of identifier collision. This allows the first identifier to be significantly shorter in the context of the slot, saving bandwidth and making the logic of the tags simpler, and thus, cheaper. It can further be shown that, in the 99% of cases in which up to four tags may contend for the same slot, even a four-bit identifier allows a less than 1% probability of identifier collision within the slot. Once a tag has gained access, the Reader can grant it a unique temporary address within the context of the group address by means of Msg2 / 504 that as indicated below is sent within the same slot. Using this insight, we can modify the contention procedure to use the shorter addresses. In the following example, we assume a group size of 256:

[0359] Tag sends Msgl containing a four-bit random slot-based identifier.

[0360] Reader sends Msg2 comprising the 4-bit random slot-based identifier and an assigned temporary 8-bit group-based identifier.

[0361] Reader and Tag communicate using the 8-bit temporary group-based identifier.

[0362] The group-based identifier has a length commensurate with the number tags known to be members of the group or the maximum number of addresses within the group. It can be chosen by the Reader according to any process that ensures that each tag gets a unique address.

[0363] In general, it is described an apparatus for communicating by means of a low power device, such as a tag, the apparatus comprising a receiver configured for receiving a request message in a request burst, wherein the request message includes an indication of a number of slots in the request burst, a controller coupled to the receiver configured to determine an apparatus identifier or a random number, the controller being arranged to select a transmission slot number to deliver a reply message within the request burst, wherein the transmission slot number is selected on the basis of at least the number of slots and on the random number or the apparatus identifier; a transmitter coupled to the controller to transmit the reply message after the end of the request message in the slot corresponding to the selected transmission slot number.

[0364] Furthermore, the apparatus may include in the reply message an identifier wherein the identifier may be a first ID for contention-based random access. Furthermore, the previous apparatus may be adapted to receive within the transmission slot a second message including the first ID and a second ID allocated for subsequent communication.

[0365] Furthermore, the previous apparatus may be adapted to use a first ID size that depends on the number of devices contending for the slot and / or receive an indication of the first ID size in the request message.

[0366] An apparatus for multiple access adapted to:

[0367] - select a number of slots nO for a request burst,

[0368] - transmit a first request burst comprising nO slots, each slot including a request message.

[0369] An apparatus for multiple access adapted to monitor for the reception of one or more reply messages from one or more low power device such as a tag in time / frequency resources subsequent to the request message in each of the slots.

[0370] An apparatus as above adapted to select a first ID size, and send an indication of the first ID size in the request message.

[0371] An apparatus as above adapted to select a first ID size based on the number of devices expected to contend for a single slot and the required collision probability within a slot.

[0372] Section: R2 - Dealing with collisions in the chosen random ID

[0373] In the above procedures, Msg 1 may include a random identifier. The reader may reply with the same random identifier in the subsequent Msg2. A problem may arise if two AIoT devices reply in the same slot and pick up the same random identifier. In this case, they may consider that they are correctly inventoried, when they are not.

[0374] To address this concern, in an embodiment that may be combined with other embodiments or used independently, the generation of the random identifier may be guided by the reader, e.g., using some helper data that may be included in the request message or paging message. The reader may know which devices inventoried, and the reader may know some information about the AIoT devices, e.g., an identifier. The reader may then send such helper data HD to the AIoT devices, and the AIoT devices may use said HD to obtain the random ID by applying a given function F() that may take as input HD or a parameter dependent of HD and / or other parameters specific to the AIoT devices. Function F() may be proprietary or may be standardized. F() may also be indicated by means of HD. Examples of F() may include:

[0375] Device lD XOR HASH(K_HD, nonce), i.e., the AIoT device identifier or part of it (Device lD) is xored with the output of a hash function (in general, cryptographic function) that takes as input a key identified by HD or derived by means of HD and a nonce, the reader, upon reception of the random identifier has to undo the operation, Device lD MASK HD where HD acts as a bit mask that selects a subset of the bits of the AIoT device identifier (Device lD). The HD bit mask is chosen by the reader in such a way that all returned random identifiers are unique,

[0376] LSB(16, Hash(Device_ID, nonce), i.e, the random identifier is obtained as the 16 least significant bits (LSB) of the output of the Hash function taking as input the AIoT device identifier (Device lD) concatenated with HD. HD may be a nonce selected in such a way that the output of the function for all AIoT devices that need to be inventoried is different.

[0377] In an embodiment that may be combined with other embodiments or used independently, AIoT devices may generate the random identifier at random and transmit it in Msgl (signal 503 in Fig. 5). When two or more AIoT devices select the same random identifier, they will obtain the same random identifier back from the reader in Msg2 (signal 504 in Fig. 5). This will trigger the transmission of a device specific Msg3 (signal 505 in Fig. 5) by the two or more devices, e.g., this Msg3 may contain a device specific identifier and / or may contain some device specific data and / or may include some fields that are protected with a device specific key. Reader may then reply / acknowledge the reception of Msg3 in Msg4 and include in the acknowledgement message Msg4 some of the device specific data, e.g., part of the device identifier or a fingerprint (e.g., hash function) of the device specific data. This information in Msg4 (signal 506 in Fig. 5) can be used by each of the AIoT devices to determine whether their own transmission of Msg3 was successful or not. Next to this field serving the purpose of acknowledging Msg3, Msg4 may include other fields such as an identifier used for subsequent message scheduling.

[0378] In an embodiment that may be combined with other embodiments or used independently, the lifetime of Random ID can be limited. For instance, it can be limited to a slot, e.g., access opportunity. For instance, a device is told / configured to discard Random ID when it has completed its actions or when new access opportunity has started. For instance, a device may do this as the default action. For example, the reader may provide the device with AS ID if it, say, offers CFRA or requires device to re-access. For instance, the device may use AS ID (with a flag to indicate AS ID, not Random ID) during next CBRA or assigned CFRA.

[0379] In a related embodiment that may be combined with other embodiments or used independently, the random ID can be used in place of AS ID (e.g., if not many devices). For instance, a device is told to retain Random ID or treat it as AS ID. For instance, a reader can simply assign AS ID as the Random ID sent by the device in Msg 1 (thus no special procedure in device), in this case, this may be indicated by a flag. In an example, the lifetime of AS ID could be limited to access round or service request, or could be made persistent (i.e., stored in NV RAM) of multiple access rounds.

[0380] In an embodiment that may be combined with other embodiments or used independently, a common procedure unifying CBRA and CFRA may use assigned slot ID (including subslot) instead of random choice. Furthermore, it may use AS ID in place of Random ID in msgl (signal 503 in Fig. 5).

[0381] In an embodiment that may be combined with other embodiments or used independently, Msgl (signal 503 in Fig. 5) may include a flag indicating whether the ID it carries is a random ID or a previously assigned AS ID. This may be an independent flag, or it may be achieved by splitting the ID range into a first range for random IDs and a second range for allocated AS IDs.

[0382] Section: R2- Selection of 2-step vs 3-step contention-based random access (CBRA)

[0383] In some scenarios, it is preferable to define a unified random-access procedure for Ambient loT (AIoT) devices. In AIoT, contention-based random access may be a 2-step CBRA process or a CBRA 3-step process. The difference between 2-step and 3-step is that in the 2-step procedure, the device sends Random ID, Device ID and any data in msgl (equivalent to signal 503 in Fig. 5) and the reader responds (if it feels like it) with Msg2 (signal 504 in Fig. 5) containing at least the Random ID. Meanwhile, in the 3-step procedure, Msgl only carries the Random ID, with Device ID and data following in Msg3 (signal 505 in Fig. 5) if Msg2 is received successfully. In a unified approach, it is a challenge determining and orchestrating when one of the CBRA processes is applied.

[0384] Some proposals indicate that the decision between 2-step RA and 3-step RA is up to the reader. Other proposals propose to study reader-based and device-based criteria for selection between 2-step vs 3-step AIoT access procedure. Such proposals may require that all devices support both 2- step and 3-step procedures and can select between them on at least a per-page basis. This seems unwise, given the likely different capabilities of AIoT devices. Additionally, a device may be preconfigured for one or other; the reader might be unaware so can only state a preference but must be able to handle whatever response comes from the device. This is to avoid the situation where a reader requests, say, 3-step but the device is only capable of responding with 2-step.

[0385] Thus, the following embodiments may be applied to address these problems:

[0386] In an embodiment that may be combined with other embodiments or used independently, the reader may indicate a preference of a given CBRA method, e.g., 2-step or 3-step) in a request message, e.g., paging message. The preference may be based on its capabilities, a configuration received from the core network or AF indicating the type of CBRA method to use, the expected energy levels of the AIoT devices, etc. The AIoT device / tag may then reply according to its capabilities and / or context. For instance, if the AIoT device / tag is only capable of a 2-step CBRA method, the device sends msgl with dev ID and data. For instance, if the AIoT device / tag is only capable of a 3-step CBRA method, the device sends msgl without devID or data (i.e., fallback to 3step); reader sends msg2, inviting msg3; device sends msg3. In other words, the reader expresses a preference and the device either follows the reader, if it is capable of doing so, or uses whatever procedure is available to it.

[0387] In some cases, the reader may indicate a preference unless the reader knows that a device only supports one CBRA approach.

[0388] In some cases, the indication may be explicit (e.g., via a flag); in other cases the indication may be implicit (e.g., reader transmits Msg2 in 3-step CBRA).

[0389] In some cases, the AIoT device may indicate in Msg 1 whether it prefers a confirmation of its random ID in a message Msg2 (3-step CBRA) or not (2-step CBRA).

[0390] In some cases, the AIoT device may be capable of both the 2-step CBRA and 3-step CBRA and the AIoT device may follow the indication of the reader, unless some contextual situation prevents it from using the preferred CBRA method. For instance, the AIoT device may be short of energy, and thus, it may use 2 step procedure instead of a 3-step procedure. For instance, the data transmission may be too long, so that instead of using the 2 step procedure, the 3-step procedure is selected. This contextual situation may be used together with a configuration / policy / implementation of the AIoT device to determine which CBRA procedure is selected.

[0391] In some cases, the reader may not only indicate which CBRA procedure is preferred, but also the configuration / policy (or an indication thereof) to control the selection, e.g., energy levels to select a given CBRA procedure, or maximum message size to select a given CBRA procedure.

[0392] Section: R2 / R1 - Multiplexing answers of multiple tags in a random access procedure

[0393] In the above procedure, the reader may only transmit three times (signal 502, 504, and 506) if there is a single tag and the single tag replies directly to the transmitted signal 502, 504, and 506. However, there may be multiple tags and not all tags may receive, e.g., the first signal 502 correctly. Thus, there is a need of multiplexing signals 502, 504, and 506 and allowing the reader to process answers of the tags that are at different stages in the procedure, e.g., a random access procedure, e.g., a first tag may have already received signal 502 and replied with signal 503 while another tag may have not received signal 502 yet. To address this need, the following embodiments may be applicable:

[0394] In an embodiment that may be combined with other embodiments or used independently, a request message includes fields that may belong to signals 502, 504, 506 respectively. This allows addressing multiple tags in a single procedure even if tags are at different stages of the procedure in Fig. 5.

[0395] In a particular case, there may be four tags Tagl, Tag2, Tag3, and Tag4 and the actual procedure may be as illustrated as follows where MsgO, Msgl, Msg2, Msg3, Msg4, Msg5 refer to signals 502, 503, 504, 505, and 506 in Fig. 5.

[0396] At time to, the reader sends the initial message MsgO. At time t1 , tags Tag1 and Tag2 reply with two messages Msg1 and Msg2. In this case, both devices manage to perform multiple access procedure in a successful manner. At time t2, since the reader still wants to check the presence of Tag3 and Tag4, it sends again (fields of) MsgO, but also (fields of) Msg2 forTagl and Tag2. In the subsequent reply at time t3, at least two tags are expected to reply, namely Tag1 and Tag2, i.e., the Tags that already engaged in the previous MsgO, with Msg3. Furthermore, in this specific example, Tag3 replies with Msg1 . At time t4, reader replies again with a message that comprises Msg4 (forTagl and Tag2) and Msg2 forTag3 and MsgO to try to obtain an answerfrom Tag4, and so on. To realize this example, the following procedures may be applied.

[0397] In an embodiment that may be combined with other embodiments or used independently, when a Tag has replied using signal 503 as in Fig. 5, the Tag may include the amount of resources required in a subsequent message (e.g., how many bits are to be exchanged in signal 505) so that the reader can allocate resources (e.g., time) to transmit that information in that message.

[0398] It is to be noted that the above message flow does not take into account what may happen if some messages are missed, e.g., when at tl Msgl(Tagl) is lost. Thus, above message flow can be enhanced by means of other embodiments in this invention related to message retransmission.

[0399] In a related embodiment that may be combined with other embodiments or used independently, the procedure (e.g., a random access procedure, e.g., as in Fig. 5) of multiple tags may be multiplexed over multiple rounds of request bursts (related to Fig. 4), and in particular, some slots in each request burst may be used for contention (e.g., to receive response signal 503 in Fig. 5) and some slots in each request burst may be used for the exchange of allocated information (e.g., to receive response signal 505 in Fig. 5). In a particular case, the first request burst may include all slots for contention while the second request burst may include some slots for contention and some slots may be allocated for the transmission of scheduled data / messages. Which slots are used for the transmission of scheduled data / messages may be indicated implicitly or explicitly, e.g., if there is an indication that the second request burst has N 1 slots, and it includes signals 504 for two tags, the first two slots of the second request burst may be reserved / allocated for those two tags, while the remaining N 1-2 slots may be reserved for contention.

[0400] In an embodiment that may be combined with other embodiments or used independently, a request burst may include n contention-based slots that may be used to receive signal 503 from m tags (between 0 and n tags). Prior to the initialization of a subsequent request burst round, the reader may keep allocating contention-free slots to the m tags that managed to access in the contention-based slots. For instance, if n=3 and tag 1 and tag 2 manage to send their signals 503 in the contention-based slots, the reader may allocate subsequent contention-free slots by sending subsequent request messages including the identity of the tags (e.g., the random number indicated in signal 503). This allows then the reader / tag to exchange all messages / signals included in Fig. 5 within the contention free slots of the same request burst. Another advantage is that if some of the tags takes longer to reply, also in interactions with an AF or CN, the reader that swap the order of the communication allowing for a better performance. Fig. 16 depicts a possible instantiation of this embodiment in which the reader seeks four tags, Tagl, Tag2, Tag3, and Tag4. Three request bursts may be performed to retrieve them. The first request burst includes 3 contention based slots, each of them starting with a request message identified by R (and as in other embodiments). Fig. 16 shows that two tags, Tagl and Tag2 reply (e.g., with signal 503 as per Fig. 5). Then the reader allocates contention-free slots sending request messages R including the identity of the tag that it desires to address (e.g., R (Tagl) indicates a request for Tagl). After each of such a request, the addressed tag may reply with, e.g., signal 505 as per Fig. 5. Once a request burst is finished, including the contention free slots, a new request burst may start to interact with the remaining tags. In Fig. 16, in the second request burst there are two contention-based slots that are used by Tag3 to reply and exchange signals 503 and 505. In a last request burst, Tag4 manages to access and exchange data with the reader.

[0401] In general, it is described a method for multiple access adapted to:

[0402] - select, by a reader, a number of slots nO for a first request burst,

[0403] - transmit, by the reader, a first request burst comprising nO slots, each slot may include a request message or part of it to indicate the start of the slot, wherein one or more of the following conditions may apply:

[0404] - condition 1: receive, by the reader, a contention message from a first tag in one slot in the first request burst, determine the need to transmit a further request burst and select the number of slots nl of the further request burst, transmit the further request burst with nl slots wherein one slot is allocated for a communication procedure with the first tag in the further request burst. condition 2:

[0405] Indicate, by the reader, implicitly or explicitly, the slot allocated to the first tag in the further request burst. condition 3 :

[0406] Wherein nO slots are contention-based slots and are followed by nO 1 contention-free slots wherein at least one tag is allocated a contention free slot upon successful communication in a contention-based slot. condition 4: wherein the number of nO slots refers to contention-based slots determined at the beginning of the request burst round, while the number of nO 1 contention-free slots is adaptable based on the number of tags replying. condition 5 :

[0407] Allocating, by the reader, at least one contention-free slot in a request burst to a tag that successfully communicated in a contention-based slot in the request burst to finish a communication procedure with the tag in the single request burst.

[0408] In an embodiment that may be combined with other embodiments or used independently, when a reader receives multiple signals 503 as in Fig. 5 from multiple Tags, the reader may reply in subsequent signal 504 as in Fig. 5 including all received random identities of multiple Tags. The order of random identities of multiple tags in such signal 504 implicitly indicates the resources allocated to the tags to reply in the subsequent message 505. For instance, in above procedure, at time t2, Msg2 includes first Tagl and then Tag2, this can indicate that in Msg3 at time t3, the first slot or subslot (as per above embodiments) is reserved for Tag 1 and the second slot or subslot (as per above embodiments) is reserved for Tag2. Subsequent time resources would be for Tag3 and / or Tag4 to perform access, e.g., as per above embodiments. If other multiple access procedure is used, e.g., frequency based, frequency carriers for Tag 1 and Tag 2 may also be reserved in a similar manner.

[0409] In a related embodiment that may be combined with other embodiments or used independently, two tags may reply with Msgl at a given time, e.g., Tag 1 and Tag 2 at tl. Each Msgl message may include a random identifier. However, the tags may select the same resources, e.g., the same time slot, in the reply of the answers Msg 1. Thus, only one of the Msg 1 messages may be properly received by the reader, e.g., only Msgl(Tagl). The reader may then reply with Msg2 for this tag, e.g., Msg2(Tagl) giving an indication of the resources (e.g., time slot / subslot, or carrier frequency, etc.) to use in the transmission of a subsequent message Msg3 so that it can be transmitted without collisions. This procedure is featured by the direct allocation of resources for the subsequent message Msg3 so that it makes unnecessary the allocation of a local identifier (e.g., between reader and tag) for the subsequent transmission.

[0410] In a related embodiment that may be combined with other embodiments or used independently, the initial message MsgO (signal 502 in Fig. 5) may include an indication on the identifier size to be included in the subsequent message Msgl (signal 503 in Fig. 5). This allows the reader to control the identifier space of the identifiers selected and included in Msg 1. For example, if a reader is close to a single tag, the reader may request in MsgO an identifier bit length of 0 bits, i.e., no identifier, because no contention is required. However, if the reader is close to tens of tags, the reader may request in MsgO an identifier bit length of 8 bits. This indication may be explicit (by indicating the number of bits) or based on a codebook. In a related embodiment that may be combined with other embodiments or used independently, the number of bits of the identifier exchange in Msgl and the number slots of the request burst may be signaled jointly. This is because if a single tag needs to be queried, then a single slot and no identifier is required, but if tens of tags need to be queried, then many slots are needed together with a larger identifier space. For instance, if two bits are available, the two bits may indicate the following joint parameters:

[0411] In a related embodiment that may be combined with other embodiments or used independently, the identifier returned in Msg2 (signal 504 in Fig. 5) by the reader upon reception of Msgl (signal 503 in Fig. 5) from a tag corresponds to the concatenation of an identifier indicating the resources (e.g., time slot number) used by the tag in Msgl (signal 503 in Fig. 5) and the identifier included in Msg 1 itself. This allows the reader to name / identify differently two tags that picked up the same identifier value in Msgl (signal 503 in Fig. 5) but used different communication resources to differentiate themselves.

[0412] In an embodiment that may be combined with other embodiments or used independently, a request message sent by a reader may include a field requesting an indication on the energy level of the tag. Additionally, or alternatively, an answer from a tag may include one or more fields indicating the current energy level (e.g., low, medium, high) and / or status (charging or not) and / or an estimate of the amount of data that may be transmitted. A reader may then use the energy level information from the answer fields to prioritize and / or schedule the communication with certain tags, e.g., those tags whose energy level is suitable. In an embodiment that may be combined with other embodiments or used independently, the frame structure for the downlink (reader to tags) may be similar to the one in Fig. 2 where the request message may comprise the fields required for signals 502, 504, and / or 506. The reply signals 503 and 505 may be transmitted or backscattered performing multiple access or reserved access in the subsequent illuminating signal (or lack of it) according to previous embodiments.

[0413] In an embodiment that may be combined with other embodiments or used independently, signal 502 that may correspond to a request message and may include a preamble may trigger the reply of many tags, thus, it is important to include information in this signal to limit / filter which tags are triggered by signal 502. This may include as described in other embodiments a service ID, a network ID, and application ID, or a device ID. In a first case: if signal 502 includes a tag ID (e.g., in the preamble as shown in Fig. 6), only the tag with that tag ID may reply to such a signal 502. Since it was addressed by its tag ID, the device may skip message 503 and reply directly with message 505. In a second case: if signal 502 includes a group identifier such as a service ID, network ID, application ID, group ID, etc, then multiple tags may reply and the messages in Fig. 5 would be required. It is to be noted that the first case leads to a protocol between reader and tag while the second case leads to a protocol in which the reader is collecting the replies from (many) tags. It is to be noted that in this second case, signal 502 resembles to some extent a synchronization signal such as SSB or paging message or scheduling message but with the focus on ambient loT devices. That synchronization signal / paging message / scheduling message triggers a random-access procedure similar to a 4-message random access procedure or a 2-step random access procedure.

[0414] In an embodiment that may be combined with other embodiments or used independently, each tag has a hard-coded ID or address of, say, 48-64 bits or 12-16 hex digits. This ensures that every can have a unique address. As with IPv6 addressing, it would also enable addresses of different types, e.g., representing tag capabilities or applications or with, e.g., company-owned prefixes or, for secure applications, a cryptographically-random address field.

[0415] In an embodiment that may be combined with other embodiments or used independently, a reader may assign a tag with an ID or address to use in place of its hard-coded address or instruct the tag to generate its own address. Alternatively, a tag may be given an instruction like, “Use this header followed by the last n digits of your hard-coded address’ - useful when assigning addresses to multiple tags. Assigned addresses can be much shorter when only local uniqueness is required, or addresses might comprise a common header and a locally-unique tail - use the tail for general communications after discovery.

[0416] In an embodiment that may be combined with other embodiments or used independently, it should be possible to address (a group of) tags using a wildcard mechanism. For example, one of the hex numerals, e.g., OxF, may be assigned to a wild card meaning ‘any digit’. This wild card shall not be part of a device’s address but may be used by a reader to address a group of devices. For example, ‘0x42FF’ addresses all devices with an address beginning ‘0x42xx’, ‘0xFFF5’ addresses all devices with an address that ends in ‘0xxx5’, and so on. In this way, a reader might address, ‘all tags from supplier x’, or, ‘all tags created / assigned within the last week’, or, ‘all sensors in room 42’. An alternative mechanism might be to have a bit mask indicating the digits to be ‘wildcarded’ where the bit mask may be transmitted in the request message.

[0417] In an embodiment that may be combined with other embodiments or used independently, it should be possible to include a ‘response probability’ field in the message from the reader, e.g., signal 502. When faced with a thousand tags of, as yet, unknown addresses, it would be good to limit the number of responses to a broadcast / groupcast message, e.g., discovery. The probability field asks the tag to generate a random number and only respond if the number falls below the threshold set by the ‘response probability’ field. This could also be combined with the wildcarding. The reader may adjust this parameter depending on how many replies or collisions it observes as described in other embodiments.

[0418] In a related embodiment that may be combined with other embodiments or used independently, different tag types are assigned to different QoS classes and each QoS class (or group of QoS classes) may be associated to a different probability. For instance, tags used for access control can get probability 1 so that they always respond and the person carrying the tag can always access (e.g., go through a door), but tags used for sporadic measurements of temperature, CO2, etc may get a low probability, e.g. 0.01 so that they hardly transmit.

[0419] In a related embodiment that may be combined with other embodiments or used independently, instead of a probability, a tag may be assigned a minimum time (e.g. contention or back off time) between transmissions (from tag to reader). Furthermore, QoS classes may also be linked to different minimum times between transmissions. For instance, tags used for access control get a minimum time between transmissions of 0 so that they always respond and the person carrying the tag can always access (e.g., go through a door), but tags used for sporadic measurements of temperature, CO2, etc may get a minimum time between transmissions of 3600 (at most once per hour) so that they hardly transmit.

[0420] In a related embodiment that may be combined with other embodiments or used independently, the probability to transmit or the minimum time between transmissions may be configured in the tag or may be updatable.

[0421] In an embodiment that may be combined with other embodiments or used independently, Aloha or slotted Aloha may be possible mechanisms for contention resolution for tags. The slot or back-off time used by a tag could be a function of the current device ID or address (e.g., address modulo n) for a ‘guided’ Aloha. The advantage is that tags selected by wildcards line automatically themselves up for transmission. A disadvantage is that tags with the same result when the function (e.g., module) is applied to the device ID or address will always clash. This can be mitigated or solved by adding a random factor that optionally increases with every retransmission or using the ‘response probability’ field to reduce probability of clash.

[0422] Fig. 9a and 9b represent two procedures in which the multiple access procedures described in the various embodiments of this invention as well as contention procedures may be applied. The procedures involve multiple (Fig. 9a) or a single (Fig. 9b) tags 900, a reader 901 (e.g., UE and / or gNB) and a network function (NF) in a core network or application function 902. In Fig. 9a, entity 902 may send a message 903 that may be a request to retrieve data, or a command, etc. Then entity 901 may start a procedure similar to the one described in Fig. 5 wherein signals 904, 905, 906, 907, 909 may correspond to signals 502, 503, 504, 505, 506. Messages 905 and / or 907 may carry some data that may be forwarded to entity 902 in messages 908 and / or 908’ . Similarly, messages 909 and / or 909’ may be received by entity 901 from entity 902 and may be forwarded to entity 900 in messages 906 and / or 910. In a particular instance, messages 908 and 909 are not present and messages 905 and 906 do not carry / exchange end-to-end data, and these messages mainly serve the purpose of contention resolution.

[0423] In Fig. 9b, entity 902 may send a message 903 that may be a request to retrieve data, or a command, etc. Then entity 901 may send a request 904. Entity 900 may then reply with message 907, and part of the data may be forwarded to entity 902. Entity 901 may confirm in message 909 the correct reception of the data.

[0424] In some approaches, a multiple round procedure (similar to the one described by means of Fig. 4) may be used. In each round, there may be multiple slots, e.g., round k may have N_k slots. The number of slots in a round may be indicated by the reader. Then within a slot, a tag may perform a type of random-access procedure as in Fig. 5 (signals 503-506). However, in this case, it is important to allow for slots that do not have fixed duration because if they had fixed duration, the duration should be long (e.g., since signal 505 may be included that may include data from the tag towards the reader). To enable slots of a variable time duration, embodiments in this invention may be applicable.

[0425] In an embodiment related to Fig 5, that may be combined with other embodiments or used independently, if the reader does not receive a signal 503 (e.g., including a random identifier) within a time T, the reader may transmit a message (request) indicating the next time slot within the request burst (e.g. 504). This requires the reader to have a timer, and start the timer after the transmission of a request. The value T may be configurable. The technical effect of this embodiment is illustrated by means of the following example. Assume a situation in which the slots have a fixed duration, e.g., 2 time units, thus, a procedure / request burst of N slots takes 2*N time units. However, in practice, not all slots will be occupied because the choice of slots is random. So if a reader notices that after, e.g., 0.5 time units, no signal (reply message is being received), the reader can directly send a request indicating the next slot. In this case, if in average p% of the slots are occupied, this procedure / request burst relying on this embodiment will take:

[0426] N*(2*p + 0.5*(l-p)).

[0427] This embodiment is therefore advantageous because it reduces the duration of the round without decreasing the number of devices that can access the medium. In an embodiment related to Fig. 5 that may be combined with other embodiments or used independently, the request message may include an indication on the (expected) duration for the Aloha-like contention (e.g., time allowed for the reception of Signal 503).

[0428] In an embodiment related to Fig. 5 that may be combined with other embodiments or used independently, the reader may send an initial message indicating the start of a request burst (e.g. 502).

[0429] In an embodiment related to Fig. 5 that may be combined with other embodiments or used independently, the reader may send an initial message indicating the start of a request burst and that may indicate the number of slots, and upon reception of it, the tags may select a slot (e.g., at random). The selected slot is placed in a counter by each tag. If later the reader signals the next slot by sending a request message, all the tags that receive it decrement their counters and those whose counters reach zero (in general, they may track when the selected slot is reached), may perform a short random backoff and send a random ID to the reader (signal 503). If the reader acks it (signal 504), then the tag sends a data packet (signal 505).

[0430] In an embodiment that may be combined with other embodiments or used independently, the reader sends the next request message (indicating the next slot k+1) when the random -access procedure in slot k has finished. This allows for slots of variable duration.

[0431] In an embodiment related to Fig. 5 that may be combined with other embodiments or used independently, if two tags send signals 503 within a slot and both of them are properly received, the reader may prioritize one of the signals, and may acknowledge signal 503 of a first tag first (with signal 504) and the reader and the first tag may perform the random access procedure (e.g., as in Fig 5). Once this procedure with the first tag is finished, the reader may acknowledge signal 503 of the second tag (with another signal 504). The reader and the second tag may then complete this second random -access procedure. This has the advantage of having multiple communication procedures within a single time slot.

[0432] In a scenario, a reader may be configured to send a failure indication when a message is not received from a tag / AIoT device, e.g,, message 503 or 505 in Fig. 5 are not received or messages 905 or 97 in Fig. 9a / 9b are not received. However, in this case, if the confirmation message is lost, the tag / AIoT device may consider that its data / message has reached the reader successfully, when it has not. To address this situation, in an embodiment that may be combined with other embodiments or used independently, the reader may choose to use a failure indication message and / or confirmation message for the reception of device to reader messages. Which messages are used may be indicated to the tag / AIoT device in a previous message, e.g., in an initial request message, or in message 502, etc. For instance, if the reader determines that the communication link from reader to devices is good, it may rely on a failure indication message only, but if the link is not good, it may use a confirmation message. For instance, the initial rounds may use confirmation messages so that a device is always 100% sure that the data is delivered, while the last rounds may use failure indication messages. Additionally or alternatively, the reader may keep track of the devices that have not sent a given message (e.g., 503 or 905) even after sending, e.g., a failure indication message. The reader may have / start a timer when a failure indication message is sent, and if the timer times out without having received an answer from the device, the reader may be adapted to resend the failure indication message. Additionally, the reader may be adapted to resend the failure indication message to a device up to X times.

[0433] In general, it is described a method for multiple access adapted to:

[0434] - select, by a reader, a number of slots nO for a request burst,

[0435] - transmit, by a reader, a first request burst comprising nO slots, each slot including a request message, wherein one or more of the following conditions may apply:

[0436] - condition 1: start, by the reader, a timer upon transmission of the request message in a slot, and transmit, by the reader, the request message in the next slot if no answer has been received within a maximum contention time T. condition 2: include, by the reader, an indication of the maximum contention time T, in the request message. condition 3 : receive, by the reader, at least two contention messages from at least two tags, prioritize, by the reader, the contention message of a first tag perform, by the reader, a communication procedure with the first tag, perform a second communication procedure with the second tag. condition 4:

[0437] Include, by the reader, an indication of an identifier size in the request message, wherein the identifier size is used by a tag to determine the size of the identifier, e.g., a random identifier, included in the reply to the request message Section: R1 / R2 - segmentation strategies

[0438] In some scenarios, segmentation from device to reader may follow a strategy in which the reader sends request messages, and the device returns segments segment by segment, e.g., as follows

[0439] R2D trigger, then

[0440] D2R: segl, then

[0441] R2D trigger, then

[0442] D2R: seg2, then

[0443] R2D trigger, then

[0444] D2R: seg3, ...

[0445] However, this may be a very long process.

[0446] Thus, in an embodiment of the invention that may be combined with other embodiments or used independently, segmentation is improved by means of TDMA where multiple subslots are feasible within a slot, as described in other embodiments, so that a tag may send X segments in sequence. Additionally or alternatively, multiple slots may be used, e.g., reserved, for a long transmission (requiring multiple slots).

[0447] In FDMA, multiple tags may be able to send multiple messages (e.g., Msg3 corresponding to Signal 505 in set 1800-2) in parallel, these messages may require segmentation and not all tags may have been able to transmit all segments or may have the same number of segments. This may cause that multiple blocks 1800-2 are / need to be transmitted until all segments of all messages of all devices participating in the FDMA communication are received. Only then the reader may start transmitting the messages in set 1801-2. This increases the communication latency.

[0448] Thus, in an embodiment of the invention that may be combined with other embodiments or used independently, the messages exchanged in blocks 1800-2 and 1801-2 overlap. This means that a reader may keep acknowledging segments of messages received in sets 1800-2, e.g., messages contained in 1801-2 and may start transmitting messages in 1801-2 while further segments are still transmitted. This is feasible because messages in 1801-2 are not using FDMA.

[0449] For instance, in an exemplary procedure illustrated in Fig. 19, if two devices wish to send message 1802 (e.g., Msg3) in a block 1800-2-1 (similar to block 1800-2 in Fig. 18), and one of the messages (of the second device) requires segmentation while another of the messages (of the second device) does not, then in the first set 1800-2-1, a segment of each of the messages 1802 may be transmitted, e.g., in frequencies fl and f2. This set 1800-2-1 is transmitted in a first subslot. Then set 1801-2 starts at the beginning of the second subslot, at frequency fO, including the first answer 1803 for the first device whose message 1802 included a single segment and whose transmission has already finished. This message confirms that the segment of the second message of the second device has been properly received. In parallel, using FDMA another set 1800-2-2 is transmitted including the second segment of message 1802 of the second device, during the second subslot at frequency f2. The second device may transmit this message in a proactive manner, assuming that the previous segment was received well. Then, the answer to that second message can be transmitted by the reader next in the second subslot of 1801-2.

[0450] For instance, in an exemplary procedure illustrated in Fig. 20, if three devices wish to send message 1802 (e.g., Msg3) in a block 1800-2-1 (similar to block 1800-2 in Fig. 18), and one of the messages (of the third device) requires segmentation while the other messages (of the first and second devices) do not, then in the first set 1800-2-1, a segment of each of the messages 1802 may be transmitted, e.g., in frequencies fl, f2, and f3. This set 1800-2-1 is transmitted in a first subslot. Then set 1801-2 starts at the beginning of the second subslot, at frequency fO, including the first answer 1803 for the first device whose message 1802 included a single segment and whose transmission has already finished. This message may also include an indication to the third device that its segment was properly received, so that a subsequent segment can be transmitted. This message may also include an indication to the second device that its last segment was properly received, and its answer will be transmitted in a subsequent subslot. Then, the next third subslot, at frequency fO, includes the first answer 1803 for the second device whose message 1802 included a single segment and whose transmission has already finished. In parallel, using FDMA another set 1800-2-2 is transmitted including the second segment of message 1802 of the third device, during the third subslot at frequency f . Then, the answer to that third message is transmitted by the reader next in the third subslot of 1801-2.

[0451] In general, it is described a method for operating an apparatus comprising: receiving, by the apparatus, a first segment and a second segment of a first message and a second message from a first device and a second device wherein the first segment is received at a first frequency, and the second segment is received at a second frequency and both the first and second segments are received at a same first time, determining, by the apparatus, the first message from the first device is complete and the second message from the second device requires at least a third segment, transmitting, by the apparatus, a first answer to the first device at a third frequency at a second time, And performing, by the apparatus, one or more of: o Receiving the third segment of the second message at the second frequency at the second time, o Including an indication of the correct reception of the second segment of the second message in the first answer.

[0452] Section: R2 - fairness in the random access procedure

[0453] A reader handles the random -access procedure of many AIoT devices / tags. Tags may select a slot, and attempt access in the slot by sending an initial message Msgl (signal 503 in Fig. 5). If this message is not received properly by the reader, or the subsequent message reply from the reader is not received properly by the tag, the tag may not be supposed to automatically re-access. A reason for this is that if many devices attempt to access, most Msgl and Msg2 will not be properly received. Also, some tags may be further away from the reader, and their messages may be more likely to be received wrongly, either by the reader or the tag.

[0454] As indicated in other embodiments, a slot may be linked / connected to a purpose. Thus, in a related embodiment that may be combined with other embodiments or used independently, the purpose may refer to provide access to AIoT devices that have tried to perform the random access procedure n times / at least n times / no more than n times / more than n times / etc. This may be indicated by means of a field in the request message / paging message. For instance, this may be a flag that may be 0 if the slot is to be used by devices that have not attempted to access and may be 1 if the slot is to be used by devices that have attempted to access, but failed in the past. This field may be common for all slots in a communication round (as in Fig. 4). Additionally or alternatively, if a communication rounds has N contention-based slots, the first N 1 slots may be used by devices that have not attempted to access yet, and the rest N-N 1 slots may be used by devices that had attempted to access already (but failed).

[0455] As indicated in other embodiments, when a tag does not manage to have access, it may be given resources for further communication. Thus, in a related embodiment that may be combined with other embodiments or used independently, when a tag fails to access due to contention resolution failure, the reader may provide communication resources for further access.

[0456] In a related embodiment that may be combined with other embodiments or used independently, a reader may not always need to reply with Msg2 (i.e., signal 504 in Fig. 5). For instance, if there are multiple tags in a room, the tags reporting a sensed value, as long as a tag reports, the reader has enough information. A reader may have been informed, e.g., by the CN, that it requires at least n (e.g., n = 1) answers after sending a request message / request burst. If the reader gets less than n answers, the reader may just send one more request burst / communication round.

[0457] In some embodiments, it is expected that the failure of receiving Msg3 (i.e., signal 505 in Fig. 5) could be handled by means of attempting to re-access. In some cases, after Msg3, the reader may expect more replies from the AIoT device. Even if the reader may be transparent to the communication between the AIoT device and the NF / AF, the NF / AF may provide the reader with a configuration describing the expected answer from the AIoT device, e.g., answer / or no-answer, e.g., expected size of a reply message, etc. In general, the NF / AF may provide an answer template that can be used by the reader to verify the correct operation of the AIoT device. In this way, the reader can check whether the AIoT device provides the expected answer by using this answer template. If the provided reply message (or lack of reply message before a timer expires) does not fit the answer template received from the NF / AF, the reader may then re-send the previous request message (e.g., Msg2 or other message received from the NF / AF.

[0458] Section: R2 - Management of replies from tags

[0459] One or more readers may start multiple communication procedures, each of them involving multiple communication rounds. In this situation, it is important to manage how a tag replies, e.g., to prevent the tag from replying multiple times within the same communication procedure, and how the reader and / or NF / AF manage the communication procedures. It is to be noted that the purpose of these communication procedures may refer to, e.g., “reachability paging” (reader pages devices unknown to the reader) and / or ’’inventory paging” (reader pages devices in inventory group). Embodiments in this invention address these goals:

[0460] In an embodiment that maybe combined with other embodiments or used independently, a reader may use a (session) ID to identify a communication procedure, and a tag may use a circular look-up table with one or more entries, and the tags keep adding the last used ID to, e.g., a table with 4 entries, and a tag is not supposed to reply to any ID that is in the table of four entries and will override a value after receiving the fifth ID. In general, a tag with a table with n entries will override an entry after receiving the n+1 request. In general, the minimum ID size in bits is int(log2(n))+l where int(a) returns the integer part of a, and log2(a) computes the logarithmic value of a in base 2. This minimum ID size makes sure that all IDs in the table can be different, if the reader(s) make sure that they do not use the same IDs in n subsequent requests. A tag may remove the table, if energy disappears. If there is energy, the table may be formed. The size of the table may depend on the device capabilities. The tag may also store this information in non-volatile memory. Reader may pick up a short ID at random, whose length may depend on the capabilities of the devices it intends to communicate with. Reader may check if a given ID is used by readers close by (space) currently (time), and if not used, use it. Additionally or alternatively, a NF / AF performs this check to make sure that IDs are unique, e.g., in a given area. This short session ID may be mapped, e.g., by the reader, to the long session ID, e.g., received from the core network / AF, e.g., comprising one or more of the following identifiers PLMN ID, AF ID, Service, Request ID, time. Additionally, alternatively, this mapping is done by the NF / AF. When the NF / AF manages the ID, the NF / AF may pick up a suitable ID and use in multiple readers so that the multiple readers perform a cooperative inventory procedure.

[0461] In a scenario, many tags may need to be paged, and using a single reader may require too much time. Thus, in an embodiment that may be combined with other embodiments or used independently, the NF / AF may decide to use two or more readers. The NF / AF may identify the readers, and provide them with the inventory request messages. These request messages may be identified by a common ID so that a tag does not need to respond to different readers involved in the cooperative communication procedure.

[0462] In a scenario, a tag sets a flag when it has successfully communicated in response to an inventory page, and this flag is stored until the tag's energy disappears. However, this has the problem that a tag may reply again and again during the multiple rounds of a communication procedure. In a further embodiment that may be combined with other embodiments or used independently, a tag may be configured / adapted to reply when it is requested to reply (e.g., the request message such as a trigger message) includes its identity and / or the tag has information to provide (e.g., sensed data).

[0463] In a scenario, a tag implementation is arranged such that some, non-volatile memory can retain its contents for a short period of time after energy levels have become too low for the tag to perform communication functions. Advantageously, said memory may retain its contents long enough to allow the tag to recharge if an ambient energy source is available. If no energy source is available, the memory will eventually discharge. In some scenarios, there may be an arrangement in which the flag indicating that the tag has responded to an inventory page is stored in such semi-volatile memory, thus allowing the tag to retain the flag over the several rounds of a communication procedure and thereby suppress further replies to the same communication procedure. This has a problem that the process of clearing the flag at the end of the communication procedure is not well-defined and the tag might therefore not respond to a new communication procedure because the flag is still raised.

[0464] In a variation of the flag procedure, successive communication procedures may be associated with an alternating A / B indicator, which is carried in the paging requests. A tag that receives a page for a communication procedure ‘A’ checks whether its ‘A’ flag is set or reset. If set, it ignores the page. If reset, it also resets its ‘B’ flag and attempts to respond. If it is successful in responding, it sets its ‘A‘ flag and may then ignore further page ‘A’ messages. The next communication procedure handled by the reader is labelled as ‘B’ and a tag that has responded to the previous ‘A’ service request will still respond to the new ‘B’ service request even if its ‘A’ flag has not fully discharged.

[0465] In a further variation, to allow for a tag that cannot charge sufficiently in the time available and sleeps through communication procedure ‘B’ in the above example and therefore does not respond to the following communication procedure ‘A’, because its ‘A’ flag is still set, two or more bits can be used to label a communication procedure as ‘A1, ‘B1, ‘C’, ‘D1and so on as needed to allow for charging time and communication procedure arrival rate.

[0466] In a scenario, the differences and similarities between reachability and inventory paging may be as in the table:

[0467] Section: S - Coordination between the RAN protocols and the end-to-end protocols A RAN protocol may be considered as the protocol that runs between an AIoT device and a reader (e.g., UE or gNB). An end-to-end protocol may be considered as the protocol that runs between AIoT device and a NF or AF in / outside the core network. While many protocols will run end to end, transparently to the reader, in an embodiment of the invention that may be combined with other embodiments or used independently, the NF or AF may need to provide the reader certain parameters so that the reader can optimize its performance. For instance: the AF / NF may (need to) inform the reader about the expected number of AIoT devices that may answer to an inventory procedure so that the reader can adapt / optimize the parameters of multiple access procedure; the AF / NF may need to provide the reader with an intermediate verification value so that the reader can verify messages received from the AIoT devices.

[0468] Similarly, other processes may be improved as illustrated in the following embodiments.

[0469] In an embodiment that may be combined with other embodiments or used independently, an AF / NF may perform a control operation with an AIoT device and may include a (long) device specific identifier, e.g., in messages 903 / 904 in Fig. 9a. This long specific identifier in message 903 serves as information for the reader to trigger further interactions. For further interactions between reader / AIoT device, the reader may assign a (short) identifier so that the communication is optimized. Instead of assigning a short identifier that is not related to the long identifier (that may require further bandwidth and resources at the AIoT device), the reader and AIoT device may be configured to use as short identifier a subset of the long identifier, e.g., the last k bits. The reader may inform the AIoT device about the subset of bits to exchange / use as short identifier, e.g., it may signal the k value referring to the k least significant bits to use as short identifier. This may be indicated in message 904, and subsequent messages (e.g., 905, 906, 907, 910) may use this short identifier. The AIoT device use this short identifier over the air messages with the reader, and the reader may map it to the long identifier when forwarding the messages towards the NF / AF. Even if a message between AIoT device and reader uses a short identifier, security (e.g., computation of a MAC included in the message) may be based on the long identifier so that the receiving party can verify it.

[0470] In scenarios, the reader and / or AIoT devices may be configured with parameters to optimize performance or RAN procedures. For instance, to avoid long and uncertain wait times at the reader, a maximum time, TR2D max, e.g., adjustable transmission / reception window, may be defined between a reader to device transmission and the corresponding device to reader transmission following it. For instance, it may configure the types of multiple access methods that are supported by a device (TDMA, FDMA, CDMA) so that MA procedure can be optimized. However, this type of parameters may be device and / or device class specific.

[0471] Thus, in an embodiment that may combined with other embodiments or used independently, when the reader receives a command to forward to AIoT devices from the NF / AF, the reader receives helper data / metadata including configuration parameters, e.g., timing parameters such as TR2D max, or configuration parameters indicative of a device type / class or other from which the reader can deduce or compute a suitable TR2D value, MA procedures, etc. This allows the reader to optimize the communication with the device. These parameters may be device (class) specific and thus, the AF / NF may just indicate the device type / class and the reader may look up the corresponding parameters. Additionally or alternatively, this helper data / metadata may be received per device or per batch of devices. For instance, the reader may receive a list of devices (identities), the list of messages (for each of the devices), and metadata for all devices and / or for each device.

[0472] Section: S - Distribution of reader functionality over multiple devices

[0473] In an embodiment that may be combined with other embodiments or used independently, the reader functionalities may be distributed over two or more devices acting as a transmitter of the request burst and receiver of the answers of the ambient loT tags. In this case, the transmitter may be, e.g., a base station or UE, and the receiver maybe e.g., a UE or base station. In this case, the transmitter needs to coordinate with the receiver to make sure that the receiver listens to the replies. This may be indicated by means of a configuration transmitted in a MAC control element, or an RRC message or a DCI message or a SCI (Sidelink Control Information) so that the receiver can determine the instants of time it needs to receive.

[0474] In a related embodiment that may be combined with other embodiments or used independently, a first UE acts as a transmitter and the UE may be controlled by a user that determines when he needs to “scan” a tag. In this case, the UE may need to send a request to a base station to request the allocation of communication resources, e.g., to transmit the request burst and / or transmit the illuminating signal (e.g. carrier wave externally provided). The base station may send those allocated communication resources to the UE acting as transmitter, and any other potential device acting as a receiver.

[0475] In an embodiment that may be combined with other embodiments or used independently, the reader functionalities may be distributed over two or more devices acting as a transmitter of the request message / request burst and receiver of the replies of the ambient loT tags. In this case, the transmitter(s) may be, e.g., a base station or UE, and the receiver(s) may be e.g., a UE or base station. In this case, the transmitter(s) may need to coordinate the carrier wave generation in time, frequency, space domain with the nodes which can provide carrier wave externally and / or ambient loT tags which can generate carrier wave internally, to minimize the interference of different carrier waves with each other and with signal transmissions / reception of other transmitters and receivers in the system. In a related embodiment that may be combined with other embodiments or used independently, the coordination between UE and base station, or between base stations, or between UEs may be performed by means of messages exchanged through the Uu, Xn, or PC5 interfaces. Coordination between UE and base station may be based on the exchange of an RRC message including one or more information elements related allocation resources, parameters, as well as synchronization resources.

[0476] Section: S / R2 - Overall procedures for Ambient loT, e.g. to improve contention for a slot

[0477] The Ambient loT study for 3GPP 5G Rel-19 describes two topologies. An architecture of the form shown in Fig. 11 is used. In an embodiment that may be used independently or combined with other embodiments, the AIoT Devices communicates with an AIoT Reader. The AIoT reader may be a base station or a UE. In turn, the AIoT Reader communicates with a network entity that, for the purpose of this disclosure, is referred to as the AIoT Application or, more simply, the network. It is convenient to make some assumptions about the relationship between these three components. The AIoT Application may communicate with AIoT devices via any AIoT Reader in range of the AIoT devices. To this end, the AIoT Application may store information about the likely (network) location of AIoT devices in terms of the AIoT Readers most likely to be in range of the AIoT devices. Alternatively, the AIoT reader may announce its presence (on behalf of the AIoT application), requesting tags to communicate. The AIoT Reader may act as an interface between the AIoT device and the AIoT Application that is essentially transparent to data and commands transferred between the AIoT Application and the AIoT device. The AIoT Reader may handle all communications across the air interface and, to this end, may store data and commands temporarily while executing a service request. It is not required nor assumed to retain any information about the AIoT devices outside the service requests. It is assumed that security is handled in end-to-end fashion between AIoT devices and the AIoT Application; any AIoT Reader used by the AIoT Application is assumed to be authenticated by the network and may be trusted implicitly by the AIoT devices.

[0478] The term AIoT Application may be replaced by AIOTF or other Network Function (NF) within the core network that manages AIoT operations. In addition, the term AIoT Application may be replaced by Application Function (AF) that may operate inside the Core Network or outside of the Core Network and that may indirectly (e.g. through NEF) use a network function in the core network for managing the Ambient loT devices and handling communicating (e.g. at NAS layer) with the Ambient loT devices.

[0479] Fig 13 illustrates another general AIoT procedure that may be mapped to, e.g., Fig. 9a. It indicates multiple phases, including an initial paging / request (that may correspond to a first request burst). A paging response that may correspond to the messaging between AIoT device / tag and reader and serves the purpose of confirming the access to a CB slot, and giving an indication to the AIoT device of the CF slot allocation, either in the same request burst or in a subsequent request burst). Then a device identification, authentication, key establishment may be executed. Finally, there may be a data transfer phase, e.g., the Reader sends a sequence of commands to the device to enable reading from or writing to the device or to instruct the device to perform other functions. Depending on the application requirements data exchanged with the device may be stored within the Reader or may need to be communicated with the network in real time. The device may indicate to the Reader that it has data to send. Steps 2 (paging / request), 3 (identification, authentication) and 4 (data transfer) may be handled in a single CB slot or may be divided across an initial CB slot and one or more subsequent CF slots.

[0480] In some embodiments it may be preferable to defer the data transfer phase and, optionally, the authentication phase to a separate contention-free slot allocated by the Reader or to allocate extra communication resources. This may be the case if a tag has a significant amount of data to transfer or if it needs to report on the result of a command from the network, for example. Alternatively, if the Reader successfully receives Paging response messages from more than one tag in a slot, then it may allocate separate, dedicated slots for the extra devices for authentication and data transfer. Embodiments below describe the use of CF slots for steps 3 and 4. It will be apparent that other divisions are possible but will not be described explicitly. For example, step 3, the authentication step, could be performed in the initial CB slot with CF slots being allocated for data transfer conditionally on the success of the authentication and the need for data transfer. For example, step 3 and at least part of step for could be performed in the initial CB slot with subsequent CF slots allocated if a significant amount of data needs to be transferred or if the tag needs time to process a command. In a first embodiment using CF slots, when several devices respond in step 2, the Reader assigns contention-free slots to all devices that respond successfully. Steps 3 and 4 are then performed separately for each device using the assigned slots. Since not all devices will succeed in obtaining channel access in a given cycle, the paging cycle / request bursts may be repeated from phase 1 multiple times until all devices have been reached or no more answers are obtained. Once the Reader believes it has reached all / a percentage of devices or times out, it may send a service response message to the network to indicate completion, optionally including data collected, command responses, reports on the performance of the paging cycles (e.g., number of devices responding successfully) and so on.

[0481] In an embodiment that may be combined with other embodiments or used independently, the network may issue a service request to a reader, containing at least a group address addressing one or more tags and, optionally, meta-information such as the maximum duration of the service event and / or the minimum number of tags to be read and so on. The service request may also comprise commands to be carried out by the tags, data to be transferred and security credentials.

[0482] In an embodiment that may be combined with other embodiments or used independently, on receiving the service request, the reader may perform a number of cycles comprising a paging message (e.g., an initial message in a request burst or a request message in a request burst or another message, e.g., signal 502 in Fig. 5) followed by a number of contention-based slots (CB slots) that can be used by the AIoT devices to submit a paging response (e.g., signal 503 in Fig. 5) requesting access to the channel, and, optionally, a number of contention-free slots (CF slots) that can be assigned to specific tags. In some cases, the CF slots may be located first and the CB slots may be located at the end. The reader may determine the number of CB and CF slots according to the current state of the service request, the number of devices being addressed, the available channel resources and so on. Fig. 10 illustrates such a procedure wherein the initial paging message (AIoT page) is followed by n contention based (CB) slots.

[0483] In an embodiment that may be combined with other embodiments or used independently, the paging message may comprise a group address of some form (for example, a 48 -bit or 64-bit device address with a few LSBs masked off), an indication of how many slots will follow, a number uniquely identifying the service request (to allow tags to determine whether a paging message is part of an existing service request, to which they may have already responded, or part of a new service request, to which they might not have yet responded) and, optionally, the number of the current paging cycle within the service request (for the benefit of tags with a CF allocation in a different paging cycle / request burst round). Optionally, the paging message may additionally comprise a list of assigned slots and their assignee tags. Optionally, the paging message may carry a command that tags should perform on successful channel access. Tags that receive the paging message and determine that they are addressed by it (in a contention-based slot), perform contention, e.g., they choose a random number between 0 and one less than the number of slots indicated and await their turn. Furthermore, they may pick up a random number / identifier to transmit in the selected slot. A tag that determines that is being addressed and given access in a contention free slot (CF slot), waits for the slot, and communicates in it. Each paging cycle (or request burst) (may contain a mix of contention-based and contention-free slots as in Fig. 10 (only CB slots) and Fig. 12 (n CB slots and m CF slots). With this arrangement, a Device that succeeds in a CB slot may be allocated a CF slot in the same cycle or, if insufficient CF slots are available, in a subsequent paging cycle. The reader may determine the number of CB and CF slots according to the current state of the service request, the number of devices being addressed, the available channel resources and so on.

[0484] The above CB procedure refers to Aloha, an access mechanism that can be used by stations competing for a common resource when the stations have no ability to co-ordinate with each other. When a packet arrives at a station, it is transmitted without regard for whether the channel is already in use. If packets are a fixed length and if their arrival rate can be modelled using a Poisson model, then it can be shown that the maximum throughput is l / 2e packets per packet duration.

[0485] Slotted Aloha improves on this by confining transmissions to well-defined slots, with throughputs rising to 1 / e packets per packet duration. In an embodiment that can be combined with other embodiments or used independently, a separate acknowledgement channel may acknowledge packets that have been successfully received.

[0486] Slotted Aloha makes the assumption that all slots are the same duration. For Ambient loT, this could also be true. For inventory applications, for example, it might be reasonable to assume that each tag has approximately the same amount of data to transfer. If data transfer takes place during the slot, then slots can be the same length. If, on the other hand, no tag contends for the slot or devices contend but none succeeds, then there will be no authentication or data transfer phases. If this is the case, then it would be efficient to terminate the slot early. In this case, advantage can be taken of the assumption that the tags are receiving continuously because this implies that the slots do not need to adhere to a fixed raster and may, in fact, start at irregular intervals. Thus, in an extension of the embodiment, a CB slot may be terminated early by simply bringing forward the start of the next slot. This may apply for contention failure, device identification / authentication failure or when less data or even no data is transferred than expected.

[0487] Each slot may comprise a number of elements and / or be used for a number of purposes. The slots may correspond to the same request burst or to multiple request bursts as indicated in other embodiments. For instance:

[0488] Start of slot indication

[0489] Page response from tag

[0490] Tag acknowledge (optionally containing information about dedicated slot)

[0491] Optional tag authentication procedure

[0492] Optional data transfer procedure

[0493] Fig. 14 shows a possible message sequence within a contention-based slot. At the beginning of each CB slot, the Reader or other device may send a message indicating the start of the slot and optionally, the slot number within the cycle / request burst round (for tags that match the slot number against their chosen slot numbers), optionally, the cycle / request burst round number (for tags that are allocated a CF slot in a different paging cycle) and, optionally, the service request number.

[0494] A tag determines whether to contend for the CB slot by checking if its chosen slot number matches the slot number indicated by the start of slot message. Alternatively, it decrements its slot count on every start of slot message and determines a match when the count reaches zero.

[0495] In an embodiment that may be combined with other embodiments or used independently, following the start of slot message, the tag, if it wishes to contend for the slot, may issue a Page Response message (e.g., reply message) comprising a random number. Advantageously, the tag performs a random backoff before issuing the Page Response (e.g., reply message) with the parameters of the backoff being set, for example, by the reader in the Paging message (e.g., request message). If several tags contend for the same slot, the backoff increases the chance that at least one tag will be successful. Advantageously, the tag applies to its transmission a random frequency offset, which, preferably, is a multiple of the channel bandwidth. Advantageously the tag applies a unique spreading code to its transmission.

[0496] If the Reader receives a Page Response successfully, it may send an acknowledgement message containing the random number to the tag with an optional short temporary address. Additionally, or alternatively, it may send a Device CF Allocation message which contains the random number and a CF slot allocation to the Device. The CF Allocation message may be protected by ARQ: if the Reader does not receive an Ack from the Device, it resends the CF Allocation message. The CF allocation may indicate a dedicated CF slot in the same or a subsequent paging cycle or it may indicate that communication may continue in the current CB slot. If the tag needs an undetermined period of time to generate a response to a command, the CF allocation may indicate that the tag should contend for a new CB slot when it is ready to do so. If no such acknowledgement message is received by the tag or a message containing a different random number is received, the tag may determine that it has failed to win the slot and waits for the next paging cycle.

[0497] Assuming that a tag has succeeded in the contention phase, it can continue with an optional tag authentication procedure to identify and authenticate the tag to the reader or a core network function and / or an application functions and, if required, a data transfer procedure.

[0498] Fig. 15 shows a possible message sequence during a contention-free slot according to some embodiments. After the start of slot message, the device may confirm its identity with the Reader. If the Reader accepts the device, it acknowledges the device Identity message. The Reader may then forward commands from the network and transfer data to and from the Device. Variations can be imagined. For example, the Device Identity exchange may take place in the CB slot prior to the allocation of a CF slot; failure to identify the Device may result in no CF slot being allocated. For example, the exchange of data and commands may take place in the CB slot. This might be appropriate if the expected data payload is small, for example. For example, if the allocated CF slot is not sufficient, further CF slots can be allocated. In another variant, the identity may not be exchanged in a different message, but it may be implicit in the data exchange, e.g., the usage of keying materials linked to said identity / the identity allocated to that CF slot so that if the integrity verification fails, the reader determines that it is talking to an attacker and / or the wrong tag. Similarly, if the tag fails to communicate, it may determine that it is communicating with the wrong reader.

[0499] For inventory applications, for example, it might be reasonable to assume that each tag has approximately the same amount of data to transfer. If data transfer takes place during the slot, then slots can be the same length. If, on the other hand, no tag contends for the slot or devices contend but none succeeds, then there will be no authentication or data transfer phases. If this is the case then it would be efficient to terminate the slot early. Thus in an extension of the embodiment, a CB slot can be terminated early by bringing forward the start of the next slot.

[0500] In some embodiments it may be preferable to defer the data transfer phase and, optionally, the authentication phase to one or more separate contention-free slots allocated by the Reader or to allocate extra communication resources. This may be the case if a tag has a significant amount of data to transfer or if it needs to report on the result of a command from the network, for example. Alternatively, if the Reader successfully receives Paging response messages from more than one tag in a slot, then it may allocate separate, dedicated slots for the extra devices for authentication and data transfer.

[0501] In this mode of operation, after the authentication step, the Reader indicates to the tag that it will receive a dedicated CF slot in a subsequent paging cycle, including the expected paging cycle number in the acknowledgement message. The next and subsequent Paging messages will additionally allocate CF slots to specific tags as well as a number of CB slots.

[0502] Once a tag has taken part in a Service Request, it will normally not be required to take further part and can ignore Paging messages carrying the same Service identifier. Exceptionally, a tag will need to wait for data or commands from the network and can be accessed during the active service request via, for example, the short temporary ID assigned by the reader. Exceptionally, a tag will need to report on the results of a command made earlier during the service request period. If not assigned a CF slot, it may contend for a CB slot a second time using the same procedure.

[0503] The paging cycle may be repeated multiple rounds until a condition occurs, e.g., all devices have been reached, no more answers are obtained, etc. In an embodiment that may be combined with other embodiments, or used independently, to allow tags to choose a CB slot, it is assumed that CB slots are numbered consecutively from 0 (or 1) to (n-1) (or n), where n is the number of CB slots in the paging message. Tags then choose a random number in that range. The start of slot messages could carry the slot number to allow the tags to match against their chosen slot. A tag that misses its slot, as determined, for example, by detecting a slot number higher than its chosen slot may either choose a new number within the remaining range or wait until the next paging cycle. An alternative mechanism is to ignore any slot number in start of slot messages but instead count down each time a start of slot message is received. When the count reaches zero, a match is declared and the tag contends for the slot. Missed start of slot messages cause a tag to contend for a later slot than it initially chose. A consequence is a potential need to allow guard slots after the final CB slot to allow for tags that missed a sufficient number of slots to push them beyond the nth slot, bearing in mind that tags might not be aware that they have missed slots. In any case, tags that unexpectedly receive a new paging / request message announcing the start of a new paging cycle should abandon the contention attempt on the previous cycle and start again.

[0504] In an embodiment that may be combined with other embodiments, or used independently, CF slots may follow CB slots (and any guard slots) and could be numbered as a continuation of the numbering of the CB slots (guard slots would also be numbered in sequence but would not form part of the initial CB allocation nor would they be allocated as a CF slot). Unlike CB slots, CF slots are allocated to specific tags and said tags must use their allocated slots. That makes it imperative that the tags identify their slot reliably. A number of strategies are possible. For example, a tag is expected to send a message, such as a device identity, to indicate its presence to the Reader. If the tag misses its CF slot, owing to interference, perhaps, the Reader can resend the start of slot message a number of times until a response is received. Alternatively or additionally, since there is no requirement that the slots are sent in strict numerical order, the Reader can resend the start of slot message later in the cycle. For example, depending on the nature of the channel, the slot number may contain some element of redundancy, for example, a Hamming code that is robust to bit errors or it may comprise a sequence with synchronization properties, such as a Zadoff-Chu sequence, that could be detected with a simple correlator.

[0505] Section: R1 / S - Adaptive energy-aware communication procedure

[0506] In certain scenarios, an Ambient loT device receives from the reader / network a (set of) temporary ID(s) or new configuration information (e.g. policy update, fresh credentials) that it may need to store in non-volatile memory or storage medium. This requires a substantial amount of energy from an uninterrupted energy source, otherwise the writing procedure may fail. In an embodiment that may be combined with other embodiments or used independently, an ambient loT device may send a confirmation or acknowledgement (e.g. as part of an RRC or NAS or an application layer response message) that writing the received data to non-volatile memory or storage medium was successful, possibly in addition to sending a confirmation or acknowledgement (e.g. as part of an RRC or NAS or an application layer response message) that a ‘write’ command was successfully received by the device.

[0507] In another embodiment that may be combined with other embodiments or used independently, in case of sending a ‘write’ command or an important command to be processed by the ambient loT device, a reader device (e.g. UE, gNB) may perform an action to increase the amount of received power, e.g., the reader device may perform one or more of: increase the transmit power and / or direct a signal beam (e.g. of illumination signal) and / or increase signal bandwidth / density and / or operate in higher frequency for one or more transmission signals and / or transmit another type of high energy signal (e.g. based on Qi or other wireless power standard) in the direction of the ambient loT device and / or in the transmission signals that are used for communication with the ambient loT device, and / or instruct another device (e.g. wireless power energy source) to perform some of previous actions, so that the ambient loT device can use the received energy for energy harvesting.

[0508] Additionally or alternatively, the reader device may receive information from the CN or application that a command (that may be encrypted using credentials not available to the reader device) entails a ‘write’ command or is another important command that requires the reader device (itself or by instructing another device to so so) to provide more energy to the ambient loT device for energy harvesting or adapt some communication parameters. This may also be done by a separate message, e.g., before receiving the respective command. Based on this trigger, the reader device may temporarily provide more energy to the ambient lot device, or may instruct another device to do so, during a time period before, during or after sending the respective command to the ambient loT device. Additionally or alternatively, the reader device may adapt the time period for transmitting an illuminating signal (which may be a signal for backscattering or a dedicated signal for providing energy, e.g. RF energy and which may also be called impinging signal in this document) signal to the Ambient loT device, adapt the number of retransmissions of the respective command and / or number of retry attempts or adapt the number of communication rounds giving room to recharge the energy storage and / or delay sending the respective command. Additionally or alternatively, the reader may also determine this (that the communication with the AIoT device requires the AIoT device obtaining a signal with an increased received power) implicitly based on the information contained in the messages / commands received from the CN or application to be transmitted to the AIoT device. Similarly, the reader may determine other communication parameters based on the received commands. For instance, if a reader receives commands to identify N AIoT devices, the reader may determine RAN parameters such as the number of communication rounds or the number of slots in a communication round based on N.

[0509] In another embodiment that may be combined with other embodiments or used independently, in case of sending a ‘write’ command or an important command to be processed by the ambient loT device, a reader device (e.g. UE, gNB) may add information as part of the request message, e.g. a paging / wakeup message, or other message that indicates to the ambient loT device that an upcoming message is expected to contain a ‘write’ command or other important command, i.e. before sending the respective command to the ambient loT device. Upon receiving this information, the Ambient loT device may enter a power save mode in which it may avoid spending energy on lower priority tasks (e.g. processing or sending low priority messages) and / or may not respond to the paging / wakeup message if it does not have sufficient energy (at least below a certain threshold) to process the respective command and / or may respond to the paging / wakeup message with a message including information about its energy status (e.g. how much energy it has stored, or how long it would take before it has harvested sufficient energy for processing the command). The reader may use this information to adapt the communication, e.g., adapt the time period for transmitting an illuminating signal to the Ambient loT device, adapt the number of retransmissions of the respective command and / or number of retry attempts or adapt the number of communication rounds giving room to recharge the energy storage and / or delay sending the respective command and / or inform the CN or application about it, and / or provide additional energy towards the ambient loT device or instruct another device to do so (as described in other embodiments).

[0510] Additionally or alternatively, the CN / application or reader may estimate (e.g. based on capabilities it has stored or has received about the ambient loT device) how much energy is needed by the ambient loT device to process the respective command, and may use that estimate to determine a delay to send the respective command or to determine how long or how much it has to provide additional energy towards the ambient loT device or instruct another device to do so. Additionally or alternatively, it may provide the estimate in a message (e.g. paging / wakeup message or other message) to the ambient loT device, which may use it to determine how much additional energy it still needs to harvest before it is able to process the respective command.

[0511] In an embodiment of the invention that may be combined with other embodiments or used independently, the reader may determine, based on one or more of

[0512] (1) the message received from the CN / application (implicitly or explicitly);

[0513] (2) the context (location, knowledge of devices, ); and (3) configuration, at least one parameter of the communication procedure between the reader and at least one AIoT device that may need to be adapted to guarantee that a message or command to be delivered to the device is received properly (e.g. successful reception at least with a probability higher than a threshold). Examples of the communication parameters may be as in other embodiments and may include: transmission power, direction, number of rounds / retransmissions, number of slots in a round, use of security in the communication, duration of transmitting illumination signal, etc. The reader may require some knowledge about, e.g., the type of device (e.g., type of energy storage), and / or distance to the device, and / or estimation of the amount of energy that the device can charge per unit of time for a given transmission power of the reader, and / or the amount of energy that the device may require to transmit a message itself,... Given these parameters, the reader may then determine how one or more parameters of the communication procedure may be adapted. For instance, the reader may determine that the capacitor of the AIoT device needs to be fully charged before a communication round is started, and the reader may determine how long it takes given the (estimated) current energy level, type of device, and charging speed (given the transmission power of the reader and the relative locations), with this information, the reader may determine a duration of the illumination signal whose purpose is to charge the AIoT device, and after this duration, a communication round may be triggered / started by the reader.

[0514] In an example, if the reader receives a “write” command (e.g. in message 903 in Fig. 9a) from the CN for a particular Ambient loT device or other command that requires energy, e.g., a lot of energy, on the Ambient loT device to be processed successfully (e.g. a read command for which a response with large number of bytes is expected), then the reader may temporary halt all communication in the direction or addressed to that Ambient loT device, in particular after receiving a negative energy status report as response to a previous paging message (e.g. as part of “inventory” before sending the command). This gives the Ambient loT device some additional time to gather additional energy for executing the command. The reader may estimate the delay based on the type of command, an indication from the CN / AF about the size of the message to be written to memory or the size of the response message, an indication from the CN / AF about an estimated amount of energy that is needed, an estimated delay (e.g. waiting timer) provided by the CN / AF, an estimated delay received from the Ambient loT device in a previous message, an estimation of how long the Ambient loT device would need to be further illuminated (that may be further based on estimated distance between the Ambient loT device and the illuminating device and / or information about the type of Ambient loT device).

[0515] In general, it is proposed a method for operating an apparatus, the method comprising: receiving a first message from a network function or an application function; determining based on the contents of the first message the energy requirements for processing a command towards a device; and adapting at least a parameter of a communication procedure between the apparatus and the device to ensure that the device can process the command transmitted in the communication procedure.

[0516] Section: S - Adaptive communication procedure depending on service request

[0517] In certain scenarios, a service request from the AF / NF (e.g. in message 903 in Fig. 9a) may be an inventory-only request or a command request (e.g. write command to store some data onto the Ambient loT device) or a combined inventory-command request (e.g. a request that indicates that the inventory is for the purpose of issuing a command). The result of such command may be to activate an actuator operated by the Ambient loT device, e.g. open a door. It is important for the user that such command is performed in a responsive manner. Also a command procedure usually requires an authentication step, also for that it is important that theauthentication can be performed in a timely manner otherwise some temporary information may be lost (e.g. when the Ambient loT has insufficient energy to maintain the volatile memory or has insufficient energy to write to non-volatile memory) and the authentication procedure would have to be performed all over again. Unless it is already known beforehand if an Ambient loT device is in coverage range of a reader, it is important to discover the Ambient ioT device first by performing some inventory first. Performing a full inventory before sending a command may result in delays of more than 30 seconds according to clause 7.2.2 of TR 38.769 for a group of devices. For a single device, the inventory is more acceptable, i.e. possibly below 1 second if close to the selected reader, according to clause 7.2.1 of TR 38.769. However, this requires handling differently different types of requests executed by a reader. It is a goal of the invention to address this need.

[0518] In an embodiment that may be combined with other embodiments or implemented independently, if a reader receives a service request that includes a command / command request or indicates that an inventory is for the purpose of issuing a command, e.g., to a specific AIoT device / tag, then the reader may apply a higher priority and / or a different timer (in particular with a shorter timeout value) to send a request burst to the Ambient IoT device and / or the request burst may have less slots (e.g., a single slot allocated to the addressed device) and / or the request burst may allocate a contention free slot to the addressed device and / or the allocated contention free slot may be located at the beginning of the request burst and / or apply a higher priority or a different timer to transmit a response received from the Ambient IoT device(s) to the AF / NF, than e.g., if the service request includes a request for inventory only, and / or if the message that includes the service request indicates that the service request is addressed to multiple devices rather than a single device (or in general depending on the amount of devices that are addressed). If the reader has received multiple other service requests (e.g. to perform inventory only) and / or is already operating some other ongoing service request procedures, the reader may handle the command or related inventory request first or put it in front / earlier in the queue of service operations and / or request bursts to be handled and / or handling of forwarding received responses from the Ambient loT devices to the AF / NF, and / or may interrupt ongoing service operation.

[0519] . The reader may apply a lower priority and / or a different timer (e.g. with a longer timeout value) to send a request burst to the Ambient loT device and / or the request burst may have more slots and / or the request burst may allocate no or less contention free slots to the addressed device and / or the allocated contention free slot may not be located at the beginning of the request burst and / or a lower priority or a different timer is used to transmit a response received from the Ambient loT device to the AF / NF, e.g., if the service request includes a request for inventory only, if the reader has received multiple other service requests (e.g. to perform inventory only) and / or is already operating some other ongoing service request procedures, and / or if the message that includes the service request indicates that the service request is addressed to a single devices rather than multiple devices (or in general depending on the amount of devices that are addressed).

[0520] Additionally or alternatively, the reader applies a different aggregation configuration / policy for transmitting the responses received from one or more Ambient loT devices to the AF / NF (e.g. send the response as soon as possible when received, possibly not even waiting for a timeout value).

[0521] Additionally or alternatively, if the reader can (securely) identify the respective Ambient loT device(s) after receiving a response to a paging message or response to a command request (e.g. based on a matching temporary ID derived from a long term ID), then it may apply a higher priority or a different timer to and / or a different aggregation configuration / policy for transmitting the responses received from the Ambient loT device(s) to the AF / NF (e.g. send the response as soon as possible when received, possibly not even waiting for a timeout value).

[0522] Additionally or alternatively, the reader may receive information and / or a configuration from the network / application about: priority or QoS value for handling a service request (from which the reader can derive a set of timers / timeout values or aggregation configuration / policy), time indication / preference and / or timeout value for sending the request burst and / or sending the response to the AF / NF aggregation configuration / policy information on how to (securely) identify the addressed Ambient loT device(s) whereby this information may be differentiated per device (e.g. for a set of matching device IDs, group IDs or device types) or per type of service request or per command or per “session” ID. This information may be provided together with receiving the service request or pre-configured to the reader (e.g. as part of a policy configuration / update procedure). The reader may use this information to select communication parameters for the radio interface / communication with the ambient loT devices / tags, e.g., as explained in the embodiment and other embodiments, e.g., by selecting the number of slots in a request burst, allocating contention free slots, selecting suitable timers, etc. The configuration may also indicate how these parameters are to be selected.

[0523] Section: S / R2 - Inverse paging

[0524] In some situations, a tag may not wait till it gets a request from a reader (e.g., intermediate UE or gNB, in general RAN) but it may send a message (AWAKE signal) to the reader. Such operation may be called Device Originated Autonomous (DO A) communication. The reason is that some tags may not have always energy, but rather collect it via energy harvesting techniques, and when enough, wake up to communicate. Upon reception of the AWAKE signal, the RAN may then send a message (e.g., request message) requesting data from the tag or delivering data to the tag, as needed. For this type of tags, a reader may try sending a request message on-demand, but the request message may not be received by a tag simply because the tag does not have enough energy at the point of time when the request (burst) is sent. In reference to Fig. 7, 700 may represent a tag and 701 may represent the RAN. At time 702, the RAN may receive a request (e.g., from the core network or from an application function) to request the presence of 700. At a later time 703, the tag has harvested enough energy so that it can transmit the AWAKE signal 704, so that the tag can send the request towards tag 700. Then the tag replies in message 706. At a later point of time the RAN 701 gets data to transmit to the tag. At later time 708 the tag gathers again enough energy so that it sends a new AWAKE signals at time 709. The RAN 701 delivers the data in message 710. To improve this type of procedure, the following embodiments may apply:

[0525] In an embodiment that may be combined with other embodiments or used independently, the AWAKE signal may include an identifier of the Ambient loT device that can be used for inventory purposes (e.g. a permanent identifier or part thereof, or temporary ID mapped to a permanent identifier), so that a subsequent request message may not be needed. Furthermore, the RAN 701 may report the presence of the tag to the CN at that point (e.g. as a (delayed) inventory response). Alternatively 704 and 706 are combined in a single message and no request is transmitted to the tag.

[0526] In an embodiment that may be combined with other embodiments or used independently, prior to sending a request message or a request burst, the reader (or other device in the RAN) sends a powering signal. The powering signal may be, e.g., the preamble itself, so that by receiving the preamble, the tag may absorb the energy that is used to load a capacitor and start running the internal logic (e.g., clock) and getting the clock synchronized with the synchronization signal in the preamble allowing the reception of the rest of the request message and the later transmission or backscatter operation. This way, the tag can communicate with the reader even if it does not have a battery or other power source, and the reader can discover and identify the tag without waiting for its spontaneous message. The powering signal may also be a separate signal.

[0527] In an embodiment that may be combined with other embodiments or used independently, the RAN may just send a request burst but lacking the request messages, i.e., just including the illuminating signal. This allows tags that are backscattering -capable only to reply and send the AWAKE signal. Then the process may follow.

[0528] In an embodiment that may be combined with other embodiments or used independently, a tag roaming into a new area / region with ambient loT network deployed by a visiting PLMN may send the AWAKE signal to the reader to notify the presence of a new tag from a home PLMN, reader may forward the information to the network function in the core network or application function, and then a roaming procedure may be initiated by the network function in the core network or application function.

[0529] Section: S3 - Inverse paging: security related additions

[0530] The following embodiments are described in the context of Device Originated Autonomous (DOA) communication, but they may also apply to DT / DO-DTT operation, e.g., as illustrated in other embodiments, e.g., related to Fig. 9.

[0531] In an embodiment that may be combined with other embodiments or used independently, the tag 700 has a key and a cryptographic function such as ASCON, AES, a pseudorandom function, a New Radio (NR) Encryption Algorithm (NEA) or a NR Integrity Algorithm (NIA). The RAN 701 has also been configured with the same key. The cryptographic function and the key are used to generate a token that is sent in the AWAKE signal so that the reader can verify the token, and only if the token is verified, send a further message to the tag. This way, the tag can authenticate itself to the reader and prevent unauthorized access or cloning or privacy tracking. For instance, the tag may generate a random value and obtain the token as the least significant bits of HMAC(k, random), or it may use ASCON as an XOF initialize with the key and retrieve 16 more bits of the XOF or it may use an encryption function in counter mode and apply the encryption function that takes as input the key to an increasing counter. The token may be based on a challenge-response protocol, where the reader sends a random nonce in the request message (e.g., in the request burst) and the tag uses it as an input to the cryptographic function along with the key. The first time the tag may apply the cryptographic function to a pre-configured random nonce, that is updated in the answer of the RAN 701 to the AWAKE signal. For instance, in message 704 the tag 700 may use a random nonce that may have been preconfigured. In message 705 the tag 700 may receive a new nonce. This new nonce may then be used in the later AWAKE signal 709. The token may also include a tag identifier or other information that the reader can use to identify the tag. The reader may have a database of the keys and identifiers of the valid tags, or it may use a public key infrastructure (PKI) to verify the tokens. The AWAKE signal may be transmitted using backscatter modulation or active transmission, depending on the power availability of the tag. The AWAKE signal may also be sent periodically or triggered by a sensor or event. The AWAKE signal may include other information such as the status or location of the tag that may facilitate later communication with entity 701.

[0532] In a related embodiment to the previous one that may be combined with other embodiments or used independently, the tag transmits in the AWAKE signals a (one-time) pseudonym pID. An initial pseudonym may be configured in the tag prior to deployment. The pseudonym is securely updated in the subsequent answer provided by the reader / RAN, e.g., the next pID may be encrypted by XORing the pID determined by the reader / RAN with the output of the cryptographic function described in previous embodiment. For instance, if pID is 16 bits long, ASCON may work as an XOF, and 32 bits may be retrieved from its internal state as XOF1 | XOFO where XOF1 refers to the 16 most significant bits of the 32-bit XOF output and XOFO refers to the 16 least significant bits of the 32-bit XOF output. Then the reply to the awake message may contain: XOF1 XOR pID | XOFO. When receiving this message, the tag may obtain the next 32-bit XOF output, check the freshness of the message based on XOFO and retrieve pID by XORing the received XOF1 XOR pID with XOFl again.

[0533] In an embodiment that may be combined with other embodiments or used independently, the AWAKE signal may be or contain a preamble as shown, e.g., in Fig. 6, where the ID may be a service ID or a device ID, or a pseudonym (pID) and the security check may refer to an authentication tag (e.g., the token in previous embodiment or MIC computed over the ID or encrypted ID or pseudonym) so that the AWAKE signal is only processed accepted if the verification of the authentication tag succeeds. In a particular option, a subsequent action (e.g., delivery or data or delivery of a new pseudonym is only executed if the verification of authorization tag succeeds. In a related embodiment to the previous one that may be combined with other embodiments or used independently, the ID in Fig. 6 is encrypted with a public-key, e.g., with the public-key owned by the RAN (or other network entity such as a network function in a core network or an application function) so that the identity of the tag remains confidential.

[0534] In a related embodiment to the previous one that may be combined with other embodiments or used independently, the ID in Fig. 6 is the pseudonym in previous embodiment. In an embodiment that may be combined with other embodiments or used independently, the AWAKE signal (e.g., 704 in Fig. 7) may play a similar role as signal 503 in Fig. 5, that may then be followed by signal 504 in Fig. 5 as an answer from the reader / RAN, then be followed by signal 505 as an answer from the tag, and then be finally acknowledged by the reader / RAN with signal 506, although as seen in Fig. 7 not all these messages may be needed.

[0535] In an embodiment that may be combined with other embodiments or used independently, if the tag used a group ID in its AWAKE signal, then the answer of the reader / RAN is a broadcast message, but if it is a device ID or pseudonym, then the answer is a unicast message.

[0536] Section: S3- Security aspects related to the preamble protection and processing

[0537] In a further related embodiment that may be combined with other embodiments or used independently, the identification sequence in a preamble or in an initial message is scrambled with a scrambling sequence obtained by means of a cryptographic function (e.g., HMAC, ASCON,...) that takes as input a key and part of the information in the preamble.

[0538] In a further related embodiment that may be combined with other embodiments or used independently, the preamble includes also a value (e.g., appended after the synchronization sequence) that is used to compute an authentication tag, e.g., message authentication code, by means of a security function (e.g., HMAC based or based on ASCON) and a secret key. The input to the security function may be the concatenation of the synchronization signal, service identifier (or similar identifier), and value and may also use as input the secret key. This is advantageous because a tag may only process the request message if the processing of the preamble is successful, and the message authentication code matches the expected one. This can prevent malicious attacks or interference from other sources that may use the same frequency band. The secret key may be shared among the tags and the reader in advance and linked to the, e.g., service identifier, or derived from a common secret. The value used to compute the message authentication code may be a random nonce, a timestamp, a counter, or a combination thereof.

[0539] In a further related embodiment that may be combined with other embodiments or used independently, the security filtering proposed in previous embodiments may be applied after acquiring the preamble and getting synchronized. For instance, the field after the preamble may be a service identifier that may be scrambled or after which a MAC may be included so that the tag receiving the message can check whether the message is intended for it or not and whether it is coming from a trusted source before further processing it (and spending additional energy). Only if the security processing succeeds (service identifier is unscrambled properly or the MAC verification succeeds), the rest of the message is processed.

[0540] In a further embodiment that may be combined with other embodiments or used independently, the preamble may be followed by the rest of the request message, which may contain additional information and instructions for the tag. The tag may only receive and process the rest of the request message if the preamble is processed correctly, i.e., the tag has successfully synchronized its clock and verified that the request message belongs to the service that the tag is associated with, and / or a security check is passed. Note that these conditions may be done in a consecutive manner, e.g., first the preamble provides a given level of synchronization, then the preamble includes a known identifier (e.g., service identifier) the tag is associated with, and then the security check passes. If any condition is not met, then the processing stops. If all conditions are met, then the rest of the message is processed. Note that the field including the known identifier and / or providing the security check may be within the preamble or right after the preamble and before the remaining of the message. This can allow the tag to save energy by avoiding unnecessary reception and processing of irrelevant or malformed messages.

[0541] Section: S3 - Clarifications about the architecture of inverse paging and involvement of the core network

[0542] In an embodiment that may be combined with other embodiments or used independently, the reader or RAN (e.g., a UE acting as an intermediate node or a base station) may act in a transparent manner forwarding messages between the tag and a network function (NF) in the core network or application function (AF) in or outside the core network (not visible in Fig. 7), in particular:

[0543] The NF and / or AF may own / keep track of cryptographic keys and the protocol (e.g., to protect a preamble or to protect an identity or to generate a pseudo identifier) may run end-to-end,

[0544] The NF and / or AF may keep track of tag identifiers (e.g., device ID, group ID, ...) and / or pseudonym (e.g., pID) linked to a tag, pID in above entity may play the role of a 5G-GUTI.

[0545] Section: S3 - Further clarification regarding the role of the reader / RAN / core network / application function in protecting data Fig. 8 describes interactions between several (not all of them may always be present) entities in the system. 800 refers to one or more tags. 801 refers to a user equipment (UE) that may interact with the tags. 802 refers to an access device (e.g., 5G gNB) that may also interact with the tag, directly, or through UE 801. 803 refers to a core network of a telecommunication system such as the 5G CN. 804 refers to an application function that may own one or more tags 800.

[0546] In an embodiment, that may be combined with other embodiments or used independently, a tag or AIoT device may be provisioned / configured or pre-configured with parameters (e.g., credentials) and / or configurations and / or policies (e.g., network policies). For instance, the tags may be manufactured with some credentials (e.g., an identifier and some keying materials (e.g., a symmetric key)) and those credentials may then be stored in the AF and / or CN, e.g., in a database containing those credentials. For instance, an application may be in charge of the manufacturing and may then provide the CN with those credentials. For instance, an operator of a core network may manufacture tags, and store the credentials of those tags in a database in the core network. The operator of the core network may then ship / sell tags to an end user or application function. For instance, the AIoT Device(s) may be provisioned with (long term) credentials which form or are used to derive the root of said security context, wherein security materials used for the protection of a communication session (e.g., to update a policy at the AIoT Device) may be derived from the root credentials, and taking as additional input other parameters e.g., timestamp, Nonce(s), counter, and / or Device ID. Note that the AIoT Device may be provisioned with more than one set of root security keys, in which case, the CN (e.g., AIoT Controller therein) may include an identifier, e.g., a key identifier, or a part thereof (e.g., k LSBs / MSBs) in the message sent to the AIoT Device. Step 805 represents this provisioning / configuration / preconfiguration step. In an example, the provisioning / configuration of the AIoT device may include a policy / configuration which determine aspects including, but not limited to, the following:

[0547] - A list of trusted readers (incl. one or more identities) and optionally their capabilities, security keys per reader or reader type.

[0548] - Which keys to use to decrypt and / or verify the protection of certain type(s) of illumination signal or request message.

[0549] - Which keys to use in the response to an illumination signal or request message coming from a certain reader, or the response to a certain type(s) of illumination signal or request message. The keys to be used may differ depending on the topology (e.g. in topology 3, even though the request / illumination signal is received from e.g. an intermediate device and may e.g. security keys for the specific type of reader for decrypting the received message, the keys for direct communication with a gNB / CN may be used in the response).

[0550] In an embodiment, that may be combined with other embodiments or used independently, such configurations and / or policies may require updates from the CN (e.g., AIoT Controller) and / or AF. Such updates may be sent to AIoT device(s) using “commands”. The CN may use similar / same “commands” as commands that originate from the AF, e.g. by reusing a command of type “write” but with a different payload. These commands may include parameters to indicate the origin of the payload, e.g. AF, CN or Reader and / or may include parameters to indicate the type of security keys (e.g. AF provided security key or CN provided security key) and / or indicate an identifier for a specific security key. In case of CN, these commands / updates may be sent to AIoT device(s) protected using security materials shared between the AIoT Device(s) and the AIoT Controller (or another NF within CN) thus forming a NAS-like security context. Additionally or alternatively, such updates may be sent to AIoT devices protected with security materials shared between AIoT Devices(s) and an application function, wherein the AF receives the updates first from the NF in the CN. Step 806 represents this update step.

[0551] In an embodiment that may be combined with other embodiments or used independently, a tag or AIoT device may include:

[0552] (1) application long term credentials configured by the application function and used for the end-to- end communication between the application function and AIoT device and / or

[0553] (2) CN credentials used for the communication between AIoT device and CN (e.g., AIoT controller) and / or

[0554] (3) RAN credentials used for the communication between AIoT device and RAN (when the communication involves a given access device), and / or

[0555] (4) UE credentials used for the communication between AIoT device and UE (when the communication involves a UE).

[0556] In an option of this embodiment, the application long term credentials may be derived from the CN credentials. For instance, if the CN credentials are a key and an AIoT identifier, the CN may derive long term credentials for the application by using the key to derive the long term credentials, e.g., by applying a key derivation function. This allows sharing a tag with multiple applications. For instance, if the operator of a CN sells the tags to a given application, the CN may then share with the application tag specific keys for that application. In an option of this embodiment, the CN credentials may be derived from the application long-term credentials. For instance, if the long-term credentials are a key and an AIoT identifier, the CN may obtain CN credentials that are derived from the application long-term credentials, e.g., by applying a key derivation function to the key and other parameters such as the network ID (PLMN ID) or other communication parameters. This allows an application to use multiple CNs. Furthermore, when a CN communicates with an AIoT device, AIoT device knows the CN is authorized because it has keys that have been issued for that network. In an option CN and application may have a communication interface to exchange AIoT information, in particular, keys or AIoT identifiers. In an option long term credentials and CN credentials may be independent of each other. In an option of this embodiment the RAN and / or UE credentials may be derived from the application long term credentials or the CN credentials. In Fig. 8, steps 807, 808, 809 and 810 indicate that the interactions between tag and entities 801, 802, 803, and 804 may be protected by different keys. In some example interactions: in step 807 an application function 804 may need access to information from the tags (e.g. sensor data) or may provide commands (e.g. instructions such as read or write or disable) with related payload (e.g. application configuration data). These commands and information received from the tags may be protected with the long-term credentials related to the particular application function 804. in step 808 the CN 803 may need access to information from the tags (e.g. information on the device capabilities) or may provide commands (e.g. instructions such as read or write identity information or network / communication configuration information) with related payload (e.g. identity information, policy data). These commands and information received from the tags may be protected with the CN credentials used for the communication between AIoT device and CN (e.g., AIoT controller). in step 809 a reader may need access to information from the tags (e.g. energy level, RAN configuration) or may provide commands (e.g. change modulation type, set timer / timing / timeout value (e.g. delay time, sleep interval), provide wake-up schedule, schedule (semi-persistent) resources) with related payload (e.g. RAN configuration information, time related value). These commands and information received from the tags may be protected with the RAN credentials or UE credentials used for the communication between AIoT device and the reader, depending on whether the reader is a RAN node or a UE. The reader and / or tag may include a flag in downlink respectively uplink messages to indicate which type of credentials is used. Additionaly or alternatively, the reader and / or tag may include a flag in downlink respectively uplink messages to indicate which type of reader (e.g. UE or RAN node) is used for communication.

[0557] In an embodiment that may be combined with other embodiments or used independently, a command sent to a tag may be linked to a command type and different command types may be processed with different keys (e.g. a command type to initiate reading / fetching information from the AIoT device may be processed with different type of key (e.g. non-signed public key) or different length of key (e.g. shorter) or different lifetime of key (e.g. shorter) than a command type to initiate writing / reconfiguring information onto the AIoT device (whereby the command may be e.g. protected using a signed public key for which the trusted root is stored on the AIoT device for verification of the signature)). An application command transmitted by the application may be processed with a key related to the long term credentials issued to an AIoT device. A network command may be processed with a key related to the CN keys.

[0558] In an embodiment that may be combined with other embodiments or used independently, an application fully relies on the network for the communication with an AIoT device, and all commands are protected with keys derived from or based on the CN credentials. The CN then acts as middlebox when interfacing with the application that is requesting different actions with the AIoT devices. These keys may still be used in a container-based like approach enabling multiple types of protocols for performing authentication / key establishment.

[0559] Section: S - Procedure to allow an application to own and interact with tags through CN

[0560] In an embodiment that may be combined with other embodiments or used independently, after configuration, an application function 804 may send a request 811 to the core network 803 to query / perform inventory of tags 800. In Step 812, the core network 803 may then check whether the application is authorized to interact with the tags, and identify the UE 801 and / or RAN 802 that may be able to interact with tags 800. The core network may share the query / inventory with the identified UE / RAN. The identification of the tags to be queried may be done by means of an identifier as in other embodiments, e.g., a service identifier, or a tag identifier, or a tag pseudonym. UE 801 and / or RAN 802 may interact with tags 800 in Step 813, e.g., as in other embodiments in this invention with the purpose of, e.g., retrieving data (e.g., identifier) from the tags and / or configuring the tags 800. UE 801 and / or RAN 802 may provide the core network 803 with a confirmation of the interaction and / or collected data in Step 814. All or part of the received data may be shared with the application 804 in step 815.

[0561] :: S3 - Procedure to enable secure communication with a TAG via the user plane In an embodiment that may be combined with other embodiments or used independently, a tag key management function (TKMNF) is defined in the core network that handles the Ambient loT (core network) keys, and these keys are used to perform a security protocol with the tag over the user plane. This allows for a similar interaction pattern independently of the type of the reader, a UE (topology 2) or a base station (topology 1).

[0562] In particular, the TKMNF can perform a protocol to enable the mutual authentication of tag 800 and TKMNF, and transfer data — securely — between tag and TKMNF. The TKMNF may be associated and / or handle the association with the application function that owns the tag, or it may be a separate entity that communicates with the application function. The TKMNF may have access to the tag identity and the corresponding key, which may be shared with the application function, e.g., when the tag is purchased or registered. This key may be in general any type of credentials that may be used in the security protocol. The TKMNF may also have access to the tag identifier, e.g., Tag ID, that is linked to the tag , as well as the UE ID and / or RAN ID that can interact with the tag.

[0563] In one example, the security protocol may be based on the EAP-AKA' (Extensive Authentication Protocol - Authentication and Key Agreement prime) algorithm, which is used for authentication and key agreement in 5G networks. The EAP-AKA' algorithm uses symmetric cryptography and challenge-response mechanisms to authenticate the parties and generate session keys. The EAP-AKA' algorithm may be modified to suit the tag scenario, e.g., by using the tag identity and key instead of the IMSI and K, and by using the TKMNF instead of the AUSF. The EAP- AKA' messages may be encapsulated in the user plane packets that are exchanged between the UE and the tag, and relayed by the RAN 802 and the core network 803 to the TKMNF. The UE may act as a proxy that forwards the messages without processing them, or it may participate in the protocol by verifying the messages and generating its own session key. The RAN and the core network may also act as proxies, or they may enforce some security policies, e.g., by checking the authorization of the UE and the TKMNF to communicate with the tag. After the successful completion of the security protocol, the tag and the TKMNF may have established a secure channel that can be used to exchange data, e.g., configuration commands, sensor readings, or status updates. The data may be encrypted and integrity-protected with the session keys derived from the EAP-AKA' algorithm. The data may also be encapsulated in the user plane packets that are routed between the UE and the tag, and relayed by the RAN and the core network to the TKMNF. The TKMNF may then share the data with the application function, or process the data according to the application logic. Additionally or alternatively, the data may be sent to the UPF.

[0564] In another example, the security protocol may be executed as illustrated in Fig. 9a where 900 may be the tag and 902 maybe the TKMNF. Message 903 / 4 may be a request (challenge) as in other embodiments created by the TKMNF, these messages may include, e.g., a first nonce. Messages 905 / 908 may be the answer created by the tag (as part of a challenge / response protocol), these messages may include, e.g., a second nonce. Upon reception of 908, the TKMNF may verify the tag. The answer may be messages 909 / 906 and may allow the tag to verify the TKMNF. The tag may then derive a session key that may be used by the tag to protect data sent in messages 907 / 908’ and received in messages 9097910. The session key may be computed by means of a key derivation function KDF taking as input the key (a key shared between the tag and the TKMNF), and the first and second nonces. Other input may be, e.g., the tag capabilities. This session key may be used to encrypt, or integrity protect or both the exchanged data.

[0565] In an embodiment that may be combined with other embodiments or used independently, prior to a message exchange as in previous embodiment, a tag may have received a wake up message from a reader, e.g., a UE, requesting the tag to identity / authenticate itself. The tag may send a generic message, powering the tag. The message may be generic since the reader may not know the identity of the tag. The tag may encrypt its identity / service with a key (e.g., symmetric key) shared with the TKMNF and may send, e.g., E{ID, K, Nonce}, i.e., protected ID under key K (shared with TKMNF) using Nonce. This key K may be a key shared with multiple devices. Upon reception of this message, the TKMNF may start above procedure with messages 903 / 904. The message may include the identity of, e.g., the TKMNF and / or home network and / or application ID. This identity can be used by the reader to route the message in a suitable manner. Upon decryption, the TKMNF may know the identity of the tag, and may proceed to request and / or receive data from the tag, wherein a procedure as in previous embodiment may be applicable.

[0566] Section: S - Procedure to allow a user to own and interact with tags through CN

[0567] In an embodiment that may be combined with other embodiments or used independently, a user may have a subscription that is stored in the core network. This subscription may be for his UE 801. This subscription may be linked to some credentials, e.g., the credentials (e.g., long-term key) of a unique user identifier such as a SUPI. The user may buy one or more tags 800, e.g., from the operator of the core network or an application. The operator may then add the identities of said one or more tags to the user subscription:

[0568] SUPI

[0569] TAG ID1

[0570] TAG ID2 TAG IDN

[0571] This information may be stored in a network function for user authentication and / or a network function specific for the management of tags and tags information.

[0572] This may have been done, e.g., in steps 805 and / or 806 in Fig. 8. The user may use the tags to track some personal items, e.g., a backpack, or a pet (e.g., a dog), or a child. At some point of time, the user may wish to determine the location of a tag, so that the user may use his UE 801 to send a request 816 (in general, interact) to the core network 803 to perform a tracking operation. The core network may then verify whether the user is authorized to perform the tracking operation, and the core network may select the tag identity (could also be multiple tag identities) and / or keying materials to create a query for the one (or more tags). The tag identities that may be selected are from those linked to the identity of the user in the user subscription. The core network may then identify the last known location of the tags.

[0573] SUPI

[0574] TAG ID I, LOCATION 1

[0575] TAG ID2, LOCATION2

[0576] TAG IDN, LOCATIONN

[0577] The core network may identify suitable UEs or access devices to deliver a query to the tags based on this last known location. The core network may then create and share said query with the selected UE / access devices in Step 817. In step 818, UE 801 may interact with tags, obtaining an answer (that may also be interpreted locally by the UE without further intervention of the core network). In step 819, RAN 802 may interacts with tags, obtaining an answer. In some cases, a tag may use different credentials (e.g., keys) depending on whether the tag communicates with a UE reader, or a base station reader, or with the NF / AF. In some cases, a tag may have some root credentials and may derive different keys from them, depending on whether the tag communicates with a UE reader, or a base station reader, or with the NF / AF. In step 820, RAN 802 may share the answer with core network 803 that may update the information about the tag(s), e.g., its location. In Step 821, the UE 801 may upload information to core network 803 (e.g., answer of the tag as per step 818) and / or may receive information from the core network 803, e.g., information about the requested tag. In an example, the UE may send a command to play a sound and / or blink a light to allow the user to identify the position of the tag.

[0578] The operator may charge a fixed monthly fee for each of the tags associated to the user subscription, plus a given fee for a number of queries / requests. In some examples, a user may own a UE and the subscription of the UE may be linked to one or more tags. In an example, the UE may be used as the (preferred) reader for the tags.

[0579] In above embodiments, the core network may use the CN credentials to issue queries or commands towards the tags. The same CN credentials may be used by the tags to protect their answers or derive pseudonyms or protect identifiers.

[0580] In an embodiment that may be combined with other embodiments or used independently, the credentials (e.g., a symmetric key) of a tag may be derived (e.g., by means of a cryptographic function) from the long term credentials of the UE, e.g., by means of a cryptographic function, e.g., a key derivation function and / or may be stored in the UE itself (e.g., in the USIM). This may allow both the network / application AND UE to compute a valid (i.e., secure) message, e.g., a valid message to send a paging / request message to the tag. A UE may be considered trusted, and thus, a UE may be authorized to send such requests (e.g., location request) and replies from the network. In an example, only the results of the procedure are uploaded (e.g., an updated location, status, etc). In an embodiment, the UE may be configured to regularly “ping”, i.e., verify the presence of the device, e.g., by sending a request message. The UE may be configured to request the network / application (e.g., a network function used to keep track of the positions of the tags), to obtain the position of the tags when they are not in the reach of the UE.

[0581] In an embodiment that may be combined with other embodiments or used independently, the credentials (e.g., a symmetric key) of a tag may be derived (e.g., by means of a cryptographic function) from the long term credentials of the UE, e.g., by means of a cryptographic function in such a way that the UE is authorized to perform only some actions. For instance, a UE may store long term key K and the tag may store long term K’ = F (K | parameters), i.e., K’ is obtained as a function of K and some parameters, e.g., the long term identity of the tag (e.g., its electronic product code). The tag may also store some other parameters, e.g, a second key KI. Some commands may be accepted if protected by means of a key or parameter derived from K’ . Some commands may be accepted if protected by means of a key or parameter dependent on KI .

[0582] Section: S3 - Bootstrapping CN credentials

[0583] In an embodiment that may be combined with other embodiments or implemented independently, an ambient loT device may have a secure storage and / or hardware element containing application credentials. Based on an exchange between an AF and CN, the CN credentials to be used are encrypted using AF credentials. The CN may receive the encrypted payload (i.e. which includes the CN credentials) and forward it to a reader which may transmit the encrypted payload to an ambient loT device, upon which the ambient loT device may decrypt the CN credentials, store them and use them in subsequent communication between the ambient ioT device and a core network. Additionally or alternatively, in order to enable an ambient loT device to connect to the AF to retrieve the CN credentials, a reader may indicate (e.g. by means of a flag / message / payload as part of an illumination signal or a subsequent downlink message) to the ambient loT device that the reader is capable to connect the ambient loT tag to an AF (possibly including an identifier of the AF), upon which the ambient loT device may generate and transmit the necessary messages to connect with the AF.

[0584] Additionally or alternatively, the ambient loT tag may indicate to the reader (e.g. by means of a flag / message / payload as part of a backscattered message) that it wants to establish a connection to an AF (possibly including an identifier of the AF)(e.g. because it does not have any CN credentials yet or the CN credentials are not valid anymore), upon which the reader may forward the subsequent messages from the ambient loT device to the AF and vice versa.

[0585] In an embodiment that may be combined with other embodiments or implemented independently, an ambient loT device may have secure storage and / or hardware element containing default credentials (e.g. shared key or public key and / or device / user identity) and / or bootstrap profile (e.g. similar / same as Issuer Security Domain - Root (ISD-R) as specified by GSMA SGP.01 v4.1) to securely connect to a subscription manager (e.g. similar / same as specified by GSMA SGP.01 v4.1), whereby the subscription manager comprises a routing entity (SM-SR) configured to manage secure data communication with the ambient loT device and the service system, and a profile preparation entity (SM-DP) or similar entity, whereby (instead of generating an eSIM profile) the profile preparation entity or similar entity determines and / or generates a set of symmetric keys for a selected / pre-configured core network (which may be selected based on the default credentials used in the secure connection to the subscription manager and / or an identity of the ambient loT device transmitted by the ambient loT device to the subscription manager) and / or home network key or other CN credentials for a selected / pre-configured core network that can be used by an ambient loT device to protect communication between the ambient loT device and the selected / pre-configured core network, and provides the set of symmetric keys and / or home network key to the ambient loT device, which may store these credentials and use them in subsequent communication between the ambient ioT device and a core network. In order to enable an ambient loT device to connect to a subscription manager, a reader may indicate (e.g. by means of a flag / message / payload as part of an illumination signal or a subsequent downlink message) to the ambient IoT device that the reader is capable to connect the ambient IoT tag to a subscription manager, upon which the ambient IoT device may generate and transmit the necessary messages to connect with the subscription manager. Additionally or alternatively, the ambient IoT device may indicate to the reader (e.g. by means of a flag / message / payload as part of a backscattered message) that it wants to establish a connection to a subscription manager (e.g. because it does not have any CN credentials yet or the CN credentials are not valid anymore), upon which the reader may forward the subsequent messages from the ambient loT device to the subscription manager and vice versa.

[0586] Section: R2 / S3 - Further details on retransmissions , reliability, and protection against replay attacks

[0587] Document 3GPP TR 23.700-13 Study on Architecture support of Ambient power-enabled Internet of Things version 0.2.0 describes several architectures and message sequence charts on how the communication between core network, readers and Ambient loT devices (i.e. AioT devices) may occur. The communication between these imposes some security and privacy related challenges, in addition to reliability challenges (e.g. messages getting lost and requiring re-transmission). In particular, for the “Command” procedure (e.g. command to open a door), a solution is needed for the Ambient loT device to prevent replay attacks by a malicious reader whilst allowing for reliable retransmissions. As described in other embodiments, a reader may include a token / authentication tag for example in an AWAKE signal or in an initial request message so that a tag can verify the authenticity of the reader and e.g. check if the reader is part of a whitelist stored in the tag. However, simply being able to trust the reader is not sufficient to prevent against replay attacks. The reader would e.g. have to ensure that each time a message is sent to the tag, the message is protected with fresh credentials. Also trusting the reader requires UE or RAN specific credentials which may not always be possible to use or easy to deploy in case of Ambient loT devices. Furthermore, keeping track of counters or current time may not be so easy for Ambient loT devices.

[0588] In an embodiment that may be combined with other embodiments or used independently, an ambient loT device is provisioned / pre-configured with AF and / or CN credentials. The AF or CN may initiate communication with a reader in order to transmit a command to the ambient loT device. Next to the command for the ambient loT device to execute, the message from the AF (directly or indirectly via the CN) or CN to the reader may include an identifier of the ambient loT device, an application identifier, and / or a message counter and may be protected using AF and / or CN credentials. The ambient loT device may store an internal counter corresponding to the message counter and update the value of the counter (e.g. to the value of the message counter) each time a new message originating from the AF or CN is successfully received by the ambient loT device (i.e. from or through the reader). The ambient loT device may only accept the message as genuine if the message counter is bigger than the stored counter, and discard messages if the message counter is smaller or equal to the stored counter. If the counter is sufficiently big, then it can filter out replayed messages. However, if the communication between the reader and the ambient loT device was disrupted, then the ambient loT device may not receive the respective message. Until the ambient loT device successfully receives a new message, it is vulnerable to replay attack by a malicious reader. Therefore, in an option to protect against this, the message as constructed by the AF or CN includes a timestamp and / or validity time as part of its protected payload (e.g. relative to a reference time or last time that the message counter or stored counter was updated). In another option, the AF and / or CN credentials to protect the message need to be refreshed / updated after a period of time (e.g. related to a reference time or last time that message counter or stored counter was updated, possibly based on cycling through a set of keys or using a time value as input to a key derivation function). The AF or CN may provide this timestamp and / or validity time an / or time until AF and / or CN credentials need to be refreshed / updated and / or a separate retry time interval, possibly in addition to a retry frequency / interval to the reader and / or a field indicating a number of retries. The reader may use this to determine the time interval in which it is allowed to retransmit the same message to the ambient loT device. This can be blind retransmissions at a certain repetition rate for a certain number of repetitions. In the following description the terms retry, retransmit and repetition are equivalent and used interchangeably.

[0589] In a related embodiment that may be combined with other embodiments or used independently, the reader may be configured to retransmit the same message with a certain retry frequency (e.g. based on the received information from the AF / CN) until the retry time interval has passed or until it received an acknowledgement from the ambient loT device that it has correctly received the message or until the number of retries has been surpassed.

[0590] Similarly, in a related embodiment that may be combined with other embodiments or used independently, the ambient loT device may be configured with a retry time interval and / or retry frequency and / or number of retries, so that it may expect retransmissions of the same message to occur. Additionally or alternatively, the ambient loT device may receive or may be (pre-)configured with a retry time interval and / or retry frequency and / or number of retries, based on which the ambient loT will retransmit the same response to a message or to retransmit the same device originated message to the reader until the retry time interval has passed or until it received an acknowledgement from the reader that it has correctly received the message or until the number of retries has been surpassed. The retry frequency and / or retry time interval and / or number of retries may depend on a given QoS parameter or message type provided by the AF / CN to the reader or ambient loT device or may depend on the message to be transmitted (e.g. response requested from the ambient loT device (e.g. based on a request in an initial message from the reader e.g. carried as part of wake-up / paging or illumination signal)).

[0591] Additionally or alternatively, the retry frequency or retry time interval or number of retries may be configured by the AF / CN by means of a policy provisioned (e.g. by the AF / CN) to the reader and / or ambient loT device, whereby the policy may include conditions for different values of these fields. In an option, the retry frequency and / or retry time interval and / or number of retries may depend on a signal strength of a downlink signal / message (e.g. illumination signal) to be measured by an ambient loT device or on a signal strength of an uplink signal / message (e.g. backscattered signal) to be measured by a reader (as indicated in a condition). In another option, the retry frequency and / or retry time interval and / or number of retries may depend on the amount of energy available to an ambient loT device or amount of energy to be harvested (e.g. for (re-)transmitting a message) (as indicated in a condition). In another option, the retry frequency and / or retry time interval and / or number of retries may depend on the type of message to be transmitted (as indicated in a condition). The configuration / policy for retrying by the reader and / or ambient loT device may also include operational transmission values, such as transmit power, Modulation Coding Scheme (MCS), frequency band. Additionally or alternatively, the reader and / or ambient loT device includes the number of retry attempts (performed thus far or remaining) as part of an additional field in the transmitted message, whereby the additional field with the number of retry attempts may be protected using UE or RAN credentials. The reader and / or ambient loT device may also include the time of / until the next retry attempt as part of an additional field in the transmitted message, whereby the additional field with the time of / until the next retry attempt may be protected using UE or RAN credentials.

[0592] In a related embodiment that may be combined with other embodiments or used independently, retry frequency or retry time interval or number of retries may depend on an operational mode of the reader and / or ambient loT device (whereby the retry related values may be configured through a policy provisioned by the network), e.g. operational mode wherein backscatter communication is used or an operational mode wherein device originated signals are generated by an ambient loT device itself, and / or an operational mode for emergency communication or different power-saving operational modes. Additionally or alternatively, retry frequency or retry time interval or number of retries may depend on a coverage enhancement mode / level similar to LTE-M / NB-IoT (see 3GPP TS 36.300) but with specific levels for ambient loT, whereby the reader and / or ambient loT device may select a coverage enhancement mode / level based on a trigger from the network (e.g. RRC message, SIB). The number of retry frequency or retry time interval or number of retries for the different coverage enhancement modes / levels may be configured through a policy provisioned by the network. Additionally or alternatively, retry frequency or retry time interval or number of retries may depend on the tracking area of the reader and / or ambient loT device (whereby the retry related values may be configured through a policy).

[0593] In an example, the ambient loT device may be configured with a policy or receive a configuration message from the reader (e.g. RRC message, control information in the reader to device (R2D) link) indicating a retry frequency or retry time interval or number of retries (which as mentioned before is equivalent to number of repetitions), and use this to determine how many times to send (i.e. retransmit) RACH Msgl (i.e. signal 503 in Fig. 5) and / or RACH Msg3 (i.e. signal 505 in Fig. 5) during a 4-step RACH procedure or similarly how many times to send (i.e. retransmit) MsgA in a 2-step RACH procedure. The policy or message received from the reader may depend on certain conditions or may indicate different retry frequency and / or retry time interval and / or number of retries for different conditions as mentioned in previous embodiments, e.g. the retry frequency and / or retry time interval and / or number of retries may be given different values for different QoS parameters or different coverage enhancement modes / levels (that may be specified for Ambient loT) or different message type to be transmitted by the Ambient loT device (e.g. response requested from the ambient loT device (e.g. based on a request in an initial triggering message from the reader e.g. carried as part of wake-up / paging or illumination signal)) or on different signal strength levels (e.g. of a downlink signal / message or illumination signal, whereby the signal strength may be measured by an ambient loT device) or on different levels / amounts of energy available to an ambient loT device or amount of energy to be harvested (e.g. for (re-)transmitting a message). The policy or message from the reader may include operational transmission values, such as transmit power, Modulation Coding Scheme (MCS), frequency band to be used for retransmissions of RACH Msgl and / or RACH Msg3 and / or RACH MsgA messages. The ambient loT device may use the information configured by the policy or configuration message to determine (e.g. by evaluating the conditions, such as the amount of energy available to the ambient loT device or signal strength level) the number of retries, retry interval and / or retry frequency for re-transmitting Msgl, Msg3, MsgA during RACH procedure and / or for later transmissions. Additionally or alternatively, after a policy or configuration message is received by the ambient loT device it may be stored in permanent storage (e.g. such policy or configuration message may be part of a “write” command). The reader may trigger certain conditions based on the stored policy or previously received configuration message by the ambient loT device, e.g. by indicating a QoS value or coverage enhancement level / mode in a subsequent message to the ambient loT device. The ambient loT device may use the received QoS value or coverage enhancement level / mode to determine based on the stored policy or previously received configuration message the number of retries, retry interval and / or retry frequency to use for one or more subsequent message (retransmissions.

[0594] Additionally or alternatively, the ambient loT device may have stored the number of retries, retry interval and / or retry frequency for different QoS levels or coverage enhancement level / mode (e.g. as specified for Ambient loT in 3GPP specifications) in permanent storage (e.g. based on factory settings). Similarly as above, the reader may trigger certain conditions based on such preconfiguration stored in the ambient loT device, e.g. by indicating a QoS value or coverage enhancement level / mode in a message to the ambient loT device. The ambient loT device may use the received QoS value or coverage enhancement level / mode to determine based on the pre-configuration stored in the ambient loT device the number of retries, retry interval and / or retry frequency to use for one or more subsequent message (re-)transmissions.

[0595] Additionally or alternatively, in order to ensure that the AF / CN knows which messages have been successfully received, the ambient loT device should include one or more of the received counter values from one or more last received messages from the AF / CN (i.e. via the reader) in a response message or subsequent uplink message to the AF / CN, whereby these counter values need to be protected using AF / CN credentials. Based on this information, the AF / CN may adjust a counter and / or reconfigure a retry timer, retry interval, number of retries, operational mode for an ambient loT device or reader.

[0596] In an embodiment variant that may be combined with other embodiment variants, instead of or in addition to the reader re-transmitting the same message MSG1 from the AF / CN to an ambient loT device during a retry interval, the reader may transmit a message (e.g. NAS message using its own NAS security keys / context) to the CN or AF including a request for retransmission of MSG 1, upon which the AF / CN creates a new m...

Claims

CLAIMS1. A method for operating a device in low power communication, the method comprising receiving at the device a request message in a first request burst, wherein the request message includes an indication of a number of slots in the first request burst, selecting by the device a transmission slot number; transmitting by the device the reply message after the end of the request message in a slot corresponding to the selected transmission slot number.

2. The method of claim 1, wherein the selecting of the transmission slot number includes determining an apparatus identifier or a random number, selecting the transmission slot number on the basis of at least the number of slots and on the random number or the apparatus identifier, and wherein the transmitting the reply message is performed within the first request burst.

3. The method of claim 1 or 2, wherein the request message includes a request slot number indication indicative of a request slot number, the request slot number being the slot number within the first request burst in which the request message has been sent, and wherein the selecting the transmission slot number is performed on the basis of the request slot number indication.

4. The method of any of the preceding claims, comprising maintaining a count value of a number of subsequent received request messages, and triggering the step of transmitting the reply message on the basis of the count value.

5. The method of any of the preceding claims, wherein the transmitting the reply message in the selected slot number includes backscattering the reply message in a received illuminating signal.

6. The method of any of the preceding claims, wherein the reply message includes at least one or more of the following:- data obtained from a sensor,- an apparatus identifier,- a status of the device including one or more of an energy status, an indication that the device has more data to transmit, an amount of data, an amount of data to be transmitted by the device.

7. The method of any of the preceding claims, wherein each transmission slot is divided into one or more subslots; wherein the indication of the number of slots in the first request burst comprises an indication of slots and / or subslots; wherein the selecting of a transmission slot includes selecting a selected transmission subslot number; and wherein the transmitting the reply message includes transmitting in the selected transmission subslot number.

8. The method of any of the preceding claims, wherein a transmission slot and / or transmission subslot comprises time and frequency resources used to multiplex reply messages in time and / or frequency.

9. The method of claim 8, wherein the indication of the number of slots in the first request burst indicates one of:- a total number of slots / subslots, and available time slots / subslots;- a total number of slots / subslots, and available frequency slots / subslots;- one or more available time slots / subslots and frequency slots / subslots.

10. The method of any of the preceding claims, wherein the request message comprises one or more received identifiers, and wherein the method comprises determining that the one or more received identifiers matches one or more stored identifiers, and wherein the step of transmitting the reply message in the slot / subslot corresponding to the selected transmission slot / subslot number is conditioned to the result of the determining.

11. The method of any of the preceding claims, comprising receiving a second request message upon or following transmission of the reply message, wherein the second request message indicates the allocation of a contention-free slot for a subsequent communication, and the second request message is transmitted in the first request burst or in a second request burst.

12. The method of any of the preceding claims, comprising obtaining a random number or identity value equal to or greater than the number of slots, applying a function, wherein said function takes as input the random number or identity value and uniformly selects a slot and / or subslot.

13. The method of claim 12, wherein the number of slots is given by the number of time resources times the number of frequency resources.

14. The method of any of the preceding claims, wherein the request message comprises one or more authentication values, and wherein the method comprises determining an apparatus identifier or a random number and transmitting the reply message in the slot / subslot corresponding to the selected transmission slot / subslot number provided that the one or more authentication values can be successfully verified.

15. The method of claim 14, wherein the device is in a temporary disabled state.

16. The method of any of the preceding claims, wherein the request message comprises a first freshness parameter, and wherein the method comprising the device determining a second freshness parameter, obtaining an authentication value, and transmitting the freshness parameter and authentication value in the reply message.

17. The method of claim 16, comprising one or more of:- deriving a session key upon determining an indication in the request message requiring the derivation of the session key, and using the session key to security process a command in a subsequent access round and / or slot, wherein the subsequent slot and / or subslot are contention-free slots and / or subslots;- deriving an intermediate verification value and transmitting the intermediate verification value in the reply message.

18. An apparatus for low power communication, the apparatus comprising a receiver, a transmitter, a controller, and a memory storing instructions which, when executed, cause the apparatus to: receive a request message in a first request burst, wherein the request message includes an indication of a number of slots in the first request burst, select a transmission slot number; transmit the reply message after the end of the request message in the slot corresponding to the selected transmission slot number.

19. An ambient loT tag or a low power device comprising the apparatus in claim 18.

20. A method for a multiple access procedure, comprising selecting by a device a number slots nO for a request burst, transmitting a first request burst comprising nO slots, each slot including a request message.

21. A method for a multiple access procedure comprising: selecting by a device a number of slots nO for a request burst, transmitting a first request burst comprising nO slots, each slot including a request message, and each request message including a slot number indication indicative of the current slot number within the first request burst in which each request message is transmitted.

22. A method for a multiple access procedure comprising: selecting by a device a number of slots nO for a request burst, transmitting a first request burst comprising nO slots, each slot comprising one or more subslots, and each slot being preceded by a request message, receiving one or more replies from one or more responding devices in the subslots.

23. A method for a multiple access procedure comprising: receiving assistance information to perform an inventory procedure wherein the assistance information includes at least an indication of the number of devices in the inventory procedure, selecting a number of slots nO for a first request burst,sending a request message to a base station to reserve communication resources to perform the inventory procedure with nO slots, and transmitting the first request burst in the resources allocated by the base station, wherein the first request message comprises nO slots, each slot comprising one or more subslots, and each slot being preceded by a request message.

24. A method for a multiple access procedure, comprising:- transmitting a first request burst to two or more devices, wherein the first request burst comprises nO slots,- receiving at least a first reply from a first device in a contention-based slot during the first request burst, wherein the first reply from the first device comprises a random identifier,- transmitting a second request burst comprising nl slots indicating at least a first contention-free slot for the first device and the first identifier received from the first device, and- receiving a second reply from the first device in the indicated contention-free slot.

25. A method of any of claims 20 to 24, comprising monitoring the reception of one or more reply messages from one or more low-power devices in the time resources subsequent to the request message in each of the slots.

26. The method of any of claims 20 to 25, wherein a slot comprises one or more subslots and a reply message can fit within a subslot.

27. The method of any of claims 20 to 26, comprising transmitting an illuminating signal subsequent to some or each request message.

28. The method of any of claims 20 to 27, comprising monitoring for the reception of one or more reply messages from one or more devices in time and / or frequency resources subsequent to the request message in each of the slots.

29. The method of any of claims 20 to 28, comprising- determining an indication in a reply message from a first device, wherein the indication indicates that the device has more data to transmit and / or that the first device has a low energy status, and- transmitting a subsequent request message allowing the first device to perform the data transmission.

30. The method of any of claims 20 to 29, comprising- determining the need to transmit a second request burst,- selecting the number of slots nl of the second request burst, and- transmitting the second request burst with nl slots.

31. The method of 30, wherein the determining the need to transmit the second request burst and / or the selecting of the number of slots nl includes estimating the number of devices seeking access based on at least one of:- a number of collisions per slot,- a number of slots without reply, and / or- a number of slots in the first request burst in the first request burst.

32. The method of any of claims 20 to 31, wherein the first request burst and / or the second request burst contain at least one contention free slot.

33. The method of any of claims 20 to 32, comprising receiving a first reply from a responding device to a first request message in a contention slot and a second reply by the responding device to a second request message in a contention-free slot.

34. The method of any of claims 20 to 33, comprisingadjusting the duration of a slot and / or subslot upon determining the presence of a reply message in the slot and / or subslot.

35. The method of any of claims 20 to 34, comprising sending a request message to a base station to reserve communication resources to perform the multiple access procedure.

36. The method of claim 35, comprising receiving a configuration message from the base station with the reserved communication resources to perform the multiple access procedure.

37. The method of any of claims 20 to 36, comprising receiving assistance information from a network or application function wherein the assistance information comprises one or more of:- an estimated number of devices seeking access;- one or more long-term identifiers;- configuration parameters indicative implicitly or explicitly of one or more device types and / or communication parameters including one or more of timing values, TR2D_max value, supported multiple access procedures, supported parameters in the multiple access procedures;- a configuration determining the conditions to send a request message and / or retry sending a request message to a device.

38. The method of any of claims 20 to 37, comprising receiving assistance information from a communication device (NF / AF) wherein the assistance information comprises one or more of:- one or more intermediate verification values;- one or more authentication values associated with the request message to be sent to one or more devices; receiving one or more reply messages andverifying the one or more reply messages based on one or more the intermediate verification value or on the authentication values, forwarding the reply messages to the network or application function based on the result of the verification.

39. The method of any of claims 20 to 38, comprising storing a long-term identifier associated to a user subscription, and the user subscription is linked to the ownership of at least a first device, and one or more of the following apply to the device:- the device is authorized to send a request burst to at least the first device;- the device is authorized to retrieve the position of at least the first device;- the device is authorized to perform a command on at least the first device.

40. The method of any of claims 20 to 39, comprising: starting a timer upon transmission of a first request message, and transmitting a second request message if the device does not receive any reply message before the timer reaches a threshold time.

41. The method of any of claims 1 to 17 and 20 to 40, wherein a request message comprises one or more of:- a preamble,- the number of slots in the request burst in which the request message is transmitted,- a slot number indication indicative of the current slot number within the request burst in which the request message is transmitted,- a time delay parameter,- a device identifier,- an identifier identifying a group of devices,- an indication on whether the slot includes an illuminating signal or not,- time and / or frequency resource information of one or more illuminating signals (i.e. carrier wave(s) externally provided),- a request (session) identifier,- information acknowledging the reception status of the reply messages from devices, and / or- specific request data, etc.

42. The method of claim 41, wherein the information acknowledging the reception status of the reply messages from first devices comprises an information set for each first devices having provided a reply message, wherein each information set comprises a random identifier provided by each first devices in the reply message and an indication of the slot / subslot used by the first device to transmit the reply message carrying the random identifier.

43. The method of any of claims 20 to 42, wherein the apparatus is part of a User Equipment or a base station.

44. An apparatus to perform a multiple access procedure, comprising a receiver, a transmiter, a controller, and a memory storing instructions which, when executed, cause the apparatus to:- select a number of slots nO for a request burst,- transmit a first request burst comprising nO slots, each slot including a request message.

45. An apparatus to perform a multiple access procedure, comprising: a receiver, a transmiter,a controller, and a memory storing instructions which, when executed, cause the apparatus to:- select a number of slots nO for a request burst,- transmit a first request burst comprising nO slots, each slot including a request message, and each request message including a slot number indication indicative of the current slot number within the first request burst in which each request message is transmitted.

46. An apparatus to perform a multiple access procedure, comprising: a receiver, a transmitter, a controller, and a memory storing instructions which, when executed, cause the apparatus to:- select a number of slots nO for a request burst,- transmit a first request burst comprising nO slots, each slot comprising one or more subslots, and each slot being preceded by a request message,- receive one or more replies from one or more devices in the subslots.

47. An apparatus to perform a multiple access procedure, comprising: a receiver, a transmitter, a controller, and a memory storing instructions which, when executed, cause the apparatus to:- receive assistance information to perform an inventory procedure wherein the assistance information includes at least an indication of the number of devices in the inventory procedure,- select a number of slots nO for a first request burst,- send a request message to a base station to reserve communication resources to perform the inventory procedure with nO slots, and- transmit the first request burst in the resources allocated by the base station, wherein the first request message comprises nO slots, each slot comprising one or more subslots, and each slot being preceded by a request message.

48. An apparatus to perform a multiple access procedure, comprising: a receiver, a transmitter, a controller, and a memory storing instructions which, when executed, cause the apparatus to:- transmit a first request burst to two or more devices, wherein the first request burst comprises nO slots,- receive at least a first reply from a first device in a contention-based slot during the first request burst, wherein the first reply from the first device comprises a random identifier,- transmit a second request burst comprising nl slots indicating at least a first contention free slot for the first device and the first identifier received from the first device, and- receive a second reply from the first lower device in the indicated contention free slot.

49. An apparatus for secure communication with a second device, the apparatus comprising: a processor, a transceiver, a storage unit storing a symmetric key, wherein the storage unit includes instructions which, when executed, cause the apparatus to receive a request message including an indication of a security procedure, determine a number of parameters required to perform the security procedure, obtain the parameters required to perform the security procedure by executing a cryptographic function taking as input the symmetric key, and send a reply message to perform the security procedure based on the obtained parameters.

50. A method for secure communication between a first device and a second device, the method comprising: receiving, by the first device, a request message including an indication of a security procedure, determining, by the first device, a number of parameters required to perform the security procedure, obtaining, by the first device, the parameters required to perform the security procedure by executing a cryptographic function, and sending, by the first device, a reply message to perform the security procedure based on the obtained parameters.

51. The method of claim 50, comprising one or more of: receiving an explicit indication in the request message about the required parameters to perform the security procedure; receiving the indication in the request message about the required parameters to perform the security procedure, and obtaining the required parameters to perform the security procedure based on the indication and a stored configuration or profile; receiving an indication in the request message about the parameter size to perform the security procedure; using an extensible output function as cryptographic function to obtain the parameters; using ASCON in extensible output function mode as cryptographic function to obtain the parameters; sending, the reply message upon obtaining an authentication value indicated as a required parameter to perform the security procedure and verifying the authentication value.

52. A computer program for device communication, wherein the program comprises instructions implementing the method of any of claims 1 to 17, 20 to 43 and 50 and 51.

Images