Method, ambient internet of things device and communication device

Abstract

An example of the object of the present disclosure is to provide a method, an ambient Internet of Things (IoT) device and a communication device capable of supporting efficient and reliable connectionless communication. In one example aspect, a method is performed by an ambient Internet of Things (IoT) device. The method includes: receiving configuration information including a Cell Radio Network Temporary Identifier (C-RNTI) of the ambient IoT device and / or security related information in other than a Radio Resource Control (RRC) message; receiving, from a communication apparatus, an unmodulated carrier wave; and backscatting or reflecting the unmodulated carrier wave using the C-RNTI and / or the security related information.

Description

METHOD, AMBIENT INTERNET OF THINGS DEVICE AND COMMUNICATION DEVICE

[0001] The present disclosure relates to a method, an ambient Internet of Things (IoT) device and a communication device.

[0002] Under the 3rd Generation Partnership Project (3GPP) standards, a NodeB (or an eNB in Long Term Evolution (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.

[0003] NPL 1: the Next Generation Mobile Networks (NGMN) Alliance, 'NGMN 5G White Paper', February 17th, 2015, V1.0, <URL: https: / / www.ngmn.org / 5g-white-paper.html>

[0004] Ambient IoT devices make use of 'backscatter' or 'reflected' communication in which the devices transmit data by reflecting or backscattering radio frequency (RF) signals from a base station or other devices without necessarily having to actively generate their own RF signals. Instead, the 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 ambient IoT device (also herein referred to simply as the IoT device for simplicity).

[0005] An example of the object of the present disclosure is to provide a method, an ambient Internet of Things (IoT) device and a communication device capable of supporting efficient and reliable connectionless communication.

[0006] In a first example aspect, a method performed by an ambient Internet of Things (IoT) device, the method including: 　　receiving configuration information including a Cell Radio Network Temporary Identifier (C-RNTI) of the ambient IoT device and / or security related information in other than a Radio Resource Control (RRC) message; 　　receiving, from a communication apparatus, an unmodulated carrier wave; and 　　backscatting or reflecting the unmodulated carrier wave using the C-RNTI and / or the security related information.

[0007] In a second example aspect, a method performed by a communication device, the method including: 　　transmitting, to an ambient Internet of Things (IoT) device, configuration information including a Cell Radio Network Temporary Identifier (C-RNTI) of the ambient IoT device and / or security related information in other than a Radio Resource Control (RRC) message; 　　transmitting, to the ambient IoT device, an unmodulated carrier wave, and wherein 　　the unmodulated carrier wave is backscatted or reflected by the ambient IoT device using the C-RNTI and / or the security related information.

[0008] In a third example aspect, an ambient Internet of Things (IoT) device including: 　　means for receiving configuration information including a Cell Radio Network Temporary Identifier (C-RNTI) of the ambient IoT device and / or security related information in other than a Radio Resource Control (RRC) message; 　　means for receiving, from a communication apparatus, an unmodulated carrier wave; and 　　means for backscatting or reflecting the unmodulated carrier wave using the C-RNTI and / or the security related information.

[0009] In a fourth example aspect, a communication device includes: 　　means for transmitting, to an ambient Internet of Things (IoT) device, configuration information including a Cell Radio Network Temporary Identifier (C-RNTI) of the ambient IoT device and / or security related information in other than a Radio Resource Control (RRC) message; 　　means for transmitting, to the ambient IoT device, an unmodulated carrier wave, and wherein 　　the unmodulated carrier wave is backscatted or reflected by the ambient IoT device using the C-RNTI and / or the security related information.

[0010] According to the present disclosure, it is possible to provide a method, an ambient Internet of Things (IoT) device and a communication device capable of supporting efficient and reliable connectionless communication.

[0011] Examples of apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:Fig. 1 illustrates schematically a mobile (cellular or wireless) communication system to which example embodiments of the disclosure may be applied;Fig. 2 illustrates schematically a first connectivity topology that may be used in the communication system of Fig. 1;Fig. 3 illustrates schematically a second connectivity topology that may be used in the communication system of Fig. 1;Fig. 4A illustrates schematically a third connectivity topology that may be used in the communication system of Fig. 1;Fig. 4B illustrates schematically another arrangement of the third connectivity topology of Fig. 4A;Fig. 5 illustrates typical use of an integrity algorithm that may be used in the communication system of Fig. 1;Fig. 6 illustrates typical use of an encryption algorithm that may be used in the communication system of Fig. 1;Fig. 7 is a simplified illustration of a key derivation hierarchy that may be used in the communication system of Fig. 1;Fig. 8 is a simplified sequence diagram illustrating a procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a RAN node and an IoT device;Fig. 9 is a simplified sequence diagram illustrating a procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between two RAN nodes and an IoT device;Fig. 10 is a simplified sequence diagram illustrating a procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a RAN node, an L2 type intermediate node, and an IoT device;Fig. 11 is a simplified sequence diagram illustrating a procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a RAN node, an L1 type intermediate node, and an IoT device;Fig. 12 is a simplified sequence diagram illustrating a procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a RAN node, an L2 type assisting node, and an IoT device;Fig. 13 is a simplified sequence diagram illustrating a procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a RAN node, an L1 type assisting node, and an IoT device;Fig. 14 is a simplified sequence diagram illustrating a first procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a RAN node, an assisting node, and an IoT device;Fig. 15 is a simplified sequence diagram illustrating a second procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a RAN node, an assisting node, and an IoT device;Fig. 16 is a simplified block schematic diagram illustrating the main components of a user equipment that may be used in the communication system of Fig. 1;Fig. 17A is a simplified block schematic diagram illustrating the main components of a user equipment that may be used in the communication system of Fig. 1;Fig. 17B is a simplified block schematic diagram illustrating the main components of a user equipment that may be used in the communication system of Fig. 1;Fig. 17C is a simplified block schematic diagram illustrating the main components of a user equipment that may be used in the communication system of Fig. 1;Fig. 18 is a simplified block schematic diagram illustrating the main components of a RAN node that may be used in the communication system of Fig. 1; andFig. 19 is simplified block schematic diagram illustrating the main components of an intermediate or assisting node that may be used in the communication system of Fig. 1.

[0012] The present disclosure relates to a communication system and to parts thereof. 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 or equivalents or derivatives thereof (including LTE-Advanced, Next Generation or 5G networks, future generations, and beyond). The present disclosure in particular relates to providing support for connectionless communication in the context of backscatter communications in a communication system including 'Ambient' Internet-of-Things (IoT) devices.

[0013] Each of the drawings or figures is merely an example to illustrate one or more example embodiments. Each figure may not be associated with only one particular example embodiment, but may be associated with one or more other example embodiments. As those of ordinary skill in the art will understand, various features or steps described with reference to any one of the figures can be combined with features or steps illustrated in one or more other figures, for example, to produce example embodiments that are not explicitly illustrated or described. Not all of the features or steps illustrated in any one of the figures to describe an example embodiment are necessarily essential, and some features or steps may be omitted. The order of the steps described in any of the figures may be changed as appropriate.

[0014] (Related Arts) 　　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.

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

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

[0017] 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 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 F1 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.

[0018] 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), an Authentication Server Function (AUSF), a Unified Data Management (UDM) entity for managing user specific data, a Policy Control Function (PCF), an Application Function (AF), a Security Anchor Function (SEAF), an Authentication credential Repository and Processing Function (ARPF), and / or the like. 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.

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

[0020] 'Ambient' IoT attempts to address some of the above issues and relies on ultra-low complexity devices with ultra-low power to help address use cases and scenarios that might not otherwise be possible based on existing Low-power wide-area (LPWA) IoT technology.

[0021] Ambient IoT devices make use of 'backscatter' or 'reflected' communication in which the devices transmit data by reflecting or backscattering radio frequency (RF) signals from a base station or other devices without necessarily having to actively generate their own RF signals. Instead, the 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 ambient IoT device (also herein referred to simply as the IoT device for simplicity).

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

[0023] Such ambient IoT devices may be categorised as follows: - Type A devices: Any ambient IoT device that has no means of energy storage and no independent signal generation / amplification capabilities. Such devices rely on backscatter communications (described below) to communicate with other devices. - Type B devices: Any ambient IoT device that has means of energy storage but no independent signal generation capabilities. Such devices similarly rely on backscatter communications (described below) to communicate with other devices. However, beneficially they can use their stored energy to assist in those backscattering communications. For example, the device can use its stored energy to amplify backscattered signals. - Type C devices: Any ambient IoT device that has means of energy storage and independent signal generation, i.e., the device has active radio frequency (RF) components that can generate signals for transmission. Typically, such type C devices are much reduced capabilities compared to a non-ambient IoT device.

[0024] Typically, type A, B, and C devices each have their own set of power consumption targets, complexity targets, latency targets, data rate targets, and the like.

[0025] For example, the power consumption target for type A devices during transmitting / receiving is typically set to less than or equal to 1 microwatts (μW), or less than or equal to 10 μW, while for type C devices the power consumption target during transmitting / receiving is typically set to a value between 1 milliwatt (mW) and 10 mW. The power consumption target during transmitting / receiving for type B devices is typically set with reference to the power consumption targets of the type A and C devices. For example, typically, the power consumption target during transmitting / receiving for type B devices is either i) much greater than that of type A devices but less than that of type C devices, or ii) greater than or equal to that of type A devices but less than that of type C devices.

[0026] With respect to complexity targets, type A devices typically have a target comparable to that set out in International Radio Frequency Identification (RFID) Standards ISO18000-6C (equivalent to Electronic Product Code (EPC), global Class 1 (C1), Generation 2 (G2) or 'EPC C1G2' for short), while type C devices typically have a complexity target in orders of magnitude lower than the complexity of narrowband-(NB-)IoT. The complexity target for type B devices is typically set with reference to the complexity targets of the type A and C devices. For example, typically the complexity target of type B devices is greater than the complexity target for type A devices but less than the complexity target for type C devices.

[0027] With respect to latency targets, for type A, B, and C devices, typically a one-way end-to-end maximum latency target is set of between 1 second (shorter latency target) to 10 seconds (longer latency target). The data rate targets type A, B, and C devices are typically set at a maximum of no less than 5 kilobits-per-second (kbps), and minimum of no less than 0.1 kbps for both uplink (UL) and downlink (DL) transmission, with a maximum message size target for such transmissions of approximately 1000 bits i.e., it is aimed for ambient IoT devices to receive and transmit a maximum of approximately 1000 bits per message.

