Method performed by ambient internet-of-things and ambient internet-of-things

Abstract

A wireless communication system is described that consists of at least one 'Ambient' Internet-of-Things (A-IoT) device, at least one A-IoT device reader, and optionally a RAN node that are mutually configured for supporting per A-IoT device type and per A-IoT device designed R2D preambles.

Description

METHOD PERFORMED BY AMBIENT INTERNET-OF-THINGS AND AMBIENT INTERNET-OF-THINGS

[0001] The present disclosure relates to a communication system and to parts thereof.

[0002] The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards, equivalents, or derivatives thereof (including Long-Term Evolution (LTE)-Advanced, Next Generation or 5G networks, future generations, and beyond). The present disclosure relates, in particular but not exclusively, to ambient Internet-of-Things (A-IoT) systems and for mechanisms for supporting per A-IoT device type and / or per A-IoT device designed R2D preambles.

[0003] Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the term '5G' and 'new radio' (NR) is used to refer to an evolving communication technology that supports a variety of applications and services. Various details of 5G networks are described in, for example, the 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https: / / www.ngmn.org / 5g-white-paper.html. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.

[0004] Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipments or 'UEs') connect to a core network and communicate with other communication devices or remote servers. For simplicity, the present application may use the term access network node, RAN node (or simply RAN) or base station to refer to any such access nodes.

[0005] For simplicity, the present application will use the term mobile device, user device, UE, or IoT device, to refer to any communication device that is able to connect to the core network via one or more base stations. Although the present application may refer to mobile devices in the description, it will be appreciated that the technology described can be implemented on any communication devices (mobile and / or generally stationary) that can connect to a communication network for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory. An IoT device may, for example, be any UE equipped with appropriate electronics, software, sensors, network connectivity, and / or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may, for example, be in the form of automated equipment that may operate without requiring human supervision or interaction.

[0006] In the current 5G architecture, the base station structure may be split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by a CU-DU interface (e.g., an F1 interface). This enables the use of a 'split' architecture in which the typically 'higher' CU layers (for example, but not necessarily or exclusively, Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) layers) and the, 'lower' DU layers (for example, but not necessarily or exclusively, Radio Link Control (RLC), Media (sometimes referred to as 'Medium') Access Control (MAC), and Physical (PHY) layers) are separated between a particular CU, and one or more DUs that are connected to and controlled by that CU via the CU-DU interface. Thus, for example, the higher layer CU functionality for a number of base stations may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each base station.

[0007] In 5G, core network entities comprise logical nodes (or 'functions') including control plane functions (CPFs) and one or more user plane functions (UPFs). The CPFs include, amongst other things, one or more Access and Mobility Management Functions (AMFs), a session management function (SMF), and one or more location management functions (LMFs). The AMF generally corresponds to the MME in 4G and performs many of the functions performed by the MME. Each UPF combines functionality of both the S-GW and P-GW - specifically user plane functionality of the S-GW (SGW-U) and user plane functionality of the P-GW (PGW-U). The SMF provides session management functionality (that formed part of MME functionality in 4G). The SMF also combines the some of the functionality provided by the S-GW and P-GW - specifically control plane functionality of the S-GW (SGW-C) and control plane functionality of the P-GW (PGW-C). The SMF also allocates IP addresses to each UE.

[0008] When a UE wishes to access a cell (and / or a beam) it may attempt to access that cell and / or beam using a random access (RACH) procedure that historically involved four distinct steps. More recently, a simplified access procedure has been developed by which a UE may attempt to access that cell and / or beam using a two-step RACH procedure. Both the four-step and two-step RACH procedures are well known to those skilled in the art.

[0009] In summary, the four-step procedure typically involves the UE selecting random access resources (including, for example, a preamble) that it uses to initiate the RACH procedure. The UE sends the selected preamble in a first message ('Msg1') to a base station over a physical random access channel (PRACH). In response, the base station responds with a random access response (RAR) (or 'Msg2'). The RAR indicates reception of the preamble and includes, amongst other things, an uplink grant field indicating resources to be used in the uplink for a physical uplink shared channel (PUSCH). The UE then sends a third message ('Msg3') to the network over a physical uplink shared channel (PUSCH) based on the information in the RAR. The specific message sent by the UE in this step, and the content of the message, depends on the context in which the random access procedure is being used. For initial RRC connection setup, for example, Msg3 typically comprises an RRC Setup request or similar message carrying a temporary randomly generated UE identifier. The network responds with a fourth message ('Msg4') which carries the randomly generated UE identifier received in Msg3 for contention purposes to resolve any collisions between different UEs using the same preamble sequence. When successful, Msg4 also transfers the UE to a connected state.

[0010] As those skilled in the art will appreciate, while a contention based random access (CBRA) procedure is described, a non-contention based (or 'contention free') procedure may also be used, e.g., in which a dedicated preamble is assigned by the base station to the UE.

[0011] The two-step procedure is similar in terms of the information transferred but involves one UE to base station message ('MsgA') and one base station to UE message ('MsgB'). MsgA, in effect, combines Msg1 and Msg3 of the four-step procedure, and MsgB, in effect, combines Msg2 and Msg4 of the four-step procedure.

[0012] It will be appreciated that random access procedures such as those mentioned above may also be used in other contexts including, for example, handover, connection reestablishment, requesting uplink (UL) scheduling where no dedicated resource for a scheduling-request has been configured for the UE, etc.

[0013] NPL 1: 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN), available from https: / / www.ngmn.org / 5g-white-paper.html.

[0014] Recently, IoT has attracted much attention in the wireless communication world, and as IoT develops and grows, more 'things' are expected to be interconnected to improve productivity efficiency and increase the comforts of life. In this vein efforts have been made to try to reduce the size, complexity, and power consumption of IoT devices to enable the deployment of tens or even hundreds of billions of IoT devices for various applications. Typically, such IoT devices are powered by batteries that need to be replaced or recharged manually. Thus, as the number of IoT devices deployed grows apace, there is an increasingly negative impact from such devices as the need to replace them leads to increasingly high maintenance costs, serious environmental issues, and even safety hazards for some use cases, for example, for the use of wireless sensors in electrical power, and petroleum industries.

[0015] 'Ambient' IoT (A-IoT) attempts to address some of the above issues and relies on ultra-low complexity devices with ultra-low power.

[0016] A-IoT devices (which may also be referred to simply as IoT devices for simplicity) make use of 'backscatter' or 'reflected' communication to communicate with an A-IoT device reader which may be a cellular RAN node (base station), or other device connected to a cellular communication network. Specifically, A-IoT devices transmit data by reflecting or backscattering radio frequency (RF) signals from the A-IoT device reader without necessarily having to actively generate their own RF signals. Instead, A-IoT devices effectively modulate their impedance or reflectivity in response to an incoming RF signal (known as an 'unmodulated carrier' or 'unmodulated carrier signal'), which causes the signal to be reflected to a receiver. The backscattered signals (also referred to as 'reflected' signals) carry information, encoded by the modulation, of the impedance or reflectivity of the A-IoT device.

[0017] Such backscattered signals are typically transmitted on the same frequency as the unmodulated carrier signal from which it originated, but alternatively, the backscattered signals may undergo additional processing such that the backscattered signals have an offset from the frequency of the unmodulated carrier signal.

[0018] It can be seen that A-IoT devices and associated A-IoT device readers have much in common with radio frequency identification (RFID) tags and associated RFID readers. However, A-IoT devices need to be able to operate successfully in a conventional, orthogonal frequency-division multiplexing (OFDM) based, cellular communication system, and to co-exist with more complex conventional UEs (such as smart phones, conventional IoT devices, and the like). Accordingly, compared to conventional RFID devices, A-IoT devices and associated A-IoT device readers are typically subject to additional constraints and need to be able to support additional functionality.

[0019] A-IoT devices may be categorised as follows: - Type 1 devices: A-IoT devices that have means of energy storage but no independent signal generation or downlink (DL) / uplink (UL) amplification capabilities. Such devices rely solely on backscatter communication to communicate in the uplink with other devices. Type 1 devices typically have an initial sampling frequency offset (SFO) up to 10Xppm (where the value of X is still to be agreed but may, for example, be 4 or 5). - Type 2a devices: A-IoT devices that have means of energy storage, and no independent signal generation capabilities, but that do have both DL and UL amplification capabilities. Such devices similarly rely on backscatter communication in the uplink to communicate with other devices. For example, the device can use stored energy to amplify signals backscattered on a carrier wave provided externally. Type 2a devices similarly have a typical initial SFO up to 10Xppm (where the value of X is still to be agreed but may, for example, be 4 or 5). - Type 2b devices: A-IoT devices that have means of energy storage and independent signal generation, i.e., the device has active radio frequency (RF) components that can generate signals for transmission. Hence, UL transmissions may be generated internally by the device or may be backscattered on a carrier wave provided externally. Type 2b devices also have both DL and UL amplification capabilities. For example, the device can use its stored energy to amplify signals backscattered on the carrier wave provided externally. Type 2b devices similarly have a typical initial SFO up to 10Xppm (where the value of X is still to be agreed but may, for example, be 4 or 5).

[0020] It will be appreciated that type 1, 2a, and 2b, are only examples of possible ambient IoT device categories and that other categories and / or types of ambient IoT devices are possible. For example, the term 'type A' device is also sometimes used to refer to an ambient IoT device that has no means of energy storage and no independent signal generation / amplification capabilities. Such devices also rely on backscatter communication to communicate with other devices.

[0021] Typically, type 1, 2a, and 2b devices each have their own set of power consumption targets, complexity targets, latency targets, data rate targets, and the like.

[0022] For example, the power consumption target for type 1 devices during transmitting / receiving is typically set to less than or equal to 1 microwatts (μW), while for both type 2a and 2b devices the power consumption target during transmitting / receiving is typically set to less than or equal to a few hundred microwatts (μW).

[0023] It will be appreciated that the requirement for the power consumption target to be less than or equal to a 'few hundred μW' mentioned here means that a specific value does not need to be set. It is, therefore, open to discussion to ascertain whether a given design has a corresponding power consumption that satisfies this requirement.

[0024] It is envisaged that a coverage design target for A-IoT devices will have a maximum distance of between 10m and 50m when the devices are indoors. It will be appreciated that the maximum distance for such A-IoT devices may be sub-selected within the range of 10m to 50m.

[0025] Typically, where such ambient IoT devices are implemented in a communication network / system (also referred to as an ambient IoT network) a maximum connection density target may also be set to ensure optimal performance of the network. Typically, such maximum connection density is set at 150 devices per 100 m2for indoor scenarios, and 20 devices per 100 m2for outdoor scenarios.

[0026] Ambient IoT networks may be configured to have any one of several possible connectivity topologies and may be deployed in several different ways. These topologies include: - Topology 1 in which an ambient IoT device reader (in this example a base station or RAN node) and ambient IoT device communicate with one another directly (including the possibility that the base station that transmits to the ambient IoT device is different to the base station that receives from the ambient IoT device). This topology may, therefore, need to support full duplex operation at the base station to enable backscatter communication. This can be a significant challenge if an incoming RF signal (known as an 'unmodulated carrier' or 'unmodulated carrier signal') and reflected (or backscattered) signal are within the same RF band. - Topology 2 in which a base station (or RAN node) and ambient IoT device communicate with one another via an ambient IoT device reader in the form of an intermediate / assisting node (which may be a relay, an integrated access and backhaul (IAB) node, another UE, a repeater and / or the like, which is capable of ambient IoT operation). The intermediate node transfers ambient IoT data and / or signalling between base station and the ambient IoT device. Like Topology 1, this topology may require support of full duplex operation at the intermediate node and hence faces similar associated challenges. - Topology 3 in which the ambient IoT device: receives data / signalling from the base station (or RAN node) directly but transmits data / signalling to the base station indirectly via an assisting node; or transmits data / signalling to the base station (or RAN node) directly but receives data / signalling from the base station indirectly via an assisting node. Accordingly, in this example some IoT device reader functionality is provided by the base station and some IoT device reader functionality is provided by the assisting node. The assisting node may be a relay, an IAB node, another UE, a repeater and / or the like, which is capable of ambient IoT operation. This topology has the benefit that it does not require the base station, or the assisting node, to have full duplex operation. However, the node receiving the reflected signal needs to be able to differentiate between an unmodulated carrier signal and a reflected signal from an ambient IoT device.

[0027] For Topologies 1 and 2, there may be: none of RRC states typical to conventional UEs (e.g., IDLE, CONNECTED, SUSPENDED and / or the like); none of the mobility procedures typical to conventional UEs (e.g., at least no cell selection / re-selection functionality); and / or none of the automatic repeat request (ARQ) and / or hybrid-ARQ (HARQ) typical to conventional UEs.

[0028] Typically, in ambient IoT-based systems the user experienced data rate target is between 0.1 kbps and 5 kbps (with 1 kbps being a typical rate), and the design target of the maximum message size is approximately 1000 bits over both the 'device-to-reader' ('D2R') link, and the 'reader-to-device' ('R2D') link, which is in turn based on the maximum possible application layer packet size. Thus, assuming a 1 kbps data rate, it takes 1s to transmit 1000 bits over the D2R and R2D links. Typically, the D2R link between an A-IoT device reader and one or more A-IoT devices supports both time-division multiple access (TDMA) and frequency-division multiple access (FDMA), whilst the corresponding R2D link may only support TDMA.

[0029] < A-IoT Traffic Types> 　　Typically in A-IoT systems the traffic between A-IoT device readers and A-IoT devices may be categorised as either Device-Terminated (DT) traffic, Device-Originated - Device-Terminated Triggered (DO-DTT) traffic, or Device-Originated - Autonomous (DO-A) traffic.

[0030] DT traffic may include any type of transmission by an A-IoT device reader (or other network node) to one or more A-IoT devices to provide the one or more A-IoT devices with information, inventory requests, commands, and the like. For example, R2D transmission may be considered a type of DT traffic.

[0031] DO-DTT traffic may include any type of transmission by an A-IoT device to an A-IoT device reader (or other network node) that is sent by the A-IoT device in response to receiving DT traffic from the A-IoT device reader (or other network node). For example, some D2R transmission may be considered at type of DO-DTT traffic.

[0032] DO-A traffic may include any type of transmission by an A-IoT device to an A-IoT device reader (or other network node) that is sent by the A-IoT device of its own accord. That is to say, the transmission by the A-IoT device is not triggered by, or in response to, DT traffic, but rather is sent by the A-IoT device autonomously. For example, some A-IoT devices such as sensors and the like may be designed / configured to send sensor readings to an A-IoT device reader in response to a sensor reading being above / below a specific threshold, or the like.

[0033] < R2D Transmissions> 　　The current view is that R2D transmission will typically comprise an R2D preamble to indicate a start time of the following PRDCH and possibly chip length information. This R2D preamble is followed immediately by the PRDCH transmission (carrying any R2D traffic data and / or any control information). An R2D postamble is transmitted immediately after the PRDCH transmission to indicate an end of the PRDCH transmission.

[0034] Fig. 1 illustrates an example structure of an R2D transmission that may be sent by an A-IoT device reader to one or more A-IoT devices.

[0035] As shown in Fig. 1 and described above, the R2D transmission comprises a preamble-based prefix portion before the data transmission on the PRDCH. Specifically, in the illustrated example, the prefix portion uses an R2D preamble which is followed by the PRDCH transmission (carrying any R2D traffic data and / or any control information). A suffix portion comprising an R2D postamble (not shown) may also be added after the PRDCH transmission to indicate an end of the PRDCH transmission.

[0036] In more detail, the prefix portion comprises a preamble-based R2D timing acquisition signal (R-TAS), which indicates the start time of the following PRDCH in the time domain and possibly chip length information. That R-TAS may comprise a start indicator part (SIP) to indicate the start of the R2D transmission, and a clock-acquisition part (CAP) that immediately follows the SIP, which is used to indicate / determine the on-off key (OOK) chip duration of the subsequent PRDCH transmission. The preamble / R-TAS does not form part of the PRDCH itself.

[0037] The SIP of the R-TAS is not included in the minimum time between a previous D2R transmission and the corresponding R2D transmission following it (e.g., in time TD2R_Min), but instead may be transmitted during the time period TD2R_Min. In this case, the SIP of the R-TAS may be signalled in accordance with an ON / OFF pattern i.e., high / low voltage transmission to indicate to A-IoT devices the presence of the SIP of the R-TAS during the time period TD2R_Min.

[0038] The ON / OFF pattern implemented may vary and depend upon on energy / edge detection criteria. In one example, the ON / OFF pattern used to indicate to A-IoT devices the presence of the SIP may comprise a single ON / OFF transmission - i.e., one high-voltage transmission followed by one low-voltage transmission, where ON and OFF may have the same or different durations. In another example, the ON / OFF pattern may comprise a multi-ON / OFF transmission, where different ON periods and different OFF periods may have same or different durations and different SIPs may have the same or different ON / OFF durations.

[0039] Alternatively, the ON / OFF pattern may be implemented based on an ON / OFF sequence-based design which consists of a pre-defined sequence used for detection of the SIP based on a digital correlation (e.g., by correlating / matching the pre-defined sequence to a digital sequence of '1s' and '0s').

[0040] It will be appreciated that in both examples described above, the duration for SIP can be fixed irrespective of the number of chips per OFDM symbol (M) used for the CAP and / or PRDCH. For example, it is envisaged that the SIP duration may be fixed to half an OFDM symbol or one OFDM symbol.

[0041] In the case where a single ON / OFF transmission is used, the ON period and the OFF period that follows it may be of the same duration. In another example, in the case where a single ON / OFF transmission is used, the ON period and the OFF period that follows it may be designed with a duration ratio of 1:2 or 1:3. In yet another example, in the case where a single ON / OFF transmission is used, the ON period and the OFF period that follows it may be designed with a duration ratio of 2:1 or 3:1.

[0042] In the case where a multi-ON / OFF transmission is used, multiple repetitions of ON / OFF transmissions may be implemented whereby each repetition includes an ON period and an OFF period with same duration. In another example, the multiple repetitions of ON / OFF transmissions may be implemented whereby each repetition has an ON period and an OFF period that follows it, with a duration ratio of 1:2 or 1:3. In yet another example, the multiple repetitions of ON / OFF transmissions may be implemented whereby each repetition has an ON period and an OFF period that follows it, with a duration ratio of 2:1 or 3:1. In a further example, the ON / OFF transmission may be implemented in an ON-OFF-ON pattern where the duration of ON and OFF can be different. In another example, the ON / OFF transmission may be implemented in an OFF-ON-OFF pattern where the duration of ON and OFF can be different. In yet a further example, a single ON / OFF transmissions may be implemented that includes an ON period and an OFF period with same duration, which is in turn combined with a single ON / OFF transmission that has an ON period and an OFF period that follows it, with a duration ratio of 1:2 or 1:3.

[0043] It will be appreciated that despite the many possible configurations that may be used for the prefix portion as described above, a single / common R2D preamble / SIP design with a specific ON / OFF pattern and edge detection may be preferable given that the pre-configuration / pre-definition of a single / common R2D preamble / SIP design may avoid the need for type 1 A-IoT devices to perform blind detection and the associated energy inefficiencies.

[0044] < D2R Transmissions> 　　Similarly, for D2R transmissions, it is envisaged that a prefix portion using a D2R preamble will be transmitted at the beginning of each D2R transmission, immediately before the PDRCH transmission, to indicate a start time of the PDRCH transmission. A suffix portion comprising a D2R postamble may also be transmitted following the PDRCH transmission to indicate the end of the PDRCH transmission (and possibly provide a final timing correction to the A-IoT device reader). In the context of D2R communication, however, a D2R midamble may be inserted into (sent during) the PDRCH transmission, for facilitating chip-level timing tracking and channel / interference estimation (e.g., depending on the length of that PDRCH transmission).