[0028] Typically, where such ambient IoT devices are implemented in a communication network (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.

[0029] 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 a base station 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 the incoming RF signal, and reflected signal are within the same RF band. - Topology 2 in which a base station and ambient IoT device communicate with one another (in the downlink and / or the uplink) via 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 intermediate node and hence faces similar associated challenges. - Topology 3 in which the ambient IoT device: 　　receives data / signalling from the base station directly but transmits data / signalling to the base station indirectly via an assisting node (i.e., assistance by the assisting / intermediate node is provided in the uplink); or 　　transmits data / signalling to the base station directly but receives data / signalling from the base station indirectly via an assisting node (i.e., assistance by the assisting / intermediate node is provided in the downlink). 　　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.

[0030] Topology 3 is expected to be particularly important for device type A as it allows the device to remain connected to the network even with a reduced uplink coverage.

[0031] In the case of type A and B devices, as neither have independent signal generation capabilities, any 'transmission' from those devices typically has to take the form of a backscattered signal.

[0032] In the context of such type A and B devices, therefore, it will be appreciated that certain issues and constraints may exist which impact the performance of ambient IoT networks. For example, the backscattering mechanism used by type A and B devices generally assumes that the unmodulated carrier signal, and the reflected signal from the ambient IoT device, are almost simultaneous; this poses scheduling constraints for the different topologies (especially where both the unmodulated carrier signal and the reflected signal are on the same frequency, which may make it difficult for devices to distinguish between signals).

[0033] Different considerations need to be taken into account depending on which node (base station or assisting / intermediate node) transmits the unmodulated carrier and which node (assisting / intermediate node or base station) receives the reflected carrier from the Ambient IoT device.

[0034] For Topology 3, in particular, successful operation may involve tight coordination between the three devices (base station, assisting node and ambient IoT device).

[0035] For example, the following scenarios are possible: - Scenario 1: The base station is responsible for transmission of the unmodulated carrier to the ambient IoT device, and the assisting / intermediate node is responsible for receiving the backscattered signal from the ambient IoT device; - Scenario 2: The assisting / intermediate node is responsible for transmission of the unmodulated carrier to the ambient IoT device, and the base station is responsible for receiving the backscattered signal from the ambient IoT device; - Scenario 3: The assisting / intermediate node is responsible for both transmission of the unmodulated carrier to the ambient IoT device and for receiving the backscattered signal from ambient IoT device; and - Scenario 4: The base station is responsible for both transmission of the unmodulated carrier to the ambient IoT device and for receiving the backscattered signal from the ambient IoT device.

[0036] Scenarios 1 and 2, in particular, require tight coordination between the base station and the assisting / intermediate node.

[0037] It can be seen that for all of these different topologies / scenarios the data transmission between the ambient IoT device and the base station and / or assisting / intermediate node need not be based on an RRC connection (as would be the case for conventional communication with UEs including IoT devices).

[0038] There is, therefore, a need for mechanisms to be developed to support efficient and reliable connectionless communication to be supported for ambient IoT devices.

[0039] (Notes of this disclosure) 　　The disclosure aims to provide one or more apparatus and / or one or more associated methods that at least partially addresses or contributes to addressing one or more of the above needs.

[0040] The various functional means described below that are part of the UE may be provided by a memory and one or more processors that execute instructions stored in the memory. Similarly, the various functional means described below that are part of the access network node may be provided by a memory and one or more processors that execute instructions stored in the memory.

[0041] 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 the any of the methods described below. The computer implementable instructions may be provided as a signal or on a tangible computer readable medium.

[0042] (Overview) 　　An exemplary telecommunication system will now be described in general terms, by way of example only, with reference to Figs. 1 to 7.

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

[0044] In the communication system 1 user equipment (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 or 'gNB' 5-1 operating one or more associated cells 9. Communication via the RAN node 5-1 is typically routed through a core network 7 (e.g. a 5G core network or later generations core network or evolved packet core network (EPC)).

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

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

[0047] The IoT device 3-1 may, for example, be a Type A, Type B, or Type C device as described in the introduction. As described in more detail later, depending on the connectivity topology employed, the 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 or a separate node. The intermediate, or assisting, node 5-2 may, for example, be a relay node, an integrated access and backhaul (IAB) node, another UE, 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 IoT device.

[0048] Each 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 each RAN may be configured to support 4G, 5G, 6G, and / or later generations, and / or any other 3GPP or non-3GPP communication protocols.

[0049] 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. an F1-C interface) and an appropriate interface (e.g. an F1-U interface) (together forming an F1 interface (or 'reference point')), and with one another via an appropriate interface (e.g. an E1 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 RAN node 5-1 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 be of a non-distributed form, for example as an integrated base station.

[0050] The UEs 3 (and possibly the intermediate or assisting node 5-2 if present) are configured for communication with the serving RAN node 5-1 via an appropriate air interface (for example the so-called 'Uu' interface and / or the like). It will be appreciated that the IoT device 3-1 may, alternatively or additionally, be configured for indirect communication with the serving 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 serving 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. 1).

[0051] 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 authorization, 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 a UE 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.

[0052] 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-IoT UEs 3 are each connected to the AMF 10-1 via a non-access stratum (NAS) connection over an appropriate interface (e.g. an N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated, that N1 communications are routed transparently via the RAN node 5-1.

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

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

[0055] The SMF 10-2 is connected to the AMF 10-1 via an appropriate interface (e.g. an 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-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-IoT UE 3-2, 3-3.

[0056] Each RAN node 5-1 is also configured for transmission of, and at least the non-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.

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

[0058] The DL physical signals may include, for example, reference signals (RSs) and synchronization 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).

[0059] Similarly, the at least the non-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.

[0060] Each 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-IoT UEs 3-2, 3-3. It will be appreciated that the specific of functionality with which the IoT device 3-1 is configured is dependent on the type of IoT device 3-1.

[0061] For example, the IoT device 3-1 may be a type A device that has no means of energy storage and no independent signal generation / amplification capabilities. Such type A devices may be, by way of example only, a simple object or 'tag' similar to a passive Radio-frequency identification (RFID) type tag that uses incident electromagnetic fields (from an unmodulated carrier) to automatically transmit a backscattered / reflected signal that is modulated based on information acquired at the device (e.g., a measurement from a sensor and / or an identity of the device stored or hardwired into the device). The IoT device 3-1 in this example, may be powered by energy harvested from the incident electromagnetic radiation or from other sources of energy such as light and / or heat.

[0062] Alternatively, the IoT device 3-1 may be a type B device, which may also be, by way of example only, a simple object or 'tag' similar to a passive RFID tag that uses incident electromagnetic fields (from an unmodulated carrier) to automatically transmit a backscattered / reflected signal that is modulated based on information acquired at the device (e.g., a measurement from a sensor and / or an identity of the device stored or hardwired into the device). In this case, the type B device may also have means of energy storage and / or of amplifying the transmitted backscattered / reflected signal but no independent signal generation capabilities. The IoT device 3-1 in this example, may still be powered by energy harvested from the incident electromagnetic radiation or from other sources of energy such as light and / or heat albeit, in this example, potentially stored at the IoT device 3-1.

[0063] Alternatively, the IoT device 3-1 may be a type C device that has means of energy storage and independent signal generation. In addition to being able to transmit a backscattered / reflected signal that is modulated based on information acquired at the device (e.g., a measurement from a sensor and / or an identity of the device stored or hardwired into the device), such a device may, by way of example only, have at least some (albeit possibly a significantly reduced set) of the capabilities of a non-IoT UE (such as the UEs 3-2, 3-3) to communicate with the RAN node 5-1 (and / or intermediate / assisting node 5-2).

[0064] <Connectivity Topologies> 　　The 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. 2 to 4.

[0065] Topology 1: RAN node ⇔ IoT device: 　　Fig. 2 illustrates schematically a first connectivity topology (topology 1) that may be used in the communication system 1 of Fig. 1.

[0066] As shown in Fig. 2, in topology 1, an IoT device 3-1 and a 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 IoT device 3-1 directly and bidirectionally communicates with the RAN node 5-1. The communication 20 (20-1, 20-2) between the RAN node 5-1 and the 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 20 between the RAN node 5-1 and the 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.

[0067] In this example, the RAN node 5-1 is responsible for transmission of an unmodulated carrier signal 20-1 to the IoT device 3-1. This unmodulated carrier signal is, in turn, modulated and backscattered / reflected by the IoT device 3-1, as a backscattered signal 20-2, to the RAN node 5-1. 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.

[0068] Nevertheless, although not shown in Fig. 2, topology 1 allows for the possibility that the RAN node (base station) 5-1 transmitting to the IoT device 3-1 is a different RAN node (base station) 5-1 from the RAN node (base station) 5-1 receiving from the IoT device 3-1. For example, a first RAN node (base station) 5-1 may transmit an unmodulated carrier signal 20-1 to the IoT device 3-1, and a second RAN node (base station) 5-1 may receive a resulting backscattered signal 20-2 from the IoT device 3-1. In this scenario backscattering may be supported even where full duplex operation is not supported at either of the RAN nodes (base stations) 5-1.

[0069] Topology 1 may typically be deployed for indoor scenarios, with a type A, B, and / or C IoT device and the RAN node 5-1 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.

[0070] Alternatively, topology 1 may be deployed for scenarios where the 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. In this scenario, the assisting node 5-2 may be located in an indoor or an outdoor environment. However, in such a scenario it may be the case that only type C ambient IoT devices 3-1 may be supported.

[0071] Topology 1 may also be deployed for outdoor scenarios with one or more (typically type C) ambient 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.

[0072] 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 IoT device 3-1. The RAN node 5-1 will send an unmodulated carrier signal 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.

[0073] Topology 2: RAN node ⇔ Intermediate node ⇔ IoT device: 　　Fig. 3 illustrates schematically a second connectivity topology (topology 2) of a mobile (cellular or wireless) communication system 1.

[0074] As shown in Fig. 3, in topology 2 an IoT device 3-1 and a RAN node 5-1 engage in communication with one another via an intermediate node 5-2 (which may also be referred to as an assisting node 5-2) to transfer ambient IoT data and / or signalling between the RAN node 5-1 and the IoT device 3-1. It will be appreciated that while the intermediate node 5-2 is depicted in Fig. 3 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 a RAN node 5-1 and an IoT device 3-1 and that is capable of supporting ambient IoT signalling.

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

[0076] Specifically, the communication 20-1, 20-2 between the intermediate node 5-2 and the IoT device 3-1 occurs over an appropriate air interface. For example, they may communicate over a Uu or a dedicated interface.

[0077] In a first (downlink) direction (RAN node 5-1 → intermediate node 5-2 → 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-3 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 to the IoT device 3-1 (e.g., on a 'sidelink' or similar). 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 IoT device 3-1, or may be a trigger signal for triggering transmission of the unmodulated carrier signal 20-1.

[0078] In a second (uplink) direction (IoT device 3-1 → intermediate node 5-2 → RAN node 5-1), the intermediate node 5-2 is responsible for receiving a modulated backscattered signal 20-2 from IoT device 3-1 (e.g., on a 'sidelink' or similar). Specifically, the uplink communication may comprise a modulated backscattered signal 20-2 from the IoT device 3-1 to the intermediate node 5-2 that is transmitted (e.g., on a 'sidelink' or similar) in response to receiving the unmodulated carrier signal 20-1 from the intermediate node 5-2. This modulated backscattered signal 20-2 (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-3 between the intermediate node 5-2 and the RAN node 5-1. The modulated backscattered signal 20-2 may be processed before being relayed by the intermediate node 5-2 to the RAN node 5-1. For example, the modulated backscattered signal 20-2 may be processed by the intermediate 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. Alternatively, the modulated backscattered signal 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.

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

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

[0081] It will be appreciated that 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.

[0082] Topology 2 may be deployed for scenarios with a type A, B, and / or C IoT device 3-1, in which the 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 assisting node 5-2 may be located in an indoor or an outdoor environment.

[0083] Topology 2 may also be deployed for indoor scenarios with a type A, B, and / or C IoT device 3-1, intermediate device 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.

[0084] Topology 2 may also be deployed for outdoor scenarios with a type A, B or C IoT device 3-1, RAN node 5-1 and intermediate (or assisting) 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.

[0085] 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 IoT device 3-1. The RAN node 5-1 will trigger the intermediate node 5-2 to send an unmodulated carrier signal 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. The resulting backscattered / reflected signal (or at least the data encoded in it) will then be forwarded / relayed to the RAN node 5-1.

[0086] Topology 3: RAN node ⇔ Assisting node ⇔ Ambient IoT device ⇔ RAN node: 　　Fig. 4A and 4B illustrate schematically a third connectivity topology (topology 3) of a mobile (cellular or wireless) communication system 1.

[0087] As shown in Fig. 4A and 4B, in topology 3, an IoT device 3-1, a RAN node 5-1 engage in communication with one another via an assisting node 5-2 (which may also be referred to as an intermediate node 5-2). It will be appreciated that while the assisting node 5-2 is depicted in Fig. 4A 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 a RAN node 5-1 and an IoT device 3-1.

[0088] 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 5-2 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 5-2 may be referred to as be a layer 1 ('L1') type assisting node 5-2.

[0089] As shown in Fig. 4A, the IoT device 3-1 may communicate with a 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 IoT device 3-1, or the communication between the assisting node 5-2 and the IoT device 3-1 respectively occurs over an appropriate air interface. For example, they may communicate over a Uu or dedicated 'sidelink' interface.

[0090] In this example the RAN node 5-1 (base station / cell) is responsible for transmission of an unmodulated carrier signal 20-1 to the IoT device 3-1. This unmodulated carrier signal 20-1 may be subsequently modulated and backscattered, as a modulated backscattered signal 20-2, from the 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 signal 20-2 from the IoT device 3-1. The modulated backscattered signal 20-2 (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. The modulated backscattered signal may be processed before being relayed / forwarded by the assisting node 5-2 to the RAN node 5-1. For example, the modulated backscattered signal 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. Alternatively, the modulated backscattered signal 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.

[0091] The communication 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 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 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 intermediate 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 modulated backscattered signal 20-2 received at the assisting node 5-2 from the IoT device 3-1, also occurs over an appropriate air interface. For example, they may communicate over a Uu or a dedicated interface.

[0092] 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 IoT device 3-1. The RAN node 5-1 will send an unmodulated carrier signal 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 for relaying / forwarding to the RAN node 5-1.

[0093] Alternatively, as shown in Fig. 4B, the IoT device 3-1 may communicate with a RAN node 5-1 in an uplink direction and an 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 IoT device 3-1, and the communication between the assisting node 5-2 and the IoT device 3-1, respectively occur over an appropriate air interface. For example, they may communicate over a Uu or dedicated 'sidelink' interface.

[0094] In this example the assisting node 5-2 is responsible for transmission of an unmodulated carrier signal 20-1 to the IoT device 3-1. This unmodulated carrier signal 20-1 may be subsequently modulated and backscattered, as a modulated backscattered signal 20-2, from the 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 signal 20-2 from the IoT device 3-1. The transmission of the unmodulated carrier signal 20-1 may be triggered by a downlink signal 20-3 received by the assisting node 5-2 from the RAN node 5-1. For example, the downlink signal 20-3 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 IoT device 3-1, or may be a trigger signal for triggering transmission of the unmodulated carrier signal 20-1.

[0095] 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 IoT device 3-1. The RAN node 5-1 will send an unmodulated carrier signal 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.

[0096] Similarly to Fig. 4A, in Fig. 4B, the communication 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 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 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 intermediate 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 IoT device 3-1, also occurs over an appropriate air interface. For example, they may communicate over a Uu or a dedicated interface.

[0097] 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 IoT device 3-1. The RAN node 5-1 will trigger the assisting node 5-2 to send an unmodulated carrier signal 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 RAN node 5-1.

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

[0099] Topology 3 may typically be deployed for outdoor scenarios with the IoT device 3-1 (typically a type B or C IoT device), RAN node 5-1, and the assisting 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 time 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.

[0100] Topology 3 may, nevertheless, be deployed for indoor scenarios with a type A, B, and / or C IoT device 3-1, assisting node 5-2, and RAN node 5-1 all 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 FDD, licensed TDD, or unlicensed parts of the spectrum.

[0101] Alternatively, for topology 3, the IoT device 3-1 (typically a type B or C IoT device) may be in an indoor environment but the RAN node 5-1 may be 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 assisting node 5-2 may be located in an indoor or an outdoor environment.

[0102] <Connection based Communication and Associated Security> 　　It will be appreciated that at least some of the UEs 3 are capable of initiating a direct communication connection (e.g., an RRC connection) with the RAN node 5-1. The UEs 3 that are capable of communicating via an RRC connection, and the RAN node 5-1, are mutually configured for performing appropriate RRC integrity protection and RRC confidentiality protection.

[0103] RRC Integrity Protection: 　　RRC integrity protection is provided by the Packet Data Convergence Protocol (PDCP) layer between UE 3 and RAN node 5-1 using an appropriate integrity algorithm.

[0104] Fig. 5 illustrates typical use of an integrity algorithm that may be used in the communication system 1 for RRC integrity protection. It will be appreciated that the use and mode of operation of the integrity protection algorithm illustrated in Fig. 5 is not limited to RRC integrity protection between the UE 3 and the RAN node 5-1 but may be used for other forms of user data and signalling data integrity protection between the UE 3 and the RAN node 5-1 (e.g., user plane data integrity protection) or between the UE 3 and other communication entities (e.g., NAS signalling integrity protection with the AMF 10-1 or the like).

[0105] As seen in Fig. 5, at the transmitter side 502-1 (which may be the UE 3 or RAN node 5-1), the integrity algorithm 510-1 receives a number of input parameters including an (typically 128-bit) integrity key 512-1 (typically referred to as 'KEY'), a (typically 32-bit) counter value 514-1 (typically referred to as 'COUNT'), a (typically 5-bit) bearer identity 516-1 (typically referred to as 'BEARER'), a (typically 1-bit) direction of the transmission indicator 518-1 (typically referred to as 'DIRECTION' - e.g., '0' for uplink and '1' for downlink), and the message 520-1 (typically referred to as 'MESSAGE') for which integrity protection is being applied.

[0106] Based on these input parameters the transmitter side 502-1 computes a (typically 32-bit) received message authentication code 522-1 (e.g., an access stratum (AS) message authentication code for integrity (MAC-I) or NAS message authentication code (NAS-MAC)) using the integrity algorithm 510-1. The received message authentication code 522-1 is then appended to the message 520-1 when sent.

[0107] Similarly, as seen in Fig. 5, at the receiver side 502-2 (which may be RAN node 5-1 or the UE 3), the same integrity algorithm 510-2 receives input parameters corresponding to those used at the transmitter side 502-1 including the same integrity key 512-2, the same counter value 514-2, the same bearer identity 516-2, the same direction of the transmission indicator 518-2, and the received message 520-2. The receiver side 502-2 computes the expected message authentication code 522-2 (e.g., an expected access stratum (AS) message authentication code for integrity (XMAC-I) or expected NAS message authentication code (XNAS-MAC)) from the received message 520-2 in the same way that the transmitter side 502-1 computed the received message authentication code 522-1 at the transmitter side 502-1 for the transmitted message 520-1 and hence verifies the data integrity of the message by comparing the expected message authentication code 522-2 to the received message authentication code 522-1.

[0108] It will be appreciated that, for RRC integrity protection, the input parameters to the integrity algorithms 510 in Fig. 5 will be an RRC message (as 'MESSAGE'), an RRC integrity key (as 'KEY' - e.g., 'KRRCint'), an appropriately assigned bearer identity (as 'BEARER'), a direction of transmission indicator corresponding to the direction (e.g., uplink or downlink) that the RRC message is being transmitted (as 'DIRECTION'), and a bearer specific direction dependent PDCP counter ('PDCP COUNT') value (as 'COUNT').

[0109] The RRC integrity checks are performed both in the UE 3 and the RAN node 5-1. In the case that a failed integrity check (e.g., a faulty or missing MAC-I) is detected after the start of integrity protection, the concerned message is discarded. This can happen at the RAN node side or on the UE side. In the case that a failed integrity check, the UE 3 may trigger an appropriate recovery procedure.

[0110] RRC confidentiality protection is provided by the PDCP layer between UE 3 and RAN node 5-1 using an appropriate encryption algorithm (which may also be referred to as a 'ciphering' algorithm).

[0111] RRC Confidentiality Protection: 　　Fig. 6 illustrates typical use of an encryption algorithm that may be used in the communication system 1 for RRC confidentiality protection. It will be appreciated that the use and mode of operation of the encryption protection algorithm illustrated in Fig. 6 is not limited to RRC confidentiality protection between a UE 3 and RAN node 5-1 but may be used for other forms of user data and signalling data confidentiality protection between the UE 3 and RAN node 5-1 (e.g., user plane data confidentiality protection) or between a UE 3 and other communication entities (e.g., NAS signalling confidentiality protection with the AMF 10-1 or the like).

[0112] As seen in Fig. 6, at the transmitter side 602-1 (which may be the UE 3 or RAN node 5-1), the transmitter side encryption algorithm 610-1 receives a number of input parameters including an (typically 128-bit) ciphering key 612-1 (typically referred to as 'KEY'), a (typically 32-bit) counter value 614-1 (typically referred to as 'COUNT'), a (typically 5-bit) bearer identity 616-1 (typically referred to as 'BEARER'), a (typically 1-bit) direction of the transmission indicator 618-1 (typically referred to as 'DIRECTION' - e.g., '0' for uplink and '1' for downlink), and the required length 624-1 (typically referred to as 'LENGTH') of a transmitter side keystream block (output keystream block) 630-1 (typically referred to simply as a 'KEYSTREAM').

[0113] Fig. 6 illustrates how, based on these input parameters, the transmitter side 602-1 uses the transmitter side encryption algorithm 610-1 to generate the transmitter side keystream block 630-1. The transmitter side keystream block 630-1 is then used to encrypt 632-1 an input plaintext block 634-1 (i.e., the data / signal to be encrypted - typically referred to simply as 'PLAINTEXT') by applying the transmitter side keystream block 630-1, using a bit per bit binary addition of the plaintext block 634-1 and the transmitter side keystream block 630-1, to generate and output a cipher text block 640 (typically referred to simply as a 'CIPHERTEXT').

[0114] Similarly, as seen in Fig. 6, at the receiver side 602-2 (which may be RAN node 5-1 or the UE 3), the same encryption algorithm 610-2 receives input parameters corresponding to those used at the transmitter side 602-1 including the same ciphering key 612-2, the same counter value 614-2, the same bearer identity 616-2, the same direction of the transmission indicator 618-2, and the same required length 624-2.

[0115] Fig. 6 illustrates how, based on these input parameters, the receiver side 602-2 uses the receiver side encryption algorithm 610-2 to generate the receiver side keystream block 630-1. The receiver side keystream block 630-2 is then used to decrypt 632-2 the cipher text block 640 by applying the receiver side keystream block 630-2, using a bit per bit binary addition of cipher text block 640 and the receiver side keystream block 630-2, to generate and output a recovered plaintext block 634-2 that, if successful, will be the same as the originally input plaintext block 634-1.

[0116] It will be appreciated that, for RRC confidentiality protection, the input parameters to the encryption algorithms 610 in Fig. 6 will be an RRC enciphering key (as 'KEY' - e.g., 'KRRCenc'), an appropriately assigned radio bearer identity (as 'BEARER'), a direction of transmission indicator corresponding to the direction (e.g., uplink or downlink) that the RRC signalling is being transmitted (as 'DIRECTION'), and a bearer specific direction dependent PDCP counter ('PDCP COUNT') value (as 'COUNT').

[0117] It will be appreciated that the security mechanisms described with reference to Figs. 5 to 7 are particularly relevant to how security may be implemented where the communication system 1 is a 5G / NR based communication system. Nevertheless, similar procedures may be used where the communication system 1 is an older generation (e.g., 4G) or future generation (e.g., 6G or beyond) system.

[0118] Key Derivation: 　　Fig. 7 is a simplified illustration of a key derivation hierarchy that may be used in the communication system 1 to derive the input keys (e.g., the KEY) used as an input for generating the message authentication codes in Fig. 5 or as an input for generating the keystream block in Fig. 6.

[0119] As seen in Fig. 7, for example, the RRC signalling integrity and enciphering keys referred to above (e.g., 'KRRCint' and 'KRRCenc') may be determined by the RAN node 5-1 and the UE 3 from a RAN node (base station) specific key (e.g., 'KgNB'). Similarly, a user plane integrity key (e.g., 'KUPint') and a user plane enciphering key (e.g., 'KUPenc') may be determined by the RAN node 5-1 and the UE 3 from the RAN node (base station) specific key (e.g., for the purposes of user plane integrity and confidentiality protection based on Fig. 5 and Fig. 6 respectively).

[0120] As seen in Fig. 7, in addition to being based on the RAN node (base station) specific key, the RRC / User plane signalling integrity and enciphering keys are also each derived based on a respective identifier of the associated encryption / integrity algorithm. The identifier of the associated encryption / integrity algorithm is typically provided in RRC signalling (e.g., an AS security mode command for RRC integrity / confidentiality protection and / or an RRC connection reconfiguration message for user plane integrity / confidentiality protection).

[0121] The RAN node (base station) specific key may be provided by the AMF 10-1 to the RAN node 5-1. The RAN node (base station) specific key may be derived (by the AMF 10-1 and the UE 3) from an AMF specific key (e.g., 'KAMF'). The AMF 10-1 and the UE 3 may also derive a NAS integrity key (e.g., 'KNASint') and a NAS enciphering key (e.g., 'KNASenc') from the AMF specific key - e.g., for the purposes of NAS integrity and confidentiality protection based on Fig. 5 and Fig. 6 respectively.

[0122] As seen in Fig. 7, in addition to being based on the AMF specific key, the NAS signalling integrity and enciphering keys are also each derived based on a respective identifier of the associated encryption / integrity algorithm. The identifier of the associated encryption / integrity algorithm is typically provided in NAS signalling (e.g., a NAS security mode command).

[0123] The AMF specific key may be provided by an SEAF to the AMF 10-1. The AMF specific key may, itself, be derived (by the SEAF and the UE 3) from an SEAF specific anchor key (e.g., 'KSEAF') provided to the SEAF by an AUSF.

[0124] The SEAF specific key may, itself, be derived (by the AUSF and the UE 3) from an AUSF specific security key (e.g., 'KAUSF'). The AUSF specific key may be obtained, by the AUSF, from a UDM / ARPF. The UDM / ARPF may derive the AUSF specific security key from an initial cipher key ('CK') and initial integrity key ('IK') as part an authentication and key agreement (AKA) procedure (where a 5G based AKA ('5G AKA') procedure has been used).

[0125] Nevertheless, the AUSF specific key may be derived by the AUSF from a replacement cipher key ('CK'') and replacement integrity key ('IK'') as part an authentication and key agreement (AKA) procedure (where an extensible authentication protocol (EAP) based AKA ('EPA AKA') procedure has been used). In this case, the replacement cipher key and replacement integrity key are provided by the UDM / ARPF where they are derived from the initial cipher key and initial integrity key.

[0126] In the case of 5G AKA, the UE 3 derives the AUSF specific key from the initial cipher key and initial integrity key. In the case of EPA AKA, the UE 3 derives the AUSF specific key from the replacement cipher key and replacement integrity key (which the UE 3 derives from the initial cipher key and initial integrity key).

[0127] The initial cipher key and initial integrity key may be derived, by the UDM / ARPF and the UE 3, from a UE specific ('root') key ('K') that is shared between the UE 3 and UDM / ARPF. This root key is stored at the UDM / ARPF and at the UE 3 (in a universal subscriber identity module (USIM)).

[0128] As those skilled in the art will appreciate other parameters (such as NAS uplink count for deriving KgNB, next hop (NH) value, etc.) that are not mentioned above may be used, in addition to those discussed above, for performing the various key derivations. Moreover, one or more other keys (e.g., one or more intermediate keys and / or one or more use specific keys (e.g., for non-3GPP access) may be derived as part of the key derivation procedures.

[0129] <Connectionless Communication> 　　Beneficially, the communication system 1 implements one or more mechanisms for supporting connectionless communication in the context of communication between the RAN node 5-1, and the IoT device 3-1. It will be appreciated that while the mechanisms are described with reference to IoT devices, and more specifically, ambient IoT devices, the mechanisms have application in other contexts (e.g., not necessarily involving ambient IoT devices) where connectionless communication is desirable.

[0130] The various mechanisms described beneficially address, for example, issues arising from the need for 'connectionless' communication associated with: how the RAN node 5-1 (base station / cell) is able to reach a specific IoT device 3-1 in order to stimulate that specific IoT device 3-1 to generate an 'uplink' transmission (i.e., directly to the RAN node 5-1) or 'sidelink' transmission (i.e., to the intermediate / assisting node 5-1); how a specific identity can be assigned to the IoT UE 3-1; and / or how a required level of security for the data transmission can be ensured.

[0131] In the context of connectionless communication, these issues are not trivial to address. For example, for communication via a conventional UE dedicated (e.g., 'RRC') connection, a temporary identifier (e.g., a cell radio network temporary identifier (C-RNTI)) can be assigned to the UE 3, by the RAN node 5-1, during a random access channel (RACH) based procedure. However, no such RACH procedure may be possible for communication via IoT devices 3-1 of the type described herein (especially for IoT devices 3-1 that have no capability to generate signals such as type A and type B devices). Similarly, for example, for conventional communication via a UE dedicated (e.g., 'RRC') connection, a security key is effectively assigned by RRC signaling to the UE 3 (e.g., indicating the integrity / enciphering algorithm to use). However, no such security related signalling (via RRC) may be possible for communication via IoT devices 3-1 of the type described herein because the transmissions of data via a reflected / backscattered signal will occur automatically in response to receipt of the unmodulated carrier signal without time for any such dedicated (e.g., RRC) connection or associated security context to be established.

[0132] The mechanisms described are applicable for scenarios in which the backscattered / reflected transmission carrying data occurs before any dedicated RRC connection is (or can be) established between the IoT device 3-1 and the recipient RAN node 5-1 or intermediate / assisting node 5-2. The mechanisms are, therefore, particularly relevant for devices that do not have an independent signal generation capability (e.g., type A and type B devices). It will, nevertheless, be appreciated that the mechanisms described may also be implemented for type C devices to allow for secure backscattered / reflected data transmission without a dedicated connection needing to be established.

[0133] The mechanisms described are therefore applicable where an IoT device 3-1 does not maintain any form of RRC state (e.g., its backscatter transmission is similar to RRC Idle mode based operation in conventional UEs). The IoT device 3-1 does not, therefore, maintain any signalling connection with the network but instead, data transmission is 'burst based'.

[0134] It will be appreciated, therefore, that the usual functionalities of the PDCP and RLC layers, and at least some of the MAC layer functions (e.g. logical channel prioritization (LCP)), do not apply. Similarly, functionalities of the service data adaptation protocol (SDAP) layer (which is responsible for mapping between a quality-of-service flow from the core network 7 and a data radio bearer) will not apply. The concept of a signalling radio bearer (SRB) and data radio bearer (DRB) and the corresponding logical channel do not apply for backscattered transmissions.

[0135] Nevertheless, some form of data ciphering (confidentiality protection) and / or integrity protection is desirable. Beneficially, therefore, as described in more detail later, the one or more mechanisms for supporting connectionless communication that may be implemented in the communication system may include one or more security mechanisms, for example that involve performing ciphering (confidentiality protection) and / or integrity protection based on a security key (and / or information from which a security key can be derived) that is distributed to the IoT device 3-1 before any backscatter data transmission.

[0136] The security mechanisms are described in more detail below in the context of a scenario in which there is no NAS layer between the IoT device 3-1 and the core network. Accordingly, in the security mechanisms described the AS layer (between the RAN node 5-1 and the IoT device 3-1) effectively replaces some NAS layer functionality in the handling / management of 'parent' security keys (e.g., KAMFand / or other 'parent' keys shown in Fig. 7) from which the keys used for ciphering and / or integrity protection are ultimately derived. It will, nevertheless, be appreciated that alternatively (or additionally), a NAS layer may be supported between the IoT device 3-1 and the network, and the NAS layer may handle / manage at least some aspects of device connectivity (including 'parent' security keys such as KAMFand / or other 'parent' keys shown in Fig. 7). Where a NAS layer is supported, the RAN node 5-1 may therefore handle / manage the data transmission only. Nevertheless, the mechanisms described in more detail below are still generally applicable.

[0137] As described above with reference to Figs. 5 and 6., for UEs 3 that can engage in conventional RRC connection based communication, the inputs for key derivation may include an AS key (such as 'KRRCenc', 'KRRCint', etc.), a subset of a PDCP count value, a bearer identity, a data transmission direction, message, a length etc.

[0138] Beneficially, in at least some of the security mechanisms described in more detail below, a simplified key stream derivation may be used by the IoT device 3-1 in which the input for key derivation may include one or more of the following parameters: a stored key for the IoT device; an assigned security key; an assigned cell wise identity (e.g., a C-RNTI or the like); and / or a short version (or full version) of a UE temporary global identity for the IoT device 3-1. Nevertheless, it will be appreciated that the same input parameters may be used for derivation of a keystream (and / or authentication code) as described above with reference to Fig. 6 (and / or Fig. 5) - or a subset of one or more of those input parameters - but with default values assigned to them, for example: KEY: may be set to an assigned security key from the network; BEARER: all bits may be set to 1; DIRECTION: the bit may be set to 1; COUNT: all bits may be set to 1; MESSAGE: This parameter can be calculated using a security algorithm based on, for example, an assigned cell wise identity (e.g., C-RNTI or the like), a cell physical cell identifier (PCI), a cell global ID, and / or the like; LENGTH: the length of the keystream used for IoT device 3-1.

[0139] It will be appreciated that the various different mechanisms described are not mutually exclusive and all or a subset of one or more of the mechanisms may be implemented in the same communication system. For example, the various devices involved in the ambient IoT type communication may be configured to use different mechanisms in different scenarios as appropriate.

[0140] (Backscatter Transmission via Same RAN Node / cell as Unmodulated Carrier (Topology 1)) 　　As mentioned above for topology 1 (Fig. 2), in a first scenario, the RAN node 5-1 / cell 9 may be responsible for both the transmission of an unmodulated carrier signal to the IoT device 3-1, and for reception of the resulting modulated backscattered signal from the IoT device 3-1.

[0141] Fig. 8 is a simplified sequence diagram illustrating a procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a RAN node 5-1 and an IoT device 3-1, in the first scenario for topology 1, that may be used in the communication system 1.

[0142] The procedure of Fig. 8 may be initiated, for example, when the RAN node 5-1 makes a decision to contact the IoT device 3-1. This may happen, for example, in response to a core network control plane function requesting retrieval of data from the IoT device 3-1. The core network control plane function may include, with such a request, a temporary global ID (e.g., a 5G or other temporary mobile subscriber identity ((5G-) TMSI)) of the IoT device 3-1.

[0143] Initially, the RAN node 5-1 sends one or more signals indicating the target IoT device 3-1 that is required to report the data (via a backscattered transmission).

[0144] This may, for example, be via one or more signals comprising a dedicated message (e.g., a 'dedicated data retrieval request' or the like), to the IoT device 3-1, as seen at S810. The dedicated message may include an appropriate identifier of the target IoT device 3-1 (e.g., a temporary global ID such as an 'IoT Global ID' or the like). The dedicated message may also, optionally, include an appropriate identifier of the cell (cell ID). To be able to receive and process such a request, the IoT device 3-1 may be of a type that has some form of energy storage (e.g., Type B or possibly Type C).

[0145] The one or more signals indicating the target IoT device 3-1 that is required to report the data may, nevertheless, comprise a specific unmodulated carrier signal (e.g., having a specific waveform) for the purposes of identifying the IoT device 3-1 (and / or cell) as seen at S812. It will be appreciated that such a signal will also be applicable to IoT devices 3-1 that do not have energy storage (e.g., Type A) in addition to those that do (e.g., Type B or possibly Type C).

[0146] At S816, the IoT device 3-1 to which the dedicated message / specific unmodulated carrier signal is addressed may, optionally, report its temporary global ID (e.g., (5G-) TMSI) back to the RAN node 5-1. The response message sent at S816 may be as a response to receiving the message sent at S810, or as a response to the reception of the specific unmodulated carrier signal for identification sent at S812. Prior to sending the response message, the IoT device 3-1 may retrieve its temporary global ID (e.g., (5G-) TMSI) from memory at S814 for sending in the response message (e.g., for modulating a backscattered response signal, sent in response to the specific unmodulated carrier signal for identification sent at S812, to encode the temporary global ID).

[0147] At S818, the RAN node 5-1 sends a configuration message to the IoT device 3-1 including one or more of the following: an assigned cell-wise temporary ID (e.g., a C-RNTI); one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like); the IoT device's temporary Global ID; and / or one or more specific resources for the following backscattered data transmission.

[0148] At S820, the RAN node 5-1 sends an unmodulated carrier signal to the IoT device 3-1 for the purposes of stimulating the IoT device 3-1 to generate a reflected / backscattered transmission to report the required data. A specific unmodulated carrier signal (e.g., with specific waveform) may, for example, be used to indicate such a purpose.

[0149] At S822, the IoT device 3-1 will generate a backscattered / reflected transmission, modulated to encode the data, and send the backscattered / reflected transmission (which may be over a specific resource allocated by the message received at S818) to the RAN node 5-1. The data encoded into the backscattered / reflected transmission may be scrambled with a C-RNTI (e.g., previously indicated at S818).

[0150] It will be appreciated that the data carried by backscattered / reflected transmission may be subject to data ciphering and / or integrity protection (e.g. based on a security key provided by the message received at S818, and / or based on a security key derived from information provided by the message received at S818). Nevertheless, it will be appreciated that for some scenarios, such security may not be needed.

[0151] (Backscatter Transmission via Different RAN Node / cell than Unmodulated Carrier (Topology 1)) 　　As mentioned above for topology 1 (Fig. 2), in a second scenario, one RAN node 5-1 / cell 9 may be responsible for the transmission of an unmodulated carrier signal to the IoT device 3-1, and another RAN node 5-1 / cell 9 may be responsible for reception of the resulting modulated backscattered signal from the IoT device 3-1.

[0152] Fig. 9 is a simplified sequence diagram illustrating a procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a first RAN node 5-1TXthat transmits unmodulated carrier signals, an IoT device 3-1, and a second RAN node 5-1RXthat receives backscattered / reflected signals, in the second scenario for topology 1, that may be used in the communication system 1.

[0153] The procedure of Fig. 9 may be initiated, for example, when the first RAN node 5-1TXmakes a decision to contact the IoT device 3-1. This may happen, for example, in response to a core network control plane function requesting retrieval of data from the IoT device 3-1. The core network control plane function may include, with such a request, a temporary global ID (e.g., a 5G or later generations or other temporary mobile subscriber identity ((5G-) TMSI)) of the IoT device 3-1.

[0154] Initially, the first RAN node 5-1TXsends one or more signals indicating the target IoT device 3-1 that is required to report the data (via a backscattered transmission).

[0155] This may, for example, be via one or more signals comprising a dedicated message (e.g., a 'dedicated data retrieval request' or the like), to the IoT device 3-1, as seen at S910. The dedicated message may include an appropriate identifier of the target IoT device 3-1 (e.g., a temporary global ID such as an 'IoT Global ID' or the like). The dedicated message also includes an appropriate identifier of the cell (cell ID) of the first RAN node 5-1TX.

[0156] The one or more signals indicating the target IoT device 3-1 that is required to report the data may, nevertheless, comprise a specific unmodulated carrier signal (e.g., having a specific waveform) for the purposes of identifying the IoT device 3-1 (and / or cell) as seen at S912.

[0157] At S916-1, the IoT device 3-1 to which the dedicated message / specific unmodulated carrier signal is addressed may, optionally, report its temporary global ID (e.g., (5G-) TMSI) back to the second RAN node 5-1RX(i.e., a different cell 9 / RAN node 5-1 from the one that sent the message / unmodulated carrier). The response message sent at S916 may be as a response to receiving the message sent at S910, or as a response to the reception of the specific unmodulated carrier signal for identification sent at S912. Prior to sending the response message, the IoT device 3-1 may retrieve its temporary global ID (e.g., (5G-) TMSI) from memory at S914 for sending in the response message (e.g., for modulating a backscattered response signal, sent in response to the specific unmodulated carrier signal for identification sent at S912, to encode the temporary global ID). The response message sent at S916 may include the original identifier of the cell (e.g., cell ID).

[0158] At S916-2, the second (receiving) RAN node 5-1RXmay forward temporary global ID of the IoT device 3-1, to the first (original / transmitting) RAN node 5-1TX, based on the cell identifier that the second RAN node 5-1RXreceived at S916-1. The second (receiving) RAN node 5-1RXmay include an allocated cell wise ID (e.g. a C-RNTI) for the IoT device 3-1, and / or one or more specific resources for data transmission for the IoT device 3-1, with the forwarded identifier of the IoT device 3-1.

[0159] At S918, the first RAN node 5-1TXsends a configuration message to the IoT device 3-1 including one or more of the following: the cell-wise temporary ID (e.g., a C-RNTI) assigned by the second RAN node 5-1RX; one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like); the IoT device's temporary Global ID; and / or one or more specific resources for data transmission assigned by the second RAN node 5-1RX. Within this configuration message, an indication may be included to notify the IoT device 3-1 that such configuration should be used for the following backscattered data transmission. This is applicable, for example, for an IoT device 3-1 that can process the configuration message and store the configuration for the following backscattered data transmission.

[0160] At S920, the first RAN node 5-1TXsends an unmodulated carrier signal to the IoT device 3-1 for the purposes of stimulating the IoT device 3-1 to generate a reflected / backscattered transmission to report the required data. A specific unmodulated carrier signal (e.g., with specific waveform) may, for example, be used to indicate such a purpose.

[0161] At S922-1, the IoT device 3-1 will generate a backscattered / reflected transmission, modulated to encode the data, and send the backscattered / reflected transmission (which may be over a specific resource allocated by the message received at S918) to the second RAN node 5-1RX. The data encoded into the backscattered / reflected transmission may be scrambled with a C-RNTI (e.g., previously indicated at S918).

[0162] It will be appreciated that the data carried by backscattered / reflected transmission may be subject to data ciphering and / or integrity protection (e.g. based on a security key provided by the message received at S918, and / or based on a security key derived from information provided by the message received at S918). Nevertheless, it will be appreciated that for some scenarios, such security may not be needed. The original cell ID may also be included within the data.

[0163] At S922-2, when the second (receiving) RAN node 5-1RXreceives the backscattered / reflected transmission, it may decode the received signal to read the original cell identifier for the first RAN node 5-1TX, and then forward the (potentially ciphered) data to the first (original / transmitting) RAN node 5-1TXbased on that cell identifier (for deciphering if necessary).

[0164] As an alternative, which is not shown in Fig. 9, both step S916-2 and step S918 may be skipped, and, instead, one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like) can be allocated by the second (receiving) RAN node 5-1RX. In this case, the second (receiving) RAN node 5-1RXwill send a configuration message to the IoT device 3-1 including one or more of the following: the cell-wise temporary ID (e.g., a C-RNTI); one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like); the IoT device's temporary Global ID; and / or one or more specific resources for data transmission. The second (receiving) RAN node 5-1RXmay send a request to the first (original / transmitting) RAN node 5-1TXto send an unmodulated carrier signal to the IoT device 3-1 for the purposes of stimulating the IoT device 3-1 to generate a reflected / backscattered transmission to the second (receiving) RAN node 5-1RX. When the second (receiving) RAN node 5-1RXreceives the backscattered / reflected transmission, it may decode the received signal and may also decipher the ciphered data if necessary. In this case, the second (receiving) RAN node 5-1RXneed not forward the data to the first (original / transmitting) RAN node 5-1TX.

[0165] (Backscatter Transmission via L2 Intermediate Node (Topology 2)) 　　As mentioned above for topology 2 (Fig. 3), an intermediate node 5-2 may be responsible for the transmission of an unmodulated carrier signal to the IoT device 3-1 and for reception of the resulting modulated backscattered signal from the IoT device 3-1. Moreover, 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 - referred to as an L2 type intermediate node 5-2.

[0166] Fig. 10 is a simplified sequence diagram illustrating a procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a RAN node 5-1, an L2 type intermediate / assisting node 5-2, and an IoT device 3-1, that may be used in the communication system 1.

[0167] The procedure of Fig. 10 may be initiated, for example, when the RAN node 5-1 makes a decision to contact the IoT device 3-1. This may happen, for example, in response to a core network control plane function requesting retrieval of data from the IoT device 3-1. The core network control plane function may include, with such a request, a temporary global ID (e.g., a 5G or later generations or other temporary mobile subscriber identity ((5G-) TMSI)) of the IoT device 3-1.

[0168] Initially, at S1010-1, the RAN node 5-1 sends a message for retrieving the required data from (e.g., a 'data retrieval request' or the like) to the L2 intermediate node 5-2. The message may carry, for example, the IoT device's temporary Global ID and possibly an assigned cell-wise temporary ID (e.g., a C-RNTI) and / or one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like).

[0169] The intermediate node 5-2 then sends one or more signals indicating the target IoT device 3-1 that is required to report the data (via a backscattered transmission).

[0170] This may, for example, be via one or more signals comprising a separate dedicated message (e.g., a 'dedicated data retrieval request' or the like) to the IoT device 3-1 as seen at S1010-2. The dedicated message may include an appropriate identifier of the target IoT device 3-1 (e.g., a temporary global ID such as an 'IoT Global ID' or the like). The one or more signals indicating the target IoT device 3-1 that is required to report the data may, nevertheless, comprise a specific unmodulated carrier signal (e.g., having a specific waveform) for the purposes of identifying the IoT device 3-1 (and / or cell) as seen at S1012.

[0171] At S1016, the IoT device 3-1 to which the dedicated message / specific unmodulated carrier signal is addressed may, optionally, report its temporary global ID (e.g., (5G-) TMSI) back to the intermediate node 5-2. The response message sent at S1016 may be as a response to receiving the dedicated message sent at S1010-2, or as a response to the reception of the specific unmodulated carrier signal for identification sent at S1012. Prior to sending the response message, the IoT device 3-1 may retrieve its temporary global ID (e.g., (5G-) TMSI) from memory at S1014 for sending in the response message (e.g., for modulating a backscattered response signal, sent in response to the specific unmodulated carrier signal for identification sent at S1012, to encode the temporary global ID).

[0172] The intermediate node 5-2 then allocates, at S1017, an identifier for the IoT device 3-1 that is associated with the interface between the intermediate node 5-2 and the IoT device 3-1 (e.g., a sidelink ID), and maintains the relationship / mapping between that identifier and a cell-wise temporary ID (e.g., a C-RNTI), e.g., the cell-wise temporary ID allocated by the RAN node 5-1.

[0173] At S1018, the intermediate node 5-2 sends a configuration message to the IoT device 3-1 including the identifier allocated at S1017 and one or more of the following: the assigned cell-wise temporary ID (e.g., C-RNTI); one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like); the IoT device's temporary Global ID; and / or one or more specific resources for data transmission.

[0174] At S1020, the intermediate node 5-2 sends an unmodulated carrier signal to the IoT device 3-1 for the purposes of stimulating the IoT device 3-1 to generate a reflected / backscattered transmission to report the required data. A specific unmodulated carrier signal (e.g., with specific waveform) may, for example, be used to indicate such a purpose.

[0175] At S1022-1, the IoT device 3-1 will generate a backscattered / reflected transmission, modulated to encode the data, and send the backscattered / reflected transmission (which may be over a specific resource allocated by the message received at S1018) to the intermediate node 5-2. The data encoded into the backscattered / reflected transmission may be scrambled with the identifier (e.g., the sidelink ID) allocated at S1017 (e.g., as previously indicated at S1018).

[0176] It will be appreciated that the data carried by backscattered / reflected transmission may be subject to data ciphering and / or integrity protection (e.g. based on a security key provided by the message received at S1018, and / or based on a security key derived from information provided by the message received at S1018). Nevertheless, it will be appreciated that for some scenarios, such security may not be needed. The cell-wise ID (e.g., C-RNTI) may be included in an appropriate field within the data, or within a control region of the data (e.g. as a C-RNTI MAC control element (CE) within a MAC protocol data unit (PDU)) to identify the source of the data.

[0177] When the intermediate node 5-2 receives the backscattered / reflected transmission, it may decode the data in the received signal and read the cell-wise ID (e.g., C-RNTI) (if included in the received signal). The intermediate node 5-2 may add the cell-wise ID (e.g., C-RNTI) (if not included in the received signal) and then forward, at S1022-2, the (potentially ciphered) data to the RAN node 5-1 (for deciphering if necessary) together with the cell-wise ID (e.g., C-RNTI).

[0178] (Backscatter Transmission via L1 Intermediate Node (Topology 2)) 　　As mentioned above for topology 2 (Fig. 3), an intermediate node 5-2 may be responsible for the transmission of an unmodulated carrier signal to the IoT device 3-1 and for reception of the resulting modulated backscattered signal from the IoT device 3-1. Moreover, the intermediate node 5-2 may be of a type that blindly forwards a received signal without attempting to demodulate it - referred to as an L1 type intermediate node 5-2.

[0179] Fig. 11 is a simplified sequence diagram illustrating a procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a RAN node 5-1, an L1 type intermediate node 5-2, and an IoT device 3-1, that may be used in the communication system 1.

[0180] The procedure of Fig. 11 may be initiated, for example, when the RAN node 5-1 makes a decision to contact the IoT device 3-1. This may happen, for example, in response to a core network control plane function requesting retrieval of data from the IoT device 3-1. The core network control plane function may include, with such a request, a temporary global ID (e.g., a 5G or later generations or other temporary mobile subscriber identity ((5G-) TMSI)) of the IoT device 3-1.

[0181] Initially, the RAN node 5-1 sends, indirectly via the L1 intermediate node 5-2, one or more signals indicating the target IoT device 3-1 that is required to report the data (via a backscattered transmission).

[0182] This may, for example, be via one or more signals comprising a dedicated message (e.g., a 'dedicated data retrieval request' or the like) as seen at S1110. The dedicated message may carry one or more of the following: an assigned cell-wise temporary ID (e.g., a C-RNTI); one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like); the IoT device's temporary Global ID; and / or one or more specific resources for data transmission.

[0183] The one or more signals indicating the target IoT device 3-1 that is required to report the data may, nevertheless, comprise a specific unmodulated carrier signal (e.g., having a specific waveform) for the purposes of identifying the IoT device 3-1 (and / or cell) as seen at S1112.

[0184] At S1116, the IoT device 3-1 to which the dedicated message / specific unmodulated carrier signal is addressed may, optionally, report its temporary global ID (e.g., (5G-) TMSI) back to the RAN node 5-1 (indirectly via the intermediate node 5-2). The response message sent at S1116 may be as a response to receiving the message sent at S1110, or as a response to the reception of the specific unmodulated carrier signal for identification sent at S1112. Prior to sending the response message, the IoT device 3-1 may retrieve its temporary global ID (e.g., (5G-) TMSI) from memory at S1114 for sending in the response message (e.g., for modulating a backscattered response signal, sent in response to the specific unmodulated carrier signal for identification sent at S1112, to encode the temporary global ID).

[0185] If the dedicated message sent at S1110 does not include some or all of the configuration information (e.g., C-RNTI, one or more security keys / one or more security parameters, the IoT device's temporary Global ID, and / or one or more specific resources for data transmission) - or if the dedicated message is not sent - then the RAN node 5-1 may send a configuration message to the IoT device 3-1, indirectly via the intermediate node 5-2, at S1118. This configuration message may, for example, include one or more of items of information not received via the dedicated message as S1110, i.e., one or more of the following: an assigned cell-wise temporary ID (e.g., a C-RNTI); one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like); the IoT device's temporary Global ID; and / or one or more specific resources for data transmission.

[0186] At S1120, the RAN node 5-1 sends an unmodulated carrier signal to the IoT device 3-1 for the purposes of stimulating the IoT device 3-1 to generate a reflected / backscattered transmission to report the required data. A specific unmodulated carrier signal (e.g., with specific waveform) may, for example, be used to indicate such a purpose.

[0187] At S1122, the IoT device 3-1 will generate a backscattered / reflected transmission, modulated to encode the data, and send the backscattered / reflected transmission (which may be over a specific resource allocated by the message received at S1118) to the RAN node 5-1. The data encoded into the backscattered / reflected transmission may be scrambled with a C-RNTI (e.g., previously indicated at S1118).

[0188] It will be appreciated that the data carried by backscattered / reflected transmission may be subject to data ciphering and / or integrity protection (e.g. based on a security key provided by the message received at S1118 or by the dedicated message received at S1110, and / or based on a security key derived from information provided by the message received at S1118 or by the dedicated message received at S1110). Nevertheless, it will be appreciated that for some scenarios, such security may not be needed.

[0189] (Uplink Assisted Backscatter Transmission via L2 Assisting Node (Topology 3)) 　　As mentioned above for topology 3 an assisting node 5-2 can assist uplink communication by receiving backscattered transmissions and relaying / forwarding the backscattered transmissions (and / or the data encoded in those transmissions) as described with reference to Fig. 4A. Moreover, as mentioned above, 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 - referred to as an L2 type assisting node 5-2.

[0190] Fig. 12 is a simplified sequence diagram illustrating a procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a RAN node 5-1, an L2 type assisting node 5-2 that assists in an uplink direction, and an IoT device 3-1, that may be used in the communication system 1.

[0191] The procedure of Fig. 12 may be initiated, for example, when the RAN node 5-1 makes a decision that the IoT device 3-1 needs to be paged. This may happen, for example, in response to a core network control plane function requesting retrieval of data from the IoT device 3-1. The core network control plane function may include, with such a request, a temporary global ID (e.g., a 5G or later generations or other temporary mobile subscriber identity ((5G-) TMSI)) of the IoT device 3-1.

[0192] Initially, in this example, the RAN node 5-1 sends a specific unmodulated carrier signal (e.g., having a specific waveform), as seen at S1212, in order to stimulate the IoT device 3-1 to generate reflected / backscattered transmission. Additionally or alternatively, a separate message (e.g., a 'dedicated data retrieval request' or the like) may be sent, to the IoT device 3-1, before (or instead of) transmitting the unmodulated carrier signal as a trigger for the IoT Device 3-1 to send its identifier to the assisting node 5-2. If sent, the separate message may include an appropriate identifier of the target IoT device 3-1 (e.g., a temporary global ID such as an 'IoT Global ID' or the like).

[0193] The IoT device 3-1 may retrieve its temporary global ID (e.g., (5G-) TMSI) from memory at S1214 and / or may generate a random identifier for the purposes of identifying itself.

[0194] At S1216-1, the IoT device 3-1 to which the separate message / specific unmodulated carrier signal is addressed generates and sends a backscattered / reflected transmission to the assisting node 5-2. The backscattered / reflected transmission may, for example include the temporary Global Id (e.g., TMSI) or random identifier (and thus identifies itself to the assisting node 5-2).

[0195] At S1216-2, the assisting node 5-2 sends a message (e.g., an indication of ambient IoT UE ID or the like) to the RAN node 5-1 to indicate that there has been a response to the unmodulated signal. The message may include, for example, the IoT device's identifier (e.g., e.g., TMSI and / or random identifier as the temporary global ID). Hence, when the RAN node 5-1 has received the response, the RAN node 5-1 can allocate a cell-wise temporary ID (e.g., C-RNTI) to the intended IoT device 3-1 based on the temporary Global ID.

[0196] At S1218-1, the RAN node 5-1 sends a configuration message to the IoT device 3-1 including one or more of the following: the assigned cell-wise temporary ID (e.g., a C-RNTI); one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like); and / or the IoT device's temporary Global ID.