[0045] Similarly, the D2R preamble may comprise a D2R timing acquisition signal (D-TAS), which indicates the start time of the following PDRCH in the time domain and possibly also used for sampling frequency offset (SFO) estimation, carrier frequency offset (CFO) estimation, channel estimation, and interference estimation. The preamble does not form part of the PDRCH itself, and may comprise a binary signal.

[0046] < A-IoT Random Access> 　　Due to the simplicity of A-IoT technology, new random access procedures are being developed for allowing communication between an A-IoT device and the A-IoT device reader. These A-IoT access procedures are typically based on a slotted Additive Links On-line Hawaii Area (slotted-ALOHA) based algorithm / protocol that is widely used for communication between radio frequency identification (RFID) tags and their associated RFID reader. Slotted-ALOHA is a variation of the ALOHA protocol, which will be familiar to those skilled in the art. In slotted-ALOHA, a communication channel is effectively divided into small, fixed-length, time slots. Devices are only able to transmit data at particular times (e.g., during specific transmission occasions).

[0047] For random access in the context of RFID technology, as RFID tags are passive devices, the RFID reader needs to initiate any communication access from the RFID tags to the RFID reader. Specifically, communication between the RFID reader and the RFID tags is performed as part of a procedure called an inventory round. Initially, before the inventory process commences, the RFID reader typically transmits a 'Select' command to all RFID tags in the coverage area of the RFID reader, to select a particular group of the RFID tags that are allowed to respond to the RFID reader in the subsequent procedure. The Select command includes information that allows the RFID tags to identify if they are allowed to respond - for example, a device identifier (optionally with a mask) such as an electronic product code (EPC) (or part of it), and / or part of the information in the RFID tag's memory. Any RFID tag that matches the information in the Select command may respond. The RFID reader then sends a 'Query' command to initiate a random access like identification process and sets the parameters to be used for subsequent RFID tag to RFID reader communication.