[0197] At S1219, the assisting node 5-2, based on the reception of the configuration message from the RAN node 5-1, corelates the cell-wise temporary ID (e.g., C-RNTI) with an identifier for that IoT device 3-1 that is associated with the interface between the assisting node 5-2 and the IoT device 3-1 (e.g., a sidelink ID or the like) and hence assigns that identifier to the intended IoT device 3-1.

[0198] The assisting node 5-2 then sends, at S1218-2 a second configuration message (e.g., a request for backscattered transmission or the like) to the intended IoT device 3-1. This second configuration message may include, for example, the identifier associated with the interface between the assisting node 5-2 and the IoT device 3-1 assigned at S1219, the temporary global ID / random ID, one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like) for backscattered communication, and / or one or more specific resources for data transmission.

[0199] The assisting node 5-2 may also request that the IoT device 3-1 (by sending the second configuration message or possibly a separate message) generates a data transmission (i.e., to report its data) when that IoT device 3-1 receives an appropriate further unmodulated carrier signal from the RAN node 5-1. As mentioned above, one or more specific resources may be allocated for such data transmission (e.g., in the second configuration / request message). It will be appreciated that the second configuration / request message sent at S1218-2 is sent to the intended IoT device 3-1 only. In a variation on this, a negative message may be sent to any other IoT devices 3-1, e.g. to request that any other IoT devices 3-1 do not generate a data transmission (i.e., to report their data) when the appropriate further unmodulated carrier signal is received.

[0200] At S1220, the RAN node 5-1 sends the further unmodulated carrier signal to the IoT device 3-1 for the purposes of stimulating the IoT device 3-1 to generate a reflected / backscattered transmission to report the required data. A specific unmodulated carrier signal (e.g., with specific waveform) may, for example, be used to indicate such a purpose. It will be appreciated that this further unmodulated carrier signal may be different from the unmodulated carrier signal used for identification at S1212 (e.g. in terms of waveform, resources, and / or power, etc.).

[0201] It will be appreciated that, as part of this procedure, the assisting node may notify the RAN node 5-1 (e.g., at an appropriate juncture after sending the second configuration message / request at S1218-2) to initiate the transmission of the further unmodulated carrier signal.

[0202] At S1222-1, the IoT device 3-1 generates a backscattered / reflected transmission, modulated to encode the data, and sends the backscattered / reflected transmission (which may be over a specific resource allocated by the message received at S1218-2) to the assisting node 5-2. The data encoded into the backscattered / reflected transmission may be scrambled with the identifier assigned at S1219 (e.g., as previously indicated at S1218-2).

[0203] It will be appreciated that the data carried by backscattered / reflected transmission may be subject to data ciphering and / or integrity protection (e.g. based on a security key provided by the message received at S1218-2, and / or based on a security key derived from information provided by the message received at S1218-2). Nevertheless, it will be appreciated that for some scenarios, such security may not be needed. The cell-wise ID (e.g., C-RNTI) may be included in an appropriate field within the data, or within a control region of the data (e.g. as a C-RNTI MAC CE within a MAC PDU) to identify the source of the data.