[0048] Selected RFID tags (i.e., those that match the parameters in the Select command) then randomly determine a 'random access' slot (or 'reply slot') to reply in based on information in the 'Query' command. This reply slot may be the first slot (slot #0) or a subsequent slot. Selected RFID tags that do not respond immediately to the Query command in the first slot (slot #0) move to an Arbitrate state and wait to receive either a QueryAdjust command (to adjust one or more parameters provided in the original Query command and trigger the affected RFID tags to determine a new slot to reply in) or a QueryRep command (to indicate a transition to the next slot and hence the affected RFID tags to modify (decrease) an associated slot counter indicating a number of slots until the determined reply slot).

[0049] When a given selected RFID tag responds in a corresponding reply slot, that RFID tag does so by sending a 16-bit random number (RN16) to the RFID reader (the sending of this RN16 parameter is analogous to the transmission of Msg1 in conventional cellular random access procedures). This 16-bit random number may be used, for example, for the purposes of contention resolution in the event that a plurality of selected RFID tags selects the same slot for response, and hence respond to the Query command simultaneously.

[0050] Assuming that a single RFID tag has responded to the RFID reader in a given slot, the RFID reader confirms reception of the with an acknowledgement (ACK command) containing the same RN16 value (the sending of this acknowledgement is analogous to the transmission of the RAR / Msg2 in conventional cellular random access procedures). On receipt of the acknowledgement with the same RN16 value, the RFID tag that responded enters an acknowledged state and responds to the RFID reader with an EPC (a unique identifier of the RFID tag), a cyclic-redundancy check (CRC) and a protocol-control (PC) (the sending of this information is analogous to the transmission of Msg3 in conventional cellular random access procedures).

[0051] The RFID reader then sends a QueryAdjust or QueryRep command, triggering the RFID tag that has just communicated with it to return to a Ready state, and triggering the remaining selected RFID tags in the current identification process to decrease their slot counters. If no RFID tags respond in a given slot RFID reader may send another QueryRep command to trigger the remaining selected RFID tags in the current identification process to decrease their slot counters again.

[0052] For random access in the context of A-IoT devices and A-IoT device readers it is envisaged that when a response is expected from multiple devices (e.g., for the purposes of identifying multiple devices in the vicinity of the A-IoT device reader) a contention-based random access procedure may be used. This contention-based random access procedure may, for example, be similar to a conventional four-step RACH procedure or to a conventional two-step RACH procedure and may also have some similarities with the RFID random access procedure.

[0053] In an A-IoT 'four-step' random access procedure, like the RFID random access procedure, random access is triggered by the A-IoT device reader using an appropriate reader-to-device (R2D) trigger message ('A-IoT Msg0') in a manner that is analogous to the Query command of the RFID random access procedure. The A-IoT device reader includes, in this trigger message, the information (appropriate parameters) that one or more A-IoT devices need to respond to the random access trigger. It is possible that this trigger message may trigger initial access by a single device, a group of devices, or all devices in a cell / coverage area.

[0054] When triggered by the R2D trigger message (A-IoT Msg0), the one or more A-IoT devices may send an initial device-to-reader (D2R) message ('A-IoT Msg1') carrying a corresponding identifier (e.g., a random ID generated by A-IoT device), and possibly other information, to the A-IoT device reader. The A-IoT Msg0 that triggers random access between the A-IoT device reader, and the one or more A-IoT devices, also indicates to the one or more A-IoT devices X time domain resources for one or more initial D2R transmissions (e.g., for one or more A-IoT Msg1s; one A-IoT Msg1 per A-IoT device triggered for random access). Each of the one or more A-IoT Msg1s occur in a corresponding time domain resource of the X time domain resources indicated to the one or more A-IoT devices in the Msg0 that triggers the random access procedure between the A-IoT device reader and the one or more A-IoT devices. It will be appreciated that X may be equal to, or greater than 1, and when greater than 1 the maximum value is set considering the implementation complexity of the A-IoT device, the power consumption of the A-IoT device, resource usage efficiency (which may be affected at least by the SFO of the A-IoT device), and inventory latency associated with the A-IoT device.

[0055] The A-IoT device reader echoes the identifier received in the one or more initial D2R messages (one or more A-IoT Msg1s) back to the one or more A-IoT device in one or more R2D response messages (one or more 'A-IoT Msg2') that may include additional useful information where appropriate. For example, the A-IoT device reader, in response to the A-IoT Msg1s received from one or more A-IoT devices, may send a corresponding A-IoT Msg2 to each respective A-IoT device that sent an A-IoT Msg1 to the A-IoT device reader (Msg2 Transmission Option #1). Alternatively, the A-IoT device reader, in response to the A-IoT Msg1s received from one or more A-IoT devices, may send a single (common) A-IoT Msg2 to a group of the A-IoT devices that sent an A-IoT Msg1 to the A-IoT device reader (Msg2 Transmission Option #2).

[0056] In the scenario where the A-IoT device reader sends a corresponding A-IoT Msg2 to each respective A-IoT device that sent an A-IoT Msg1 to the A-IoT device reader, the transport block size (TBS) of each A-IoT Msg2 may be kept small, and the power consumption and complexity of implementation at the A-IoT devices may be less. On the other hand however, the amount of control information that needs to be sent by the A-IoT device reader is large since each A-IoT Msg2 monitoring window is different for each respective A-IoT device, and in that case multiple maximum time intervals between the transmission of the A-IoT Msg1 and the transmission of the A-IoT Msg2 (TD2R_max) may need to be configured when TDMA and / or FDMA is implemented.

[0057] In the scenario where the A-IoT device reader sends a single (common) A-IoT Msg2 to all of the A-IoT devices that sent an A-IoT Msg1 to the A-IoT device reader, the amount of control information that needs to be sent by the A-IoT device reader is small i.e., if one A-IoT Msg2 supports multiple R2D responses, the same value of TD2R_maxcan be used for FDMA. On the other hand, however, the TBS of that A-IoT Msg2 will be large, which in turn increases the power consumption and complexity of implementation at the A-IoT devices. Furthermore, where TDMA is implemented multiple TD2R_maxmay need to be configured.

[0058] Having received an A-IoT Msg2, the one or more A-IoT devices may then send a further D2R message ('A-IoT Msg3') including the A-IoT device's device identifier and / or any other higher layer data (depending on a higher layer request). It will be appreciated that the A-IoT device may consider contention resolution to be successful, if the received response message (A-IoT Msg2) includes the same random identifier that was sent by that A-IoT device in the initial D2R message (A-IoT Msg1). Hence the size of the random identifier needs to be sufficient for effective contention resolution purposes. A further R2D transmission ('A-IoT Msg4') may then be sent by the A-IoT device reader to the A-IoT device after the further D2R message (A-IoT Msg3) but does not always need to be sent. The further R2D transmission (A-IoT Msg4) may, for example, be sent to handle a transmission failure (e.g., a failure of A-IoT Msg3 due to any of a number of different reasons). It will be appreciated that the 'A-IoT Msg' terms (e.g., 'A-IoT Msg4') may or may not be used in practice.

[0059] Similarly, in an A-IoT 'two-step' random access procedure, like the RFID random access procedure, random access is triggered by the A-IoT device reader using an appropriate reader-to-device (R2D) trigger message ('A-IoT Msg0') in a manner that is analogous to the Query command of the RFID random access procedure. In the two-step scenario, however, when triggered by the R2D trigger message (A-IoT Msg0), the A-IoT device may send an initial device-to-reader (D2R) message ('A-IoT Msg1') carrying a corresponding device identifier (e.g., a random ID generated by A-IoT device or some other identifier), and / or any other higher layer data (depending on a higher layer request), to the A-IoT device reader. This initial D2R message may also include other appropriate information. The A-IoT device reader may echo some or all of the information received in the initial D2R message (A-IoT Msg1) back to the A-IoT device in a R2D response message ('A-IoT Msg2') that may include additional useful information where appropriate.

[0060] < A-IoT Device Reader Support for Different A-IoT Device Types> 　　As A-IoT devices become more prevalent and their functionalities are further developed, the difference in functionalities between different A-IoT device types (e.g., type 1, 2, 2a, and 2b) are likely to diverge.

[0061] For example, new functionalities may be supported for a subset of A-IoT device types (e.g., A-IoT device types 2, 2a, and / or 2b (e.g., there are proposals to support synchronisation functionality, and / or large frequency shifts for device 2b)) which cannot be supported by another subset of A-IoT device types (e.g., A-IoT device type 1). In such scenarios it will be appreciated that R2D transmissions associated with such new functionalities may only be intended for reception by a specific subset of A-IoT device types that specifically support those new functionalities (e.g., A-IoT device types 2, 2a, and / or 2b), and that reception and / or decoding of those R2D transmissions by A-IoT devices that do not support those new functionalities may lead to unnecessary energy wastage. This may especially be the case where a single R2D preamble / SIP pattern design is implemented for use across the whole A-IoT device system.

[0062] There is, therefore, a need to develop enhanced mechanisms that enable each A-IoT device of a specific type to avoid, or at least minimise, unnecessary reception / and or decoding of R2D transmissions from an A-IoT device reader relating to functionalities that the specific type of A-IoT device does not support.

[0063] Furthermore, within a group of A-IoT devices of the same A-IoT device type, A-IoT device specific operations are envisioned. For example, within a group of A-IoT devices of the same A-IoT device type (e.g., A-IoT device type 1), a subset of those A-IoT devices within that group of A-IoT device may be configured to support specific operations (e.g., re-transmission of segments, re-access, or the like). In such scenarios it will be appreciated that R2D transmissions associated with such A-IoT device specific operations are only intended for reception by the subset of A-IoT devices within the group of A-IoT devices of the same A-IoT device type that support those A-IoT device specific operations. Reception and / or decoding of those R2D transmissions by A-IoT devices that do not support those A-IoT device specific operations may lead to unnecessary energy wastage. This may especially be the case where a single R2D preamble / SIP pattern design is implemented for use across the whole A-IoT device system.

[0064] To date efforts have been made to help A-IoT devices of the same A-IoT device type to determine whether an R2D transmission is directed to it or not. For example, timing relationships between when an R2D transmission should be sent, and when a specific A-IoT device is configured to detect R2D transmissions, may be (pre)configured (e.g., within a range of a minimum time 'TMin' and a maximum time 'TMax') in an attempt to limit which A-IoT devices receive the R2D transmissions. For example, the R2D transmission may only be sent during a time period when the A-IoT devices for which it is intended are known to be listening for R2D transmissions. This approach, however, has a very coarse level of granularity and nevertheless requires large amounts of power expenditure during the time period (e.g., within a corresponding range of TMinand TMax) when the A-IoT device is listening.

[0065] In another example, the R2D transmissions sent by the A-IoT device reader may include (in addition to an appropriate R2D preamble / SIP pattern design) an identifier (ID) associated with the A-IoT device to which the R2D transmission is directed, and an A-IoT device may only fully decode the R2D transmission if it contains an ID corresponding to the ID of the A-IoT device. However, such IDs are typically included in the PDRCH portion of the R2D transmission and thus each A-IoT device first has to receive and decode the preamble of the R2D transmission and at least a first portion of the PRDCH to ascertain whether or not the R2D transmission is intended for the A-IoT device or not. For each A-IoT device that is not the intended recipient of the R2D transmission, unnecessary reception and decoding nevertheless occurs causing energy wastage.

[0066] There is, therefore, also a need to develop enhanced mechanisms that enable each A-IoT device of the same specific A-IoT device type to avoid, or at least minimise, unnecessary reception / and or decoding of R2D transmissions from an A-IoT device reader relating to functionalities supported by the specific A-IoT device type, when a specific operation / function to which the R2D transmission relates is not intended for the A-IoT device.

[0067] < A-IoT Random Access and DO-A Traffic> 　　It will be appreciated that the A-IoT random access procedure described above is particularly applicable in the context of DT traffic and DO-DTT traffic where an A-IoT device reader triggers transmissions by one or more A-IoT devices via an initial trigger message (e.g., PRDCH access order, or the like). However, in the context of DO-A traffic appropriate adaptations to the A-IoT random access procedure described above may be required.

[0068] For example, it will be appreciated that in the context of DO-A traffic, the (DO-A) A-IoT device that wishes to send autonomous transmissions to an A-IoT device reader may still need the A-IoT device reader to indicate to the A-IoT device appropriate resources that it may use to send DO-A transmissions to the A-IoT device reader. Additionally, in A-IoT systems that comprise both DO-A A-IoT devices and non-DO-A A-IoT devices, there is a possibility that multiple A-IoT devices within the A-IoT system may receive and decode A-IoT Msg2 from the A-IoT device reader even when that transmission is only intended for a specific DO-A A-IoT device that sent Msg1 to the A-IoT device reader. This in turn may result in unnecessary processing by some A-IoT devices, leading to power wastage.

[0069] There is therefore also a need to develop an enhanced random access procedure for A-IoT that supports the deployment of both DO-A A-IoT devices and non-DO-A A-IoT devices.

[0070] The disclosure aims to describe one or more apparatus and / or one or more associated mechanisms / procedures that at least partially addresses or contributes to meeting one or more of the above needs and / or addressing one or more of the above issues.

[0071] The disclosure has a method performed by an ambient Internet-of-Things, A-IoT, device, the method comprising receiving, from an A-IoT device reader, a reader to device (R2D) transmission including a first portion configured for at least acquiring a timing of the R2D transmission , and a second portion carrying data and / or control signalling intended for a specific set of one or more A-IoT devices wherein the first portion carries intended recipient specific information that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended.

[0072] The disclosure has a method performed by an ambient Internet-of-Things, A-IoT, device reader, the method comprising transmitting, to an A-IoT device, a reader to device (R2D) transmission including a first portion configured for acquiring at least a timing of the R2D transmission, and a second portion carrying data and / or control signalling intended for a specific set of one or more A-IoT devices wherein the first portion carries intended recipient specific information that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended.

[0073] The disclosure has an ambient internet-of-things, A-IoT, device comprising means for receiving, from an A-IoT device reader, a reader to device (R2D) transmission including a first portion configured for acquiring a timing of the R2D transmission, and a second portion carrying data and / or control signalling intended for a specific set of one or more A-IoT devices wherein the first portion carries intended recipient specific information that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended.

[0074] The disclosure has an ambient internet-of-things, A-IoT, device reader comprising means for transmitting, to an A-IoT device, a reader to device (R2D) transmission including a first portion configured for acquiring a timing of the R2D transmission, and a second portion carrying data and / or control signalling intended for a specific set of one or more A-IoT devices wherein the first portion carries intended recipient specific information that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended.

[0075] Various example described below may be implemented by means of a computer program product comprising computer implementable instructions for causing a programmable computer to carry out any of the methods described below. The computer implementable instructions may be provided as a signal or on a tangible computer readable medium.

[0076] Examples of apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:

[0077] Fig. 1 illustrates an example R2D transmission format that may be used by an A-IoT device reader to transmit to one or more A-IoT devices;Fig. 2 illustrates schematically a mobile (cellular or wireless) communication system to which example embodiments of the disclosure may be applied;Fig. 3A illustrates schematically a first possible arrangement of a first connectivity topology (topology 1) that may be used in the communication system of Fig. 2;Fig. 3B illustrates schematically another possible arrangement of a first connectivity topology (topology 1) that may be used in the communication system of Fig. 2;Fig. 4A illustrates schematically a first possible arrangement second connectivity topology (topology 2) that may be used in the communication system of Fig. 2;Fig. 4B illustrates schematically another possible arrangement second connectivity topology (topology 2) that may be used in the communication system of Fig. 2;Fig. 5A illustrates schematically a first possible arrangement of a third connectivity topology (topology 3) that may be used in the communication system of Fig. 2;Fig. 5B illustrates schematically another possible arrangement of the third connectivity topology (topology 3) of Fig. 5A;Fig. 6 is a simplified sequence diagram of an example A-IoT random access procedure that may be implemented in the communication system of Fig. 2;Fig. 7 illustrates transmission and reception of R2D transmissions that have different starting indicator parts (SIPs) for different A-IoT device types;Fig. 8 is a simplified sequence diagram of an example R2D reception procedure that may be implemented in the communication system of Fig. 2;Fig. 9 illustrates an example R2D transmission format that may be used by an A-IoT device reader in the communication system of Fig. 2;Fig. 10A is a simplified sequence diagram of another example R2D reception procedure that may be implemented in the communication system of Fig. 2;Fig. 10B is a simplified sequence diagram of another example R2D reception procedure that may be implemented in the communication system of Fig. 2;Fig. 11 illustrates transmission and reception of R2D transmissions that may include an A-IoT device type specific SIP or an A-IoT device type specific sequence / SIP;Fig. 12 is a simplified sequence diagram of an example enhanced A-IoT random access procedure that may be implemented in the communication system of Fig. 2;Fig. 13 is a simplified block schematic illustrating the main components of an A-IoT device that may be used in the communication system of Fig. 2;Fig. 14 is a simplified block schematic illustrating the main components of a RAN node that may be used in the communication system of Fig. 2; andFig. 15 is a simplified block schematic illustrating the main components of an intermediate or assisting node that may be used in the communication system of Fig. 2.

[0078] <Overview> 　　An exemplary communication system will now be described in general terms, by way of example only, with reference to Figs. 2 to 6.

[0079] Fig. 2 schematically illustrates a mobile ('cellular' or 'wireless') communication system (e.g., communication system 1) to which examples of the present disclosure are applicable.

[0080] In the communication system 1 user equipments (UEs) 3 (3-1, 3-2, 3-3) (e.g., mobile telephones and / or other mobile devices including (ambient) IoT devices) can communicate with each other via a corresponding radio access network (RAN) node 5-1 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN node 5-1 comprises a base station operating one or more associated cells. Communication via the RAN node 5-1 is typically routed through a core network 7 (e.g., a 5G / 6G or later generations core network or evolved packet core network (EPC)). As those skilled in the art will appreciate however, a base station or 'gNB' is an example of a RAN node 5-1 only and that the RAN node 5-1 may be any appropriate RAN node 5-1 (e.g., where appropriate the RAN node 5-1 may be a RAN node that operates using a different RAT than NR / 5G).

[0081] As those skilled in the art will appreciate, whilst three UEs 3, and one RAN node 5-1 are shown in Fig. 2 for illustration purposes, the system, when implemented, will typically include other RAN nodes 5-1 and UEs 3.

[0082] In the illustrated example, the UEs 3 include at least one 'ambient' IoT device 3-1 (A-IoT device 3-1) that is capable of performing backscatter communication and a number of other, non-ambient IoT, UEs 3-2, 3-3 (such as smartphones or the like) that communicate in a conventional manner.

[0083] The A-IoT device 3-1 may, for example, be a Type 1, Type 2a, or Type 2b device as described in the introduction. As described in more detail later, depending on the connectivity topology employed, the A-IoT device 3-1 may be configured for uplink (backscatter) communication and / or downlink communication directly with the RAN node 5-1 and / or may be configured for uplink (backscatter) communication and / or downlink communication indirectly via communication (e.g., 'sidelink' or similar communication) with an intermediate, or assisting, node 5-2. It will be appreciated that the intermediate, or assisting, node 5-2 may, in effect, be another node of the RAN, a separate RAN or other type of communication node, or another UE 3 that communicates with the A-IoT device 3-1 via an appropriate device-to-device (D2D) interface (e.g., sidelink, PC5 or the like). The intermediate, or assisting, node 5-2 may, for example, be a relay node (e.g., a dedicated relay or UE-relay), an integrated access and backhaul (IAB) node, a repeater and / or the like, which is capable of ambient IoT operation including receiving backscatter / reflected signals from, and / or transmitting unmodulated carrier signals to, the A-IoT device 3-1.

[0084] The RAN node 5-1 controls one or more associated cells either directly, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, and / or the like). It will be appreciated that the RAN node 5-1 may be configured to support 4G, 5G, 6G and / or later generation, and / or any other 3GPP or non-3GPP communication protocols.

[0085] The RAN node 5-1 may be a distributed base station comprising at least one distributed unit (DU) (e.g., a gNB-DU or the like), and a central unit (CU) (e.g., a gNB-CU or the like). In such a distributed base station the CU employs a separated control plane and user plane and so is, itself, split between a control plane function (CU-CP) and a user plane function (CU-UP) which respectively communicate, with the DU via an appropriate interface (e.g. F1-C logical interface) and an appropriate interface (e.g. F1-U logical interface) (together forming an F1 interface (or 'reference point')), and with one another via an appropriate interface (e.g. E1 logical interface). It will be appreciated that while the DU may include the physical and virtual elements required to provide the functionality of the lower parts of the PHY layer and hence communicate with the UEs 3 over the air interface, the base station may alternatively (or additionally) include one or more separate radio units (RUs) (e.g., providing this functionality of the lower parts of the PHY layer). It will, nevertheless, be appreciated that the RAN node 5-1 may be a base station may of a non-distributed form, for example as an integrated base station.

[0086] The UEs 3 (and possibly the intermediate or assisting node 5-2 if present) are configured for communication with the RAN node 5-1 via an appropriate air interface (for example a so-called 'Uu' interface and / or the like). It will be appreciated that the A-IoT device 3-1 may, alternatively or additionally, be configured for indirect communication with the RAN node 5-1 via an (air) interface with the intermediate or assisting node 5-2 (if present) and an (air) interface between the intermediate or assisting node 5-2 and the RAN node 5-1. Neighbouring RAN nodes 5-1 may be connected to each other via an appropriate base station to base station interface (such as the so-called 'X2' interface, 'Xn' interface and / or the like - not shown in Fig. 2).

[0087] The core network 7 includes a number of logical nodes (or 'functions') for supporting communication in the communication system 1. In this example, the core network 7 comprises control plane functions (CPFs) 10 and one or more network node entities for the communication of user data (e.g. user plane functions (UPFs) 11). The CPFs 10 include one or more network node entities for the communication of control signalling (e.g. Access and Mobility Management Functions (AMFs) 10-1), one or more network node entities for session management (e.g. Session Management Functions (SMFs) 10-2) and a number of other functions 10-n. Additional functions may include, for example: an Authentication Server Function (AUSF) which facilitates security processes; a Unified Data Management (UDM) entity for managing user specific data (e.g., for access authorisation, user registration, and data network profiles); a Policy Control Function (PCF); an Application Function (AF); a Security Anchor Function (SEAF) which is in a serving network and acts as a "middleman" during an authentication process between the UE 3 and its home network; an Authentication credential Repository and Processing Function (ARPF) which maintains the authentication credentials; and / or the like. It will be appreciated that the nodes or functions may have different names in different systems.

[0088] The RAN node 5-1 is connected to the core network nodes via appropriate interfaces (or 'reference points') such as an N2 reference point between the RAN node 5-1 and the AMF 10-1 for the communication of control signalling, and an N3 reference point between the RAN node 5-1 and each UPF 11 for the communication of user data. At least the non-ambient IoT UEs 3-2, 3-3 are each connected to the AMF 10-1 via a non-access stratum (NAS) connection over an appropriate reference point (e.g., N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated, that N1 communication is routed transparently via the RAN node 5-1.

[0089] One or more UPFs 11 are connected to an external data network 40 (e.g., an IP network such as the internet) via an appropriate reference point (e.g., N6 reference point) for communication of the user data.

[0090] The AMF 10-1 performs mobility management related functions, maintains the NAS connection with at least each non-ambient IoT UE 3-2, 3-3 and manages UE registration. The AMF 10-1 is also responsible for managing paging.

[0091] The SMF 10-2 is connected to the AMF 10-1 via an appropriate reference point (e.g., N11 reference point). The SMF 10-2 provides session management functionality (that formed part of MME functionality in LTE) and additionally combines some control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF 10-2 also allocates IP addresses to at least each non-ambient IoT UE 3-2, 3-3. The SMF 10-2 uses user information provided via the AMF 10-1 to determine what session manager would be best assigned to the user. The SMF 10-2 may be considered effectively to be a gateway from the user plane to the control plane of the network. The SMF 10-2 also allocates IP addresses to at least each non-ambient IoT UE 3-2, 3-3.

[0092] Each RAN node 5-1 is also configured for transmission of, and at least the non-ambient IoT UEs 3-2, 3-3 are configured for the reception of, control information and user data via a number of downlink (DL) physical channels and for transmission of a number of physical signals. The DL physical channels correspond to resource elements (REs) carrying information originated from a higher layer, and the DL physical signals are used in the physical layer and correspond to Res which do not carry information originated from a higher layer.

[0093] The physical channels may include, for example, a physical downlink shared channel (PDSCH), a physical broadcast channel (PBCH), and a physical downlink control channel (PDCCH). The PDSCH carries data sharing the PDSCH's capacity on a time and frequency basis. The PDSCH can carry a variety of items of data including, for example, user data, UE-specific higher layer control messages mapped down from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) for supporting a number of functions including, for example, scheduling the downlink transmissions on the PDSCH and also the uplink data transmissions on a physical uplink shared channel (PUSCH). The PBCH provides at least the non-ambient IoT UEs 3-2, 3-3 with the Master Information Block (MIB). It also, in conjunction with the PDCCH, supports the synchronisation of time and frequency, which aids cell acquisition, selection and re-selection.

[0094] The DL physical signals may include, for example, reference signals (RSs) and synchronisation signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the RAN node 5-1. The reference signals may include, for example, cell specific reference signals, UE-specific reference signal (UE-RS), downlink demodulation signals (DMRS), and channel state information reference signal (CSI-RS).

[0095] Similarly, at least the non-ambient IoT UEs 3-2, 3-3 are configured for transmission of, and the RAN node 5-1 is configured for the reception of, control information and user data via a number of uplink (UL) physical channels corresponding to REs carrying information originated from a higher layer, and UL physical signals which are used in the physical layer and correspond to REs which do not carry information originated from a higher layer. The physical channels may include, for example, the PUSCH, a physical uplink control channel (PUCCH), and / or a physical random access channel (PRACH). The UL physical signals may include, for example, demodulation reference signals (DMRS) for a UL control / data signal, and / or sounding reference signals (SRS) used for UL channel measurement.

[0096] Moreover, at least the non-ambient UEs 3-2, 3-3 and the RAN node 5-1 are mutually configured for performing a random access channel (RACH) procedure for those UEs 3-2, 3-3 to access the network. Specifically, on detection and selection of a cell (and / or a beam) the UE 3 is able to attempt access to that cell and / or beam using an initial radio resource control (RRC) connection setup procedure comprising a random access procedure with the RAN node 5-1.

[0097] Prior to attempting initial access, at least a non-ambient IoT UE 3-2, 3-3 will choose random access resources (including, for example, a preamble) to use to initiate the RACH procedure. The UE 3 sends the selected preamble (e.g., in 'Msg1') to the RAN node 5-1 over a physical random access channel (PRACH) for initiating the process to obtain synchronisation in the uplink (UL). In response, the RAN node 5-1 responds with a random access response (RAR) (or 'Msg2'). The RAR indicates reception of the preamble and includes: a timing-alignment (TA) command for adjusting the transmission timing of the UE 3 based on the timing of the received preamble; an uplink grant field indicating the resources to be used in the uplink for a physical uplink shared channel (PUSCH); a frequency hopping flag to indicate whether the UE 3 is to transmit on the PUSCH with or without frequency hopping; a modulation and coding scheme (MCS) field from which the UE 3 can determine the MCS for the PUSCH transmission; and a transmit power control (TPC) command value for setting the power of the PUSCH transmission. The UE 3 then sends a third message ('Msg3') to the RAN node 5-1 over a physical uplink shared channel (PUSCH) based on the information in the RAR. The specific message sent by the UE 3 in this step, and the content of the message, depends on the context in which the random access procedure is being used. In the example of initial RRC connection setup, however, Msg3 typically comprises an RRC Setup request or similar message carrying a temporary randomly generated UE identifier. The RAN node 5-1 responds with a fourth message ('Msg4') which carries the randomly generated UE identifier received in Msg3 for contention purposes to resolve any collisions between different UEs 3 using the same preamble sequence. When successful, Msg4 also transfers the UE 3 to a connected state.

[0098] At least the non-ambient UEs 3-2, 3-3 and the RAN node 5-1 are also mutually configured for performing a two-step RACH procedure that involves the UE 3-2, 3-3 sending one message ('MsgA') to the RAN node 5-1 and the RAN node 5-1 sending one message ('MsgB') to the UE 3-2, 3-3. MsgA, in effect, combines Msg1 and Msg3 of the four-step procedure, and MsgB, in effect, combines Msg2 and Msg4 of the four-step procedure.

[0099] While contention-based RACH procedures are described it will be appreciated that a UE 3 and the RAN node 5-1 may also perform a non-contention based (or 'contention free') procedure in which a dedicated preamble is assigned by the RAN node 5-1 to the UE 3. Moreover, the UE 3 and the RAN node 5-1 may perform a two-step RACH procedure.

[0100] Each A-IoT device 3-1 may be completely passive or may be active and configured with at least a subset of the functionality of the non-ambient IoT UEs 3-2, 3-3. It will be appreciated that the specific functionality with which the A-IoT device 3-1 is configured is dependent on the type of A-IoT device 3-1 as described above. It will, nevertheless, be appreciated that regardless of the non-ambient IoT UE functionality that an A-IoT device 3-1 may be configured with, each A-IoT device 3-1 is respectively configured with A-IoT specific functionality and each RAN node 5-1 is configured with corresponding functionality for communication with A-IoT devices 3-1.

[0101] For example, each A-IoT device reader (e.g., RAN node 5-1 or intermediate or assisting node 5-2) is also configured for transmission of, and the A-IoT devices 3-1 are configured for the reception of, control information and data via a physical R2D channel (PRDCH) for R2D communication that will typically carry any higher-layer payload, and any L1 R2D control information (if defined). For example, each R2D transmission may typically comprise an R2D preamble to indicate a start time of the following PRDCH and possibly and chip length (duration) information. This R2D preamble is followed immediately by the PRDCH transmission, which may, for example, be carrying R2D traffic data and / or control information such as indications of time domain resources and / or frequency domain resources scheduled for D2R transmissions. An R2D postamble may be transmitted immediately after the PRDCH transmission to indicate an end of the PRDCH transmission.

[0102] Similarly, each A-IoT device reader is also configured for reception of, and the A-IoT devices 3-1 are configured for the transmission of, control information and data via a physical D2R channel (PDRCH) for D2R communication that will typically carry any higher-layer payload, and any L1 D2R control information (if defined). For example, each D2R transmission may typically comprise a D2R preamble that is transmitted at the beginning of each D2R transmission, immediately before the PDRCH transmission, to indicate a start time of the PDRCH transmission. A D2R postamble may also be transmitted following the PDRCH transmission to indicate the end of the PDRCH transmission (and possibly provide a final timing correction to the A-IoT device reader).

[0103] Additionally, the PDRCH transmission may include one or more midambles. Such midambles may be embedded within a D2R transmission (e.g., between adjacent data segments of the D2R transmission), and may be provided in the PDRCH transmission for the purposes of performing timing / frequency tracking, channel estimation (e.g., depending on the length of that PDRCH transmission), and / or interference estimation. Additionally, such midambles may also be supported in the PDRCH transmission for the purposes of performing SFO estimation, SFO tracking for a PDRCH transmission with a long transmission duration, and / or timing correction procedures. For example, in the case of timing correction procedures, after SFO estimation based on the D2R preamble, a D2R midamble may be used for improving the SFO estimation.

[0104] The PRDCH may include any appropriate information. For the purposes of D2R scheduling, for example, the R2D control information may include time domain resources; frequency domain resources; modulation and coding scheme (MCS) like information; chip duration; one or more identifiers (IDs) associated with one or more A-IoT devices 3-1; an indication of a number of repetitions; and / or midamble related information.

[0105] The midamble related information may be provided explicitly and / or implicitly and may include, for example, information such as: an indication of the required / requested presence (or absence of) one or more midambles in a D2R transmission; an indication of the number of midambles that are to be included per D2R transmission; an indication of the position / location of the midamble / midambles (e.g., with respect to the preamble, data, and / or postamble in the D2R transmission); an indication of the length of the midamble / midambles; and / or the like. Nevertheless, it will be appreciated that the number of midambles that are to be included per D2R transmission, and the position / location and / or length of those midambles may alternatively be predefined by a preconfigured rule (e.g., the number and position of the midambles may be fixed and the same for every D2R transmission).

[0106] It will be appreciated that, as one or more midambles may be used to perform a number of different procedures such as those highlighted above, the design / format / length of such midambles may need to vary depending on their specific purpose. Accordingly, the midamble related information may also (or alternatively), beneficially include an explicit and / or implicit indication of one or more specific purposes for which the midamble (or plurality of midambles) is intended.

[0107] < Connectivity Topologies> 　　The A-IoT device 3-1 may form part of an ambient IoT network having any one of the possible connectivity topologies referred to in the introduction and may be deployed in any of several different ways. Possible connectivity topologies and their deployment will now be described in more detail with reference to Figs. 3 to 5.

[0108] < Topology 1: RAN node <= => IoT device:> 　　Fig. 3A illustrates schematically a first possible arrangement of a first connectivity topology (topology 1) that may be used in the communication system 1.

[0109] As shown in Fig. 3A, in the first possible arrangement of topology 1 the functionality of an A-IoT device reader is implemented as part of a RAN node 5-1. An A-IoT device 3-1 and the RAN node 5-1 engage in direct communication with one another (i.e., without the presence of an assisting or intermediate node 5-2). Specifically, as shown, the A-IoT device 3-1 directly and bidirectionally communicates with the RAN node 5-1. The communication between the RAN node 5-1 and the A-IoT device 3-1 may, for example, include ambient IoT data and / or other ambient IoT signalling (e.g., control signals or the like). The communication between the RAN node 5-1 and the A-IoT device 3-1 may occur over an appropriate air interface such as the Uu air interface, a dedicated interface for ambient IoT, or the like.

[0110] In this example, the RAN node 5-1 is responsible for transmission of an unmodulated carrier signal 20-1 to the A-IoT device 3-1; also known as the 'Carrier Wave' signal (CW). That unmodulated carrier signal 20-1 (or CW) may be transmitted by the RAN node 5-1 to the A-IoT device 3-1 to provide the A-IoT device 3-1 with a signal and / or energy upon which modulated and backscattered / reflected information can be sent. For example, upon receiving a reader-to-device (R2D) signal 20-2 from the RAN node 5-1, the A-IoT device 3-1 may modulate the unmodulated carrier signal 20-1 (or CW) it received based on the R2D signal 20-2 it received and backscatter / reflect that modulated signal as a backscattered device-to-reader (D2R) signal 20-3, to the RAN node 5-1.

[0111] Such transmission of an unmodulated carrier, and receipt of backscattering by the same RAN node (base station) 5-1 may, for example, be supported by topology 1 where full duplex operation is supported at that RAN node 5-1.

[0112] Nevertheless, while Fig. 3A shows the unmodulated carrier signal 20-1 (or CW) and the R2D signal 20-2 as originating from the same RAN node; namely RAN node 5-1, it will be appreciated that topology 1 also allows for the possibility that the RAN node 5-1 (in this case the 'IoT device reader') that communicates with the A-IoT device 3-1 may be a different communication node than a communication node that provides the unmodulated carrier signal 20-1 (or CW).

[0113] For example, as shown in Fig. 3B, which illustrates schematically a second possible arrangement of the first connectivity topology (topology 1) that may be used in the communication system 1, a separate communication node 6 may transmit the unmodulated carrier signal 20-1 (or CW) to the A-IoT device 3-1 to provide the A-IoT device 3-1 with a signal and / or energy based upon which modulated and backscattered / reflected information can be sent. The RAN node 5-1 acting as the IoT device reader may then provide the R2D signals 20-2 to the A-IoT device 3-1. Upon receiving an R2D signal 20-2, the A-IoT device 3-1 modulates the unmodulated carrier signal 20-1 (or CW) it received (e.g., based on an R2D signal 20-2 it received) and backscatter / reflect that modulated signal as a backscattered D2R signal 20-3 to the RAN node 5-1.

[0114] Topology 1 may typically be deployed for indoor scenarios, with a type 1, 2a, and / or 2b A-IoT device 3-1 and the RAN node 5-1 (IoT device reader) being located in an indoor environment. In this scenario the RAN node 5-1 typically supports one or more small cells (e.g., micro-, and pico- cells) used for voice, video, and data transmission, which are designed to provide network coverage to small areas and operate on either licensed frequency division duplex (FDD), licensed time division duplex (TDD), or unlicensed parts of the spectrum.

[0115] Alternatively, topology 1 may be deployed for scenarios where the A-IoT device 3-1 is in an indoor environment but the RAN node 5-1 is located in an outdoor environment. In this case, the RAN node 5-1 may be configured to support one or more small cells (e.g., micro-cells) used for voice, video, and data transmission, which are designed to provide network coverage to small areas and operate on either licensed FDD, licensed TDD, or unlicensed parts of the spectrum. Alternatively, the RAN node 5-1 may support one or more larger cells (e.g., macro- cells) providing radio coverage to a large area, and that operate on either licensed FDD, licensed TDD, or unlicensed parts of the spectrum.

[0116] Topology 1 may also be deployed for outdoor scenarios with one or more A-IoT devices 3-1 and the RAN node 5-1 are located in an outdoor environment. In such scenarios the RAN node 5-1 may support one or more small cells (e.g., micro-cells) used for voice, video, and data transmission, which are designed to provide network coverage to small areas and operate on either licensed FDD, licensed TDD, or unlicensed parts of the spectrum. Alternatively (or additionally), the RAN node 5-1 may support larger cells (e.g., macro- cells) providing radio coverage to a large area, and that operate on either licensed FDD, licensed TDD, or unlicensed parts of the spectrum.

[0117] This topology may, for example, be appropriate for a situation in which the RAN node 5-1 needs to fetch data (e.g., a meter record, a sensor reading, an error code and / or the like) from the A-IoT device 3-1. The RAN node 5-1 will send an unmodulated carrier signal 20-1 as a 'stimulus' signal to the A-IoT device 3-1 which will automatically respond with the required data encoded in the resulting backscattered / reflected signal.

[0118] < Topology 2: RAN node <= => Intermediate node <= => IoT device:> 　　Fig. 4A illustrates schematically a first possible arrangement of a second connectivity topology (topology 2) that may be used in the communication system 1.

[0119] As shown in Fig. 4A, in the first possible arrangement of topology 2 the functionality of an IoT device reader is implemented as part of an intermediate node 5-2. Specifically, an A-IoT device 3-1 and a RAN node 5-1 engage in communication with one another via the intermediate node 5-2 (which may also be referred to as an assisting node / IoT device reader) to transfer ambient IoT data and / or signalling between the RAN node 5-1 and the A-IoT device 3-1. It will be appreciated that while the intermediate node 5-2 is depicted in Fig. 4A as being a type of base station, the intermediate node 5-2 may in fact be any one of an IAB node, a UE 3, a repeater, or the like, or any other appropriate device, as described above, that can act as an intermediary between the RAN node 5-1 and the A-IoT device 3-1 and that is capable of supporting ambient IoT signalling.

[0120] In this example, the A-IoT device 3-1 communicates bidirectionally with the intermediate node 5-2, which is located between the A-IoT device 3-1 and the RAN node 5-1, and which is able to transfer ambient IoT data and / or signalling between the RAN node 5-1 and the A-IoT device 3-1.

[0121] Specifically, the communication between the intermediate node 5-2 and the A-IoT device 3-1 may occur over an appropriate air interface. For example, they may communicate over a Uu, a dedicated interface for A-IoT, or any other appropriate interface (e.g., a sidelink-like interface, Proximity-based Services (ProSe) interface, PC5 interface, or the like where the intermediate node 5-2 is a UE 3).

[0122] In a first (downlink) direction (RAN node 5-1 => intermediate node 5-2 => A-IoT device 3-1), a downlink signal may be transmitted from the RAN node 5-1 to the intermediate node 5-2 as part of communication 20-4 between the RAN node 5-1 and the intermediate node 5-2. The downlink signal, once received by the intermediate node 5-2, may trigger transmission of an unmodulated carrier signal 20-1 (or CW) to the A-IoT device 3-1 (e.g., on a 'sidelink' or similar interface where the intermediate node 5-2 is a UE 3). The downlink signal may be (or may carry) the unmodulated carrier signal 20-1 that is to be transmitted (e.g. relayed) by the intermediate node 5-2 to the A-IoT device 3-1 or may be a trigger signal for triggering transmission of the unmodulated carrier signal 20-1 to provide the A-IoT device 3-1 with an unmodulated carrier signal 20-1 (or CW) based upon which modulated and backscattered / reflected information can be sent. For example, upon receiving an R2D signal 20-2 from the intermediate node 5-2, the A-IoT device 3-1 may modulate the unmodulated carrier signal 20-1 (or CW) it received (e.g., based on the R2D signal 20-2) and backscatter / reflect that modulated signal as a backscattered D2R signal 20-3, to the intermediate node 5-2.

[0123] That is to say, in a second (uplink) direction (A-IoT device 3-1 => intermediate node 5-2 => RAN node 5-1) the intermediate node 5-2 is responsible for receiving a (modulated) backscattered D2R signal 20-3 from A-IoT device 3-1 (e.g., on a 'sidelink' or similar interface where the intermediate node 5-2 is a UE 3). Specifically, the uplink communication may comprise a backscattered D2R signal 20-3 from the A-IoT device 3-1 to the intermediate node 5-2 that is transmitted (e.g., on a 'sidelink' or similar interface where the intermediate node 5-2 is a UE 3) using the unmodulated carrier signal 20-1 from the intermediate node 5-2. This backscattered D2R signal 20-3 (or at least the information encoded in it), once received by the intermediate node 5-2, may be relayed / forwarded (transmitted) to the RAN node 5-1 in an uplink signal as part of the communication 20-4 between the intermediate node 5-2 and the RAN node 5-1. The backscattered D2R signal 20-3 may be processed before being relayed by the intermediate node 5-2 to the RAN node 5-1. For example, the backscattered D2R signal 20-3 may be processed by the intermediate node 5-2 to extract information encoded in the backscattered D2R signal 20-3, and to encapsulate the extracted information into an appropriate message format (e.g., in accordance with a corresponding application protocol) for communication with the RAN node 5-1. Alternatively, the backscattered D2R signal 20-3 may itself be processed by the intermediate node 5-2 (without extracting any data encoded in it) to encapsulate it into an appropriate message format (e.g., in accordance with a corresponding application protocol) for communication with the RAN node 5-1.

[0124] Such transmission of an unmodulated carrier, and receipt of backscattering by the same intermediate node 5-2 may, for example, be supported by topology 2 where full duplex operation is supported at that intermediate node 5-2.

[0125] Communication 20-4 between the RAN node 5-1 and the intermediate node 5-2 may occur over any appropriate interface. For example, the RAN node 5-1 and intermediate node 5-2 may communicate over an air interface (such as the Uu interface or the like), for example where the intermediate node 5-2 is a UE 3 (or at least acts like a UE 3 in its communication with the RAN node 5-1). The RAN node 5-1 and intermediate node 5-2 may communicate over a direct base station to base station interface (such as X2 or Xn), for example where the intermediate node 5-2 is a base station (or at least acts like a base station in its communication with the RAN node 5-1). The RAN node 5-1 and intermediate node 5-2 may communicate over an appropriate IAB interface (such as F1), for example where the RAN node 5-1 acts as an IAB donor base station and the intermediate node 5-2 is an IAB node. Nevertheless, the RAN node 5-1 and the intermediate node 5-2 may communicate over a dedicated interface for the purpose of ambient IoT.

[0126] Nevertheless, while Fig. 4A shows the unmodulated carrier signal 20-1 (or CW) and the R2D signal 20-2 as originating from the same node; namely the intermediate node 5-2, it will be appreciated that topology 2 also allows for the possibility that the intermediate node 5-2 (in this case the 'IoT device reader') transmitting to and receiving from the A-IoT device 3-1 is a different communication node than a communication node that provides the unmodulated carrier signal 20-1 (or CW).

[0127] For example, as shown in Fig. 4B, which illustrates schematically a second possible arrangement of a second connectivity topology (topology 2) that may be used in the communication system 1, a separate communication node 6 may transmit an unmodulated carrier signal 20-1 (or CW) to the A-IoT device 3-1 to provide the A-IoT device 3-1 with a signal and / or energy based upon which modulated and backscattered / reflected information can be sent. Upon receiving an R2D signal 20-2 from the intermediate node 5-2 (which may be triggered in response to the intermediate node 5-2 receiving a downlink signal as the part of communication 20-4 from the RAN node 5-1) the A-IoT device 3-1 may modulate the unmodulated carrier signal 20-1 (or CW) that it received (e.g., based on the R2D signal 20-2 it received) and backscatter / reflect that modulated signal as a (modulated) backscattered D2R signal 20-3, to the intermediate node 5-2.

[0128] Similarly to in Fig. 4A, the intermediate node 5-2 may then send / relay the backscattered D2R signal 20-3 it receives from the A-IoT device 3-1 (or at least the information encoded in it), to the RAN node 5-1 in an uplink signal as part of the communication 20-4 between the intermediate node 5-2 and the RAN node 5-1. The backscattered D2R signal 20-3 may be processed before being relayed by the intermediate node 5-2 to the RAN node 5-1. For example, the backscattered D2R signal 20-3 may be processed by the intermediate node 5-2 to extract information encoded in the backscattered D2R signal 20-3, and to encapsulate the extracted information into an appropriate message format (e.g., in accordance with a corresponding application protocol) for communication with the RAN node 5-1. Alternatively, the backscattered D2R signal 20-3 may itself be processed by the intermediate node 5-2 (without extracting any data encoded in it) to encapsulate it into an appropriate message format (e.g., in accordance with a corresponding application protocol) for communication with the RAN node 5-1.

[0129] It will be appreciated that in the arrangement of Fig. 4A and Fig. 4B, the intermediate node 5-2 may be of a type that attempts to demodulate the received backscattered signal for subsequent forwarding of the data to the RAN node 5-1 (e.g., a layer-2 (L2) relay device that attempts to demodulate any layer-1 (L1) signals that it receives). Such an intermediate node 5-2 may be referred to as be a layer 2 ('L2') type intermediate node 5-2. Nevertheless, the intermediate node 5-2 may be of a type that blindly forwards a received signal without attempting to demodulate it and hence, on receipt of the backscattered signal no attempt is made to demodulate it (e.g., an L1 repeater device or a network-controlled repeater (NCR) node). Such an intermediate node 5-2 may be referred to as be a layer 1 ('L1') type intermediate node 5-2.

[0130] Topology 2 may be deployed for scenarios with a type 1, 2a, and / or 2b A-IoT device 3-1, in which the A-IoT device 3-1 is in an indoor environment but the RAN node 5-1 is located in an outdoor environment. In this scenario the RAN node 5-1 may support one or more small cells (e.g., micro-cells) used for voice, video, and data transmission, which are designed to provide network coverage to small areas and operate on either licensed FDD, licensed TDD, or unlicensed parts of the spectrum. Alternatively, the RAN node 5-1 may support one or more larger cells (e.g., macro- cells) providing radio coverage to a large area, and that operate on either licensed FDD, licensed TDD, or unlicensed parts of the spectrum. In this scenario, the intermediate node 5-2 may be located in an indoor or an outdoor environment.

[0131] Topology 2 may also be deployed for indoor scenarios with a type 1, 2a, and / or 2b A-IoT device 3-1, intermediate node 5-2 and RAN node 5-1 are located in an indoor environment. In this scenario the RAN node 5-1 typically supports one or more small cells (e.g., micro-, and pico- cells) used for voice, video, and data transmission, which are designed to provide network coverage to small areas and operate on either licensed FDD, licensed TDD, or unlicensed parts of the spectrum.

[0132] Topology 2 may also be deployed for outdoor scenarios with a type 1, 2a or 2b A-IoT device 3-1, RAN node 5-1 and intermediate node 5-2 being located in an outdoor environment. In this scenario the RAN node 5-1 may support one or more small cells (e.g., micro-cells) used for voice, video, and data transmission, which are designed to provide network coverage to small areas and operate on either licensed FDD, licensed TDD, or unlicensed parts of the spectrum. Alternatively, the RAN node 5-1 may support one or more larger cells (e.g., macro- cells) providing radio coverage to a large area, and that operate on either licensed FDD, licensed TDD, or unlicensed parts of the spectrum.

[0133] This topology may, for example, be appropriate for a situation in which a RAN node 5-1 needs to fetch data (e.g., a meter record, a sensor reading, an error code and / or the like) from the A-IoT device 3-1. The RAN node 5-1 will trigger the intermediate node 5-2 to send an unmodulated carrier signal 20-1 as a 'stimulus' signal to the A-IoT device 3-1 which will automatically respond with the required data encoded in the resulting backscattered / reflected signal. The resulting backscattered / reflected signal (or at least the data encoded in it) will then be forwarded / relayed to the RAN node 5-1.

[0134] Topology 3: RAN node <= => Assisting node <= => A-IoT device <= => RAN node: 　　Figs. 5A and 5B illustrate schematically a third connectivity topology (topology 3) of the mobile (cellular or wireless) communication system 1.

[0135] As shown in Figs. 5A and 5B, in topology 3 part of the functionality of an A-IoT device reader is implemented as part of an assisting node 5-2 and part of the functionality of the A-IoT device reader is implemented as part of a RAN node 5-1. Specifically, an A-IoT device 3-1 and the RAN node 5-1 engage in communication with one another via the assisting node 5-2 (which may also be referred to as an intermediate node). It will be appreciated that while the assisting node 5-2 is depicted in Fig. 5A and Fig. 4B as a type of base station, the assisting node 5-2 may in fact be any one of an IAB node, a UE 3, a repeater, or the like, or any other appropriate device that can act as an intermediary between the RAN node 5-1 and the A-IoT device 3-1.

[0136] It will be appreciated that the assisting node 5-2 may be of a type that attempts to demodulate the received backscattered signal for subsequent forwarding of the data to the RAN node 5-1 (e.g., a layer-2 (L2) relay device that attempts to demodulate any layer-1 (L1) signals that it receives). Such an assisting node may be referred to as be a layer 2 ('L2') type assisting node 5-2. Nevertheless, the assisting node 5-2 may be of a type that blindly forwards a received signal without attempting to demodulate it (e.g., an L1 repeater device or a network-controlled repeater (NCR) node) and hence, on receipt of the backscattered signal no attempt is made to demodulate it. Such an assisting node may be referred to as be a layer 1 ('L1') type assisting node 5-2.

[0137] As shown in Fig. 5A, the A-IoT device 3-1 may communicate with the RAN node 5-1 in a downlink direction and an assisting (intermediate) node 5-2 in an uplink direction (e.g., on a 'sidelink' or similar). The communication between the RAN node 5-1 and the A-IoT device 3-1, or the communication between the assisting node 5-2 and the A-IoT device 3-1 respectively may occur over an appropriate air interface. For example, they may communicate over a Uu or dedicated 'sidelink' interface.

[0138] In this example the RAN node 5-1 (base station / cell) is responsible for transmission of an unmodulated carrier signal 20-1 (or CW) to the A-IoT device 3-1 to provide the A-IoT device 3-1 with a signal and / or energy based upon which modulated and backscattered / reflected information can be sent. Upon receiving an R2D signal 20-2 from the RAN node 5-1, the unmodulated carrier signal 20-1 may be modulated (e.g., based on the received R2D signal 20-2) and backscattered, as a (modulated) backscattered D2R signal 20-3, from the A-IoT device 3-1 and received at the assisting node 5-2. That is, the assisting node 5-2 is responsible for receiving the backscattered D2R signal 20-3 from the A-IoT device 3-1. The backscattered D2R signal 20-3 (or at least the information encoded in it), once received by the assisting node 5-2, may be relayed (forwarded / transmitted) to the RAN node 5-1 in another appropriate signal 20-3'. The backscattered D2R signal 20-3 may be processed before being relayed / forwarded by the assisting node 5-2 to the RAN node 5-1. For example, the backscattered D2R signal 20-3 may be processed by the assisting node 5-2 to extract information encoded in the modulated backscattered signal, and to encapsulate the extracted information into an appropriate message format (e.g., in accordance with a corresponding application protocol) for communication with the RAN node 5-1 over the appropriate signal 20-3'. Alternatively, the backscattered D2R signal 20-3 may itself be processed by the assisting node 5-2 (without extracting any data encoded in it) to encapsulate it into an appropriate message format (e.g., in accordance with a corresponding application protocol) for communication with the RAN node 5-1 over the appropriate signal 20-3'.

[0139] The communication (appropriate signal 20-3') between the RAN node 5-1 and the assisting node 5-2 occurs over an appropriate interface. For example, the RAN node 5-1 and the assisting node 5-2 may communicate over an air interface (such as the Uu interface or the like), for example where the assisting node 5-2 is a UE 3 (or at least acts like a UE 3 in its communication with the RAN node 5-1). The RAN node 5-1 and assisting node 5-2 may communicate over an appropriate IAB interface (such as F1), for example where the RAN node 5-1 acts as an IAB donor base station and the assisting node 5-2 is an IAB node. Nevertheless, the RAN node 5-1 and the assisting node 5-2 may communicate over a dedicated interface for the purpose of ambient IoT. The communication, comprising the backscattered D2R signal 20-3 received at the assisting node 5-2 from the A-IoT device 3-1, also occurs over an appropriate air interface. For example, they may communicate over a Uu or a dedicated interface.

[0140] This topology may, for example, be appropriate for a situation in which a RAN node 5-1 needs to fetch data (e.g., a meter record, a sensor reading, an error code and / or the like) from the A-IoT device 3-1. The RAN node 5-1 will send an unmodulated carrier signal 20-1 as a 'stimulus' signal to the A-IoT device 3-1 which will automatically respond with the required data encoded in the resulting backscattered / reflected signal sent to the assisting node 5-2 for relaying / forwarding to the RAN node 5-1.

[0141] Alternatively, as shown in Fig. 5B, the A-IoT device 3-1 may communicate with the RAN node 5-1 in an uplink direction and the assisting (intermediate) node 5-2 in a downlink direction (e.g., on a 'sidelink' or similar). The communication between the RAN node 5-1 and A-IoT device 3-1, and the communication between the assisting node 5-2 and the A-IoT device 3-1, respectively occur over an appropriate air interface. For example, they may communicate over a Uu or dedicated 'sidelink' interface.

[0142] In this example the assisting node 5-2 is responsible for transmission of an unmodulated carrier signal 20-1 to the A-IoT device 3-1 to provide the A-IoT device 3-1 with a signal and / or energy based upon which modulated and backscattered / reflected information can be sent. Upon receiving an R2D signal 20-2 from the assisting node 5-2, the unmodulated carrier signal 20-1 may be modulated (e.g., based on the received R2D signal 20-2) and backscattered, as a (modulated) backscattered D2R signal 20-3, from the A-IoT device 3-1 and received at the RAN node 5-1. That is, the RAN node 5-1 (base station / cell) is responsible for receiving the backscattered D2R signal 20-3 from the A-IoT device 3-1. The transmission of the unmodulated carrier signal 20-1 may be triggered by a downlink signal 20-2' received by the assisting node 5-2 from the RAN node 5-1. For example, the downlink signal 20-2' may be (or may carry) the unmodulated carrier signal 20-1 that is to be transmitted (e.g. relayed) by the assisting node 5-2 to the A-IoT device 3-1 or may be a trigger signal for triggering transmission of the unmodulated carrier signal 20-1.

[0143] This topology may, for example, be appropriate for a situation in which a RAN node 5-1 needs to fetch data (e.g., a meter record, a sensor reading, an error code and / or the like) from the A-IoT device 3-1. The RAN node 5-1 will send an unmodulated carrier signal 20-1 as a 'stimulus' signal to the IoT device 3-1 which will automatically respond with the required data encoded in the resulting backscattered / reflected signal sent to the assisting node 5-2. The resulting backscattered / reflected signal (or at least the data encoded in it) will then be forwarded / relayed to the RAN node 5-1 by the assisting node 5-2.

[0144] Similarly to Fig. 5A, in Fig. 5B the communication (downlink signal 20-2') between the RAN node 5-1 and the assisting node 5-2 occurs over an appropriate interface. For example, the RAN node 5-1 and the assisting node 5-2 may communicate over an air interface (such as the Uu interface or the like), for example where the assisting node 5-2 is a UE (or at least acts like a UE in its communication with the RAN node 5-1). The RAN node 5-1 and assisting node 5-2 may communicate over an appropriate IAB interface (such as F1), for example where the RAN node 5-1 acts as an IAB donor base station and the assisting node 5-2 is an IAB node. Nevertheless, the RAN node 5-1 and the assisting node 5-2 may communicate over a dedicated interface for the purpose of ambient IoT. The downlink communication, comprising the unmodulated carrier signal 20-1 sent from the assisting node 5-2 to the A-IoT device 3-1, also occurs over an appropriate air interface. For example, they may communicate over a Uu or a dedicated interface.

[0145] This topology may, for example, be appropriate for a situation in which a RAN node 5-1 needs to fetch data (e.g., a meter record, a sensor reading, an error code and / or the like) from the A-IoT device 3-1. The RAN node 5-1 will trigger the assisting node 5-2 to send an unmodulated carrier signal 20-1 as a 'stimulus' signal to the A-IoT device 3-1 which will automatically respond with the required data encoded in the resulting backscattered / reflected signal sent to the RAN node 5-1.

[0146] In either scenario (illustrated in Fig. 5A or 5B), backscattering may be supported even if the RAN node 5-1 and / or the assisting node 5-2 do not support full duplex operation.

[0147] <A-IoT Four-Step Random Access Procedures> 　　The A-IoT device reader (e.g., RAN node 5-1 or assisting / intermediate node 5-2) and the A-IoT device 3-1 of the communication system 1 are mutually configured for supporting A-IoT specific random access between the A-IoT device reader and the A-IoT device 3-1.

[0148] Specifically, the A-IoT device reader (e.g., RAN node 5-1 or assisting / intermediate node 5-2) and the A-IoT device 3-1 of the communication system 1 are mutually configured to support an A-IoT 'four-step' RA procedure. It will be appreciated that the term 'four-step' is used because the procedure is respectively analogous to (and serve a similar purpose to), a conventional four-step RACH procedure. Nevertheless, the A-IoT four-step RA procedure is different to their conventional cellular counterparts. For example, there may be more than four messages sent during an A-IoT four-step RA procedure. An A-IoT 'four-step' RA procedure may also be called as 'three-step' RA procedure, since sometimes, one or more steps may be skipped during random access for A-IoT device 3-1.

[0149] Fig. 6 is a simplified sequence diagram of an example A-IoT 'four-step' random access procedure that may be implemented in the communication system 1.

[0150] As seen in Fig. 6, in the A-IoT four-step random access (RA) procedure is triggered, at S602, by the A-IoT device reader sending an appropriate reader-to-device (R2D) initial trigger message ('A-IoT Msg0') targeted at or more A-IoT devices 3-1. The A-IoT device reader includes, in the initial trigger message, information (appropriate parameters) that a recipient A-IoT device 3-1 needs to respond to the random access trigger. The initial trigger message (A-IoT Msg0) may be configured to trigger initial access by a single A-IoT device 3-1 or a specific group of A-IoT devices 3-1 in a cell / coverage area. The information may comprise, for example, information indicating: a specific targeted / selected device (e.g. a device identifier); a specific targeted / selected group of one or more A-IoT devices 3-1 (e.g. a (sub)group identifier and / or one or more device identifiers); a targeted / selected device type; a device or device group that are not targeted / selected (e.g., masking information and / or a group identifier); and / or the like). Nevertheless, the initial trigger message may be configured as a 'blind' request or the like to trigger initial access by all recipient A-IoT devices 3-1 within the cell / coverage area (e.g., by omitting information targeting a specific device, or group of A-IoT devices 3-1, by including information that is common to all A-IoT devices 3-1 within the cell / coverage area, and / or by including an indicator that any recipient device should respond). The information may also comprise, for example, information indicating one or more time and / or frequency resources of one or more RA occasions (e.g., including frequency information, time / frequency resource location, length of the slots for all RA occasions, slot length for each RA occasion, and or the like). The information may also comprise, for example, information indicating the number of RA occasions and / or the availability of each RA occasion. The information may also comprise, for example, an indication that the following access cycle / RA procedure is a repetition and forms part of the current (same) access round (e.g., like a QueryRep command in RFID), or is the start (first access cycle / RA procedure) of a new access round.

[0151] It will be appreciated that all the A-IoT devices 3-1 within the cell / coverage area of the A-IoT device reader may receive the initial trigger message (A-IoT Msg0) (subject to local radio conditions, any interference, and / or the like that may result in a failure to receive the message). However, only those specifically targeted / selected by the initial trigger message (A-IoT Msg0) will be triggered to initiate random access. To facilitate this when an A-IoT device 3-1 receives the initial trigger message (A-IoT Msg0), that A-IoT device 3-1 will determine whether that A-IoT device 3-1 is targeted / selected by the initial trigger message (A-IoT Msg0) by checking (at S604) whether or not information stored locally at the A-IoT device 3-1 (e.g., a device identity (or part of such an identity), a (sub)group identity, a device type indication, or the like) matches corresponding information in the initial trigger message (A-IoT Msg0). When the device (type) matches a device (type) targeted / selected by the initial trigger message (A-IoT Msg0) the A-IoT device 3-1 performs RA resource selection as seen at S604. This RA resource selection involves selecting a specific RA occasion comprising resources to be used for a subsequent D2R transmission (e.g., of A-IoT Msg1). The resources forming each RA occasion may be divided (and hence selectable) in the time and / or frequency domain.

[0152] Having been triggered by an R2D initial trigger message (A-IoT Msg0), the A-IoT device 3-1 sends, at S606, an initial device-to-reader (D2R) message ('A-IoT Msg1') using the selected RA occasion (time / frequency resources). The initial D2R message (A-IoT Msg1) carries a corresponding identifier (e.g., a random number / random ID generated by A-IoT device 3-1), and possibly other information, to the A-IoT device reader. The identifier may, for example, be a 16-bit random number (RN16) as used in RFID access procedures but may be some other form of (random) identifier.

[0153] If the initial D2R message (A-IoT Msg1) is received successfully at the A-IoT device reader (e.g., because there is no contention or other interference that causes a reception failure), then the A-IoT device reader echoes, at S608, the identifier received in the initial D2R message (A-IoT Msg1) back to the A-IoT device 3-1 in an appropriate R2D access response message ('A-IoT Msg2') that may include additional useful information where appropriate. The R2D access response message (A-IoT Msg2) effectively serves as contention resolution - the A-IoT device 3-1 assumes contention resolution to have been successful, if a received R2D response message (A-IoT Msg2) includes the same random identifier that was sent by that A-IoT device 3-1 in the initial D2R message (A-IoT Msg1).

[0154] The A-IoT device 3-1 then sends, at S610, a further D2R message (A-IoT Msg3) including that A-IoT device's A-IoT device identifier (or possibly a short version of that identifier) (and / or a (sub)group identifier) and / or any other higher layer data (e.g., depending on a higher layer request). The A-IoT device's A-IoT device identifier may be at least locally unique and / or may be a temporary identifier allocated by the network.

[0155] An R2D data transmission / message ('A-IoT Msg4') may then be sent by the A-IoT device reader to the A-IoT device 3-1 (as seen at S612), after the further D2R message (A-IoT Msg3) has been received, that may, for example, comprise an inventory command or inventory request (or possibly an upper layer configuration). It will be appreciated that an inventory command may be used to configure the device (in which case there may be no follow-up message from the A-IoT device reader and so that access cycle / RA procedure may end). An inventory request, on the other hand requests a response from the A-IoT device 3-1 and so there will be a follow-up D2R message ('A-IoT Msg3').

[0156] If an R2D data transmission (A-IoT Msg4) is received by the A-IoT device 3-1, from the A-IoT device reader, then the A-IoT device 3-1 may respond appropriately (as seen at S614). For example, the A-IoT device 3-1 may send a D2R data transmission / message ('A-IoT Msg5') to the A-IoT device reader, for example, to provide an inventory response transmission (or the like) - for example to respond to an inventory request if provided with the previous R2D data transmission (A-IoT Msg4).

[0157] Whilst the A-IoT random access procedure described above is based on a 'four-step' conventional random access procedure, the skilled person would readily understand that appropriate adaptations can be made to the above-described procedure to instead implement an A-IoT random access procedure based on a 'two-step' conventional random access procedure.

[0158] < R2D Preamble / SIP Pattern Design for R2D Transmissions> 　　As alluded to above, as A-IoT devices 3-1 become more prevalent and their functionalities are further developed, the difference in functionalities between different A-IoT device types (e.g., type 1, 2, 2a, and 2b) are likely to diverge.

[0159] Beneficially, therefore, each A-IoT device 3-1 and each A-IoT device reader of the communication system 1 may be mutually configured for supporting one or more techniques or procedures for enabling each A-IoT device 3-1 of a specific type to avoid, or at least minimise, unnecessary reception / and or decoding of R2D transmissions from an A-IoT device reader relating to functionalities that the specific type of A-IoT device 3-1 does not support and / or for enabling each A-IoT device 3-1 of the same specific A-IoT device type to avoid, or at least minimise, unnecessary reception / and or decoding of R2D transmissions from an A-IoT device reader relating to functionalities supported by the specific A-IoT device type, when a specific operation / function to which the R2D transmission relates is not intended for the A-IoT device.

[0160] Specifically, for example, as described in more detail later, each A-IoT device 3-1 and each A-IoT device reader of the communication system 1 may be mutually configured for supporting the use of a plurality of differently configured prefix portions (e.g., using differently configured R2D preambles / SIP patterns and / or the introduction of one or mor differently configured sequences) to differentiate between different A-IoT device types for R2D transmission and reception.

[0161] Beneficially, for example, as described in more detail later, each A-IoT device 3-1 and each A-IoT device reader of the communication system 1 may be configured to support use of a plurality of A-IoT device type specific prefix portions (e.g., comprising a per A-IoT device type R2D preamble / SIP and / or a per A-IoT device type sequence) to enable each A-IoT device 3-1 to determine whether or not to receive / decode an R2D transmission. Accordingly, if the functionality with which a given R2D transmission is associated, is not supported by a given type of A-IoT device 3-1, then an A-IOT device 3-1 of the specific type can determine not to receive / decode the corresponding R2D transmission. Hence, unnecessary reception / decoding of R2D transmissions that are not supported by an A-IoT device 3-1, are avoided / minimised thus saving power / energy at the A-IoT device 3-1.

[0162] Additionally (or alternatively), as described in more detail later, each A-IoT device 3-1 and each A-IoT device reader of the communication system 1 may be beneficially configured to support use of a plurality of A-IoT device 3-1 (or A-IoT device group) specific prefix portions (e.g., comprising a per A-IoT device 3-1 (or A-IoT device group) R2D preamble / SIP and / or a per A-IoT device 3-1 (or A-IoT device group) sequence) to enable each A-IoT device 3-1 of the same given A-IoT device type (e.g., type 1, 2a, or 2b) to determine whether or not to receive / decode an R2D transmission even if that R2D transmission is associated with the given device type. Accordingly, if the R2D transmission is specifically directed toward a specific A-IoT device 3-1, or a specific group of A-IoT devices 3-1, of a given A-IoT device type (e.g., type 1, 2a, or 2b), - e.g., in relation to a specific operation / function to be performed by the specific A-IoT device 3-1, or group of A-IoT devices 3-1, other A-IoT devices 3-1 that the specific operation / function is not intended for can determine not to receive / decode the corresponding R2D transmission. Hence, unnecessary reception / decoding of R2D transmissions that are intended for a specific A-IoT device 3-1 (or a specific group of A-IoT devices 3-1) of a given A-IoT device type, at another A-IoT device 3-1 of the same given type for which the R2D transmissions are not intended, are avoided / minimised thus saving power / energy at the A-IoT device 3-1.

[0163] < Supporting both DO-A and non-DO-A A-IoT Devices> 　　As alluded to above, as A-IoT devices 3-1 become more prevalent, the deployment of DO-A A-IoT devices is also set to increase (e.g., sensors, and the like, that autonomously transmit data to A-IoT device readers).

[0164] Beneficially therefore, as described in more detail later, each A-IoT device 3-1 and each A-IoT device reader of the communication system 1 may be mutually configured for implementing one or more enhancements to a random access procedure to support the deployment of both DO-A A-IoT devices and non-DO-A A-IoT devices in the communication system 1.

[0165] < Per A-IoT Device Type R2D Prefix Portion Configurations> 　　As described above, each A-IoT device 3-1 and each A-IoT device reader of the communication system 1 may be configured to support use of a plurality of A-IoT device type specific prefix portions (e.g., comprising a per A-IoT device type specific R2D preamble / SIP and / or a per A-IoT device type specific sequence) to enable each A-IoT device 3-1 to determine whether or not to decode a PRDCH of an R2D transmission.

[0166] A number of possible techniques for implementing such A-IoT device type specific prefix portions will now be described, by way of example only.

[0167] Referring to Fig. 7, for example, which illustrates R2D transmission and reception for R2D transmissions that have different SIPs, the prefix portion of an R2D transmission may comprise an A-IoT device type specific (or 'A-IoT device type common') SIP configuration.

[0168] Specifically, in the example of Fig. 7, each A-IoT device reader is configured to use a different respective A-IoT device type specific (common / type-level) SIP configuration (e.g., SIP #1, #2, #3) for A-IoT devices 3-1 of each of a plurality of different A-IoT device types (e.g., type 1, 2a, and / or 2b). Similarly, each A-IoT device 3-1 of a specific A-IoT device type (e.g., type 1, 2a, and / or 2b) is configured to determine whether or not to decode PRDCH of a given R2D transmission sent by the A-IoT device reader based on the configuration of the SIP in the prefix portion of that R2D transmission. Specifically, if the R2D transmission sent by the A-IoT device reader contains a SIP having a configuration corresponding the specific A-IoT device type of the A-IoT device 3-1, then the A-IoT device 3-1 will fully decode that R2D transmission. If, on the other hand, the R2D transmission sent by the A-IoT device reader contains a SIP having a configuration corresponding a different A-IoT device type to that of the A-IoT device 3-1, then the A-IoT device 3-1 will not decode that R2D transmission.

[0169] For example, an A-IoT device reader may be configured to use a first SIP configuration (SIP #1) for R2D transmissions for a first set of one or more A-IoT devices 3-1 of type 1 (e.g., A-IoT devices 3-11, 3-12, 3-13) and each type 1 A-IoT device 3-11, 3-12, 3-13 may be configured to only decode PRDCH of R2D transmissions sent by an A-IoT device reader that have a prefix portion containing the first SIP configuration (SIP #1). Similarly, the A-IoT device reader may be configured to use a second SIP configuration (SIP #2) for R2D transmissions for a second set of one or more A-IoT devices 3-1 of type 2a (e.g., A-IoT devices 3-14, 3-15) and each type 2a A-IoT device 3-14, 3-15 may be configured to only decode PRDCH of R2D transmissions sent by an A-IoT device reader that have a prefix portion containing the second SIP configuration (SIP #2). Moreover, an A-IoT device reader may be configured to use a third SIP configuration (SIP #3) for R2D transmissions for a third set of one or more A-IoT devices 3-1 of type 2b (e.g., A-IoT device 3-16) and each type 2b A-IoT device 3-16 may be configured to only decode PRDCH of R2D transmissions sent by an A-IoT device reader that have a prefix portion containing the third SIP configuration (SIP #3), and so on.

[0170] Accordingly, as shown in Fig. 7, when the A-IoT device reader transmits an R2D transmission that contains SIP #1, each type 1 A-IoT device 3-11, 3-12, 3-13 will decode that R2D transmission, but the other A-IoT devices 3-14, 3-15, 3-16 (of other types) will fail to detect and decode the R2D transmission. Similarly, where the A-IoT device reader transmits an R2D transmission that contains SIP #2, each type 2a A-IoT device 3-14, 3-15 will receive and decode that R2D transmission, but the other A-IoT devices 3-11, 3-12, 3-13, 3-16 (of other types) will fail to detect and decode the R2D transmission. Moreover, where the A-IoT device reader transmits an R2D transmission that contains SIP #3, each type 2b A-IoT device 3-16 will receive and decode that R2D transmission but the other A-IoT devices 3-11, 3-12, 3-13, 3-14, 3-15 (of other types) will fail to detect and decode the R2D transmission.

[0171] <Per A-IoT Device Type SIP Design> 　　In the case of the type 1 A-IoT devices 3-11, 3-12, 3-13, the A-IoT device type specific SIP implemented for those type 1 A-IoT devices 3-11, 3-12, 3-13 may, for example, comprise a single ON / OFF transmission pattern / sequence. In this case, the ON period and the OFF period that follows it may be of the same duration (i.e., an ON:OFF duration ratio of 1:1). In another example, the ON period and the OFF period that follows may be configured to have an ON:OFF duration ratio of 1:2 or 1:3. In yet another example, the ON period and the OFF period that follows it may be configured to have an ON:OFF duration ratio of 2:1 or 3:1.

[0172] In the case of other types of A-IoT devices 3-1 (e.g., type 2a, type 2b), the A-IoT device type specific SIP may be configured to have a single ON / OFF pattern / sequence, or a multi-ON / OFF pattern / sequence. For example, the A-IoT device type specific SIP for type 2a and / or 2b A-IoT devices 3-14, 3-15, 3-16 may comprise a single ON / OFF transmission - i.e., one high-voltage transmission followed by one low-voltage transmission, where the ON and the OFF may have the same or different durations. In another example, the ON / OFF pattern may comprise a multi-ON / OFF transmission (i.e., a plurality of ON / OFF cycles), where different ON periods may have the same or different durations, and different OFF periods may have the same or different durations.

[0173] For example, where a multi-ON / OFF transmission is used, a plurality of ON / OFF transmission repetitions may occur in which each repetition includes an ON period and an OFF period with same duration. In another example, each repetition may have an ON period and an OFF period that follows it, with an ON:OFF duration ratio of 1:2 or 1:3. In yet another example, each repetition may have an ON period and an OFF period that follows it with an ON:OFF duration ratio of 2:1 or 3:1. In a further example, the ON / OFF transmission may be implemented in an ON-OFF-ON pattern where the duration of ON and OFF can be different. In another example, the ON / OFF transmission may be implemented in an OFF-ON-OFF pattern where the duration of ON and OFF can be different. In yet a further example, the ON / OFF transmission may be implemented in a pattern comprising a single ON / OFF transmission having an ON period and an OFF period with same duration, and a single ON / OFF transmission having a different ON:OFF duration ratio (e.g., 1:2, 1:3, or the like).

[0174] In yet another example, the A-IoT device type specific SIP for other types of A-IoT devices 3-1 (e.g., type 2a, type 2b) may comprise an ON / OFF pattern based on a pre-defined ON / OFF sequence to be used for detection of the SIP that is based on a digital correlation (e.g., by correlating / matching the pre-defined sequence to a digital sequence of '1s' and '0s').

[0175] It will be appreciated that whilst the above description refers specifically to A-IoT device type specific SIPs, the prefix portion of the R2D transmissions may be configured to be A-IoT device type specific in other ways (e.g., comprising an A-IoT device type specific R2D preamble / A-IoT device type sequence without necessarily including a device type specific SIP).

[0176] Beneficially, in the above enhanced mechanism, each A-IoT device 3-1 can be aware when an R2D transmission by the A-IoT device reader is intended for a different A-IoT device 3-1 than itself by detecting the device type specific prefix portion (e.g., comprising a per A-IoT device type R2D preamble / SIP and / or a per A-IoT device type sequence) of the R2D transmission prior to the PRDCH. Accordingly, each A-IoT device 3-1 does not need to decode any part of the PRDCH, thereby reducing the amount of power consumed by each A-IoT device 3-1.

[0177] Additionally, in a case where the R2D transmission is associated with new / enhanced functionalities not supported by some A-IoT device types (e.g., A-IoT device type 1), an A-IoT device type specific prefix portion (e.g., comprising a per A-IoT device type specific R2D preamble / SIP and / or a per A-IoT device type specific sequence) can be used so that A-IoT device types that do not support those new / enhanced functionalities do not decode the PRDCH transmissions.

[0178] Furthermore, the above enhanced mechanism, beneficially avoids the need for increased complexity for reception of R2D transmissions by A-IoT devices 3-1 of type 1.

[0179] < R2D Transmission Design for Reception by Both Type 1 and Type 2a A-IoT Devices> 　　Whilst the above device type specific prefix portion design is described in the context of R2D transmissions that are specifically intended for one A-IoT device type or another, it will nevertheless be appreciated that in certain circumstances an R2D transmission by an A-IoT device reader may be intended for multiple A-IoT device types. For example, a paging message, or a message as part of a random access procedure that is common for, and directed to, two or more different A-IoT device types.

[0180] By way of example only for illustrative purposes, in the procedure of Fig. 6, the initial trigger message at step S602 may be intended for a plurality of different A-IoT devices 3-1 of different A-IoT device types. In this scenario, the use of a single device type specific prefix portion as described above may not be sufficient, as doing so could result in the initial trigger message (i.e., R2D transmission) only being detected and decoded by A-IoT devices 3-1 of the specific type to which the that use the device type specific prefix portion is associated with.

[0181] In such a scenario, two separate R2D transmissions may be scheduled, each comprising a different respective device type specific prefix portion as described above. For example, one R2D transmission may be scheduled that includes a device type specific prefix portion for type 1 A-IoT devices 3-1, and a second R2D transmission may be scheduled that includes a device type specific prefix portion for type 2a A-IoT devices 3-1.

[0182] Alternatively, one or more specific R2D transmission types (e.g., paging or the like) which may be intended for a plurality of A-IoT device types (e.g., both type 1 and type 2a) may use an A-IoT device type 1 specific prefix portion (e.g., including SIP #1). Each other A-IoT device 3-1 of another A-IoT device type (e.g., type 2a) that is intended to receive that specific R2D transmission type may be configured to check / detect whether each R2D transmission it receives contains either a device type specific prefix portion for type 1 A-IoT devices 3-1 (e.g., including SIP #1) or a device type specific prefix portion for the A-IoT device type (e.g., type 2a) of the other A-IoT device 3-1 (e.g., including SIP #2). Upon detecting either of those device type specific prefix portions in the R2D transmission, each other A-IoT device 3-1 of another A-IoT device type (e.g., type 2a) that is intended to receive that specific R2D transmission type may thus detect the CAP of the R2D preamble and decode the PRDCH.

[0183] A procedure for reception of specific R2D transmission types (e.g., paging or the like) that may be intended for a plurality of A-IoT device types (e.g., both type 1 and type 2a) will now be described in more detail, by way of example only, with reference to Fig. 8.

[0184] Fig. 8 illustrates a simplified sequence diagram of an example R2D reception procedure that may performed by A-IoT devices 3-1 of one type (e.g., type 2a) for receiving R2D transmissions that may be intended for a plurality of A-IoT device types (e.g., both type 1 and type 2a).

[0185] As shown in Fig. 8, at step S802, the A-IoT device reader may transmit (or broadcast) an R2D transmission that is intended at least for A-IoT devices 3-1 of single type (e.g., type 2a), but may possibly also be intended for A-IoT devices 3-1 of more than one type - for example a first type (e.g., type 1) and a second type (e.g., type 2a). For an R2D transmission type that may be intended for A-IoT devices 3-1 of both types (e.g., type 1 and type 2a) the A-IoT device reader may include an A-IoT device type specific prefix portion (e.g., including SIP #1) associated with the first type (e.g., type 1) in the R2D transmission. For an R2D transmission type that is intended for A-IoT devices 3-1 of only the second type (e.g., type 2a) the A-IoT device reader may include an A-IoT device type specific prefix portion (e.g., including SIP #2) for the second type (e.g., type 2a) if the R2D transmission.

[0186] At step S804, the A-IoT device 3-1 (which in this example is of the second type (e.g. type 2a)), first checks / detects whether or not the R2D transmission includes an A-IoT device type specific prefix portion corresponding to the second type of the A-IoT device 3-1 (e.g., a SIP specifically for type 2a A-IoT devices 3-1 (e.g., SIP #2)).

[0187] If at step S804, the A-IoT device 3-1 of the second type detects that the prefix portion (preamble) of the R2D transmission includes an A-IoT device type specific prefix portion for A-IoT devices 3-1 of the second type (e.g., the presence of SIP #2), then at step S806, the A-IoT device 3-1 of the second type detects the CAP in the prefix portion (preamble) of the R2D transmission and decodes the data contained in the data payload of the R2D transmission (i.e., the PRDCH).

[0188] If on the other hand at step S804, the A-IoT device 3-1 of the second type does not detect that the prefix portion (preamble) of the R2D transmission includes an A-IoT device type specific prefix portion for A-IoT devices 3-1 of the second type (e.g., the presence of SIP #2), then at step S808, the A-IoT device 3-1 of the second type checks / detects whether or not the R2D transmission includes an A-IoT device type specific prefix portion for A-IoT devices 3-1 of the first type (e.g., the presence of SIP #1).

[0189] If at step S808, the A-IoT device 3-1 of the second type detects that the prefix portion (preamble) of the R2D transmission includes an A-IoT device type specific prefix portion for A-IoT devices 3-1 of the first type (e.g., the presence of SIP #1), then at step S810, the A-IoT device 3-1 of the second type detects the CAP in the prefix portion (preamble) of the R2D transmission and decodes the data contained in the data payload of the R2D transmission (i.e., the PRDCH).

[0190] If on the other hand at step S808 the A-IoT device 3-1 of the second type does not detect that the R2D transmission includes an A-IoT device type specific prefix portion for A-IoT devices 3-1 of the first type (e.g., the presence of SIP #1), then at step S812, the A-IoT device 3-1 of the second type skips receipt / decoding of the R2D transmission.

[0191] In this manner, beneficially, a single R2D transmission that is intended for both the first type (e.g. type 1) and the second type (e.g., type 2a) of A-IoT devices 3-1 may be sent with an A-IoT device type specific prefix portion for A-IoT devices 3-1 of the first type (e.g., including SIP #1), and both A-IoT devices 3-1 of the first type and A-IoT devices 3-1 of the second type may be able to detect the A-IoT device type specific prefix portion for A-IoT devices 3-1 of the first type (e.g., the presence of SIP #1), and then subsequently detect the CAP in the prefix portion (preamble) of the R2D transmission and decode the data contained in the data payload of the R2D transmission (i.e., the PRDCH).

[0192] Whilst the above R2D transmission procedure has been described in the context of transmissions that are intended for type 1 and type 2a A-IoT devices 3-1, it will nevertheless be appreciated that a similar R2D transmission procedure may be implemented to allow a single R2D transmission of a particular type to be directed toward both type 1 and type 2b A-IoT devices 3-1 (or alternatively, type 1, type 2a, and type 2b A-IoT devices 3-1).

[0193] < Per A-IoT Device Specific R2D Prefix Portion Configurations> 　　As described above, each A-IoT device 3-1 and each A-IoT device reader of the communication system 1 may be configured to support use of a plurality of A-IoT device specific prefix portions (e.g., comprising a per A-IoT device R2D preamble / SIP and / or a per A-IoT device specific sequence) to enable each A-IoT device 3-1 to determine whether or not to decode PRDCH of an R2D transmission.

[0194] Specifically, a prefix portion for an R2D transmission, may configured to be specific to a particular A-IoT device 3-1 (or group of A-IoT devices 3-1) either in addition to, or as an alternative to, being configured to be specific to a particular A-IoT device type (e.g., type 1, type 2a, and type 2b).

[0195] For example, a prefix portion for an R2D transmission may be configured to include a specific sequence that is associated with a particular A-IoT device 3-1 (or group of A-IoT devices) in addition to including a SIP that is specific to a particular A-IoT device type (e.g., type 1, type 2a, and type 2b) (e.g., as described with reference to Fig. 7). Alternatively, the prefix portion for an R2D transmission may be configured either: to include a specific sequence that is associated with a particular A-IoT device 3-1 (or group of A-IoT devices 3-1); or to include a SIP that is specific to a particular A-IoT device type (e.g., type 1, type 2a, and type 2b) (e.g., as described with reference to Fig. 7); but not both.

[0196] A number of techniques for implementing such A-IoT device specific prefix portions will now be described, by way of example only.

[0197] In this way, an A-IoT device 3-1 can be identified / indicated in an R2D transmission using its corresponding device specific sequence, rather than an ID of the A-IoT device 3-1 which is typically located in the PRACH and must be decoded by the A-IoT devices 3-1 that receive the R2D transmission. It will be appreciated that beneficially, by identifying a specific A-IoT device 3-1 using a device specific sequence, rather than an ID of the A-IoT device 3-1, energy savings may be achieved, as each A-IoT device 3-1 that receive the R2D transmission does not have to decode the PRDCH to determine whether or not the R2D transmission is intended for that respective A-IoT device 3-1. The specific A-IoT device specific sequence may be or may include a device specific SIP.

[0198] In more detail, an A-IoT device specific sequence for each A-IoT device 3-1 (or for a group of A-IoT devices 3-1) may be generated based on ID-related information associated with the A-IoT device 3-1 (or group of A-IoT devices 3-1). For example, for a given A-IoT device 3-1, a device specific sequence may be generated based on the ID of the A-IoT device 3-1. It will be appreciated this in this case, beneficially, the device specific sequence may be self-generated by each A-IoT device 3-1 based on its ID (i.e., the device specific sequence does not need to be indicated separately to the A-IoT device 3-1 by A-IoT device reader, or other node of the communication system 1).

[0199] Alternatively, an A-IoT device specific sequence for each A-IoT device 3-1 may comprise a specific and unique ON / OFF transmission pattern (e.g., similar to that described for the A-IoT device type specific SIB in relation to Fig. 7). For example, an A-IoT device specific sequence for a specific A-IoT device 3-1 may comprise a single ON / OFF transmission - i.e., one high-voltage transmission followed by one low-voltage transmission, where the ON and the OFF may have same or different durations. In another example, an A-IoT device specific sequence may include a multi-ON / OFF transmission (i.e., a plurality of ON / OFF cycles), where different ON periods may have the same or different durations, and different OFF periods may have the same or different durations.

[0200] In the case where the A-IoT device specific sequence comprises a single ON / OFF transmission, the ON period and the OFF period that follows it may be of the same duration (i.e., an ON:OFF duration ratio of 1:1). In another example, in the case where the A-IoT device specific sequence comprises a single ON / OFF transmission, the ON period and the OFF period that follows it may be configured to have an ON:OFF duration ratio of 1:2 or 1:3. In yet another example, in the case where the A-IoT device specific sequence comprises a single ON / OFF transmission, the ON period and the OFF period that follows it may be configured to havean ON:OFF duration ratio of 2:1 or 3:1.

[0201] Alternatively, in the case where the A-IoT device specific sequence comprises a multi-ON / OFF transmission, a plurality of ON / OFF transmission repetitions may occur, whereby each repetition includes an ON period and an OFF period with same duration. In another example, each repetition may have an ON period and an OFF period that follows it, with an ON:OFF duration ratio of 1:2 or 1:3. In yet another example, each repetition may have an ON period and an OFF period that follows it with an ON:OFF duration ratio of 2:1 or 3:1. In a further example, the ON / OFF transmission may be implemented in an ON-OFF-ON pattern where the duration of ON and OFF can be different. In another example, the ON / OFF transmission may be implemented in an OFF-ON-OFF pattern where the duration of ON and OFF can be different. In yet a further example, the ON / OFF transmission may be implemented in a pattern comprising a single ON / OFF transmission having an ON period and an OFF period with same duration, and a single ON / OFF transmission having a different ON:OFF duration ratio (e.g., 1:2, 1:3, or the like).

[0202] In yet another example, the A-IoT device specific sequence may comprises an ON / OFF transmission pattern, the ON / OFF transmission pattern for each A-IoT device specific sequence to be used for detection of the SIP that is based on a digital correlation (e.g., by correlating / matching the pre-defined sequence to a digital sequence of '1s' and '0s').

[0203] It will be appreciated that in all of the cases described above where A-IoT device specific sequence comprises some form of ON / OFF transmission pattern, each A-IoT device specific sequence may be generated by the network and stored at the A-IoT device reader (or another node) in an appropriate mapping table or the like, whereby each entry in the mapping table is associated with a unique index that maps to a corresponding A-IoT device specific sequence. Those indices in turn may then be used to indicate to each A-IoT device 3-1 which A-IoT device specific sequence has been assigned to it by the A-IoT device reader, and thus which A-IoT device specific sequence it should look for in R2D transmissions that it detects / receives.

[0204] In an alternative example, the respective A-IoT device specific sequence for each A-IoT device 3-1 may reuse an A-IoT device specific D2R preamble (i.e., a per A-IoT device D2R preamble) that was included in a corresponding D2R transmission sent by the A-IoT device 3-1 to the A-IoT device reader. For example, in a case where code-division multiple-access (CDMA) encoding / modulation is supported such that several A-IoT devices 3-1 can send D2R transmissions to the A-IoT device reader simultaneously over a single PDRCH, each D2R transmission by a respective A-IoT device 3-1 may include an A-IoT device specific D2R preamble that distinguishes transmissions of that A-IoT device 3-1 from transmissions of other A-IoT devices 3-1 at the A-IoT device reader. That same CDMA encoding / modulation for the D2R preamble of a D2R transmission may be re-used by the A-IoT device reader to configure an A-IoT specific sequence to be included in an A-IoT device specific prefix portion of a corresponding R2D transmission so that the resulting prefix portion (preamble) is unique to the specific A-IoT device 3-1 and allows the A-IoT device 3-1 to detect when an R2D transmission is intended for it.

[0205] It will be appreciated that to support the re-use of an A-IoT device specific D2R preamble in this way, each A-IoT device 3-1 may report one or more D2R preambles it will use to the A-IoT device reader in its D2R transmissions.

[0206] It will also be appreciated that it may be beneficial to indicate when re-use of an A-IoT device specific D2R preamble in this way is enabled / disabled. As such an appropriate enable / disable indication may be sent by the A-IoT device reader to indicate when A-IoT device specific D2R preambles begin to be used (or cease to be used) in R2D transmissions.

[0207] It will be appreciated that whilst the above description refers specifically to inclusion of A-IoT device specific sequences in the prefix potion of the R2D transmissions, the prefix portion of the R2D transmissions may be configured to be A-IoT device specific in other ways (e.g., comprising an A-IoT device specific R2D preamble / A-IoT device specific SIP that is configured in a different manner).

[0208] < R2D Transmissions with Both an A-IoT Device Type Specific SIP and an A-IoT device specific Sequence (Case #1)> 　　As alluded to above, an A-IoT device specific sequence may be implemented in addition to an A-IoT device type specific SIP in an R2D transmission. For example, a prefix portion for an R2D transmission may be configured to include a specific sequence that is associated with a particular A-IoT device 3-1 (or group of A-IoT devices) in addition to including a SIP that is specific to a particular A-IoT device type (e.g., type 1, type 2a, and type 2b) (e.g., as described with reference to Fig. 7).

[0209] Fig. 9 illustrates an example R2D transmission format that may be used by an A-IoT device reader for including an A-IoT device type specific SIP and an A-IoT device specific sequence.

[0210] As shown in Fig. 9, an R2D transmission by an A-IoT device reader to one or more A-IoT devices 3-1 may include a preamble-based prefix portion before the data transmission on the PRDCH (carrying any R2D traffic data and / or any control information). A suffix portion comprising an R2D postamble (not shown) may also be added after the PRDCH transmission to indicate an end of the PRDCH transmission.

[0211] That preamble-based prefix portion comprises an R-TAS, which indicates the start time of the following PRDCH in the time domain and possibly chip length information. That R-TAS may comprise a SIP (e.g., an A-IoT device type specific SIP) to indicate the start of the R2D transmission, and a CAP following the SIP, and which is used to indicate / determine the OOK chip duration of the subsequent PRDCH transmission (e.g., as described above with reference to Fig. 1).

[0212] Furthermore, as shown in Fig. 9, as well as the A-IoT device type specific SIP included in the R-TAS (e.g., as described above with reference to Fig. 7), the R-TAS of the R2D transmission may also include an A-IoT device specific sequence. For example, an A-IoT device specific sequence may be inserted into the R-TAS of the R2D transmission at a first position (position #1) located between the A-IoT device type specific SIP and the CAP of the R-TAS, or at a second position (position #2) located after the CAP of the R-TAS of the R2D transmission. It will be appreciated that the A-IoT device specific sequence is not included in the PRDCH of the R2D transmission to avoid coding of the A-IoT device specific sequence, and thus the need for decoding by any A-IoT device 3-1 that receives the R2D transmission. Furthermore, the position of the A-IoT device specific sequence, within the prefix portion (preamble) of the R2D transmission, e.g., relative to the A-IoT device type specific SIP and / or CAP, may be fixed to reduce detection complexity of the A-IoT device type specific SIP.

[0213] In this way, following detection of the A-IoT device type specific SIP in the R2D transmission identifying a type of A-IoT device 3-1 to which the R2D transmission is directed (e.g., type 2a), the A-IoT devices 3-1 may then detect the A-IoT device specific sequence to identify which specific A-IoT device 3-1 (or subset of A-IoT devices 3-1) within the A-IoT devices 3-1 of the identified A-IoT device type, the R2D transmission is intended for.

[0214] For example, it will be appreciated that beneficially, where an A-IoT device 3-1 receives the R2D transmission and detects an A-IoT device type specific SIP in the R2D transmission corresponding to an A-IoT device type to which the A-IoT device 3-1 belongs, that A-IoT device 3-1 may then detect the A-IoT device specific sequence to determine whether the R2D transmission is intended for it or not. On the other hand, where an A-IoT device 3-1 receives the R2D transmission and detects an A-IoT device type specific SIP in the R2D transmission corresponding to an A-IoT device type to which the A-IoT device 3-1 does not belong, that A-IoT device 3-1 may not need to subsequently detect an A-IoT device specific sequence in the R2D transmission.

[0215] Alternatively, as well as the A-IoT device type specific SIP, a pre-defined / fixed sequence (i.e., a 'default' sequence) of 0s and 1s (or some other appropriate pattern) may be included in the same position of the A-IoT device specific sequence instead of the A-IoT device specific sequence when an R2D transmission is intended, not for a specific A-IoT device 3-1, but for all / a group of / multiple A-IoT devices 3-1 (e.g., every A-IoT device 3-1 of a specific A-IoT device type, or the like). That pre-defined / fixed sequence (or other appropriate pattern) may be of the same, or a different length as an A-IoT device specific sequence.

[0216] Figs. 10A and 10B illustrates is a simplified sequence diagram of another example R2D reception procedure that may be implemented in the communication system 1 for R2D transmissions including an A-IoT device type specific SIP and an A-IoT device specific sequence.

[0217] As shown in Fig. 10A, at step S1002, the A-IoT device reader may transmit (or broadcast) an R2D transmission that is intended for an A-IoT device 3-1 of a specific type of (e.g., type 2a). That R2D transmission may, for example, include an A-IoT device type specific SIP (e.g., SIP #2), and an A-IoT device specific sequence (e.g., a sequence associated with a specific A-IoT device 3-1).

[0218] At step S1004, the A-IoT device 3-1 first checks / detects whether or not the prefix portion (preamble) of the R2D transmission includes an A-IoT device type specific SIP (e.g., a SIP for type 2a A-IoT devices 3-1 such as SIP #2). If, however, at step S1004, the A-IoT device 3-1 does not detect any A-IoT device type specific SIP in the R2D transmission, then the A-IoT device 3-1 may jump to step S1016 shown in Fig. 10b and skip receiving the R2D transmission all together.

[0219] If at step S1004, the A-IoT device 3-1 detects that the prefix portion (preamble) of the R2D transmission includes an A-IoT device type specific SIP for the A-IoT device type to which the A-IoT device 3-1 belongs (e.g., SIP #2), then at step S1006, the A-IoT device 3-1 checks / detects whether or not the prefix portion (preamble) of the R2D transmission also includes a 'default' sequence of 0s or 1s (or other appropriate sequence or pattern) which indicates that the R2D transmission is intended for all / a group of / multiple A-IoT devices 3-1. For example, the R2D transmission may be intended for all A-IoT devices 3-1 of a specific type (e.g., type 2a), not just the individual A-IoT device 3-1 shown in Figs. 10A and 10B.

[0220] If at step S1006, the A-IoT device 3-1 detects a default sequence indicating, for example, that the R2D transmission is intended for all A-IoT devices 3-1 of the type indicated by the A-IoT device type specific SIP in the R2D transmission, then the A-IoT device 3-1 may detect the CAP in the R2D transmission and decode the PRDCH at S1008.

[0221] If on the other hand at step S1006, the A-IoT device 3-1 does not detect a default sequence, then the A-IoT device 3-1 may assume that the R2D transmission is intended for a specific A-IoT device 3-1 of the A-IoT devices 3-1 of the type indicated by the A-IoT device type specific SIP in the R2D transmission. Then at step S1010, the A-IoT device 3-1 checks / detects whether or not the prefix portion (preamble) of the R2D transmission includes, at a pre-defined location with respect to the A-IoT device type specific SIP (e.g., position #1 or #2), an A-IoT device specific sequence corresponding to a specific A-IoT device 3-1 (or group of A-IoT devices 3-1), of the type indicated by the A-IoT device type specific SIP in the R2D transmission, for which the R2D transmission is intended.

[0222] Continuing in Fig. 10B, at step S1012, if the A-IoT device specific sequence detected by the A-IoT device 3-1 corresponds to the A-IoT device 3-1 that receives the R2D transmission, then the A-IoT device 3-1 detects the CAP in the prefix portion (preamble) of the R2D transmission and decodes the data contained in the data payload of the R2D transmission (i.e., the PRDCH).

[0223] If on the other hand, the A-IoT device specific sequence detected by the A-IoT device 3-1 does not correspond to the A-IoT device 3-1 that receives the R2D transmission, then, at step S1014, the A-IoT device 3-1 skips reception of that R2D transmission.

[0224] < R2D Transmission with Either an A-IoT device type specific SIP or an A-IoT device specific Sequence (Case #2)> 　　As alluded to above, the prefix portion for an R2D transmission may be configured either: to include an A-IoT device specific sequence that is associated with a particular A-IoT device 3-1 (or group of A-IoT devices); or to include an A-IoT device type SIP that is specific to a particular A-IoT device type (e.g., type 1, type 2a, and type 2b) (e.g., as described with reference to Fig. 7); but not both.

[0225] It will be appreciated that, in this example, where the A-IoT device specific sequence is sent it may be sent as an A-IoT device specific SIP of the prefix portion (preamble) of the R2D transmission.

[0226] In one example (option #1), where each R2D transmission includes either an A-IoT device type specific SIP or an A-IoT device specific sequence (but not both), a pre-defined (i.e., fixed) SIP / sequence detection order may be (pre-)configured at A-IoT devices 3-1 within the communication system 1. For example, each A-IoT device 3-1 may be (pre-)configured, upon reception of an R2D transmission, to first check / detect for an A-IoT device type specific SIP in the R2D transmission, and then, in the absence of an A-IoT device type specific SIP, the A-IoT device 3-1 may check / detect for an A-IoT device specific sequence. It will be appreciated that, beneficially, such an approach means that the A-IoT devices 3-1 at most makes two attempts to check / detect for a specific SIP / sequence in each R2D transmission they receive.

[0227] In another example (option #2), where each R2D transmission includes either an A-IoT device type specific SIP or an A-IoT device specific sequence (but not both), a semi-static indication may be provided / signalled by the A-IoT device reader to A-IoT devices 3-1 (e.g., in a previous / most recent R2D transmission with a previous SIP indication) to indicate to the A-IoT devices 3-1 either that an A-IoT device type specific SIP will be included in all subsequent R2D transmissions, or that an A-IoT device specific sequence will be included in all subsequent R2D transmissions, until a further (new) semi-static indication is signalled to the A-IoT devices 3-1 by the A-IoT device reader.

[0228] Fig. 11 illustrates transmission and reception of R2D transmissions that may include an A-IoT device type specific SIP or an A-IoT device type specific sequence / SIP.

[0229] As shown in Fig. 11, in a first R2D transmission sent by the A-IoT device reader to one or more A-IoT devices 3-1, an indication of A-IoT device type specific SIP transmission may be included that indicates to one or more A-IoT devices 3-1 that receive the first R2D transmission that an A-IoT device type specific SIP will be included in all subsequent R2D transmissions until a further (new) indication is provided.

[0230] Following reception of that first R2D transmission with the indication of A-IoT device type specific SIP transmission, and following an appropriate activation / switching time to enable each A-IoT device 3-1 time to switch / change the type of SIP / sequence it should detect for, each A-IoT device 3-1 may begin to detect for A-IoT device type specific SIPs in the subsequent R2D transmissions it receives from the A-IoT device reader.

[0231] Sometime later in an R2D transmission, the A-IoT device reader may include an indication of A-IoT device specific sequence / SIP transmission to indicate to one or more A-IoT devices 3-1 that receive that R2D transmission that an A-IoT device specific sequence / SIP will be included in all subsequent R2D transmissions until a further (new) indication is provided.

[0232] Following reception of that R2D transmission with the indication of A-IoT device specific sequence transmission, and following an appropriate activation / switching time to enable each A-IoT device 3-1 time to switch / change the type of SIP / sequence it should detect for, the one each A-IoT device 3-1 may begin to detect for A-IoT device specific sequences in the subsequent R2D transmissions it receives from the A-IoT device reader, and so on.

[0233] It will be appreciated that beneficially, the above approach only requires each A-IoT device 3-1 to perform a single SIP / sequence detection per R2D transmission.

[0234] In yet another example (option #3), in addition to the example described immediately above (i.e., option #2), additional signalling may be included in the R2D transmission, along with the indication of A-IoT device type specific SIP / A-IoT device specific sequence / SIP transmission, to signal / indicate a time duration during which the one or more A-IoT devices 3-1 should detect for the specific type of SIP / sequence indicated in the R2D transmission.

[0235] For example, a time duration list may be (pre-)configured at the one or more A-IoT devices 3-1 with corresponding time indices, and the R2D transmission sent by the A-IoT device reader that includes the indication of A-IoT device type specific SIP / A-IoT device specific sequence / SIP transmission may also include an appropriate index corresponding to a time duration in the time duration list for which the one or more A-IoT devices 3-1 should detect for the specific type of SIP / sequence indicated by the indication of A-IoT device type specific SIP / A-IoT device specific sequence / SIP transmission in the R2D transmission.

[0236] Upon expiry of the indicated time duration (or other triggering condition), each A-IoT device 3-1 may fall back to the previous type of SIP / sequence that it was indicated to detect in R2D transmissions, until a new indication of A-IoT device type specific SIP / A-IoT device specific sequence / SIP transmission is provided to the A-IoT device 3-1.

[0237] It will be appreciated that beneficially, the above approach only requires each A-IoT device 3-1 to perform a single SIP / sequence detection per R2D transmission.

[0238] < Enhanced Random Access Procedures for A-IoT Systems that Support Device Originated-Autonomous (DO-A) Traffic> 　　As mentioned above, each A-IoT device 3-1 and each A-IoT device reader of the communication system 1 may be mutually configured for implementing one or more enhancements to a random access procedure to support the deployment of both DO-A A-IoT devices and non-DO-A A-IoT devices in the communication system 1.

[0239] Fig. 12 is a simplified sequence diagram of an enhanced A-IoT 'four-step' random access procedure that may be implemented in the communication system 1 which supports the deployment of both DO-A A-IoT devices and non-DO-A A-IoT devices in the communication system 1.

[0240] As seen in Fig. 12, in the enhanced A-IoT four-step RA procedure, at step S1202, the A-IoT device 3-1 (which in this example supports DO-A communication) may determine that it has data / information that it wishes to transmit to the A-IoT device reader autonomously. By way of example, where the A-IoT device 3-1 is a sensor (e.g., temperature sensor), the A-IoT device 3-1 may determine that it wishes to send data / information autonomously to an A-IoT device reader when a sensed property (e.g., temperature) is above (or below) a specific threshold.

[0241] Having decided that it wishes to send data / information to the A-IoT device reader, the A-IoT device 3-1 may await receipt of an appropriate (periodic) R2D message / paging message, or the like, from the A-IoT device reader indicating appropriate resources that the A-IoT device 3-1 may use for sending such data / information to the A-IoT device reader.

[0242] At step S1204, the A-IoT device reader transmits an appropriate R2D message / paging message, or the like ('A-IoT Msg0'). That A-IoT Msg0 may be transmitted periodically by the A-IoT device reader and may be specifically targeted to A-IoT devices 3-1 that support DO-A communication. Alternatively, that A-IoT Msg0 may be broadcast periodically by the A-IoT device reader and be detectable by all A-IoT devices 3-1 (or a specific subset of A-IoT devices 3-1).

[0243] It will be appreciated that, alternatively, the A-IoT device 3-1 may have stored an indication of appropriate resources that the A-IoT device 3-1 may use for sending such data / information to the A-IoT device reader, that was provided in a previous (periodic) R2D message / paging message (A-IoT Msg0), or the like.

[0244] The R2D message / paging message (A-IoT Msg0) may comprise, for example, information indicating: a specific targeted / selected device (e.g. a device identifier); a specific targeted / selected group of one or more A-IoT devices 3-1 (e.g. a (sub)group identifier and / or one or more device identifiers); a targeted / selected device type (e.g., DO-A supporting devices); a device or device group that are not targeted / selected (e.g., masking information and / or a group identifier); and / or the like). Nevertheless, the R2D message / paging message (A-IoT Msg0) may be configured as a 'blind' R2D message / paging message (A-IoT Msg0) that is directed to all A-IoT devices 3-1 within the cell / coverage area (e.g., by omitting information targeting a specific device, or group of A-IoT devices 3-1, by including information that is common to all A-IoT devices 3-1 within the cell / coverage area, and / or by including an indicator that any recipient device should respond).

[0245] The information in the R2D message / paging message (A-IoT Msg0) may also comprise, for example, information indicating one or more time and / or frequency resources of one or more RA occasions (e.g., including frequency information, time / frequency resource location, length of the slots for all RA occasions, slot length for each RA occasion, and or the like) that may be used for the transmission of a Msg1 by the A-IoT devices 3-1 (e.g., by a DO-A supporting A-IoT device 3-1). The information may also comprise, for example, information indicating the number of RA occasions and / or the availability of each RA occasion.

[0246] It will be appreciated that all the A-IoT devices 3-1 within the cell / coverage area of the A-IoT device reader may receive the R2D message / paging message (A-IoT Msg0) (subject to local radio conditions, any interference, and / or the like that may result in a failure to receive the message). However, only those specifically targeted / selected by the R2D message / paging message (A-IoT Msg0) may respond to the enhanced paging message (A-IoT Msg0). To facilitate this when the A-IoT device 3-1 receives the R2D message / paging message (A-IoT Msg0), the A-IoT device 3-1 will determine whether the A-IoT device 3-1 is targeted / selected by R2D message / paging message (A-IoT Msg0) by checking (not shown) whether or not information stored locally at the A-IoT device 3-1 (e.g., a device identity (or part of such an identity), a (sub)group identity, a device type indication, or the like) matches corresponding information in the in R2D message / paging message (A-IoT Msg0). When the device (type) matches a device (type) targeted / selected by the R2D message / paging message (A-IoT Msg0), the A-IoT device 3-1 may perform a RA resource selection (not shown). This RA resource selection involves selecting a specific RA occasion comprising resources to be used for a subsequent D2R transmission (e.g., of A-IoT Msg1). The resources forming each RA occasion may be divided (and hence selectable) in the time and / or frequency domain.

[0247] Having autonomously triggered transmission of data / information to the A-IoT device reader (at S1206), the A-IoT device 3-1 sends, at S1208, an initial device-to-reader (D2R) message ('A-IoT Msg1') using a selected RA occasion (time / frequency resources). The initial D2R message (A-IoT Msg1) carries a corresponding identifier (e.g., a random number / random ID generated by A-IoT device 3-1), and possibly other information, to the A-IoT device reader. The identifier may, for example, be a 16-bit random number (RN16) as used in RFID access procedures but may be some other form of (random) identifier.

[0248] If the initial D2R message (A-IoT Msg1) is received successfully at the A-IoT device reader (e.g., because there is no contention or other interference that causes a reception failure), then the A-IoT device reader may echo, at S1210, the identifier received in the initial D2R message (A-IoT Msg1) back to the A-IoT device 3-1 in an appropriate R2D access response message ('A-IoT Msg2') that may include additional useful information where appropriate. Furthermore, A-IoT Msg2 may also include a (temporary) A-IoT device specific SIP / A-IoT device specific preamble such as that described above with reference to Figs. 9 to 11.

[0249] For example, an A-IoT device specific temporary SIP may be generated by the A-IoT device reader based on the identity (e.g., random number identity) included in A-IoT Msg1 and included in the A-IoT Msg2 transmitted by the A-IoT device reader at step S1210. That R2D access response message (A-IoT Msg2) effectively serves as contention resolution message - the A-IoT device 3-1 assumes contention resolution to have been successful, if a received R2D response message (A-IoT Msg2) includes an A-IoT device specific temporary SIP based on the identity (e.g., random number identity) included in A-IoT Msg1 that the A-IoT device 3-1 sent at step S1208.

[0250] It will be appreciated that by including such an A-IoT device specific temporary SIP in the A-IoT Msg2 which is based on the identity (e.g., random number identity) included in an A-IoT Msg1 sent by a specific A-IoT device 3-1, only the specific A-IoT device 3-1 that sent the A-IoT Msg1 that included the identity (e.g., random number identity) upon which the A-IoT device specific temporary SIP is based, can successfully decode the A-IoT Msg2. All other A-IoT devices 3-1 (regardless of whether they are DO-A devices or not) cannot generate the same A-IoT device specific temporary SIP, and therefore cannot detect this msg2 and will not decode it.

[0251] It will be appreciated that the inclusion of such an A-IoT device specific temporary SIP in the A-IoT Msg2 helps to beneficially achieve energy savings and efficiencies as only A-IoT devices 3-1 for which the A-IoT Msg2 is specifically directed will detect and decode the A-IoT Msg2.

[0252] Having detected and decoded the A-IoT Msg2 successfully the A-IoT device 3-1 then sends, at S1212, a further D2R message (A-IoT Msg3) including that A-IoT device's A-IoT device identifier (or possibly a short version of that identifier) (and / or a (sub)group identifier) and / or any other higher layer data (e.g., depending on a higher layer request). The A-IoT device's A-IoT device identifier may be at least locally unique and / or may be a temporary identifier allocated by the network.

[0253] An R2D data transmission / message ('A-IoT Msg4') may then be sent by the A-IoT device reader to the A-IoT device 3-1 (as seen at S1214), after the further D2R message (A-IoT Msg3) has been received, that may, for example, comprise an inventory command or inventory request (or possibly an upper layer configuration). It will be appreciated that an inventory command may be used to configure the device (in which case there may be no follow-up message from the A-IoT device reader and so that access cycle / RA procedure may end). An inventory request, on the other hand requests a response from the A-IoT device 3-1 and so there will be a follow-up D2R message ('A-IoT Msg3').

[0254] If an R2D data transmission (A-IoT Msg4) is received by the A-IoT device 3-1, from the A-IoT device reader, then the A-IoT device 3-1 may respond appropriately (as seen at S1216). For example, the A-IoT device 3-1 may send a D2R data transmission / message ('A-IoT Msg5') to the A-IoT device reader, for example, to provide an inventory response transmission (or the like) - for example to respond to an inventory request if provided with the previous R2D data transmission (A-IoT Msg4).

[0255] <Devices in the Communication System> < Ambient IoT device> 　　Fig. 13 is a simplified block schematic illustrating the main components of an example of a UE 3 comprising an ambient IoT device 3-1 for possible implementation in the communication system 1.

[0256] As shown, the ambient IoT device 3-1 (also referred to simply as an IoT device 3-1) has a transceiver circuit 331 that is operable to transmit signals to and to receive signals from a RAN node 5-1 (and / or an assisting node 5-2, and / or an intermediate node 5-2) via one or more antenna 333 (e.g., comprising one or more antenna elements).

[0257] The transceiver circuit 331 may comprise energy harvesting circuitry 331-1 that is configured to harvest and / or collect energy from an ambient energy source such as an incoming signal and / or other ambient sources of energy (e.g., of light, vibrations, or heat). That collected energy may then be provided to other modules of IoT device 3-1 to provide a stable power supply to those modules. The energy harvesting circuitry 331-1 may include, by way of example only, inductive and / or capacitive architectures to harvest energy from incoming signals.

[0258] It will however be appreciated that the energy harvesting circuitry 331-1 may alternatively not form part of the transceiver circuit 331, but instead is its own module. For example, this may be the case when the energy to be harvested does not originate from signals transmitted to the IoT device 3-1. By way of example only, the IoT device 3-1 may harvest energy from solar cells such as dye-sensitised solar cells (DSSCs).

[0259] The transceiver circuit 331 also has modulation circuitry 331-2 which modulates an incoming unmodulated carrier signal to the IoT device 3-1 to produce the modulated backscatter signal to be reflected from the IoT device 3-1 for receipt by another device. For example, the modulation circuitry 331-2 may be configured modulate an incoming RF signal to the IoT device 3-1 by altering the impedance or reflectivity of the IoT device 3-1 in response to receiving that incoming RF signal. The modulation circuitry 331-2 may be configured to modulate the incoming signal to encode data provided from one or more data sources 332. Typically, for example, the IoT device 3-1 may comprise a data source 332 in the form of a sensor (e.g., an optical, temperature, position sensor or the like) for providing measurement data or a sensor alert, may comprise a data source 332 in the form of a stored or hardwired parameter such as a device or device type identifier, and / or may comprise one or more other sources of data.

[0260] In this example, the transceiver circuit 331 may also have a signal amplifier 331-3 (which may utilise energy harvested by the energy harvesting circuitry 331-1) for amplifying any modulated backscattered signal to be reflected by the IoT device 3-1 for receipt at another device.

[0261] In this example, the IoT device 3-1 also has a controller 337, comprising processing circuitry 338, to control the overall operation of the IoT device 3-1. The controller 337 is associated with a memory 339 including a data buffer 345 and is coupled to the transceiver circuit 331. Although not necessarily required for its operation, the IoT device 3-1 might, of course, have all the usual functionality of a more conventional UE (e.g., a user interface 335, such as a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 339 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

[0262] The controller 337 is configured to control overall operation of the IoT device 3-1 by, in this example, program instructions or software instructions stored within memory 339. As shown, these software instructions include, among other things, an operating system 341, and a communication control module 343.

[0263] The communication control module 343 is operable to control the communication between the IoT device 3-1, the RAN node 5-1, and / or the intermediate / assisting node 5-2. The communication control module 343 may, for example, be configured for the overall handling of communication via associated physical channels (e.g., via a physical D2R channel (PDRCH), random access channel (RACH), and / or a physical R2D channel (PRDCH)).

[0264] It will be appreciated that the communication control module 343 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 343 may include sub-modules corresponding to the layers of a dedicated ambient IoT device protocol stack for controlling functions associated with those layers.

[0265] The communication control module 343 is configured, in particular, to control the IoT device's communication, where applicable, in accordance with any of the methods described herein.

[0266] < RAN node> 　　Fig. 14 is a simplified block schematic illustrating the main components of a RAN node 5-1 (e.g., a base station / IoT device reader) for implementation in the communication system 1. It will be appreciated that the RAN node 5-1 may be configured to operate as an A-IoT device reader in the communication system 1.

[0267] As shown, the RAN node 5-1 has a transceiver circuit 51 for transmitting signals to and for receiving signals from the communication devices (such as UEs 3-2; 3-3, IoT devices 3-1, and possibly assisting or intermediate devices 5-2) via one or more antenna 53 (e.g., a single or multi-panel antenna array / massive antenna), and a core network interface 55 for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the RAN node 5-1 may also be coupled to other RAN node 5-1 via an appropriate interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR). The RAN node 5-1 has a controller 57 to control the operation of the RAN node 5-1. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the RAN node 5-1 by, in this example, program instructions or software instructions stored within memory 59.

[0268] As shown, these software instructions include, among other things, an operating system 61, and a communication control module 63.

[0269] The communication control module 63 is operable to control the communication between the RAN node 5-1 and UEs 3 and other network entities (e.g., core network nodes) that communicate with the RAN node 5-1. The communication control module 63 is configured for the overall control of the reception and decoding of uplink communication, via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), a random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS), and modulated backscattered communication in accordance with ambient IoT (where applicable). The communication control module 63 is also configured for the overall control of the transmission of downlink communication including downlink communication via associated downlink channels (e.g., via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-persistent scheduling (e.g., SPS), and downlink communication of an unmodulated carrier signal in accordance with ambient IoT (where applicable). The communication control module 63 is responsible, for example: for determining where to configure the UE 3 to monitor for downlink control information (e.g., the location of search spaces, CORESETs, and associated PDCCH candidates to monitor); for determining the resources to be scheduled for UE transmission / reception of UL / DL communication (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the base station side; for configuring slots / symbols appropriately (e.g., for UL, DL or full duplex communication, or the like); for configuring bandwidth parts for the UE 3; for providing related configuration signalling to a UE 3; and the like.

[0270] Where the RAN node 5-1 is configured to operate as an A-IoT device reader the communication control module 63 is operable to control the communication between the IoT device 3-1 and the RAN node 5-1, for example, via the associated physical channels (e.g., via a physical D2R channel (PDRCH), random access channel (RACH), and / or a physical R2D channel (PRDCH)) including both dynamic and semi-static signalling.

[0271] It will be appreciated that the communication control module 63 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. By way of example only the communication control module 63 may include sub-modules corresponding to the layers of a conventional protocol stack (PHY, MAC, RRC, RLC, PDCP etc.). Moreover, where the RAN node 5-1 is configured to operate as an A-IoT device reader, the communication control module 63 may include, sub-modules corresponding to the layers of a dedicated ambient IoT device protocol stack for controlling functions associated with those layers.

[0272] The communication control module 63 is configured in particular, to control the base station's communication, in accordance with any of the methods described herein.

[0273] < Assisting (or intermediate) node> 　　Fig. 15 is a simplified block schematic illustrating the main components of an example of an assisting (or intermediate) node 5-2 for possible implementation in the communication system 1.

[0274] As shown, the assisting node 5-2 may comprise a UE 3 (such as, or similar to, UE 3-2; 3-3), an IAB node, a repeater, or the like, which is capable of ambient IoT operation. In this scenario, the assisting node 5-2 has a transceiver circuit 151 that is operable to transmit signals to and to receive signals from a UE 3 (such as an ambient IoT device) via one or more antenna 153 (e.g., comprising one or more antenna elements), and a RAN interface 155 for transmitting signals to and for receiving signals from the RAN node 5-1 (which may also be over the air via the antenna 153, or via a different antenna).

[0275] The assisting node 5-2 has a controller 157 to control the operation of the assisting node 5-2. The controller 157 is associated with a memory 159 and is coupled to the transceiver circuit 151. Although not necessarily required for its operation, the assisting node 5-2 might, of course, have other functionality (e.g., a user interface, such as a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 159 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

[0276] The controller 157 is configured to control overall operation of the UE 3 by, in this example, program instructions or software instructions stored within memory 159. As shown, these software instructions include, among other things, an operating system 161, and a communication control module 163.

[0277] The communication control module 163 is operable to control the communication between the assisting node 5-2, the RAN node 5-1, and any IoT devices (including the ambient IoT device 3-1). The communication control module 163 is configured, in particular, for the overall handling of communication with the RAN node 5-1. For example, where the intermediate / assisting node 5-2 is a UE 3 (or at least operates like a UE 3 in its communication with the RAN node 5-1) this uplink communication may be via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 163 is also configured for the overall handling of receipt of downlink communication from the RAN node 5-1. For example, where the intermediate / assisting node 5-2 is a UE 3 (or at least operates like a UE 3 in its communication with the RAN node 5-1) this downlink communication may be via associated downlink channels (e.g., of DCI via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-persistent scheduling (e.g., SPS). It will, nevertheless, be appreciated that where the assisting node 5-2 is a device other than a UE 3 (e.g., an IAB or dedicated relay) then the communication control module 163 will be configured to communicate with the RAN node 5-1 using an appropriate corresponding signalling protocol for doing so.

[0278] The communication control module 163 is also responsible for appropriate ambient IoT related communication including, for example, reception of modulated backscattered communication from an ambient IoT device (where applicable) and / or downlink communication of an unmodulated carrier signal in accordance with ambient IoT (where applicable).

[0279] It will be appreciated that the communication control module 163 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. By way of example only the communication control module 163 may include sub-modules corresponding to the layers of a conventional protocol stack (PHY, MAC, RRC, RLC, PDCP etc.). Moreover, the communication control module 163 may include, sub-modules corresponding to the layers of a dedicated ambient IoT device protocol stack for controlling functions associated with those layers.

[0280] The communication control module 163 is configured, in particular, to control the assisting node's communication, in accordance with any of the methods described herein.

[0281] < Modifications and Alternatives> 　　Detailed examples been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above examples whilst still benefiting from the enhancements embodied therein.

[0282] It will be appreciated that description of features of and actions performed by a RAN node (or a RAN operating as an A-IoT device reader), apply equally to distributed type RAN nodes as to non-distributed type RAN nodes.

[0283] It will also be appreciated that whilst information elements having specific names may have been described, differently named information elements but having a similar purpose may be used.

[0284] In the above description the UE, A-IoT device, intermediate / assisting node, and the RAN node are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the disclosed enhancements, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.

[0285] In the above examples, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the UE or base station as a signal over a computer network, or on a recording medium. Further, the functionality performed by part, or all, of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the UE or the base station in order to update their functionalities.

[0286] Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input / output (IO) circuits; internal memories / caches (program and / or data); processing registers; communication buses (e.g. control, data and / or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and / or timers; and / or the like. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0287] The User Equipment (or "UE," "mobile station," "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface.

[0288] It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.

[0289] The terms "User Equipment" or "UE" (as the term is used by 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with one another, and include standalone mobile stations, such as terminals, cell phones, smart phones, tablets, cellular IoT devices, IoT devices, and machinery. It will be appreciated that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for an extended period of time.

[0290] A UE may, for example, be an item of equipment for production or manufacture and / or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and / or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and / or their application systems; tools; moulds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and / or related machinery; paper converting machinery; chemical machinery; mining and / or construction machinery and / or related equipment; machinery and / or implements for agriculture, forestry and / or fisheries; safety and / or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and / or application systems for any of the previously mentioned equipment or machinery etc.).

[0291] A UE may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motorcycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.).

[0292] A UE may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).

[0293] A UE may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and / or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).

[0294] A UE may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).

[0295] A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and / or system, a weapon, an item of cutlery, a hand tool, or the like.

[0296] A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).

[0297] A UE may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)," using a variety of wired and / or wireless communication technologies.

[0298] Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and / or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and / or inactive for an extended period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g., vehicles) or attached to animals or persons to be monitored / tracked.

[0299] It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communication system for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0300] It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be appreciated that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in the following table. This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.

[0301] Further, the above-described UE categories are merely examples of applications of the technical ideas and exemplary examples described in the present document. Needless to say, these technical ideas and examples are not limited to the above-described UE and various modifications can be made thereto.

[0302] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0303] For example, the whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes. 　　(Supplementary note 1) 　　A method performed by an ambient Internet-of-Things, A-IoT, device, the method comprising: 　　receiving, from an A-IoT device reader, a reader to device (R2D) transmission including a first portion configured for at least acquiring a timing of the R2D transmission , and a second portion carrying data and / or control signalling intended for a specific set of one or more A-IoT devices; 　　wherein the first portion carries intended recipient specific information that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended. 　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein the method further comprises: in a case where the A-IoT device is part of the specific set of one or more A-IoT devices, decoding the second portion; and in a case where the A-IoT device is not part of the specific set of one or more A-IoT devices, not decoding the second portion. 　　(Supplementary note 3) 　　A method performed by an ambient Internet-of-Things, A-IoT, device reader, the method comprising: 　　transmitting, to an A-IoT device, a reader to device (R2D) transmission including a first portion configured for acquiring at least a timing of the R2D transmission, and a second portion carrying data and / or control signalling intended for a specific set of one or more A-IoT devices; 　　wherein the first portion carries intended recipient specific information that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended. 　　(Supplementary note 4) 　　The method according to supplementary note 1, 2 or 3, wherein the intended recipient specific information comprises a start indicator part, SIP, of the first portion, and the SIP is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended. 　　(Supplementary note 5) 　　The method according to any one of supplementary notes 1 to 4, wherein the SIP comprises a binary sequence that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended. 　　(Supplementary note 6) 　　The method according to any one of supplementary notes 1 to 4, wherein the intended recipient specific information comprises a binary sequence that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended. 　　(Supplementary note 7) 　　The method according to supplementary note 5 or 6, wherein the binary sequence comprises an M-sequence or a Golay sequence. 　　(Supplementary note 8) 　　The method according to any one of supplementary notes 1 to 7, wherein the intended recipient specific information comprises information common to at least one A-IoT device type, and each A-IoT device of the specific set of one or more A-IoT devices is respectively an A-IoT device of the at least one A-IoT device type. 　　(Supplementary note 9) 　　The method according to any one of supplementary notes 1 to 8, wherein the intended recipient specific information is configured to be specific to a specific A-IoT device, and the specific set of one or more A-IoT devices comprises that specific A-IoT device. 　　(Supplementary note 10) 　　The method according to any one of supplementary notes 1 to 5 wherein, the intended recipient specific information is configurable either: to be common to at least one A-IoT device type, and each A-IoT device of the specific set of one or more A-IoT devices is respectively an A-IoT device of the at least one A-IoT device type; or to be specific to a specific A-IoT device, and the specific set of one or more A-IoT devices comprises that specific A-IoT device. 　　(Supplementary note 11) 　　The method according to any one of supplementary notes 1 to 10, wherein the intended recipient specific information comprises a preamble of the first portion that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended. 　　(Supplementary note 12) 　　The method according to any one of supplementary notes 1 to 11, wherein the first portion comprises an R2D timing acquisition signal, R-TAS. 　　(Supplementary note 13) 　　The method according to any one of supplementary notes 1 to 12, wherein the second portion carries a message of a random access procedure. 　　(Supplementary note 14) 　　The method according to supplementary note 13, wherein the message of the random access procedure is a second message, Msg2, of the random access procedure. 　　(Supplementary note 15) 　　The method according to supplementary note 13 or 14, wherein the intended recipient specific information comprises information generated based on an identifier of the A-IoT device. 　　(Supplementary note 16) 　　The method according to supplementary note 15, wherein the identifier is an identifier that was transmitted to the A-IoT device reader by the A-IoT device in an earlier message of the random access procedure. 　　(Supplementary note 17) 　　The method according to supplementary note 16, wherein the earlier message of the random access procedure is a first message, Msg1, of the random access procedure. 　　(Supplementary note 18) 　　The method according to any one of supplementary notes 1 to 17, wherein the A-IoT device reader is a radio access network, RAN, node. 　　(Supplementary note 19) 　　The method according to any one of supplementary notes 1 to 18, wherein the A-IoT device reader is an intermediate node or an assisting node that is configured for transferring communication between a radio access network, RAN, node and the A-IoT device. 　　(Supplementary note 20) 　　An ambient internet-of-things, A-IoT, device comprising: 　　means for receiving, from an A-IoT device reader, a reader to device (R2D) transmission including a first portion configured for acquiring a timing of the R2D transmission, and a second portion carrying data and / or control signalling intended for a specific set of one or more A-IoT devices; 　　wherein the first portion carries intended recipient specific information that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended. 　　(Supplementary note 21) 　　An ambient internet-of-things, A-IoT, device reader comprising: 　　means for transmitting, to an A-IoT device, a reader to device (R2D) transmission including a first portion configured for acquiring a timing of the R2D transmission, and a second portion carrying data and / or control signalling intended for a specific set of one or more A-IoT devices; 　　wherein the first portion carries intended recipient specific information that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended.

[0304] This application is based upon and claims the benefit of priority from Great Britain Patent Application No. 2504555.0, filed on March 27, 2025, the disclosure of which is incorporated herein in its entirety by reference.

[0305] 1 COMMUNICATION SYSTEM 3, 3-1, 3-2, 3-3 UE 　　3-1, 3-11, 3-12, 3-13, 3-14, 3-15, 3-16 A-IOT DEVICE 　　　　3-11, 3-12, 3-13 TYPE 1 A-IOT DEVICE 　　　　3-14, 3-15 TYPE 2A A-IOT DEVICE 　　　　3-16 TYPE 2B A-IOT DEVICE 　　3-2, 3-3 NON-AMBIENT IOT UE 5-1 RAN NODE 5-2 INTERMEDIATE / ASSISTING NODE 7 CORE NETWORK 10 CONTROL PLANE FUNCTION 10-1 ACCESS AND MOBILITY MANAGEMENT FUNCTION 10-2 SESSION MANAGEMENT FUNCTION 10-N OTHER FUNCTIONS 11 USER PLANE FUNCTION 20-1 UNMODULATED CARRIER SIGNAL 20-2 R2D SIGNAL 20-2' DOWNLINK SIGNAL 20-3 BACKSCATTERED D2R SIGNAL 20-3' APPROPRIATE SIGNAL 20-4 COMMUNICATION 25 RESOURCE BLOCK 40 DATA NETWORK 51 TRANSCEIVER CIRCUIT 53 ANTENNA 55 CORE NETWORK INTERFACE 57 CONTROLLER 59 MEMORY 61 OPERATING SYSTEM 63 COMMUNICATION CONTROL MODULE 151 TRANSCEIVER CIRCUIT 153 ANTENNA 155 RAN INTERFACE 157 CONTROLLER 159 MEMORY 161 OPERATING SYSTEM 163 COMMUNICATION CONTROL MODULE 331 TRANSCEIVER CIRCUIT 331-1 ENERGY HARVESTIBG CIRCUITRY 331-2 MODULATION CIRCUITRY 331-3 SIGNAL AMPLIFIER 332 DATA SOURCE 333 ANTENNA 337 CONTROLLER 338 PROCESSING CIRCUITRY 339 MEMORY 341 OPERATING SYSTEM 343 COMMUNICATION CONTROL MODULE 345 DATA BUFFER

Claims

1. A method performed by an ambient Internet-of-Things, A-IoT, device, the method comprising: receiving, from an A-IoT device reader, a reader to device (R2D) transmission including a first portion configured for acquiring a timing of the R2D transmission, and a second portion carrying data and / or control signalling intended for a specific set of one or more A-IoT devices; 　　wherein the first portion carries intended recipient specific information that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended.

2. The method according to claim 1, wherein the method further comprises: 　　in a case where the A-IoT device is part of the specific set of one or more A-IoT devices, decoding the second portion; and 　　in a case where the A-IoT device is not part of the specific set of one or more A-IoT devices, not decoding the second portion.

3. A method performed by an ambient Internet-of-Things, A-IoT, device reader, the method comprising: 　　transmitting, to an A-IoT device, a reader to device (R2D) transmission including a first portion configured for acquiring a timing of the R2D transmission, and a second portion carrying data and / or control signalling intended for a specific set of one or more A-IoT devices; 　　wherein the first portion carries intended recipient specific information that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended.

4. The method according to claim 1, 2 or 3, wherein the intended recipient specific information comprises a start indicator part, SIP, of the first portion, and the SIP is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended.

5. The method according to any one of claims 1 to 4, wherein the SIP comprises a binary sequence that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended.

6. The method according to any one of claims 1 to 4, wherein the intended recipient specific information comprises a binary sequence that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended.

7. The method according to claim 5 or 6, wherein the binary sequence comprises an M-sequence or a Golay sequence.

8. The method according to any one of claims 1 to 7, wherein the intended recipient specific information comprises information common to at least one A-IoT device type, and each A-IoT device of the specific set of one or more A-IoT devices is respectively an A-IoT device of the at least one A-IoT device type.

9. The method according to any one of claims 1 to 8, wherein the intended recipient specific information is configured to be specific to a specific A-IoT device, and the specific set of one or more A-IoT devices comprises that specific A-IoT device.

10. The method according to any one of claims 1 to 5 wherein, the intended recipient specific information is configurable either: to be common to at least one A-IoT device type, and each A-IoT device of the specific set of one or more A-IoT devices is respectively an A-IoT device of the at least one A-IoT device type; or to be specific to a specific A-IoT device, and the specific set of one or more A-IoT devices comprises that specific A-IoT device.

11. The method according to any one of claims 1 to 10, wherein the intended recipient specific information comprises a preamble of the first portion that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended.

12. The method according to any one of claims 1 to 11, wherein the first portion comprises an R2D timing acquisition signal, R-TAS.

13. The method according to any one of claims 1 to 12, wherein the second portion carries a message of a random access procedure.

14. The method according to claim 13, wherein the message of the random access procedure is a second message, Msg2, of the random access procedure.

15. The method according to claim 13 or 14, wherein the intended recipient specific information comprises information generated based on an identifier of the A-IoT device.

16. The method according to claim 15, wherein the identifier is an identifier that was transmitted to the A-IoT device reader by the A-IoT device in an earlier message of the random access procedure.

17. The method according to claim 16, wherein the earlier message of the random access procedure is a first message, Msg1, of the random access procedure.

18. The method according to any one of claims 1 to 17, wherein the A-IoT device reader is a radio access network, RAN, node.

19. The method according to any one of claims 1 to 18, wherein the A-IoT device reader is an intermediate node or an assisting node that is configured for transferring communication between a radio access network, RAN, node and the A-IoT device.

20. An ambient internet-of-things, A-IoT, device comprising: 　　means for receiving, from an A-IoT device reader, a reader to device (R2D) transmission including a first portion configured for acquiring a timing of the R2D transmission, and a second portion carrying data and / or control signalling intended for a specific set of one or more A-IoT devices; 　　wherein the first portion carries intended recipient specific information that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended.

21. An ambient internet-of-things, A-IoT, device reader comprising: 　　means for transmitting, to an A-IoT device, a reader to device (R2D) transmission including a first portion configured for acquiring a timing of the R2D transmission, and a second portion carrying data and / or control signalling intended for a specific set of one or more A-IoT devices; 　　wherein the first portion carries intended recipient specific information that is configured to be specific to the specific set of one or more A-IoT devices for which the second portion is intended.

Images