[0204] When the assisting node 5-2 receives the backscattered / reflected transmission, it may decode the data in the received signal and read the cell-wise ID (e.g., C-RNTI) (if included in the received signal). The assisting node 5-2 may add the cell-wise ID (e.g., C-RNTI) (if not included in the received signal) and then forward, at S1222-2, the (potentially ciphered) data to the RAN node 5-1 (for deciphering if necessary) together with the cell-wise ID (e.g., C-RNTI). It will be appreciated that the forwarded data can be carried over a specific data pipeline, between the assisting node 5-2 and the RAN node 5-1, that has been established for that particular IoT device 3-1.

[0205] It will be appreciated that, a random identifier (as described above) may be used as an alternative for cases where the IoT device 3-1 may not have an allocated temporary global ID. This might be the case, for example, for environment sensors or the like, where the network may just need to retrieve the data from the IoT device 3-1. In such scenarios, the random identifier may be used when the IoT device generates the backscattered transmissions (i.e., in steps S1214 to S1218-2).

[0206] In another alternative, at the beginning of the procedure, before the RAN node 5-1 transmits the unmodulated carrier signal to the IoT device 3-1 at S1212, the RAN node 5-1 may send a paging message (e.g., a conventional paging message) to the intended IoT device 3-1 (i.e., to notify that device of the impending unmodulated carrier signal transmissions). After this, only the intended IoT device 3-1 will respond to the unmodulated carrier signals sent by the RAN node 5-1 (e.g., at S1216-1 and / or S1222-1), with a backscattered signal (with data to be forwarded by the assisting node 5-2).

[0207] (Uplink Assisted Backscatter Transmission via L1 Assisting Node (Topology 3)) 　　As mentioned above for topology 3 an assisting node 5-2 can assist uplink communication by receiving backscattered transmissions and relaying / forwarding the backscattered transmissions (and / or the data encoded in those transmissions) as described with reference to Fig. 4A. Moreover, as mentioned above, the assisting node 5-2 may be of type that blindly forwards a received signal without attempting to demodulate it - referred to as an L1 type assisting node 5-2.

[0208] Fig. 13 is a simplified sequence diagram illustrating a procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a RAN node 5-1, an L1 type assisting node 5-2 that assists in an uplink direction, and an IoT device 3-1, that may be used in the communication system 1.

[0209] The procedure of Fig. 13 may be initiated, for example, when the RAN node 5-1 makes a decision to contact the IoT device 3-1. This may happen, for example, in response to a core network control plane function requesting retrieval of data from the IoT device 3-1. The core network control plane function may include, with such a request, a temporary global ID (e.g., a 5G or other temporary mobile subscriber identity ((5G-) TMSI)) of the IoT device 3-1.

[0210] Initially, in this example, the RAN node 5-1 sends a specific unmodulated carrier signal (e.g., having a specific waveform), as seen at S1312, in order to stimulate the IoT device 3-1 to generate reflected / backscattered transmission. Additionally or alternatively, a separate message (e.g., a 'dedicated data retrieval request' or the like) may be sent, to the IoT device 3-1, before (or instead of) transmitting the unmodulated carrier signal as a trigger for the IoT Device 3-1 to send its identifier to the RAN node 5-1. If sent, the separate message may include an appropriate identifier of the target IoT device 3-1 (e.g., a temporary global ID such as an 'IoT Global ID' or the like).

[0211] The IoT device 3-1 may retrieve its temporary global ID (e.g., (5G-) TMSI) from memory at S1314 and / or may generate a random identifier for the purposes of identifying itself.

[0212] At S1316, the IoT device 3-1 to which the separate message / specific unmodulated carrier signal is addressed generates and sends a backscattered / reflected transmission to the RAN node 5-1 indirectly via the assisting node 5-2. The backscattered / reflected transmission may, for example include the temporary Global Id (e.g., TMSI) or random identifier (and thus identifies itself to the RAN node 5-1). Hence, when the RAN node 5-1 has received the response, the RAN node 5-1 can allocate, to the intended IoT device 3-1 based on the temporary global ID or a random identifier generated by IoT device 3-1, one or more of the following: a cell-wise temporary ID (e.g., a C-RNTI); one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like); and / or one or more specific resources for data transmission. Then at S1318, the RAN node 5-1 sends a configuration message, to the intended IoT device 3-1 including that information (e.g., the assigned cell-wise temporary ID (e.g., a C-RNTI); one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like); and / or one or more specific resources for data transmission).

[0213] At S1320, the RAN node 5-1 may send a further unmodulated carrier signal to the IoT device 3-1 for the purposes of stimulating the IoT device 3-1 to generate a reflected / backscattered transmission to report the required data. A specific unmodulated carrier signal (e.g., with specific waveform) may, for example, be used to indicate such a purpose. It will be appreciated that this further unmodulated carrier signal may be different from the unmodulated carrier signal used for identification at S1312 (e.g. in terms of waveform, resources, and / or power, etc.).

[0214] At S1322, the IoT device 3-1 will generate a backscattered / reflected transmission, modulated to encode the data, and send the backscattered / reflected transmission (which may be over a specific resource allocated by the message received at S1318) to the assisting node 5-2. The data encoded into the backscattered / reflected transmission may be scrambled with a C-RNTI (e.g., previously indicated at S1318).

[0215] It will be appreciated that the data carried by backscattered / reflected transmission may be subject to data ciphering and / or integrity protection (e.g. based on a security key provided by the message received at S1318, and / or based on a security key derived from information provided by the message received at S1318). Nevertheless, it will be appreciated that for some scenarios, such security may not be needed. The cell-wise ID (e.g., C-RNTI) may be included in an appropriate field within the data, or within a control region of the data (e.g. as a C-RNTI MAC CE within a MAC PDU) to identify the source of the data. When the assisting node 5-2 receives the backscattered / reflected transmission, it does not decode the data in the received signal but simply forwards it to the RAN node 5-1 as shown.

[0216] (Downlink Assisted Unmodulated Carrier Signal via Assisting Node (Topology 3)) 　　As mentioned above for topology 3 an assisting node 5-2 can assist downlink communication by sending the unmodulated carrier signal when needed, for example, when triggered to do so by the RAN node 5-1 or based on some other trigger event.

[0217] Fig. 14 is a simplified sequence diagram illustrating a first procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a RAN node 5-1, an assisting node 5-2 that assists in a downlink direction, and an IoT device 3-1, that may be used in the communication system 1.

[0218] The procedure of Fig. 14 may be initiated, for example, when the RAN node 5-1 makes a decision to contact the IoT device 3-1. This may happen, for example, in response to a core network control plane function requesting retrieval of data from the IoT device 3-1. The core network control plane function may provide (either with such a request or in another way) to the RAN node 5-1, both an identifier of the assisting node 5-2 and an identifier of the IoT device 3-1 (e.g., a temporary global ID such as a 5G or later generations or other temporary mobile subscriber identity) as indicated at S1406.

[0219] At S1408, the RAN node 5-1 may page the assisting node 5-2 (which may be responsible for monitoring the paging for the intended IoT device 3-1), or may use dedicated signalling, to notify the assisting node 5-2 of the RAN node's intention to reach the IoT device 3-1 associated with the assisting node 5-2 (this may, for example, be in the form of a request to page an IoT UE message or the like). The RAN node may include the temporary global ID of IoT device (e.g. TMSI) in such a notification / request. The RAN node 5-1 may also include, in the notification / request message, a cell wise unique identity (e.g., a C-RNTI) and / or one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like) for the IoT device 3-1.

[0220] As seen at S1410, the assisting node 5-2 may then send a request to the IoT device 3-1 to request that the IoT device 3-1 performs a backscattered / reflected transmission. This request may include one or more of the following: the IoT device's temporary Global ID; the cell-wise unique identity (e.g., a C-RNTI); one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like). This request message may be sent over one or more specific resources which may be shared by multiple ambient capable IoT devices. After receiving the backscattered transmission request, the IoT device 3-1 compares its own global ID with the received global ID at S1414. Only an IoT device 3-1 having a temporary global ID (e.g. TMSI) matching the received global ID will generate a backscattered transmission when a further unmodulated carrier signal has been received (i.e., for the purposes of stimulating the IoT device 3-1 to generate a reflected / backscattered transmission to report the required data).

[0221] At S1420, the assisting node 5-2 initiates the transmission of the further unmodulated carrier signal for the purposes of stimulating the IoT device 3-1 to generate a reflected / backscattered transmission to report the required data.

[0222] At S1422, the IoT device 3-1 will generate a backscattered / reflected transmission, modulated to encode the data, and send the backscattered / reflected transmission to the assisting node 5-2. The data encoded into the backscattered / reflected transmission may be scrambled with a C-RNTI (e.g., previously indicated at S1418).

[0223] It will be appreciated that the data carried by backscattered / reflected transmission may be subject to data ciphering and / or integrity protection (e.g. based on a security key provided by the message received at S1418, and / or based on a security key derived from information provided by the message received at S1418). Nevertheless, it will be appreciated that for some scenarios, such security may not be needed.

[0224] Fig. 15 is a simplified sequence diagram illustrating a second procedure for coordinating unmodulated carrier signal and backscatter signal transmissions between a RAN node 5-1, an assisting node 5-2 that assists in a downlink direction, and an IoT device 3-1, that may be used in the communication system 1.

[0225] The procedure of Fig. 15 may be initiated, for example, when the RAN node 5-1 makes a decision to contact the IoT device 3-1. This may happen, for example, in response to a core network control plane function requesting retrieval of data from the IoT device 3-1. The core network control plane function may provide (either with such a request or in another way) to the RAN node 5-1, both an identifier of the assisting node 5-2 and an identifier of the IoT device 3-1 (e.g., a temporary global ID such as a 5G or later generations or other temporary mobile subscriber identity) as indicated at S1506.

[0226] At S1508, the RAN node 5-1 may page the assisting node 5-2 (which may be responsible for monitoring the paging for the intended IoT device 3-1), or may use dedicated signalling, to notify the assisting node 5-2 of the RAN node's intention to reach the IoT device 3-1 associated with the assisting node 5-2 (this may, for example, be in the form of a request to page an IoT UE message or the like). The RAN node may include the temporary global ID of IoT device 3-1 (e.g. TMSI) in such a notification / request. The RAN node 5-1 may also include, in the notification / request message, a cell wise unique identity (e.g., a C-RNTI) and / or one or more security keys / one or more security parameters which can be used in security key derivation (e.g., key derivation count value or the like) for the IoT device 3-1.

[0227] As seen at S1510, the assisting node 3-1 may then send a request to the IoT device 3-1 to request that the IoT device 3-1 performs a backscattered / reflected transmission. In this example, this request includes the IoT device's temporary Global ID. This message may, for example, be sent in a broadcast manner.

[0228] After receiving the backscattered transmission request, the IoT device 3-1 may compare its own global ID with the received global ID to determine whether the request is for that IoT device 3-1. Only an IoT device 3-1 having a temporary global ID (e.g. TMSI) matching the received global ID need respond to the request sent at S1510.

[0229] Then, at S1511, the intended IoT device 3-1 provides a feedback message to the assisting node 5-2, to acknowledge the request sent at S1510.

[0230] The assisting node 5-2 may then send, at S1518, to the IoT device 3-1 that provides the acknowledgement at S1511, an indication / notification message to the IoT device 3-1 for backscattered transmission. The indication / notification includes, for that IoT device 3-1, the cell wise unique identity (e.g. C-RNTI) and / or one or more security keys / one or more security parameters which can be used in security key derivation. This indication / notification message may also indicate one or more specific resources for the backscattered transmission by the IoT device 3-1.

[0231] At S1520, the assisting node 5-2 initiates the transmission of the further unmodulated carrier signal for the purposes of stimulating the IoT device 3-1 to generate a reflected / backscattered transmission to report the required data.

[0232] At S1522, the IoT device 3-1 will generate a backscattered / reflected transmission, modulated to encode the data, and send the backscattered / reflected transmission to the assisting node 5-2. The data encoded into the backscattered / reflected transmission may be scrambled with a C-RNTI (e.g., previously indicated at S1518).

[0233] It will be appreciated that the data carried by backscattered / reflected transmission may be subject to data ciphering and / or integrity protection (e.g. based on a security key provided by the message received at S1518, and / or based on a security key derived from information provided by the message received at S1518). Nevertheless, it will be appreciated that for some scenarios, such security may not be needed.

[0234] (Components of the Communication System) 　　User Equipment 　　Fig. 16 is a simplified block schematic diagram illustrating the main components of a UE 3-2; 3-3 for implementation in the system of Fig. 1.

[0235] As shown, the UE 3-2; 3-3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a base station 5 via one or more antenna 33 (e.g., comprising one or more antenna elements). The UE 3 has a controller 37 to control the operation of the UE 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily required for its operation, the UE 3-2; 3-3 might, of course, have all the usual functionality of a conventional UE 3-2; 3-3 (e.g., a user interface 35, 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 39 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

[0236] The controller 37 is configured to control overall operation of the UE 3-2; 3-3 by, in this example, program instructions or software instructions stored within memory 39. As shown, these software instructions include, among other things, an operating system 41, and a communication control module 43.

[0237] The communication control module 43 is operable to control the communication between the UE 3-2; 3-3 and its serving RAN node or RAN nodes 5-1 (and other communication devices connected to the RAN node 5-1, such as further UEs and / or core network nodes). The communication control module 43 is configured for the overall handling of uplink communications 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 43 is also configured for the overall handling of receipt of downlink communications 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). The communication control module 43 is responsible, for example: for determining where to monitor for downlink control information; for determining the resources to be used by the UE 3 for transmission / reception of UL / DL communications (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the UE side; for determining how slots / symbols are configured (e.g., for UL, DL or full duplex communication, or the like); for determining which bandwidth parts are configured for the UE 3-2; 3-3; for determining how uplink transmissions should be encoded and the like.

[0238] It will be appreciated that the communication control module 43 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 43 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc.

[0239] The communication control module 43 is configured, in particular, to control the UE's communications, where applicable, in accordance with any of the methods described herein.

[0240] Ambient IoT device 　　Fig. 17A is a first simplified block schematic diagram illustrating the main components of an example of a UE comprising an ambient IoT device 3-1 for possible implementation in the system of Fig. 1.

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

[0242] The transceiver circuit 131 has energy harvesting circuitry 131-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 131-1 may include, by way of example only, inductive and / or capacitive architectures to harvest energy from incoming signals.

[0243] It will however be appreciated that the energy harvesting circuitry 131-1 may alternatively not form part of the transceiver circuit 131, 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).

[0244] The transceiver circuit 131 also has modulation circuitry 131-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 131-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 131-2 may be configured to modulate the incoming signal to encode data provided from one or more data sources 132. Typically, for example, the IoT device 3-1 may comprise a data source 132 in the form of a sensor (e.g., an optical, temperature, position sensor or the like) for providing measurement data or a sensor alert, or it may comprise a data source 132 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.

[0245] Although not necessarily required for its operation, the IoT device 3-1 might, of course, have additional functionality (e.g., a user interface, a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user, and / or signal processing capability to allow interpretation of, and appropriate actions to be performed in response to, received signals as described herein).

[0246] Fig. 17B is a second simplified block schematic diagram illustrating the main components of another example of a UE comprising an ambient IoT device 3-1 for possible implementation in the system of Fig. 1.

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

[0248] The transceiver circuit 231 has energy harvesting circuitry 231-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 231-1 may include, by way of example only, inductive and / or capacitive architectures to harvest energy from incoming signals.

[0249] It will however be appreciated that the energy harvesting circuitry 231-1 may alternatively not form part of the transceiver circuit 231, 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).

[0250] The transceiver circuit 231 also has modulation circuitry 231-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 231-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 231-2 may be configured to modulate the incoming signal to encode data provided from one or more data sources 232. Typically, for example, the IoT device 3-1 may comprise a data source 232 in the form of a sensor (e.g., an optical, temperature, position sensor or the like) for providing measurement data or a sensor alert, or it may comprise a data source 232 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.

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

[0252] Although not necessarily required for its operation, the IoT device 3-1 might, of course, have additional functionality (e.g., a user interface, a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user, and / or signal processing capability to allow interpretation of, and appropriate actions to be performed in response to, received signals as described herein).

[0253] Fig. 17C is a second simplified block schematic diagram illustrating the main components of another example of a UE comprising an ambient IoT device 3-1 for possible implementation in the system of Fig. 1.

[0254] 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) via one or more antenna 333 (e.g., comprising one or more antenna elements).

[0255] The transceiver circuit 331 has 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.

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

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

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

[0259] In this example, the IoT device 3-1 also has a controller 337 to control the overall operation of the IoT device 3-1. The controller 337 is associated with a memory 339 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.

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

[0261] The communication control module 343 is operable to control the communication between the IoT device 3-1, a RAN node 5-1, and / or an assisting node 5-2. The communication control module 343 may, for example, be configured for the overall handling of uplink communications 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 343 may also be configured for the overall handling of receipt of downlink communications 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).

[0262] It will be appreciated that the communication control module 343 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities.

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

[0264] RAN node 　　Fig. 18 is a simplified block schematic diagram illustrating the main components of a RAN node 5-1 (e.g., a base station) for implementation in the system of Fig. 1.

[0265] 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 base stations 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.

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

[0267] The communication control module 63 is operable to control the communication between the RAN node (base station) 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 communications, 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 communications 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 communications (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.

[0268] It will be appreciated that the communication control module 63 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 63 may include, for communicating with a UE 3, a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc. Moreover, the communication control module 63 may include, for communicating with a core network entity such as an AMF 10-1 (or similar node such as an MME), an NG / S1 application protocol (NG / S1-AP) sub-module, a stream control transmission protocol (SCTP) sub-module, an IP sub-module, a layer 1 (L1) sub-module, a layer 2 (L2) sub-module, etc. (or corresponding sub-modules for communicating with a core network function).

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

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

[0271] 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 3-1) 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).

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

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

[0274] 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 uplink communications to the RAN node 5-1. For example, where the 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 communications from the RAN node 5-1. For example, where the 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 (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.

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

[0276] It will be appreciated that the communication control module 163 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 163 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc.

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

[0278] (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.

[0279] For example, it will be appreciated that whilst the described signalling procedures related to topology 3 in which a different node transmits the unmodulated carrier than receives the backscattered transmission, the principles described herein may be applied to scenarios in which the same node transmits the unmodulated carrier an receives the backscattered transmission (e.g., using connectivity topology 1 or 2 described above).

[0280] It will be appreciated that description of features of and actions performed by a RAN node (base station), apply equally to distributed type base stations as to non-distributed type base stations.

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

[0282] In the above description the UE and the base station 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.

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

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

[0285] The memories shown above may be formed by a non-transitory computer readable medium or a tangible storage medium. However, the memories may be formed by a combination of a non-transitory computer readable medium and a tangible storage medium.

[0286] A program includes instructions (or software codes) that, when loaded into a computer, cause the computer to perform one or more of the functions described in the example embodiments. The program may be stored in a non-transitory computer readable medium or a tangible storage medium. By way of example, and not limitation, non-transitory computer readable media or tangible storage media can include a random-access memory (RAM), a read-only memory (ROM), a flash memory, a solid-state drive (SSD) or other memory technologies, CD-ROM, digital versatile disk (DVD), Blu-ray disc ((R): Registered trademark) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices. The program may be transmitted on a transitory computer readable medium or a communication medium. By way of example, and not limitation, transitory computer readable media or communication media can include electrical, optical, acoustical, or other form of propagated signals.

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

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

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

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

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

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

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

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

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

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

[0297] It will be appreciated that IoT technology can be implemented on any communication devices 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.

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

[0299] 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. Further, each example embodiment can be appropriately combined with at least one of example embodiments.

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

[0301] Part of or all the foregoing aspects can be described as in the following appendixes, but the present disclosure is not limited thereto. Some or all of elements specified in any of Supplementary Notes may be applied to various types of hardware, software, and recording means for recording software, systems, and methods. 　　(Supplementary Note 1) 　　A method performed by an ambient Internet of Things (IoT) device, the method comprising: 　　receiving configuration information including a Cell Radio Network Temporary Identifier (C-RNTI) of the ambient IoT device and / or security related information in other than a Radio Resource Control (RRC) message; 　　receiving, from a communication apparatus, an unmodulated carrier wave; and 　　backscatting or reflecting the unmodulated carrier wave using the C-RNTI and / or the security related information. 　　(Supplementary Note 2) 　　The method according to Supplementary Note 1, further comprising: 　　receiving, from the communication apparatus, a global identity of the ambient IoT device, for the communication apparatus to identify the ambient IoT device; and 　　transmitting a specific identity corresponding to the global identity of the ambient IoT device upon the receiving the global identity of the ambient IoT device, and wherein 　　the receiving the configuration information is performed upon the transmitting the global identity of the ambient IoT device. 　　(Supplementary Note 3) 　　The method according to Supplementary Note 2, wherein 　　the receiving the global identity of the ambient IoT device is performed via an unmodulated carrier wave. 　　(Supplementary Note 4) 　　The method according to Supplementary Note 2 or 3, further comprising: 　　receiving, from the communication apparatus, cell information indicating a cell operated by the communication apparatus, along with the global identity of the ambient IoT device, and wherein 　　the transmitting the specific identity corresponding to the global identity of the ambient IoT device is performed by transmitting, to another communication apparatus, the global identity of the ambient IoT device and the cell information, 　　the C-RNTI is allocated by the another communication apparatus upon the transmitting the global identity of the ambient IoT device and cell information to the another communication apparatus, and 　　the C-RNTI and the cell information is transmitted from the another communication apparatus to the communication apparatus based on the cell information. 　　(Supplementary Note 5) 　　The method according to any one of Supplementary Notes 1 to 4, wherein 　　the configuration information includes at least one of: 　　　　the global identity of the ambient IoT device, or 　　　　resource used for the backscattering or reflecting the unmodulated carrier wave. 　　(Supplementary Note 6) 　　The method according to any one of Supplementary Notes 1 to 5, wherein 　　the communication apparatus includes an intermediate node, 　　the configuration information includes a sidelink identity for sidelink communication between the ambient IoT device and the intermediate node, and method further comprises: 　　scrambling the unmodulated carrier wave using the sidelink identity. 　　(Supplementary Note 7) 　　The method according to any one of Supplementary Notes 2 to 4, wherein 　　the transmitting the specific identity corresponding to the global identity of the ambient IoT device is performed by transmitting the specific identity to an assisting node, 　　the specific identity is transmitted from the assisting node to the communication apparatus, and 　　the configuration information is received from the communication apparatus via the assisting node. 　　(Supplementary Note 8) 　　The method according to Supplementary Note 7, further comprising: 　　receiving a sidelink identity for sidelink communication between the ambient IoT device and the assisting node; and 　　scrambling the unmodulated carrier wave using the sidelink identity, and wherein 　　the transmitting the unmodulated carrier wave is performed by transmitting the unmodulated carrier wave scrambled by the sidelink identity to the assisting node. 　　(Supplementary Note 9) 　　The method according to any one of Supplementary Notes 1 to 8, wherein 　　the receiving the global identity of the ambient IoT device is performed based on a request from another communication device to the communication device, and 　　the backscatting or reflecting the unmodulated carrier wave is performed by backscatting or reflecting to the another communication device. 　　(Supplementary Note 10) 　　A method performed by a communication device, the method comprising: 　　transmitting, to an ambient Internet of Things (IoT) device, configuration information including a Cell Radio Network Temporary Identifier (C-RNTI) of the ambient IoT device and / or security related information in other than a Radio Resource Control (RRC) message; 　　transmitting, to the ambient IoT device, an unmodulated carrier wave, and wherein 　　the unmodulated carrier wave is backscatted or reflected by the ambient IoT device using the C-RNTI and / or the security related information. 　　(Supplementary Note 11) 　　An ambient Internet of Things (IoT) device comprising: 　　means for receiving configuration information including a Cell Radio Network Temporary Identifier (C-RNTI) of the ambient IoT device and / or security related information in other than a Radio Resource Control (RRC) message; 　　means for receiving, from a communication apparatus, an unmodulated carrier wave; and 　　means for backscatting or reflecting the unmodulated carrier wave using the C-RNTI and / or the security related information. 　　(Supplementary Note 12) 　　A communication device comprising: 　　means for transmitting, to an ambient Internet of Things (IoT) device, configuration information including a Cell Radio Network Temporary Identifier (C-RNTI) of the ambient IoT device and / or security related information in other than a Radio Resource Control (RRC) message; 　　means for transmitting, to the ambient IoT device, an unmodulated carrier wave, and wherein 　　the unmodulated carrier wave is backscatted or reflected by the ambient IoT device using the C-RNTI and / or the security related information.

[0302] Elements corresponding to some or all of elements (e.g., structures and functions) specified in Supplementary Notes 2 to 9 dependent on Supplementary Note 1 may also be dependent on Supplementary Note 10, Supplementary Note 11 and Supplementary Note 12 in dependency similar to that of Supplementary Notes 2 to 9 on Supplementary Note 1. Some or all of elements specified in any of Supplementary Notes may be applied to various types of hardware, software, and recording means for recording software, systems, and methods.

[0303] This application is based upon and claims the benefit of priority from United Kingdom Patent Application No. 2319441.8, filed on December 18, 2023, the disclosure of which is incorporated herein in its entirety by reference.

[0304] 1　　COMMUNICATION SYSTEM 3-1　　AMBIENT IOT DEVICE 3-2, 3-3　　USER EQUIPMENT 5-1　　(R)AN 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 FUNCTION 11　　USER PLANE FUNCTION 21　　EXTERNAL DATA NETWORK 31　　TRANSCEIVER CIRCUIT 33　　ANTENNA 35　　USER INTERFACE 37　　CONTROLLER 39　　MEMORY 41　　OPERATING SYSTEM 43　　COMMUNICATION CONTROL MODULE 131　　TRANSCEIVER CIRCUIT 131-1　　ENERGY HARVESTING CIRCUITRY 131-2　　MODULATION CIRCUITRY 132　　DATA SOURCE 133　　ANTENNA 231　　TRANSCEIVER CIRCUIT 231-1　　ENERGY HARVESTING CIRCUITRY 231-2　　MODULATION CIRCUITRY 231-3　　SIGNAL AMPLIFIER 232　　DATA SOURCE 233　　ANTENNA 331　　TRANSCEIVER CIRCUIT 331-1　　ENERGY HARVESTING CIRCUITRY 331-2　　MODULATION CIRCUITRY 331-3　　SIGNAL AMPLIFIER 332　　DATA SOURCE 333　　ANTENNA 335　　USER INTERFACE 337　　CONTROLLER 339　　MEMORY 341　　OPERATING SYSTEM 343　　COMMUNICATION CONTROL MODULE 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

Claims

1. A method performed by an ambient Internet of Things (IoT) device, the method comprising: 　　receiving configuration information including a Cell Radio Network Temporary Identifier (C-RNTI) of the ambient IoT device and / or security related information in other than a Radio Resource Control (RRC) message; 　　receiving, from a communication apparatus, an unmodulated carrier wave; and 　　backscatting or reflecting the unmodulated carrier wave using the C-RNTI and / or the security related information.

2. The method according to claim 1, further comprising: 　　receiving, from the communication apparatus, a global identity of the ambient IoT device, for the communication apparatus to identify the ambient IoT device; and 　　transmitting a specific identity corresponding to the global identity of the ambient IoT device upon the receiving the global identity of the ambient IoT device, and wherein 　　the receiving the configuration information is performed upon the transmitting the global identity of the ambient IoT device.

3. The method according to claim 2, wherein 　　the receiving the global identity of the ambient IoT device is performed via an unmodulated carrier wave.

4. The method according to claim 2 or 3, further comprising: 　　receiving, from the communication apparatus, cell information indicating a cell operated by the communication apparatus, along with the global identity of the ambient IoT device, and wherein 　　the transmitting the specific identity corresponding to the global identity of the ambient IoT device is performed by transmitting, to another communication apparatus, the global identity of the ambient IoT device and the cell information, 　　the C-RNTI is allocated by the another communication apparatus upon the transmitting the global identity of the ambient IoT device and cell information to the another communication apparatus, and 　　the C-RNTI and the cell information is transmitted from the another communication apparatus to the communication apparatus based on the cell information.

5. The method according to any one of claims 1 to 4, wherein 　　the configuration information includes at least one of: 　　　　the global identity of the ambient IoT device, or 　　　　resource used for the backscattering or reflecting the unmodulated carrier wave.

6. The method according to any one of claims 1 to 5, wherein 　　the communication apparatus includes an intermediate node, 　　the configuration information includes a sidelink identity for sidelink communication between the ambient IoT device and the intermediate node, and method further comprises: 　　scrambling the unmodulated carrier wave using the sidelink identity.

7. The method according to any one of claims 2 to 4, wherein 　　the transmitting the specific identity corresponding to the global identity of the ambient IoT device is performed by transmitting the specific identity to an assisting node, 　　the specific identity is transmitted from the assisting node to the communication apparatus, and 　　the configuration information is received from the communication apparatus via the assisting node.

8. The method according to claim 7, further comprising: 　　receiving a sidelink identity for sidelink communication between the ambient IoT device and the assisting node; and 　　scrambling the unmodulated carrier wave using the sidelink identity, and wherein 　　the transmitting the unmodulated carrier wave is performed by transmitting the unmodulated carrier wave scrambled by the sidelink identity to the assisting node.

9. The method according to any one of claims 1 to 8, wherein 　　the receiving the global identity of the ambient IoT device is performed based on a request from another communication device to the communication device, and 　　the backscatting or reflecting the unmodulated carrier wave is performed by backscatting or reflecting to the another communication device.

10. A method performed by a communication device, the method comprising: 　　transmitting, to an ambient Internet of Things (IoT) device, configuration information including a Cell Radio Network Temporary Identifier (C-RNTI) of the ambient IoT device and / or security related information in other than a Radio Resource Control (RRC) message; 　　transmitting, to the ambient IoT device, an unmodulated carrier wave, and wherein 　　the unmodulated carrier wave is backscatted or reflected by the ambient IoT device using the C-RNTI and / or the security related information.

11. An ambient Internet of Things (IoT) device comprising: 　　means for receiving configuration information including a Cell Radio Network Temporary Identifier (C-RNTI) of the ambient IoT device and / or security related information in other than a Radio Resource Control (RRC) message; 　　means for receiving, from a communication apparatus, an unmodulated carrier wave; and 　　means for backscatting or reflecting the unmodulated carrier wave using the C-RNTI and / or the security related information.

12. A communication device comprising: 　　means for transmitting, to an ambient Internet of Things (IoT) device, configuration information including a Cell Radio Network Temporary Identifier (C-RNTI) of the ambient IoT device and / or security related information in other than a Radio Resource Control (RRC) message; 　　means for transmitting, to the ambient IoT device, an unmodulated carrier wave, and wherein 　　the unmodulated carrier wave is backscatted or reflected by the ambient IoT device using the C-RNTI and / or the security related information.

Images