Method performed by intermediate device, method performed by base station, intermediate device and base station

Abstract

An aspect of this disclosure includes a method performed by an intermediate device for relaying communication between a base station and a mobile device, the method comprising receiving, from the base station, a message for allocating at least one random access resource for communicating with the mobile device communicating with the mobile device using the at least one random access resource.

Description

METHOD PERFORMED BY INTERMEDIATE DEVICE, METHOD PERFORMED BY BASE STATION, INTERMEDIATE DEVICE AND BASE STATION

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

[0002] The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards, equivalents, or derivatives thereof (including Long Term Evolution (LTE)-Advanced, Next Generation or 5G networks, future generations, and beyond). The present disclosure relates, in particular but not exclusively, to random access procedures in an 'Ambient' Internet-of-Things (IoT) system, in the context of an A-IoT connectivity topology comprising at least one or more (potentially multiple) intermediate nodes; also known as A-IoT 'Topology 2'.

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

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

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

[0006] In the current 5G architecture, the base station structure may be split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0027] Typically in ambient IoT-based systems the user experienced data rate target is between 0.1 kbps and 5 kbps (with 1 kbps being a typical rate), and the design target of the maximum message size is approximately 1000 bits over both the 'device-to-reader' ('D2R') link, and the 'reader-to-device' ('R2D') link, which is in turn based on the maximum possible application layer packet size. Thus assuming a 1 kbps data rate, it takes 1s to transmit 1000 bits over the D2R and R2D links.

[0028] Currently it is envisaged that, for A-IoT, fewer physical channels will be supported, and UL and DL physical layer (layer-1 (L1)) communication will be simplified significantly. For example, there may be a single physical R2D channel (PRDCH) for R2D communication and a single physical D2R channel (PDRCH) for D2R communication. For R2D, the PRDCH will typically carry any higher-layer payload, and any L1 R2D control information (if defined). For D2R, the PDRCH will typically carry any higher-layer payload, and any L1 D2R control information (if defined). The PDRCH may also carry, for example, a response transmitted from the A-IoT device to a reader during a contention-based access procedure. The current view is that R2D transmission will typically comprise an R2D preamble to indicate a start time of the following PRDCH and possibly and chip length information. This R2D preamble is followed immediately by the PRDCH transmission (carrying any R2D traffic data and / or any control information). An R2D postamble is transmitted immediately after the PRDCH transmission to indicate an end of the PRDCH transmission. Similarly, for D2R transmissions, it is envisaged that a D2R preamble will be transmitted at the beginning of each D2R transmission, immediately before the PDRCH transmission, to indicate a start time of the PDRCH transmission. A D2R postamble may also be transmitted following the PDRCH transmission to indicate the end of the PDRCH transmission (and possibly provide a final timing correction to the A-IoT device reader). In the context of D2R communication, however, a D2R midamble may be inserted into (sent during) the PDRCH transmission, for facilitating chip-level timing tracking and channel / interference estimation (e.g., depending on the length of that PDRCH transmission).

[0029] Thus, as the R2D preamble is used to indicate the start of each R2D transmission, the R2D postamble implicitly indicates the Transport Block Size (TBS) of the PDRCH transmission by indicating the end of each R2D transmission. Accordingly, there is no need to restrict the timing of the R2D transmission to align with a conventional OFDM slot (e.g., an NR slot in a 5G system). Moreover, given the potential for a large number of small packets to be transmitted via A-IoT communications, flexible and efficient scheduling can be facilitated by not imposing a constraint that the boundary of the R2D transmission should align with that of the OFDM (e.g. NR) slots. Nevertheless, since the R2D transmission waveform is an OFDM-based waveform, the start of a R2D transmission may be aligned with the boundary of an OFDM (e.g., NR) symbol (including any cyclic prefix) when the R2D transmission co-exists with such transmissions) for in-band and guard-band operations.

[0030] Generally, for A-IoT communication, it is envisaged that multiple A-IoT logical channels for communication of upper layer data need not be supported. It is yet to be determined whether the concept of A-IoT logical channels is used (e.g., depending on final modelling issues). It is also envisaged that access stratum (AS) layer (above the PHY layer) RLC-like retransmission / repetition will not be supported for A-IoT. Nevertheless, this does not preclude the reader and device resending the payload again as a new transmission from the perspective of the MAC layer. It is yet to be determined how segmentation is to be handled (if needed).

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

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

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

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

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

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

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

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

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

[0040] When triggered by the R2D trigger message (A-IoT Msg0), the A-IoT device may send an initial device-to-reader (D2R) message ('A-IoT Msg1') carrying a corresponding identifier (e.g., a random ID generated by A-IoT device), and possibly other information, to the A-IoT device reader. The A-IoT device reader echoes the identifier received in the initial D2R message (A-IoT Msg1) back to the A-IoT device in an R2D response message ('A-IoT Msg2') that may include additional useful information where appropriate. The A-IoT device may then send a further D2R message ('A-IoT Msg3') including the A-IoT device's device identifier (ID) and / or any other higher layer data (depending on a higher layer request). It will be appreciated that the A-IoT device may consider contention resolution to be successful, if the received response message (A-IoT Msg2) includes the same random identifier that was sent by that A-IoT device in the initial D2R message (A-IoT Msg1). Hence the size of the random identifier needs to be sufficient for effective contention resolution purposes. A further R2D transmission ('A-IoT Msg4') may then be sent by the A-IoT device reader to the A-IoT device after the further D2R message (A-IoT Msg3) but does not always need to be sent. The further R2D transmission (A-IoT Msg4) may, for example, be sent to handle a transmission failure (e.g., a failure of A-IoT Msg3 due to any of a number of different reasons). It will be appreciated that the 'A-IoT Msg' terms (e.g., 'A-IoT Msg4') may or may not be used in practice.

[0041] Similarly, in an A-IoT 'two-step' random access procedure, like the RFID random access procedure, random access is triggered by the A-IoT device reader using an appropriate reader-to-device (R2D) trigger message ('A-IoT Msg0') in a manner that is analogous to the Query command of the RFID random access procedure.

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

[0043] Whilst the overall contention based A-IoT two-step and four-step random access procedures have been developed, however, there is still a need for further enhancement to those procedures, especially in the context of Topology 2 . For example, there is still a need to further develop A-IoT random access procedures that take account of how to appropriately control and / or configure one or more intermediate nodes (e.g., an intermediate UE) to act as an A-IoT device reader.

[0044] In more detail, there is still a need to further develop A-IoT random access procedures for topology 2 to allow the support of appropriate resource allocations to one or more intermediate nodes (e.g., an intermediate UE) in topology 2 when the intermediate nodes are acting as A-IoT device readers.

[0045] Additionally, appropriate adaptations of A-IoT random access procedures for topology 2 are needed to take account of different situations and / or connectivity states that one or more intermediate nodes - also referred to as assisting nodes - (e.g., an intermediate UE) in topology 2 may find themselves when they are acting as A-IoT device readers. For example, when one or more intermediate nodes (e.g., an intermediate UE) in topology 2 are acting as A-IoT device readers appropriate mechanisms may be needed to wake up the intermediate nodes if they are in an RRC inactive state or an RRC idle state.

[0046] Additionally, when one or more intermediate nodes (e.g., an intermediate UE) in topology 2 are acting as A-IoT device readers, appropriate mechanisms may be needed to deal with scenarios where an intermediate node does not have an RRC connection temporarily with another device (e.g., an A-IoT device and / or a RAN node, or the like) due to, for example, the occurrence of a handover (HO) event, or a radio link failure (RLF) event. Additionally, when one or more intermediate nodes (e.g., an intermediate UE) in topology 2 are acting as A-IoT device readers, appropriate mechanisms may be needed to deal with scenarios where an intermediate node is temporarily outside the coverage area of another device with which it intends to communicate (e.g., an A-IoT device and / or a RAN node, or the like).

[0047] Additionally, when two or more intermediate nodes (e.g., an intermediate UE) in topology 2 are acting as A-IoT device readers, appropriate mechanisms may be needed to deal with scenarios where a different intermediate node is acting as an A-IoT device reader for receiving communication via the D2R link (or 'Rx A-IoT device reader') than is acting as an A-IoT device reader for transmitting communication via the R2D link (or 'Tx A-IoT device reader').

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

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

[0050] The disclosure has a method performed by an intermediate device for relaying communication between a base station and a mobile device, the method comprising receiving, from the base station, a message for allocating at least one random access resource for communicating with the mobile device communicating with the mobile device using the at least one random access resource.

[0051] The disclosure has a method performed by a base station for communicating data to a mobile device via an intermediate device, the method comprising transmitting, to the intermediate device, a message for allocating at least one random access resource for the intermediate device in communicating with the mobile device, and wherein the at least one random access resource is used by the intermediate device for communicating with the mobile device.

[0052] The disclosure has an intermediate device for relaying communication between a base station and a mobile device, the intermediate device comprising means for receiving, from the base station, a message for allocating at least one random access resource for communicating with the mobile device means for communicating with the mobile device using the at least one random access resource.

[0053] The disclosure has a base station for communicating data to a mobile device via an intermediate device, the base station comprising means for transmitting, to the intermediate device, a message for allocating at least one random access resource for the intermediate device in communicating with the mobile device, and wherein the at least one random access resource is used by the intermediate device for communicating with the mobile device.

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

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

[0056] Fig. 1 illustrates schematically a mobile (cellular or wireless) communication system to which example embodiments of the disclosure may be applied;Fig. 2A illustrates schematically a first possible arrangement of a first connectivity topology (topology 1) that may be used in the communication system of Fig. 1;Fig. 2B illustrates schematically another possible arrangement of a first connectivity topology (topology 1) that may be used in the communication system of Fig. 1;Fig. 3A illustrates schematically a first possible arrangement second connectivity topology (topology 2) that may be used in the communication system of Fig. 1;Fig. 3B illustrates schematically another possible arrangement second connectivity topology (topology 2) that may be used in the communication system of Fig. 1;Fig. 4A illustrates schematically a first possible arrangement of a third connectivity topology (topology 3) that may be used in the communication system of Fig. 1;Fig. 4B illustrates schematically another possible arrangement of the third connectivity topology (topology 3) of Fig. 4A;Fig. 5 illustrates a simplified sequence diagram of an enhanced A-IoT initial RA and resource allocation procedure that may be implemented in the communication system of Fig. 1;Fig. 6A illustrates a simplified sequence diagram of an enhanced A-IoT initial RA and resource allocation procedure that may be implemented in the communication system of Fig. 1;Fig. 6B illustrates a simplified sequence diagram of an enhanced A-IoT initial RA and resource allocation procedure that may be implemented in the communication system of Fig. 1;Fig. 7A illustrates a simplified sequence diagram of yet another enhanced A-IoT initial RA and resource allocation procedure that may be implemented in the communication system of Fig. 1;Fig. 7B illustrates a simplified sequence diagram of yet another enhanced A-IoT initial RA and resource allocation procedure that may be implemented in the communication system of Fig. 1;Fig. 8 illustrates a simplified sequence diagram of an enhanced A-IoT procedure for handling a loss of RRC connection with an A-IoT device reader that may be implemented in the communication system of Fig. 1;Fig. 9 illustrates a simplified sequence diagram of an enhanced A-IoT procedure for handling a scenario in which an A-IoT device reader moves out-of-coverage that may be implemented in the communication system of Fig. 1.Fig. 10 is a simplified block schematic illustrating the main components of a user equipment that may be used in the communication system of Fig. 1;Fig. 11 is a simplified block schematic illustrating the main components of an ambient IoT device that may be used in the communication system of Fig. 1;Fig. 12 is a simplified block schematic illustrating the main components of a RAN node that may be used in the communication system of Fig. 1; andFig. 13 is a simplified block schematic illustrating the main components of an intermediate or assisting node that may be used in the communication system of Fig. 1.

[0057] <Overview> 　　An exemplary telecommunication system will now be described in general terms, by way of example only, with reference to Figs. 1 to 5.

[0058] Figs. 2A and 2B schematically illustrate a mobile ('cellular' or 'wireless') communication system (e.g., communication system 1) to which examples of the present disclosure are applicable.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0080] For example, each RAN node 5-1 is also configured for transmission of, and the A-IoT devices 3-1 are configured for the reception of, control information and data via a physical R2D channel (PRDCH) for R2D communication that will typically carry any higher-layer payload, and any L1 R2D control information (if defined). Similarly, each RAN node 5-1 is also configured for reception of, and the A-IoT devices 3-1 are configured for the transmission of, control information and data via a physical D2R channel (PDRCH) for D2R communication that will typically carry any higher-layer payload, and any L1 D2R control information (if defined).

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

[0082] Fig. 2A illustrates schematically a first possible arrangement of a first connectivity topology (topology 1) that may be used in the communication system 1.

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

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

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

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

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

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

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

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

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

[0092] Fig. 3A illustrates schematically a first possible arrangement of a second connectivity topology (topology 2) that may be used in the communication system 1.

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

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

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

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

[0097] That is to say, in a second (uplink) direction the intermediate node 5-2 is responsible for receiving a modulated backscattered (D2R) signal 20-3 from A-IoT device 3-1 (e.g., on a 'sidelink' or similar interface where the intermediate node 5-2 is a UE 3). Specifically, the uplink communication may comprise a modulated backscattered signal 20-3 from the A-IoT device 3-1 to the intermediate node 5-2 that is transmitted (e.g., on a 'sidelink' or similar interface where the intermediate node 5-2 is a UE 3) in using the unmodulated carrier signal 20-1 from the intermediate node 5-2. This modulated backscattered D2R signal 20-3 (or at least the information encoded in it), once received by the intermediate node 5-2, may be relayed / forwarded (transmitted) to the RAN node 5-1 in an uplink signal as part of the communication 20-4 between the intermediate node 5-2 and the RAN node 5-1. The modulated backscattered D2R signal 20-3 may be processed before being relayed by the intermediate node 5-2 to the RAN node 5-1. For example, the modulated D2R backscattered D2R signal 20-3 may be processed by the intermediate node 5-2 to extract information encoded in the modulated D2R 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 D2R 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.

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

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

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

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

[0102] Similarly to in Fig. 3A, the intermediate node 5-2 may then send / relay the modulated backscattered D2R signal 20-3 it receives from the A-IoT device 3-1 (or at least the information encoded in it), to the RAN node 5-1 in an uplink signal as part of the communication 20-4 between the intermediate node 5-2 and the RAN node 5-1. The modulated backscattered D2R signal 20-3 may be processed before being relayed by the intermediate node 5-2 to the RAN node 5-1. For example, the modulated backscattered D2R signal 20-3 may be processed by the intermediate node 5-2 to extract information encoded in the modulated backscattered D2R 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 D2R 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.

[0103] It will be appreciated that in the arrangement of Figs. 3A and Fig. 3B, 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.

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

[0105] Topology 2 may also be deployed for indoor scenarios with a type 1, 2a, and / or 2b A-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.

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

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

[0108] Figs. 4A and 4B illustrate schematically a third connectivity topology (topology 3) of a mobile (cellular or wireless) communication system.

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

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

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

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

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

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

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

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

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

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

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

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

[0121] <Configuring, and Communicating via, an Intermediate Node for A-IoT Topology 2> 　　Beneficially, the RAN node 5-1, intermediate node 5-2 (e.g., intermediate UE 3-2) acting as an A-IoT device reader, and the A-IoT device 3-1 of the communication system 1 are mutually configured for implementing one or more mechanisms / techniques for supporting configuration of, and communication via, an intermediate node 5-2 (e.g., intermediate UE 3-2) acting as the A-IoT device reader and the A-IoT device 3-1.

[0122] A number of these possible mechanisms / techniques that may be implemented in the communication system 1 will now be briefly introduced, by way of example only, before a more detailed description of the various mechanisms / techniques is provided.

[0123] It will be appreciated that the communication system 1 need not support all the possible mechanisms / techniques to achieve a technical benefit. For example, the communication system 1 may only support a single one of the mechanisms / techniques described. Nevertheless, the various mechanisms / techniques described are not mutually exclusive and so the communication system 1 may support all, or a subset of the various mechanisms / techniques described to provide a commensurate benefit. For example, some of the mechanisms / techniques may supported as different options that may be used by the A-IoT device reader and the A-IoT device 3-1 at different times in the communication system 1 depending on the prevailing conditions.

[0124] For example, as described in more detail later, the communication system 1 may be configured to support one or more procedures that allow for efficient configuration / allocation of resources to an intermediate node 5-2, or intermediate UE 3-2, that acts as an A-IoT device reader. The one or more procedures may, for example, comprise one or more procedures that allow for efficient configuration / allocation of resources to intermediate nodes 5-2, or intermediate UEs 3-2, that act as A-IoT device readers in a scenario in which two intermediate nodes 5-2 (or intermediate UEs 3-2) provide A-IoT device reader functions for a given A-IoT device 3-1. For example a scenario in which one intermediate node 5-2 acts as a transmitter A-IoT device reader that transmits R2D signals to the A-IoT device 3-1, and one intermediate node 5-2 acts as a receiver A-IoT device reader that receives D2R signals from the A-IoT device 3-1.

[0125] Beneficially, as described in more detail later, the communication system 1 may additionally (or alternatively) support one or more procedures for handling a loss of RRC connection between the RAN node 5-1 and an intermediate node 5-2 (e.g., intermediate UE 3-2) acting as an A-IoT device reader; and / or for handling a scenario in which one or more intermediate nodes 5-2 (e.g., intermediate UEs 3-2) acting as A-IoT device readers are temporarily outside the coverage area of the RAN node 5-1.

[0126] Several enhancements to an A-IoT access procedure between one or more A-IoT device readers and one or more A-IoT devices 3-1 in topology 2 will now be described in further detail with respect to Figs. 5 to 9.

[0127] <Enhanced Initial RA Procedures for A-IoT> <Initial RA and Resource Allocation Procedure for A-IoT> 　　Fig. 5 illustrates a simplified sequence diagram of an enhanced A-IoT initial RA and resource allocation procedure that may be implemented in the communication system 1.

[0128] As shown in Fig. 5, there is provided a core network (CN) 7 (e.g., 5GC) in communication with a RAN node 5-1 (e.g., a base station, or the like). There is also provided an intermediate / assisting node 5-2 that operates as an A-IoT device reader (for example an intermediate / assisting UE 3, or the like). Whilst the following description refers to the A-IoT device reader specifically as an intermediate UE 3-2, this does not preclude the A-IoT device reader being any other appropriate intermediate device capable to acting as an A-IoT device reader.

[0129] To enable the A-IoT device reader (e.g., intermediate UE 3-2) to communicate with the A-IoT device 3-1, the CN 7 triggers an enhanced initial RA and resource allocation procedure such as that shown in Fig. 5.

[0130] It will be appreciated that in the procedure of Fig. 5, the intermediate / assisting node 5-2 will typically be in an RRC connected state prior to being able to communicate with the RAN node 5-1 and act as an A-IoT device reader for the A-IoT device 3-1. For example, where the intermediate / assisting node 5-2 is an intermediate UE 3-2, that intermediate UE 3-2 will typically enter an RRC connected state (like a typical UE 3) prior to being able to act as an A-IoT device reader for the A-IoT device 3-1.

[0131] At step S502, the CN 7 sends an inventory request (e.g., an inventory request message, or the like) to the RAN node 5-1 over an appropriate interface (e.g., via the Next Generation Application Protocol (NGAP) on the N2 reference point between the RAN node 5-1 and the AMF 10-1 of the CN 7). The inventory request message sent by the CN 7 to the RAN node 5-1 may include an appropriate indication of the type (or types) of A-IoT devices 3-1 that the CN 7 wishes to query.

[0132] For example, the inventory request message may include an appropriate indication of a special category of A-IoT device 3-1 that the CN 7 wishes to query, and which may be reached via a specific intermediate / assisting node 5-2 acting as an A-IoT device reader (e.g., via an intermediate UE 3-2). In this scenario, prior to the CN 7 sending the inventory request message to the RAN node 5-1, an association between the specific A-IoT device reader (or readers) and one or more A-IoT devices 3-1 that can be reached by it may be (pre)defined via an appropriate registration or subscription procedure, or the like. In this way the CN 7 may be aware of which specific A-IoT device reader serves which A-IoT devices 3-1 prior to it sending inventory request messages to the RAN node 5-1.

[0133] Where an association between a specific intermediate / assisting node 5-2 acting as an A-IoT device reader and one or more A-IoT devices 3-1 is (pre)defined via an appropriate registration procedure, the inventory request message sent at step S502, may include an appropriate indication (or indications) of A-IoT devices 3-1, and / or A-IoT device types, and / or A-IoT device groups that the CN 7 wishes to communicate with, and their respective associated A-IoT device reader (or readers). In this way the inventory request message sent at step S502 indicates, to the RAN node 5-1, which A-IoT devices 3-1 are targeted by the CN 7, and via which A-IoT device reader (or readers) those A-IoT devices 3-1 can be reached.

[0134] It will be appreciated that in certain circumstances the A-IoT device reader (or readers) associated with the A-IoT devices 3-1 with which the CN 7 wishes to communicate may be in an RRC idle state at the time that the RAN node 5-1 receives the inventory request message. For example, where the intermediate / assisting node 5-2 acting as the A-IoT device reader is an intermediate UE 3-2, sometime after establishing an RRC connection with the RAN node 5-1, the intermediate UE 3-2 may enter an RRC idle / inactive state / mode until the intermediate UE 3-2 is ready to (re)enter an RRC connected state (e.g., by transmitting a request to the RAN node 5-1 to (re)establish / resume the RRC connection). The decision to transmit such a request to the RAN node 5-1 may, for example, be in response to the intermediate UE 3-2 receiving a paging message, or the like, to indicate that a device in the network wishes to send information to, or receive information from, the intermediate UE 3-2. In this scenario, the inventory request message sent at step S502 (or another independent message) may be used to initiate a paging procedure by the RAN node 5-1 to move the A-IoT device reader (e.g., an intermediate UE 3-2) from an RRC idle state / mode to an RRC connected state / mode.

[0135] For example, having received the inventory request message sent at step S502, the RAN node 5-1 may send, at step S504, an appropriate paging message to the intermediate / assisting node 5-2 acting as the A-IoT device reader to trigger the A-IoT device reader to switch from an RRC idle state to an RRC connected state. For example, the RAN node 5-1 may send a paging message at step S504 to the A-IoT device reader to 'wake-up' the device reader based on the information contained in the inventory request message it received from the CN 7 at step S502 (e.g., an indication of the A-IoT devices 3-1, and / or A-IoT device types, and / or A-IoT device groups that the CN 7 wishes to communicate with, and their respective associated A-IoT device reader). That paging message sent at step S504 may in turn trigger the A-IoT device reader to perform an appropriate RRC (re)establishment procedure towards the RAN node 5-1 at step S506.

[0136] Alternatively, rather than an association between a specific intermediate / assisting node 5-2 acting as the A-IoT device reader and one or more A-IoT devices 3-1 being (pre)defined and indicated in the inventory request message sent at step S502, the RAN node 5-1, having received the inventory request message sent at step S502, may perform reader selection and assign a specific intermediate / assisting node 5-2 acting as the A-IoT device reader for use in communicating with the one or more A-IoT devices 3-1 indicated in the inventory request message. In this scenario, the RAN node 5-1 may assign a specific A-IoT device reader based on prior knowledge of a capability of an A-IoT device reader (or readers) to which it was already connected and which is served by the RAN node 5-1.

[0137] For example, an intermediate / assisting node 5-2 (e.g., an intermediate UE 3-2), already connected to the RAN node 5-1 may have already reported (e.g., during RA, or the like), or may periodically report via appropriate messaging, to the RAN node 5-1, its capability to act as an A-IoT device reader for specific A-IoT devices 3-1 when connected to the RAN node 5-1. Based on that prior knowledge (or periodically reported knowledge), the RAN node 5-1 may assign a specific intermediate / assisting node 5-2 (e.g., an intermediate UE 3-2) to act as the A-IoT device reader for the A-IoT devices 3-1 indicated in the inventory request message it received at step S502.

[0138] At step S504, as alluded to above, if the intermediate / assisting node 5-2 acting as the A-IoT device reader (e.g., an intermediate UE 3-2) indicated in the inventory request message, or selected / assigned by the RAN node 5-1 upon receiving the inventory request message sent, is in RRC Idle state or RRC Inactive state, the RAN node 5-1 sends a paging message to the indicated / assigned intermediate UE 3-2.

[0139] That paging message may be sent to the indicated / assigned intermediate / assisting node 5-2 (e.g., intermediate UE 3-2) over an appropriate interface, and may include, amongst other things, a specific 'paging cause' value to indicate to the indicated / assigned intermediate / assisting node 5-2 (e.g., intermediate UE 3-2) that the paging it is receiving from the RAN node 5-1 is a request for it to act as an A-IoT device reader (for a specific indicated set of A-IoT devices 3-1) (e.g., A-IoT devices 3-1, and / or A-IoT device types, and / or A-IoT device groups as indicated in the inventory request message sent at step S502).

[0140] Having received the paging message at step S504, at step S506, as alluded to above, the indicated / assigned intermediate / assisting node 5-2 (e.g., intermediate UE 3-2) may initiate an appropriate RA procedure with the RAN node 5-1 to (re)establish an RRC connection with the RAN node 5-1, enabling it to act as an A-IoT device reader for the A-IoT devices 3-1 indicated in the inventory request message. That RA procedure may be any appropriate RA procedure known to the skilled person. By way of example only, the RA procedure may be a 2-step, a 3-step or a 4-step (A-IoT specific) RACH procedure such as those described above.

[0141] During the RA procedure, one or more of the messages transmitted by the RAN node 5-1 to the intermediate / assisting node 5-2 (e.g., A-IoT Msg2 / Msg4 in a 4-step A-IoT RACH procedure, A-IoT Msg2 / MsgB in a 2-step A-IoT RACH procedure, or the like) may include a cause value to specify to the indicated / assigned, intermediate / assisting node 5-2 (e.g., intermediate UE 3-2) a cause for the RRC (re)connection request. For example, the cause value may indicate to the indicated / assigned intermediate / assisting node 5-2 (e.g., intermediate UE 3-2) that it is to act as an A-IoT device reader for a specific indicated set of A-IoT devices 3-1 (e.g., A-IoT devices 3-1, and / or A-IoT device types, and / or A-IoT device groups as indicated in the inventory request message sent at step S502).

[0142] At step S506, (which may come either immediately after step S502 if RRC connection (re)establishment is not needed, or after step S506 where RRC connection (re)establishment was required), the RAN node 5-1 performs resource allocation for the intermediate / assisting node 5-2 acting as the A-IoT device reader (e.g., intermediate UE 3-2), which may include the resources for: i) a random access procedure between the A-IoT device reader and A-IoT devices 3-1; and ii) data transmission (for R2D and / or D2R direction) after completion of a successful random access procedure with the A-IoT device reader.

[0143] It will be appreciated that the RAN node 5-1 that performs resource allocation for the A-IoT device reader (e.g., intermediate UE 3-2) is assumed to be in control of the resources that can be used for the communication between the A-IoT devices 3-1 and the intermediate / assisting node 5-2 acting as the A-IoT device reader (e.g., intermediate UE 3-2). Those resources may also be subject to dedicated signalling-based allocation from the RAN node 5-1 to the A-IoT device reader (e.g., intermediate UE 3-2). Alternatively, those resources may be subject to semi-static resource allocation and / or dynamic resource allocation.

[0144] The resources that can be used for the purposes of random access procedures between the intermediate / assisting node 5-2 acting as the A-IoT device reader (e.g., intermediate UE 3-2) and A-IoT devices 3-1 may, for example, form part of a shared resource pool, and may be shared by multiple A-IoT devices 3-1 that may access that intermediate / assisting node 5-2 (e.g., intermediate UE 3-2) as an A-IoT device reader. Those resources may, for example, be mapped to random access occasions that the intermediate / assisting node 5-2 acting as the A-IoT device reader can indicate to the respective A-IoT devices 3-1 that it can communicate with in an initial triggering message (or messages) sent to those respective A-IoT devices 3-1.

[0145] The resources that can be used for the purposes of A-IoT device data transmission between the intermediate / assisting node 5-2 acting as the A-IoT device reader (e.g., intermediate UE 3-2) and A-IoT devices 3-1 may, for example, be dedicated resources, with different sets of dedicated resources being assigned for each respective A-IoT device 3-1 with which the A-IoT device reader can communicate. In this case, the RAN node 5-1 may need to allocate a dedicated resource (or resources) for each A-IoT device 3-1.

[0146] Alternatively, resources that can be used for the purposes of A-IoT device data transmission between the intermediate / assisting node 5-2 acting as the A-IoT device reader (e.g., intermediate UE 3-2) and A-IoT devices 3-1 may, for example, form part of another shared resource pool assigned by the RAN node 5-1. In this case, the A-IoT device reader (e.g., intermediate UE 3-2) may allocate a specific resource (or resources) to a specific A-IoT device 3-1 based on the resources available within the shared resource pool for A-IoT data transmissions at the time that the A-IoT device 3-1 successfully accesses the A-IoT device reader (e.g., intermediate UE 3-2).

[0147] In other words, the resources in the shared resource pool that can be used for the purposes of A-IoT device data transmission between the A-IoT device reader (e.g., intermediate UE 3-2) and A-IoT devices 3-1 may be allocated to A-IoT devices 3-1 by the RAN node 5-1 on a 'first-come-first-served' basis.

[0148] It will be appreciated that although the shared resource pool for random access procedures and the shared resource pool data transmission for A-IoT devices 3-1 described above are describe as two separate and distinct shared resource pools, in the scenario where the random access procedure being performed between the A-IoT device reader and the A-IoT devices 3-1 is contention free, the two abovementioned shared resource pools may be combined into a single resource pool.

[0149] It will be appreciated that the combining of the two abovementioned shared resource pools is possible when the access procedure (or procedures) are contention free, since the A-IoT devices 3-1 can generate / perform a data transmission in its very first message to the A-IoT device reader.

[0150] As alluded to above, resource allocation by the RAN node 5-1 to assign resources for use by the A-IoT devices 3-1 in communication with the A-IoT device reader may typically be performed via an appropriate dedicated signalling-based allocation procedure. Nevertheless, those resources may instead be subject to semi-static resource allocation procedures and / or dynamic resource allocation procedures.

[0151] In the case where the resource allocation by the RAN node 5-1 to assign resources for use by the A-IoT devices 3-1 is subject to semi-static resource allocation procedures, the resources for both random access procedures between the intermediate / assisting node 5-2 acting as the A-IoT device reader and A-IoT devices 3-1, and data transmission for A-IoT devices 3-1 after completion of a successful random access procedure with the A-IoT device reader can be allocated at step S508.

[0152] Alternatively, in the case where the resource allocation by the RAN node 5-1 to assign resources for use by the A-IoT devices 3-1 is subject to semi-static resource allocation procedures, the resource for random access procedures between the intermediate / assisting node 5-2 acting as the A-IoT device reader and A-IoT devices 3-1 may be allocated at step S508, while the resources for use by the A-IoT devices 3-1 in data transmission may be allocated at a later step (e.g., during the initial access procedure at S514).

[0153] In the case where the resource allocation by the RAN node 5-1 to assign resources for use by the A-IoT devices 3-1 is subject to dynamic resource allocation procedures, the resource for random access procedures between the A-IoT device reader and A-IoT devices 3-1 may be allocated at step S508, while the resources for use by the A-IoT devices 3-1 in data transmission may be allocated at a later step (e.g., during the initial access procedure at step S514).

[0154] For example, during the initial access procedure at step S514, the A-IoT device reader (e.g., intermediate UE 3-2) may send an appropriate message / indication to the RAN node 5-1 to inform the RAN node 5-1 that it has received a response message (e.g., an 'A-IoT Msg1' of a 4-step A-IoT RACH procedure) from an A-IoT device 3-1 with which it is performing the random access procedure. In response to that indication, the RAN node 5-1 may send an appropriate command message to the A-IoT device reader (e.g., intermediate UE 3-2) to command that it sends another message (e.g., an A-IoT 'Msg2' in a 4-step A-IoT RACH procedure) to the A-IoT device 3-1 to indicate dynamically allocated resources to the A-IoT device 3-1 for use in data transmissions, and the like.

[0155] In all of the scenarios described above where the resources for random access procedures and / or data transmission are assigned from one or more shared resource pools, the intermediate / assisting node 5-2 acting as the A-IoT device reader (e.g., intermediate UE 3-2) may be configured to send appropriate messages / indications to the RAN node 5-1 to indicate when the A-IoT device reader has started using assigned resources form the one or more shared resource pools according to the status of the resources used at A-IoT air interface. Similarly, the A-IoT device reader (e.g., intermediate UE 3-2) may also be configured to send appropriate messages / indications to the RAN node 5-1 to indicate when the A-IoT device reader has stopped using assigned resources form the one or more shared resource pools according to the status of the resources used at A-IoT air interface. In this scenario, the message or message may, for example, be Uu notification messages, or the like.

[0156] Alternatively, where the resources for random access procedures and / or data transmission are assigned from one or more shared resource pools, the RAN node 5-1 may be configured to assume that the A-IoT device 3-1 to which the RAN node 5-1 has assigned resources from the one or more shared resource pools will begin to be used by the A-IoT device 3-1 as soon as they are assigned. In this case, the intermediate / assisting node 5-2 acting as the A-IoT device reader (e.g., intermediate UE 3-2) may still be configured to send appropriate messages / indications to the RAN node 5-1 to indicate when the A-IoT device reader has stopped using assigned resources form the one or more shared resource pools according to the status of the resources used at A-IoT air interface.

[0157] Based on those messages indicating when the A-IoT device reader has started / stopped using assigned resources form the one or more shared resource pools, a resource (or resources) from the one or more shared resource pools may be recycled by the RAN node 5-1 and subject to subsequent allocation to another device in the communication system 1 (e.g., another A-IoT device reader, or the like). It will be appreciated that reusing resources in this manner may improve the overall efficiency of resource allocation in the communication system 1.

[0158] At step S510, the RAN node 5-1 may send an appropriate configuration message (e.g., an RRC (Re)configuration message, or any other type of RRC message), to the A-IoT device reader to (re)configure A-IoT device reader (e.g., the intermediate UE 3-2), together with an indication of the resources allocated by the RAN node 5-1 at step S508. The A-IoT device reader may respond (not shown) with an appropriate configuration response message (e.g., an RRCReconfigurationComplete message, or the like) to acknowledge the resource configuration message sent at step S510.

[0159] At In step S512, the intermediate / assisting node 5-2 acting as the A-IoT device reader (e.g., intermediate UE 3-2) transmits an appropriate triggering message (e.g., an initial triggering message / A-IoT 'Msg0', or the like) to the A-IoT device 3-1 to trigger an appropriate initial access procedure (e.g., an adapted RACH procedure for A-IoT devices 3-1). That initial triggering message may be sent to the A-IoT device 3-1 using the resources allocated for that purpose by the RAN node 5-1 and indicated to the A-IoT device 3-1 in the resource configuration sent at step S510. The initial triggering message may also include random access resources allocated by the RAN node 5-1 for use by the A-IoT device 3-1 in performing a random access procedure with the A-IoT device reader as described above.

[0160] At step S514, the A-IoT device 3-1, having received the initial triggering message at step S512, performs an initial access procedure to access the intermediate / assisting node 5-2 acting as the A-IoT device reader (e.g., intermediate UE 3-2). The initial access procedure may be performed between the A-IoT device 3-1 and the A-IoT device reader using resources allocated to them for that purpose by the RAN node 5-1 as described above.

[0161] As part of that initial access procedure triggered by the intermediate / assisting node 5-2 acting as the A-IoT device reader, a first message sent by the A-IoT device 3-1 to the A-IoT device reader to 'request' initial access (e.g., an A-IoT 'Msg1' or the like) may include an appropriate indication of the identity of the A-IoT device reader to which the A-IoT device 3-1 is attempting to gain access, thereby ensuring that the correct A-IoT device reader in the communication system 1 responds to the first message sent by the A-IoT device 3-1 requesting initial access.

[0162] Following completion of the initial access procedure at step S514, the intermediate / assisting node 5-2 acting as the A-IoT device reader may indicate to the RAN node 5-1, via an appropriate message, the successful access of one or a set of A-IoT devices 3-1 (via e.g., device IDs). In response to that indication of the successful access of one or a set of A-IoT devices 3-1, the RAN node 5-1 may configure the A-IoT device reader with resources for use in data transmissions as a follow-up to the A-IoT device initial access procedure. Alternatively, the resources for use in data transmission may be allocated to the A-IoT device reader at step S508 as previously described.

[0163] At step S516, the A-IoT device 3-1 sends data to the intermediate / assisting node 5-2 acting as the A-IoT device reader using the resources assigned for data transmission purposes and which have been indicated to the A-IoT device reader as previously described. The A-IoT device reader may then aggregate the data it receives from several A-IoT devices 3-1 with which it is in communication or aggregate the data from the same A-IoT device 3-1 that it receives over time before forwarding that data to the RAN node 5-1 in an appropriate UL transmission.

[0164] It will be appreciated that in the scenario where the A-IoT device reader aggregates data it receives from several A-IoT devices 3-1, or where it aggregates data it receives over time, before forwarding that data on to the RAN node 5-1, the data, as it is received, may temporarily be stored in a memory of the A-IoT device reader (step S517).

[0165] At step S518, the intermediate / assisting node 5-2 acting as the A-IoT device reader (e.g., intermediate UE 3-2) may use an appropriate container (e.g., an RRC container) to contain / host the data it received from the A-IoT device (or devices) 3-1 for forwarding / transmission to the RAN node 5-1. Once contained within the appropriate container, the data is sent to the RAN node 5-1 via an appropriate UL transmission message. That appropriate UL transmission message to the RAN node 5-1 may also include, for example, the device ID of the A-IoT device (or devices) 3-1 from which the data originates, and optionally the purpose of the data being transmitted.

[0166] At step S520, the RAN node 5-1 may send an appropriate indication / message (e.g., a specific NGAP message) to the CN 7 to acknowledge the inventory request message sent to the RAN node at the beginning of the procedure at step S502. That indication / message may also include the data that the RAN node 5-1 received from the A-IoT device (or devices) 3-1 at step S518.

[0167] Although the data transmission from the A-IoT device (or devices) 3-1 to the CN 7 is described above as involving the packaging and transmission / forwarding of the data in two steps (namely steps S518 and S520), it will nevertheless be appreciated that steps S518 and S520 may be combined into a single step. In this scenario, the data may be transmitted by the A-IoT device reader to the CN 7 via upper layer signalling-based data transmissions between the A-IoT device reader and the CN 7. This being the case, it will be appreciated that transmission carrying the data (or the container holding the data on the transmission) may be transparent to the RAN node 5-1.

[0168] <Initial RA and Resource Allocation Procedure for A-IoT with Multiple Intermediate Nodes> 　　Figs. 6A and 6B illustrate a simplified sequence diagram of another enhanced A-IoT initial RA and resource allocation procedure that may be performed in the communication system 1.

[0169] As shown in Figs. 6A and 6B, there is provided a core network (CN) 7 (e.g., 5GC) in communication with a RAN node 5-1 (e.g., a base station, or the like). There is also provided a plurality of intermediate / assisting nodes 5-21, 5-22 (for example intermediate / assisting UEs 3-2, or the like) that each operate as an A-IoT device reader. That intermediate / assisting nodes 5-21, 5-22 include a receiver (Rx) intermediate / assisting node 5-21 that operates as an Rx A-IoT device reader and a transmitter (Tx) intermediate / assisting node 5-22 that operates as a Tx A-IoT device reader.

[0170] Whilst the following description refers to the A-IoT device readers specifically as intermediate UEs 3-2 this does not preclude the A-IoT device readers being any other appropriate intermediate devices capable of acting as an A-IoT device reader.

[0171] To enable the Tx and Rx A-IoT device readers (e.g., intermediate UEs 3-2) to communicate with the A-IoT device 3-1, the CN 7 triggers an enhanced initial RA and resource allocation procedure such as that shown in Figs 6A and 6B (hereafter referred collectively as Figs. 6A, 6B where appropriate).

[0172] It will be appreciated that in the procedure of Figs. 6A and 6B, the intermediate / assisting nodes 5-22, 5-23 (e.g., the receiver (Rx) intermediate / assisting node 5-21 that operates as an Rx A-IoT device reader and a transmitter (Tx) intermediate / assisting node 5-22 that operates as a Tx A-IoT device reader) will typically be in an RRC connected state prior to being able to communicate with the RAN node 5-1 and act as A-IoT device readers for the A-IoT device 3-1. For example, where the Tx and Rx A-IoT device readers are intermediate UEs 3-2, those intermediate UEs 3-2 will typically enter RRC connected state (like a typical UE 3) prior to being able to act as A-IoT device readers for the A-IoT device 3-1.

[0173] At step S602, the CN 7 sends an inventory request (e.g., an inventory request message, or the like) to the RAN node 5-1 over an appropriate interface (e.g., via the Next Generation Application Protocol (NGAP) on the N2 reference point between the RAN node 5-1 and the AMF 10-1 of the CN 7). The inventory request message sent by the CN 7 to the RAN node 5-1 may include an appropriate indication of the type (or types) of A-IoT devices 3-1 that the CN 7 wishes to query.

[0174] For example, the inventory request message may include an appropriate indication of a special category of A-IoT device 3-1 that the CN 7 wishes to query, and which may be reached via a specific intermediate / assisting node 5-21 acting as a Tx A-IoT device reader (e.g., via an intermediate UE 3-2) and / or a specific intermediate / assisting node 5-22 acting as an Rx A-IoT device reader (e.g., via an intermediate UE 3-2).

[0175] In this scenario, prior to the CN 7 sending the inventory request message to the RAN node 5-1, an association between the specific Tx A-IoT device reader and / or the specific Rx A-IoT device reader, and one or more A-IoT devices 3-1 that can be reached by them may be (pre)defined via an appropriate registration or subscription procedure, or the like. In this way the CN 7 may be aware of which specific Tx and / or Rx A-IoT device readers serve which A-IoT devices 3-1 prior to the CN 7 sending inventory request messages to the RAN node 5-1.

[0176] Where an association between a specific intermediate / assisting node 5-21 acting as a Tx A-IoT device reader, a specific intermediate / assisting node 5-22 acting as an Rx A-IoT device reader, and one or more A-IoT devices 3-1 is (pre)defined via an appropriate registration procedure, the inventory request message sent at step S602, may include an appropriate indication (or indications) of A-IoT devices 3-1, and / or A-IoT device types, and / or A-IoT device groups that the CN 7 wishes to communicate with, and their respective associated Tx and / or Rx A-IoT device readers. In this way the inventory request message sent at step S602 indicates, to the RAN node 5-1, which A-IoT devices 3-1 are targeted by the CN 7, and via which Tx and / or Rx A-IoT device readers those A-IoT devices 3-1 can be reached.

[0177] It will be appreciated that in certain circumstances the Tx and / or Rx A-IoT device readers associated with the A-IoT devices 3-1 with which the CN 7 wishes to communicate may be in an RRC Idle or RRC Inactive state at the time that the RAN node 5-1 receives the inventory request message. For example, where the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader and / or the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader are intermediate UEs 3-2 sometime after establishing an RRC connection with the RAN node 5-1, those intermediate UEs 3-2 may enter an RRC idle / inactive state / mode until the intermediate UEs 3-2 are ready to (re)enter an RRC connected state (e.g., by transmitting a request to the RAN node 5-1 to (re)establish / resume the RRC connection). The decision to transmit such a request to the RAN node 5-1 may, for example, be in response to the intermediate UEs 3-2 receiving a paging message, or the like, to indicate that a device in the network wishes to send information to, or receive information from, the intermediate UEs 3-2. In this scenario, the inventory request message sent at step S602 (or another independent message) may be used to initiate a paging procedure by the RAN node 5-1 to move the Tx and / or Rx A-IoT device readers (e.g., intermediate UEs 3-2) from an RRC Idle or RRC Inactive state / mode to an RRC connected state / mode.

[0178] For example, having received the inventory request message sent at step S602, the RAN node 5-1 may send, at step S604a, an appropriate paging message to the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader to trigger the Tx A-IoT device reader to switch from an RRC idle state to an RRC connected state. Similarly, having received the inventory request message sent at step S602, the RAN node 5-1 may send, at step S604b, an appropriate paging message to the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader to trigger the Rx A-IoT device reader to switch from an RRC Idle or RRC Inactive state to an RRC connected state.

[0179] In more detail, the RAN node 5-1 may send a paging message at steps S604a and S604b to the Tx and Rx A-IoT device readers respectively to 'wake-up' those device readers based on the information contained in the inventory request message it received from the CN 7 at step S602 (e.g., an indication of the A-IoT devices 3-1, and / or A-IoT device types, and / or A-IoT device groups that the CN 7 wishes to communicate with, and their respective associated Tx and / or Rx A-IoT device readers). That paging message sent at steps S604a and S604b may in turn trigger the Tx and / or Rx A-IoT device readers and the RAN node 5-1 to perform an appropriate RRC (re-)establishment procedure at steps S606a and S606b respectively.

[0180] Alternatively, rather than an association between a specific intermediate / assisting node 5-21 acting as the Tx A-IoT device reader and / or a specific intermediate / assisting node 5-22 acting as the Rx A-IoT device reader, and one or more A-IoT devices 3-1 being (pre)defined and indicated in the inventory request message sent at step S602, the RAN node 5-1, having received the inventory request message sent at step S602, may perform Tx and / or RX A-IoT device reader selection and assign a specific intermediate / assisting node 5-21 to act as the Tx A-IoT device reader and a specific intermediate / assisting node 5-22 to act as the Rx A-IoT device reader for use in communicating with the one or more A-IoT devices 3-1 indicated in the inventory request message. In this scenario, the RAN node 5-1 may assign specific Tx and / or Rx A-IoT device readers based on prior knowledge of a capability of the Tx and / or Rx A-IoT device readers to which it is already connected, and which serve the RAN node 5-1.

[0181] For example, intermediate UEs 3-2, already connected to the RAN node 5-1 may have already reported (e.g., during RA, or the like), or may periodically report via appropriate messaging, to the RAN node 5-1, their capability to act as Tx and an Rx A-IoT device reader respectively for specific A-IoT devices 3-1 when connected to the RAN node 5-1. Based on that prior knowledge (or periodically reported knowledge), the RAN node 5-1 may assign specific intermediate UEs 3-2 to act as the Tx and / or Rx A-IoT device reader for the A-IoT devices 3-1 indicated in the inventory request message it received at step S602.

[0182] At step S604a. as alluded to above, if the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader (e.g., an intermediate UE 3-2) indicated in the inventory request message or selected / assigned by the RAN node 5-1 upon receiving the inventory request message sent, is in RRC Idle or RRC Inactive state, the RAN node 5-1 sends a paging message to the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader assigned by the RAN node 5-1.

[0183] Similarly at step S604b, as alluded to above, if the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader (e.g., an intermediate UE 3-2) indicated in the inventory request message or selected / assigned by the RAN node 5-1 upon receiving the inventory request message sent, is in RRC Idle or RRC Inactive state, the RAN node 5-1 sends a paging message to the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader assigned by the RAN node 5-1.

[0184] Those paging messages sent at steps S604a and S604b may be sent to the indicated / assigned intermediate / assisting nodes 5-21, 5-22 respectively over an appropriate interface, and may each include, amongst other things, a specific 'paging cause' value to indicate to the indicated / assigned intermediate / assisting nodes 5-21, 5-22 that the paging they are receiving from the RAN node 5-1 is a request for it to act as a Tx and / or Rx A-IoT device reader respectively for a specific indicated set of A-IoT devices 3-1 (e.g., A-IoT devices 3-1, and / or A-IoT device types, and / or A-IoT device groups as indicated in the inventory request message sent at step S602).

[0185] Having received the paging message at step S604a, at step S606a, as alluded to above, the indicated / assigned intermediate / assisting node 5-21 that is to act as the Tx A-IoT device reader may initiate an appropriate RA procedure with the RAN node 5-1 to (re)establish an RRC connection with the RAN node 5-1, enabling it to act as a Tx A-IoT device reader for the A-IoT devices 3-1 indicated in the inventory request message. That RA procedure may be any appropriate RA procedure known to the skilled person. By way of example only, the RA procedure may be a 2-step, 3-step or a 4-step (A-IoT specific) RACH procedure such as those described above.

[0186] Similarly, having received the paging message at step S604b, at step S606b, as alluded to above, the indicated / assigned intermediate / assisting node 5-22 that is to act as the Rx A-IoT device reader may initiate an appropriate RA procedure with the RAN node 5-1 to (re)establish an RRC connection with the RAN node 5-1, enabling it to act as a Rx A-IoT device reader for the A-IoT devices 3-1 indicated in the inventory request message. That RA procedure may be any appropriate RA procedure known to the skilled person. By way of example only, the RA procedure may be a 2-step, 3-step or a 4-step (A-IoT specific) RACH procedure such as those described above.

[0187] During those RRC Connection (Re)establishment procedures of steps S606a and S606b one or more of the messages transmitted by the RAN node 5-1 to the intermediate / assisting node 5-21 and the intermediate / assisting node 5-22 (e.g., A-IoT Msg2 / Msg4 in a 4-step A-IoT RACH procedure, A-IoT Msg2 / MsgB in a 2-step A-IoT RACH procedure, or the like) may include a cause value to specify to the indicated / assigned intermediate / assisting node 5-21 and the intermediate / assisting node 5-22 a cause for the RRC (re)connection request. For example, the cause value may indicate to the indicated / assigned intermediate / assisting node 5-21 and the intermediate / assisting node 5-22 that they are to act as Tx and / or Rx A-IoT device readers respectively (for a specific indicated set of A-IoT devices 3-1) (e.g., A-IoT devices 3-1, and / or A-IoT device types, and / or A-IoT device groups as indicated in the inventory request message sent at step S602).

[0188] At step S606 (which may come either immediately after step S602 if RRC connection (re)establishment is not needed, or after step S606 where RRC connection (re)establishment was required), the RAN node 5-1 performs resource allocation for the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader and the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader, which may include the resources for: i) a random access procedure between the Tx and / or Rx A-IoT device readers and A-IoT devices 3-1; ii) R2D data transmission after completion of a successful random access procedure with the Tx A-IoT device reader (e.g., intermediate UE 3-2); and iii) D2R data transmission after completion of a successful random access procedure with the Rx A-IoT device reader (e.g., intermediate UE 3-2).

[0189] It will be appreciated that the resource allocation for the Tx and / or Rx A-IoT device readers by the RAN node 5-1 may be performed in the same manner as described above with respect to step S508 in Fig. 5. The description above regarding step S508 thus applies equally to step S608, save that: the resource allocation must be performed for two different A-IoT device readers; namely a Tx A-IoT device reader and an Rx A-IoT device reader, and in the case of dynamic resource allocation, appropriate interaction between the RAN node 5-1, the Tx A-IoT device reader, and the Rx A-IoT device reader may be required.

[0190] For example, in the case where the resource allocation by the RAN node 5-1 to assign resources for use by the A-IoT devices 3-1 is subject to dynamic resource allocation procedures, the resources for random access procedures between the Tx and / or Rx A-IoT device readers and A-IoT devices 3-1 are allocated at step S608, while the resources for use by the A-IoT devices 3-1 for use in data transmission may be allocated at a later step (e.g., step S614).

[0191] In this scenario, during the initial access procedure at step S614, the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader (e.g., intermediate UE 3-2) may send an appropriate message / indication to the RAN node 5-1 to inform the RAN node 5-1 that it has received a response message (e.g., a 'Msg1' of a 4-step A-IoT RACH procedure) from an A-IoT device 3-1 with which it is performing the random access procedure. In response to that indication, the RAN node 5-1 may send an appropriate command message to the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader (e.g., intermediate UE 3-2) to command that it sends another message (e.g., a 'Msg2' in a 4-step A-IoT RACH procedure) to the A-IoT device 3-1 to indicate dynamically allocated resources to the A-IoT device 3-1 for use in data transmissions, and the like.

[0192] Alternatively, during the initial access procedure at step S614, the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader (e.g., intermediate UE 3-2) may send an appropriate message / indication to the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader directly to inform the Tx A-IoT device reader that it has received a response message (e.g., a 'Msg1' of a 4-step A-IoT RACH procedure) from an A-IoT device 3-1 with which it is performing the random access procedure, and to request that the Tx A-IoT device reader respond to that A-IoT device 3-1 with a command in another message (e.g., a 'Msg2' in a 4-step A-IoT RACH procedure) to indicate dynamically allocated resources to the A-IoT device 3-1 for use in data transmissions, and the like.

[0193] At step S610a, the RAN node 5-1 may send an appropriate configuration message (e.g., an RRC (Re)configuration message, or any other type of RRC message), to the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader (e.g., intermediate UE 3-2) to (re)configure the Tx A-IoT device reader with the allocated resources, allocated by the RAN node 5-1 at step S608. The Tx A-IoT device reader may respond (not shown) with an appropriate configuration response message (e.g., an RRCReconfigurationComplete message, or the like) to acknowledge the resource configuration message sent at step S610a.

[0194] Similarly, at step S610b, the RAN node 5-1 may send an appropriate configuration message (e.g., an RRC (Re)configuration message, or any other type of RRC message), to the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader (e.g., intermediate UE 3-2) to (re)configure the Rx A-IoT device reader with the allocated resources allocated by the RAN node 5-1 at step S608. The Rx A-IoT device reader may respond (not shown) with an appropriate configuration response message (e.g., an RRCReconfigurationComplete message, or the like) to acknowledge the resource configuration message sent at step S610b.

[0195] Following step S610b, once the Rx A-IoT device reader has been (re)configured with the allocated resources allocated by the RAN node 5-1 at step S608, the Rx A-IoT device reader may begin to monitor those resources allocated for use in a random access procedure to monitor for an access request an A-IoT device 3-1, or group of A-IoT devices 3-1, or type of A-IoT devices 3-1 as appropriate.

[0196] At step S612, the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader (e.g., intermediate UE 3-2) transmits an appropriate triggering message (e.g., an initial triggering message / A-IoT 'Msg0', or the like) to the A-IoT device 3-1 to trigger an appropriate initial access procedure (e.g., an adapted RACH procedure for A-IoT devices 3-1). That initial triggering message may be sent to the A-IoT device 3-1 using the resources allocated for that purpose by the RAN node 5-1 and indicated to the A-IoT device 3-1 in the resource configuration sent at step S610a. The initial triggering message may also include random access resources allocated by the RAN node 5-1 for use by the A-IoT device 3-1 in performing a random access procedure with the A-IoT device reader as described above.

[0197] Additionally, the triggering message sent at step S612 may also include an appropriate indication (e.g., an ID) of the Tx A-IoT device reader transmitting the triggering message, and / or an appropriate indication (e.g., an ID) of the Rx A-IoT device reader expecting to receive a response from the A-IoT device 3-1. The triggering message sent at step S612 may also include an indication of random access resources allocated by the RAN node 5-1 for communication with the Rx A-IoT device reader.

[0198] It will be appreciated that the triggering message sent at step S612 may serve to ask / trigger the A-IoT devices 3-1 that receive it to perform an initial access procedure with the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader in preparation for sending data to that Rx A-IoT device reader. Following successful completion of that initial access, the triggering message sent at step S612 may also serve to ask / trigger the transmission of data (e.g., an inventory response, or the like) from the A-IoT device 3-1 to the Rx A-IoT device reader via backscattered transmission.

[0199] Additionally, the initial triggering message may also include an indication of the resources allocated by the RAN node 5-1 that the A-IoT devices 3-1 are to monitor for a random access response message (e.g., 'Msg2' in a 4-step A-IoT RACH procedure) after sending the initial random access request in cases where the random access procedure is contention-based.

[0200] Additionally, the initial triggering message may also include an indication of the resources that the A-IoT devices 3-1 are to monitor for a random access response message (e.g., 'Msg2' in a 4-step A-IoT RACH procedure) after sending the initial random access request message to the A-IoT devices 3-1 in the scenario where the random access procedure is contention-based.

[0201] The enhanced A-IoT initial RA and resource allocation procedure described above with reference to Fig. 6A will now be continued with reference to Fig. 6B.

[0202] At step S614, the A-IoT device 3-1, having received the initial triggering message at step S612, performs an initial access procedure to access the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader (e.g., intermediate UE 3-2). The initial access procedure may be performed between the A-IoT device 3-1 and the Rx A-IoT device reader using resources allocated to them for that purpose by the RAN node 5-1 as described above. It will be appreciated that the Rx A-IoT device reader therefore may continuously monitor for an initial access request message, or the like, from the A-IoT device 3-1 in the random access resources designated / assigned for use by the Rx A-IoT device reader (e.g., the R2D transmission link) to monitor for such an initial access request message as described above.

[0203] As part of that initial access procedure, a first message sent by the A-IoT device 3-1 to the Rx A-IoT device reader to request initial access (e.g., a 'Msg1', or the like) may include an appropriate indication of the identity of the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader to which the A-IoT device 3-1 wishes to gain access, thereby ensuring that the correct Rx A-IoT device reader in the communication system 1 responds to the first message sent by the A-IoT device 3-1 requesting initial access.

[0204] Following completion of the initial access procedure at step S614, the RAN node 5-1 may configure the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader to monitor one or more resources designated / assigned for use by the A-IoT device 3-1 for transmission of data to the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader (e.g., the D2R transmission link) as a follow-up of its initial access procedure. It is assumed that the same set of resources may be distributed from the RAN node 5-1 to the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader, and then from the Tx A-IoT device reader to the A-IoT device 3-1.

[0205] In other words, following completion of the initial access procedure at step S614, the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader may indicate to the RAN node 5-1, via an appropriate message, the successful access of one or a set of A-IoT devices 3-1 (via e.g., device IDs). In response to that indication of the successful access of one or a set of A-IoT devices 3-1, the RAN node 5-1 may request the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader to announce the resources assigned by the RAN node 5-1 for use in data transmissions between the A-IoT device 3-1 and the Rx A-IoT device reader. That announcement may be made over the R2D transmission link to the A-IoT device 3-1 by the Tx A-IoT device reader.

[0206] Alternatively, rather than announcing the resources assigned by the RAN node 5-1 for use in data transmissions between the A-IoT device 3-1 and the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader, the resources for data transmissions between the A-IoT device 3-1 and the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader may be allocated at the beginning of the transmission of the initial triggering message at step S612 together with the random access resources indicated in that initial triggering message.

[0207] At step S616, the A-IoT device 3-1 sends data to the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader (e.g., intermediate UE 3-2) using the resources assigned for data transmission purposes and which have been indicated to intermediate / assisting node 5-22 acting as the Rx A-IoT device reader as previously described. The Rx A-IoT device reader may then aggregate the data it receives from several A-IoT devices 3-1 with which it is in communication or aggregate the data from the same A-IoT device 3-1 that it receives over time before forwarding that data to the RAN node 5-1 in an appropriate UL transmission.

[0208] For example, the data transmission received by the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader may be stored in a data store at step S618 and then once all (or a prerequisite) number of data transmissions has been received / stored, the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader may then aggregate the data before forwarding that data to the RAN node 5-1 in an appropriate UL transmission.

[0209] At step S620, the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader (e.g., intermediate UE 3-2) may use an appropriate container (e.g., an RRC container) to contain / host the data it received from the A-IoT device (or devices) 3-1 for forwarding / transmission to the RAN node 5-1. Once contained within the appropriate container, the data is sent to the RAN node 5-1 via an appropriate UL transmission message. That appropriate UL transmission message to the RAN node 5-1 may also include, for example, the device ID of the A-IoT device (or devices) 3-1 from which the data originates, and optionally the purpose of the data being transmitted.

[0210] At step S622, the RAN node 5-1 may send an appropriate indication / message (e.g., a specific NGAP message) to the CN 7 to acknowledge the inventory request message sent to the RAN node at the beginning of the procedure at step S602. That indication / message may also include the data that the RAN node 5-1 received from the A-IoT device (or devices) 3-1 at step S620.

[0211] Although the data transmission from the A-IoT device (or devices) 3-1 to the CN 7 is described above as involving the packaging and transmission / forwarding of the data in two steps (namely steps S620 and S622), it will nevertheless be appreciated that steps S620 and S622 may be combined into a single step. In this scenario, the data may be transmitted by the Rx A-IoT device reader to the CN 7 via upper layer signalling-based data transmissions between the Rx A-IoT device reader and the CN 7. This being the case, it will be appreciated that transmission carrying the data (or the container holding the data on the transmission) may be transparent to the RAN node 5-1.

[0212] Figs. 7A and 7B illustrate a simplified sequence diagram of yet another enhanced A-IoT initial RA and resource allocation procedure that may be implemented in the communication system of Fig. 1.

[0213] As shown in Figs. 7A and 7B, there is provided a core network (CN) 7 (e.g., 5GC) in communication with a RAN node 5-1 (e.g., a base station, or the like). There is also provided a plurality of intermediate / assisting nodes 5-21, 5-22 (for example intermediate / assisting UEs 3-2, or the like) that each operate as an A-IoT device reader. That intermediate / assisting nodes 5-21, 5-22 include a receiver (Rx) intermediate / assisting node 5-21 that operates as an Rx A-IoT device reader and a transmitter (Tx) intermediate / assisting node 5-22 that operates as a Tx A-IoT device reader.

[0214] Whilst the following description refers to the A-IoT device readers specifically as intermediate UEs 3-2 this does not preclude the A-IoT device readers being any other appropriate intermediate devices capable of acting as an A-IoT device reader.

[0215] To enable the Tx and Rx A-IoT device readers (e.g., intermediate UEs 3-2) to communicate with the A-IoT device 3-1, the CN 7 triggers an enhanced initial RA and resource allocation procedure such as that shown in Figs. 6A and 6B (hereafter referred collectively as Figs. 6A, 6B where appropriate).

[0216] It will be appreciated that in the procedure of Figs. 6A and 6B, the intermediate / assisting node 5-2 (e.g., the receiver (Rx) intermediate / assisting node 5-21 that operates as an Rx A-IoT device reader and a transmitter (Tx) intermediate / assisting node 5-22 that operates as a Tx A-IoT device reader) will typically be in an RRC connected state prior to being able to communicate with the RAN node 5-1 and act as A-IoT device readers for the A-IoT device 3-1. For example, where the Tx and Rx A-IoT device readers are intermediate UEs 3-2, those intermediate UEs 3-2 will typically enter an RRC connected state (like a typical UE 3) prior to being able to act as A-IoT device readers for the A-IoT device 3-1.

[0217] At step S702, the CN 7 sends an inventory request (e.g., an inventory request message, or the like) to the RAN node 5-1 over an appropriate interface (e.g., via the Next Generation Application Protocol (NGAP) on the N2 reference point between the RAN node 5-1 and the AMF 10-1 of the CN 7). The inventory request message sent by the CN 7 to the RAN node 5-1 may include an appropriate indication of the type (or types) of A-IoT devices 3-1 that the CN 7 wishes to query.

[0218] For example, the inventory request message may include an appropriate indication of a special category of A-IoT device 3-1 that the CN 7 wishes to query, and which may be reached via a specific intermediate / assisting node 5-21 acting as a Tx A-IoT device reader (e.g., via an intermediate UE 3-2) and / or a specific intermediate / assisting node 5-22 acting as an Rx A-IoT device reader (e.g., via an intermediate UE 3-2).

[0219] In this scenario, prior to the CN 7 sending the inventory request message to the RAN node 5-1, an association between the specific Tx A-IoT device reader and / or the specific Rx A-IoT device reader, and one or more A-IoT devices 3-1 that can be reached by them may be (pre)defined via an appropriate registration or subscription procedure, or the like. In this way the CN 7 may be aware of which specific Tx and / or Rx A-IoT device readers serve which A-IoT devices 3-1 prior to the CN 7 sending inventory request messages to the RAN node 5-1.

[0220] Where an association between a specific intermediate / assisting node 5-21 acting as a Tx A-IoT device reader, a specific intermediate / assisting node 5-22 acting as an Rx A-IoT device reader, and one or more A-IoT devices 3-1 is (pre)defined via an appropriate registration procedure, the inventory request message sent at step S702, may include an appropriate indication (or indications) of A-IoT devices 3-1, and / or A-IoT device types, and / or A-IoT device groups that the CN 7 wishes to communicate with, and their respective associated Tx and / or Rx A-IoT device readers. In this way the inventory request message sent at step S702 indicates, to the RAN node 5-1, which A-IoT devices 3-1 are targeted by the CN 7, and via which Tx and / or Rx A-IoT device readers those A-IoT devices 3-1 can be reached.

[0221] It will be appreciated that in certain circumstances the Tx and / or Rx A-IoT device readers associated with the A-IoT devices 3-1 with which the CN 7 wishes to communicate may be in an RRC idle state at the time that the RAN node 5-1 receives the inventory request message. For example, where the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader and / or the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader are intermediate UEs 3-2 sometime after establishing an RRC connection with the RAN node 5-1, those intermediate UEs 3-2 may enter an RRC idle / inactive state / mode until the intermediate UEs 3-2 are ready to (re)enter an RRC connected state (e.g., by transmitting a request to the RAN node 5-1 to (re)establish / resume the RRC connection). The decision to transmit such a request to the RAN node 5-1 may, for example, be in response to the intermediate UEs 3-2 receiving a paging message, or the like, to indicate that a device in the network wishes to send information to, or receive information from, the intermediate UEs 3-2. In this scenario, the inventory request message sent at step S702 (or another independent message) may be used to initiate a paging procedure by the RAN node 5-1 to move the Tx and / or Rx A-IoT device readers (e.g., intermediate UEs 3-2) from an RRC idle / inactive state / mode to an RRC connected state / mode.

[0222] For example, having received the inventory request message sent at step S702, the RAN node 5-1 may send, at step S704 an appropriate paging message to the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader to trigger the Tx A-IoT device reader to switch from an RRC idle / inactive state to an RRC connected state.

[0223] In more detail, the RAN node 5-1 may send a paging message at steps S704 to the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader to 'wake-up' that` device reader based on the information contained in the inventory request message it received from the CN 7 at step S702 (e.g., an indication of the A-IoT devices 3-1, and / or A-IoT device types, and / or A-IoT device groups that the CN 7 wishes to communicate with, and their respective associated Tx and / or Rx A-IoT device readers). That paging message sent at steps S704 may in turn trigger the intermediate / assisting node 5-21 to act as the Tx A-IoT device reader and the RAN node 5-1 to perform an appropriate RRC re-establishment procedure at steps S706.

[0224] Alternatively, rather than an association between specific Tx and / or Rx A-IoT device readers and one or more A-IoT devices 3-1 being (pre)defined and indicated in the inventory request message sent at step S702, the RAN node 5-1, having received the inventory request message sent at step S702, may assign specific Tx and / or Rx A-IoT device readers for use in communicating with the one or more A-IoT devices 3-1 indicated in the inventory request message. In this scenario, the RAN node 5-1 may assign specific Tx and / or Rx A-IoT device readers based on prior knowledge of a capability of the Tx and / or Rx A-IoT device readers to which it is already connected, and which serve the RAN node 5-1.

[0225] For example, where the intermediate / assisting nodes 5-21, 5-22 acting as the Tx A-IoT device reader and the Rx A-IoT device reader respectively, are already connected to the RAN node 5-1, they may have already reported (e.g., during RA, or the like), or may periodically report via appropriate messaging, to the RAN node 5-1, their capability to act as Tx and an Rx A-IoT device reader respectively for specific A-IoT devices 3-1 when connected to the RAN node 5-1. Based on that prior knowledge (or periodically reported knowledge), the RAN node 5-1 may assign specific intermediate UEs 3-2 to act as the Tx and / or Rx A-IoT device reader for the A-IoT devices 3-1 indicated in the inventory request message it received at step S702.

[0226] At step S704, as alluded to above, if the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader (e.g., an intermediate UE 3-2) indicated in the inventory request message or selected / assigned by the RAN node 5-1 upon receiving the inventory request message sent, is in RRC idle / inactive state, the RAN node 5-1 sends a paging message to the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader.

[0227] The paging message sent at steps S704 may be sent to the indicated / assigned intermediate / assisting node 5-21 that is to act as the Tx A-IoT device reader over an appropriate interface, and may each include, amongst other things, a specific 'paging cause' value to indicate to the indicated / assigned intermediate UE 3-2 that the paging it is receiving from the RAN node 5-1 is a request for it to act as a Tx A-IoT device reader (for a specific indicated set of A-IoT devices 3-1) (e.g., A-IoT devices 3-1, and / or A-IoT device types, and / or A-IoT device groups as indicated in the inventory request message sent at step S702).

[0228] Having received the paging message at step S704a, as alluded to above, the indicated / assigned intermediate / assisting node 5-21 acting as the Tx A-IoT device reader may initiate an appropriate RA procedure with the RAN node 5-1 to (re)establish an RRC connection with the RAN node 5-1, enabling it to act as a Tx A-IoT device reader for the A-IoT devices 3-1 indicated in the inventory request message. That RA procedure may be any appropriate RA procedure known to the skilled person. By way of example only, the RA procedure may be a 2-step, 3-step, or a 4-step A-IoT RACH procedure such as those described above.

[0229] During that RRC Connection (Re)establishment procedure at step S706, one or more of the messages transmitted by the RAN node 5-1 to the intermediate UE 3-2, (e.g., Msg2 / Msg4 in a 4-step A-IoT RACH procedure, Msg2 / MsgB in a 2-step A-IoT RACH procedure, or the like) may include a cause value to specify to the indicated / assigned intermediate / assisting node 5-21 acting as the Tx A-IoT device reader a cause for the RRC (re)connection request. For example, the cause value may indicate to the indicated / assigned intermediate / assisting node 5-21 that it is to act as Tx A-IoT device reader for a specific indicated set of A-IoT devices 3-1 (e.g., A-IoT devices 3-1, and / or A-IoT device types, and / or A-IoT device groups as indicated in the inventory request message sent at step S702).

[0230] At step S708, (which may come either immediately after step S702 if RRC connection (re)establishment is not needed, or after step S706 where RRC connection (re)establishment was required), the RAN node 5-1 allocates resources for at least the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader to perform the inventory request the RAN node 5-1 received from the CN 7 at step S702. For example, the RAN node 5-1 may allocate resources for an initial access procedure between the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader and one or more A-IoT devices 3-1.

[0231] Having allocated resources for at least the Tx A-IoT device reader to perform an initial access procedure with the one or more A-IoT devices 3-1, the RAN node 5-1 may indicate those resources to the Tx A-IoT device reader via an appropriate resource configuration message sent at step S709.

[0232] At step S710, the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader (e.g., intermediate UE 3-2) transmits an appropriate triggering message (e.g., an initial triggering message) to the A-IoT device 3-1 to trigger an appropriate initial access procedure (e.g., an adapted A-IoT RACH procedure for A-IoT devices 3-1). That initial triggering message may be sent to the A-IoT device 3-1 using the resources allocated for that purpose by the RAN node 5-1 and indicated to the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader in the resource configuration sent at step S709. The initial triggering message may also include random access resources allocated by the RAN node 5-1 for use by the A-IoT device 3-1 in performing an initial access procedure with the Rx A-IoT device reader.

[0233] Additionally, the triggering message sent at step S712 may also include an appropriate indication (e.g., an ID) of the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader transmitting the triggering message, and / or an appropriate indication (e.g., an ID) of the Rx A-IoT device reader expecting to receive a response from the A-IoT device 3-1. The triggering message sent at step S712 may also include an indication of random access resources allocated by the RAN node 5-1 for communication with the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader.

[0234] For example, the resources necessary for the Rx A-IoT device reader to perform a random access procedure with one or more A-IoT devices 3-1 may be configured by the RAN node 5-1 and may be indicated to the A-IoT devices 3-1 in the initial triggering message at step S710. For example, the resources for the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader to perform a random access procedure may be configured by the RAN node 5-1 and may be reported to the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader in the resource configuration sent at step S709. Alternatively, the resources for the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader to perform a random access procedure may be preconfigured at the Tx A-IoT device reader, and the Tx A-IoT device reader may include an indication of those resources in its initial triggering message at step S710.

[0235] In another example, the resources necessary for the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader to perform a random access procedure with one or more A-IoT devices 3-1 may be default resources (e.g., predefined by an appropriate specification).

[0236] In yet another example, the resources necessary for the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader to perform a random access procedure with one or more A-IoT devices 3-1 may be dedicated resources allocated by the RAN node 5-1 to the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader when the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader is in RRC connected state (i.e., they may be allocated by the RAN node 5-1 during an RRC (re)connection procedure, or the like).

[0237] In yet another example, the resources necessary for the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader to perform a random access procedure with one or more A-IoT devices 3-1 may be indicated / transmitted in a specific system information block (SIB). In this case, the resources will be shared resources that may be shared amongst all Rx A-IoT device readers (including intermediate / assisting node 5-22).

[0238] Additionally, the initial triggering message sent at step S710 may serve to ask / trigger the A-IoT devices 3-1 that receive it to perform an initial access procedure with the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader in preparation for sending data to that intermediate / assisting node 5-22 acting as the Rx A-IoT device reader. Following successful completion of that initial access, the triggering message sent at step S710 may also serve to ask / trigger the transmission of data (e.g., an inventory response, or the like) from the A-IoT device 3-1 to the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader via backscattered transmission.

[0239] At step S712 the A-IoT device 3-1, having received the initial triggering message at step S710, performs an initial access procedure to access the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader (e.g., intermediate UE 3-2). The initial access procedure may be performed between the A-IoT device 3-1 and the Rx A-IoT device reader using resources allocated to them for that purpose as described above.

[0240] Where the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader is in RRC connected state / mode it may continuously monitor for an initial access request message, or the like, from the A-IoT device 3-1 in the random access resources designated / assigned for use by the Rx A-IoT device reader (e.g., the D2R transmission link) to monitor for such an initial access request message.

[0241] Alternatively, where the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader is in RRC idle / inactive state / mode the Rx A-IoT device reader may follow a fixed cycle to monitor for an initial access request message, or the like, from the A-IoT device 3-1 in the random access resources designated / assigned for use by the Rx A-IoT device reader (e.g., the D2R transmission link) to monitor for such an initial access request message. In this scenario, the random access resources may be allocated in a cyclical manner to ensure / maintain reasonable power consumption levels during the initial access procedure.

[0242] Step S714 may occur during the initial access procedure at step S712 (e.g., after the Rx A-IoT device reader echoes an initial access request to the A-IoT devices 3-1 such as a 'Msg1' in an A-IoT RACH-like procedure), or after the initial access procedure at step S712.

[0243] At step S714, the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader initiates an appropriate random access procedure with the RAN node 5-1 to establish an RRC connection if the Rx A-IoT device reader is not already in an RRC connected state. During that random access procedure a special RRC connection establishment cause may be included by the Rx A-IoT device reader in an RRC connection establishment request message it sends to the RAN node 5-1 sent as part of this procedure.

[0244] Additionally, at step S714, an indication of the identity (e.g., ID) of the A-IoT device 3-1, and / or a group of A-IoT devices 3-1 that the Rx A-IoT device reader expects to receive data transmissions from in the future may be provided to RAN node 5-1 either during, or after, the RRC connection establishment procedure.

[0245] At step S716, following successful RRC connection establishment between the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader and the RAN node 5-1, the RAN node 5-1 may configure appropriate resources for the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader to monitor for D2R link transmissions from the A-IoT devices 3-1. Those configured resources may then be indicated to the Rx A-IoT device reader via appropriate messaging at step S717.

[0246] During the configuration of the appropriate resources for the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader to monitor for D2R link transmissions from the A-IoT devices 3-1 it is assumed that the same set of resources may be distributed from the RAN node 5-1 to the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader and then from the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader to the A-IoT devices 3-1. For example, the Rx A-IoT device reader may report to the RAN node 5-1 the successful access of a particular A-IoT device 3-1 with a device ID of A-IoT device 3-1 as described above, and then the RAN node 5-1 may be able to request the that the intermediate / assisting node 5-21 acting as the Tx A-IoT device reader announce those resources for data transmission to that A-IoT device 3-1 via R2D link based transmission.

[0247] It will be appreciated that, alternatively, the resources for data transmissions from the A-IoT device 3-1 to the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader may be allocated in the initial triggering message sent at step S710 along with the random access resources. In this case it will be appreciated that the configuration of the resources for data transmission by the RAN node 5-1 may be performed at step S708 instead of step S716.

[0248] The enhanced A-IoT initial RA and resource allocation procedure described above with reference to Fig. 7A will now be continued with reference to Fig. 7B.

[0249] At step S718 the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader may report to the RAN node 5-1 that the Rx A-IoT device reader has successfully accessed the A-IoT device 3-1 with the device ID of A-IoT device 3-1 included in the RRC connection establishment request sent during the RRC connection establishment procedure at step S714. In response to reporting successful access to the A-IoT device 3-1, the RAN node 5-1 may then request the intermediate / assisting node 5-21 acting at the Tx A-IoT device reader to announce, to the A-IoT device 3-1, the resources that the A-IoT device 3-1 may use for the transmission of data to the Rx A-IoT device reader via the R2D data transmission link.

[0250] At step S719, the A-IoT device 3-1 sends data to the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader (e.g., intermediate UE 3-2) using the resources assigned for data transmission purposes and which have been indicated to the Rx A-IoT device reader as previously described. The Rx A-IoT device reader may then aggregate the data it receives from several A-IoT devices 3-1 with which it is in communication or aggregate the data from the same A-IoT device 3-1 that it receives over time before forwarding that data to the RAN node 5-1 in an appropriate UL transmission.

[0251] For example, the data transmission received by the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader may be stored in a data storage at step S720 and then once all (or a prerequisite) number of data transmissions has been received / stored, the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader may then aggregate the data before forwarding that data to the RAN node 5-1 in an appropriate UL transmission.

[0252] At step S722, the intermediate / assisting node 5-22 acting as the Rx A-IoT device reader (e.g., intermediate UE 3-2) may use an appropriate container (e.g., an RRC container) to contain / host the data it received from the A-IoT device (or devices) 3-1 for forwarding / transmission to the RAN node 5-1. Once contained within the appropriate container, the data is sent to the RAN node 5-1 via an appropriate UL transmission message. That appropriate UL transmission message to the RAN node 5-1 may also include, for example, the device ID of the A-IoT device (or devices) 3-1 from which the data originates, and optionally the purpose of the data being transmitted.

[0253] At step S724, the RAN node 5-1 may send an appropriate indication / message (e.g., a specific NGAP message) to the CN 7 to acknowledge the inventory request message sent to the RAN node at the beginning of the procedure at step S702. That indication / message may also include the data that the RAN node 5-1 received from the A-IoT device (or devices) 3-1 at step S718.

[0254] Although the data transmission from the A-IoT device (or devices) 3-1 to the CN 7 is described above as involving the packaging and transmission / forwarding of the data in two steps (namely steps S722 and S724), it will nevertheless be appreciated that steps S722 and S724 may be combined into a single step. In this scenario, the data may be transmitted by the Rx A-IoT device reader to the CN 7 via upper layer signalling-based data transmissions between the Rx A-IoT device reader and the CN 7. This being the case, it will be appreciated that transmission carrying the data (or the container holding the data on the transmission) may be transparent to the RAN node 5-1.

[0255] <Procedure for A-IoT after loss of RRC Connection with an A-IoT device reader> 　　Fig. 8 illustrates a simplified sequence diagram of an enhanced A-IoT procedure for handling a loss of RRC connection with an A-IoT device reader that may be implemented in the communication system 1 of Fig. 1.

[0256] As shown in Fig. 8, there is provided a core network (CN) 7 (e.g., 5GC) in communication with a RAN node 5-1 (e.g., a base station, or the like). There is also provided an intermediate / assisting node 5-2 that operates as an A-IoT device reader (for example an intermediate / assisting UE 3-2, or the like). Whilst the following description refers to the A-IoT device reader specifically as an intermediate UE 3-2 this does not preclude the A-IoT device reader being any other appropriate intermediate device capable to acting as an A-IoT device reader.

[0257] It will be appreciated that although the procedure of Fig. 8 only involves a single A-IoT device reader, the procedure may be appropriately adapted to provide a Tx A-IoT device reader and an Rx A-IoT device reader. For example, the intermediate / assisting node 5-2 may in turn be comprise a receiver (Rx) intermediate / assisting node 5-21 that operates as an Rx A-IoT device reader and a transmitter (Tx) intermediate / assisting node 5-22 that operates as a Tx A-IoT device reader.

[0258] It will also be appreciated that the procedure of Fig. 8 (or a similar procedure adapted to the presence of separate Rx and Tx A-IoT device readers) may occur towards the end of any of the procedures described above with reference to Figs. 5 to 7A, 7B in the event of a loss of RRC connectivity.

[0259] It will further be appreciated that in the procedure of Fig. 8, the A-IoT device reader starts off in an RRC connected state and that steps S802 to S806 are similar to steps S516 to S520 respectively of the procedure shown in Fig. 5. Accordingly, the description of steps S516 to S520 above applies equally to steps S802 to S806 in the procedure shown in Fig. 8.

[0260] Following step S806, as shown in Fig. 8, the A-IoT device reader may temporarily lose connection with the RAN node 5-1 (come out of connection with the RAN node 5-1).

[0261] For example, the IoT device reader may temporarily lose connection with the RAN node 5-1 due to a radio link failure (RLF) event. In this scenario, the A-IoT device reader is no longer able to forward any data it received from one or more A-IoT devices 3-1 (or any signalling responses) to the RAN node 5-1. Accordingly, to enable the A-IoT device reader to forward the data to the RAN node 5-1 it may attempt to re-establish its connection with the original (source) RAN node 5-1 or with a different (target) RAN node 5-1.

[0262] For example, the connection may be re-established by performing an appropriate RRC connection reestablishment procedure, or the like with the original (source) RAN node 5-1. Alternatively, the A-IoT device reader may trigger an appropriate handover procedure from a source cell / source RAN node (e.g., RAN node 5-1) to a target cell of the same or a different (target) RAN node 5-1, and reestablish an RRC connection with the target cell / target RAN node 5-1. These re-establishment scenarios are hereafter referred to collectively as Case#1.

[0263] In another example, the A-IoT device reader may, having lost RRC connection with the RAN node 5-1 due to an RLF, enter an RRC IDLE mode / state, and may at some time later establish a new RRC connection again with, for example, a different RAN node 5-1. This scenario is hereafter referred to as Case#2.

[0264] Irrespective of whether the response of the A-IoT device reader to the RLF (e.g., irrespective whether the A-IoT device reader responds to the RLF by attempting to re-establish the RRC connection with the original RAN node 5-1 or a different RAN node 5-1 in accordance with Case#1, or to establish a new RRC connection with a different RAN node 5-1 in accordance with Case#2) both the A-IoT device reader and the RAN node 5-1 may nevertheless maintain the RRC context of the A-IoT device reader to enable the resumption of data forwarding upon RRC connection (re)establishment by the A-IoT device reader.

[0265] In both Case#1 and Case#2 described above, when the A-IoT device (or devices) 3-1 sends a data transmission to the A-IoT device reader, the A-IoT device reader, on account of its lost connection with the RAN node 5-1, temporarily stores the data it receives at step S810.

[0266] Case#1 and Case#2 will now be discussed separately with respect to the remaining steps of the procedure shown in Fig. 8.

[0267] <Case#1> 　　At step S812, the A-IoT device reader and the RAN node 5-1 may perform an appropriate RRC re-establishment procedure to re-establish the RRC connection between the A-IoT device reader and the RAN node 5-1. The RAN node 5-1 may be the initial RAN node 5-1 with which the A-IoT device reader previously had a connection, or alternatively the RAN node 5-1 may be a new RAN node 5-1 to which the A-IoT device reader has performed a handover to then re-establish an RRC connection.

[0268] Either during RRC connection re-establishment, or alternatively having re-established an RRC connection, the A-IoT device reader may begin forwarding the data it has stored that it received from the A-IoT devices 3-1 to the RAN node 5-1 with which it has re-established (is re-establishing) the RRC connection (e.g., the initial RAN node 5-1).

[0269] For example, at step S812 during the RRC connection re-establishment procedure between the A-IoT device reader and the RAN node 5-1 (e.g., the initial RAN node 5-1) the stored data for the A-IoT devices 3-1 may be carried by (or multiplexed with) the first layer-3 (L3) message sent to the RAN node 5-1 when the A-IoT devices tries to recover / recovers its RRC connection. For example, when the A-IoT device reader sends its first uplink UL RRC message (e.g., an RRC connection re-establishment request message) to the RAN node 5-1 (e.g., the initial RAN node 5-1) as part of the RRC connection re-establishment procedure of step S812, all (or part) of the stored data for the A-IoT devices 3-1 may be carried by the first UL RRC message (e.g., in an RRC container, or the like).

[0270] In another example, having re-established an RRC connection, the A-IoT device reader may begin forwarding the data it has stored that it received from the A-IoT devices 3-1 to the RAN node 5-1 with which it has the re-established RRC connection (e.g., the initial RAN node 5-1) - i.e., data forwarding occurs after the RRC connection re-establishment procedure has terminated.

[0271] In this case, it will be appreciated that during the RRC connection re-establishment procedure at step S812 the first uplink UL RRC message (e.g., an RRC connection re-establishment request message) to the RAN node 5-1 (e.g., the initial RAN node 5-1) as part of the RRC connection re-establishment procedure may include a 'proper data size' report that reports, to the RAN node 5-1 the size of the amount of data stored at the A-IoT device reader that it has received from A-IoT devices 3-1.

[0272] It will be appreciated that the inclusion of the 'proper data size' report in the first uplink UL RRC message may be used by the RAN node 5-1 to assist it in determining the amount of resources that are required for the forwarding of the data. That is to say the RAN node 5-1 (e.g., the initial RAN node 5-1) may use the 'proper data size' report to schedule appropriate resources for the A-IoT device reader to forward the data on to the RAN node 5-1 (e.g., the initial RAN node 5-1).

[0273] Alternatively, during the RRC connection re-establishment procedure at step S812 the first uplink UL RRC message (e.g., an RRC connection re-establishment request message) to the RAN node 5-1 (e.g., the initial RAN node 5-1) as part of the RRC connection re-establishment procedure may include an indication of a specific establishment cause to specify the purpose, or just the indication of the data availability of the data stored at the A-IoT device reader (and the size of that data). The RAN node 5-1 (e.g., the initial RAN node 5-1) may then use the specific establishment cause (and the size of the data) to schedule appropriate resources for the A-IoT device reader to forward the data on to the RAN node 5-1 (e.g., the initial RAN node 5-1).

[0274] Following the scheduling of the appropriate resources the A-IoT device reader may forward the data first onto the RAN node 5-1 (e.g., the initial RAN node 5-1), at step S814, which may in turn forward the data onto the CN 7 (step S816). It will be appreciated that steps S814 and S816 are the similar to steps S804 and S806 respectively, and thus the description for those steps applies equally to steps S814 and S816 (i.e., steps S814 and S816 are similar to steps S518 and S520 respectively of the procedure shown in Fig. 5).

[0275] <Case#2> 　　It will be appreciated that in Case#2, although the A-IoT device reader and the RAN node 5-1 have lost their RRC connection, as the A-IoT device reader has entered RRC idle or inactive state / mode, it may continue to receive data from the A-IoT devices 3-1 during RRC idle or inactive mode through the use of the resource allocated previously by the RAN node 5-1 when the A-IoT device reader was in RRC connected mode with the RAN node 5-1. Accordingly, while in RRC idle or inactive state / mode, the A-IoT device reader may receive data from one or more A-IoT devices 3-1 and store that data as in step S810.

[0276] At step S812, the A-IoT device reader and a new RAN node 5-1 may perform an appropriate RRC (re)establishment procedure to establish a new RRC connection between the A-IoT device reader and a new RAN node 5-1.

[0277] Either during RRC connection re-establishment, or alternatively having re-established an RRC connection, the A-IoT device reader may begin forwarding the data it has stored that it received from the A-IoT devices 3-1 to the new RAN node 5-1 with which it has the RRC connection.

[0278] For example, at step S812 during the RRC connection (re)establishment procedure between the A-IoT device reader and a new RAN node 5-1 the stored data for the A-IoT devices 3-1 may be carried by (or multiplexed with) the first layer-3 (L3) message sent to the new RAN node 5-1 when the A-IoT devices tries to recover / recovers its RRC connection. For example, when the A-IoT device reader sends its first uplink UL RRC message (e.g., an RRC connection re-establishment request message) to the new RAN node 5-1 as part of the RRC connection re-establishment procedure of step S812, all (or part) of the stored data for the A-IoT devices 3-1 may be carried by the first UL RRC message (e.g., in an RRC container, or the like).

[0279] Having re-established an RRC connection with a new cell and / or a new RAN node 5-1, the A-IoT device reader may report to the new RAN node 5-1, appropriate information pertaining to the previous serving cell / source RAN node 5-1 (e.g., the initial RAN node 5-1).

[0280] Furthermore, in the case where the established RRC connection is with a new RAN node 5-1 (as opposed to, for example a new cell being provided by the source RAN node 5-1), the new RAN node 5-1 may fetch the UE context associated with the A-IoT device reader from the source RAN node 5-1 to enable the new RAN node 5-1 to construct a single (e.g., NGAP) message for forwarding the data it receives from the A-IoT device reader to the CN 7.

[0281] Alternatively, in the case where the established RRC connection is with a new RAN node 5-1 (as opposed to, for example a new cell being provided by the source RAN node 5-1), the new RAN node 5-1 may forward the data it receives from the A-IoT device reader to the source RAN node 5-1 for the source RAN node 5-1 to construct a single (e.g., NGAP) message for forwarding the data it received from the new RAN node 5-1 to the CN 7.

[0282] Alternatively, in the case where the established RRC connection is with a new RAN node 5-1 (as opposed to, for example a new cell being provided by the source RAN node 5-1), the new RAN node 5-1 and the source RAN node 5-1 may each construct a single (e.g., NGAP) message for forwarding data they received from the A-IoT device reader.

[0283] In Case#2 the decision by the A-IoT device reader to perform an appropriate RRC re-establishment procedure to re-establish its RRC connection may be configurable in some manner or other by the network.

[0284] For example, the A-IoT device reader may be configured with a timer on how long it needs to keep the data that it has received from the A-IoT device 3-1. That timer may, for example, be triggered at the time that the A-IoT device 3-1 loses its RRC connection and the A-IoT device reader may attempt to re-establish its RRC connection during the rundown of the timer. In this scenario, in the event that the timer expires prior to the A-IoT device reader being able to re-establish an RRC connection with the network and forward the data onto a RAN node 5-1 and / or the CN 7, the data may be removed from the data store of the A-IoT device 3-1. For example, if the A-IoT device reader is out of coverage, the A-IoT device reader may only keep the data a limited amount of time in order to save its power and memory.

[0285] In another example, the A-IoT device reader may be configured with a data threshold. For example, since the A-IoT device reader may continue to receive the data from the A-IoT devices 3-1 even though it lost the RRC connection with the network, a data limit / threshold may be configured. At the point that the data limit / threshold is reached, the A-IoT device reader may then attempt to re-establish an RRC connection with the network and forward the data onto a RAN node 5-1 and / or the CN 7.

[0286] In another example, the A-IoT device reader may be configured to only attempt to re-establish an RRC connection with the network to perform data forwarding when data transmission between the A-IoT devices 3-1 and the A-IoT device reader has completed or terminated. For example, the A-IoT device reader can determined whether data transmissions from the A-IoT devices 3-1 have come to an end based on the resource allocation for D2R transmissions (i.e., once all resource allocated have be used). Alternatively, the A-IoT devices 3-1 may send an appropriate indication to the A-IoT device reader when data transmissions have come to an end.

[0287] In yet another example, the A-IoT device reader may be configured to not attempt to re-establish an RRC connection with the network to perform data forwarding unless the network pages the A-IoT device reader requesting the A-IoT device reader to attempt to re-establish an RRC connection with the network.

[0288] In yet a further example, the A-IoT device reader may be configured to attempt to re-establish an RRC connection with the network only when cellular coverage is available.

[0289] Following the scheduling of the appropriate resources the A-IoT device reader may forward the data first onto the RAN node 5-1 with which it has a newly (re)established connection (step S814), which may in turn forward the data onto the CN 7 (step S816). It will be appreciated that steps S814 and S816 are similar to steps S804 and S806 respectively, and thus the description for those steps applies equally to steps S814 and S816 (i.e., steps S814 and S816 are similar to steps S518 and S520 respective of the procedure shown in Fig. 5).

[0290] <Procedure for A-IoT after an A-IoT device reader moves Out-of-Coverage> 　　Fig. 9 illustrates a simplified sequence diagram of an enhanced A-IoT procedure for handling a scenario in which an A-IoT device reader moves out-of-coverage that may be implemented in the communication system 1 of Fig. 1.

[0291] As shown in Fig. 9, there is provided a core network (CN) 7 (e.g., 5GC) in communication with a RAN node 5-1 (e.g., a base station 5-1, or the like). There is also provided an intermediate / assisting node 5-2 that operates as an A-IoT device reader (for example an intermediate / assisting UE 3-2, or the like). Whilst the following description refers to the A-IoT device reader specifically as an intermediate UE 3-2 this does not preclude the A-IoT device reader being any other appropriate intermediate device capable to acting as an A-IoT device reader.

[0292] It will be appreciated that although the procedure of Fig. 9 only involves a single A-IoT device reader, the procedure may be appropriately adapted to provide a Tx A-IoT device reader and an Rx A-IoT device reader. For example, the intermediate / assisting node 5-2 may in turn be comprise a receiver (Rx) intermediate / assisting node 5-21 that operates as an Rx A-IoT device reader and a transmitter (Tx) intermediate / assisting node 5-22 that operates as a Tx A-IoT device reader.

[0293] It will be appreciated that in the procedure of Fig. 9, the A-IoT device reader starts off in RRC connected state with the RAN node 5-1. For example, where the A-IoT device reader is an intermediate UE 3-2, that intermediate UE 3-2 should be in RRC connected state (like a typical UE) prior to being able to act as an A-IoT device reader for the A-IoT device 3-1.

[0294] At step S902, the CN 7 sends an A-IoT command message, or the like, to the RAN node 5-1 over an appropriate interface (e.g., via the Next Generation Application Protocol (NGAP) on an appropriate (e.g., N2) reference point between the RAN node 5-1 and the AMF 10-1 of the CN 7). That A-IoT command message may, for example, be an inventory request (e.g., an inventory request message, or the like), which may include an appropriate indication of the type (or types) of A-IoT devices 3-1 that the CN 7 wishes to query.

[0295] At step S904 the RAN node 5-1 forward the A-IoT command message (e.g., the inventory request) to the A-IoT device reader (e.g., intermediate UE 3-2). For example, the RAN node 5-1 may forward the A-IoT command message to the A-IoT device reader over an appropriate interface (e.g., a Uu interface, or the like).

[0296] At step S906, the RAN node 5-1 may allocate appropriate resources to the A-IoT device reader for the transmission of an appropriate triggering message, or the like, to the A-IoT devices 3-1, and the transmission of a .corresponding response message, or the like, from the A-IoT devices 3-1. For example, at step S906 the RAN node 5-1 may allocate resources to / for the A-IoT devices 3-1 in the same manner as described above at step S508 in the procedure shown in Fig. 5.

[0297] Following the allocation of the resources to / for the A-IoT device reader, as shown in Fig. 9, the A-IoT device reader (e.g., the intermediate UE 3-2) may move out of coverage of the RAN node 5-1. By way of example only, having been configured / allocated with appropriate resources by the RAN node 5-1 for scenarios where the A-IoT device reader is indoors, the A-IoT device reader may move outdoors, resulting in a temporary loss of coverage by the RAN node 5-1. However, as it may be assumed that the loss of coverage it temporary, it will be appreciated that the RAN node 5-1 may maintain some or all of the context information it has pertaining to the A-IoT device reader and the A-IoT devices 3-1.

[0298] In the event that the A-IoT device reader loses coverage with the RAN node 5-1, it will be appreciated that the A-IoT device reader will not be able to forward any data it receives from A-IoT devices 3-1 to the RAN node 5-1.

[0299] It will be appreciated however that while temporarily out of coverage A-IoT communication between the A-IoT device reader and the A-IoT devices 3-1 may continue. For example, the sending of data and / or signalling by one or more A-IoT devices 3-1 to the A-IoT device reader may continue using resources previously allocated by the RAN node 5-1 via dedicated signalling to the A-IoT device reader. In this scenario, as the A-IoT device reader is unable to forward the data and / or signalling it receives to the RAN node 5-1, it may instead temporarily store that data and / or signalling in its memory, similarly to step S720 in the procedure shown in Figs. 7A and 7B.

[0300] For example, despite the A-IoT device reader being out of coverage with the RAN node 5-1, and having transitioned into an RRC idle state / mode, the A-IoT device reader will keep any A-IoT related configurations (e.g., resource allocations, and the like) that it has previously received from the RAN node 5-1 to enable the A-IoT device reader to continue to support communication with A-IoT devices 3-1 over the A-IoT interface. It will be appreciated that the maintenance of such configurations may be beneficial, especially in the scenario where the A-IoT device reader re-establishes its RRC connection with a different (new) RAN node 5-1, as the new RAN node 5-1 may not support A-IoT operation. Accordingly, despite not supporting A-IoT operation, the A-IoT device reader and A-IoT devices 3-1 may continue to communicate using the A-IoT configurations they received previously from RAN node 5-1.

[0301] Thus, as the A-IoT device reader and the A-IoT devices 3-1 are still able to communicate despite the A-IoT device reader being out of coverage with the RAN node 5-1, at step S908, the A-IoT device reader and A-IoT devices 3-1 may perform an appropriate initial access procedure similar to, for example, the initial access procedure described above at step S514 of the procedure shown in Fig. 5.

[0302] Following the completion of the initial access procedure at step S908, at step S909 data transmission between A-IoT devices 3-1 and the A-IoT device reader may occur. As described above, due to the A-IoT device reader being out of coverage of the RAN node 5-1, that data may be stored at the A-IoT device reader.

[0303] At some time later, the A-IoT device reader may attempt to re-establish its RRC connection, either with the original RAN node 5-1 with which it had an RRC connection (e.g., the initial RAN node 5-1) or with a new RAN node 5-1. For example, at step S910 the A-IoT device reader may attempt to re-establish an RRC connection in a similar manner to that described above at step S812 in the procedure shown in Fig. 8.

[0304] Once an RRC connection has been re-established by the A-IoT device reader with a RAN node 5-1 of the network (e.g., a new RAN node 5-1) the A-IoT device reader may report to the new RAN node 5-1, appropriate information pertaining to the previous serving cell / source RAN node 5-1 (e.g., the initial RAN node 5-1).

[0305] Furthermore, in the case where the re-established RRC connection is with a new RAN node 5-1 (as opposed to, for example a new cell being provided by the source RAN node 5-1), the new RAN node 5-1 may fetch the UE context associated with the A-IoT device reader from the source RAN node 5-1 to enable the new RAN node 5-1 to construct a single (e.g., NGAP) message for forwarding the data it receives from the A-IoT device reader to the CN 7.

[0306] Alternatively, in the case where the re-established RRC connection is with a new RAN node 5-1 (as opposed to, for example a new cell being provided by the source RAN node 5-1), the new RAN node 5-1 may forward the data it receives from the A-IoT device reader to the source RAN node 5-1 for the source RAN node 5-1 to construct a single (e.g., NGAP) message for forwarding the data it received from the new RAN node 5-1 to the CN 7.

[0307] Alternatively, in the case where the re-established RRC connection is with a new RAN node 5-1 (as opposed to, for example a new cell being provided by the source RAN node 5-1), the new RAN node 5-1 and the source RAN node 5-1 may each construct a single (e.g., NGAP) message for forwarding data they received from the A-IoT device reader.

[0308] Furthermore, it will be appreciated that the decision by the A-IoT device reader to perform an appropriate RRC re-establishment procedure to re-establish its RRC connection may be configurable in some manner or other by the network.

[0309] For example, the A-IoT device reader may be configured with a timer on how long it needs to keep the data that it has received from the A-IoT device 3-1. That timer may, for example, be triggered at the time that the A-IoT device 3-1 loses its RRC connection and the A-IoT device reader may attempt to re-establish its RRC connection during the rundown of the timer. In this scenario, in the event that the timer expires prior to the A-IoT device reader being able to re-establish an RRC connection with the network and forward the data onto a RAN node 5-1 and / or the CN 7, the data may be removed from the data store of the A-IoT device 3-1. For example, if the A-IoT device reader is out of coverage, the A-IoT device reader may only keep the data a limited amount of time in order to save its power and memory.

[0310] In another example, the A-IoT device reader may be configured with a data threshold. For example, since the A-IoT device reader may continue to receive the data from the A-IoT devices 3-1 even though it lost the RRC connection with the network, a data limit / threshold may be configured. At the point that the data limit / threshold is reached, the A-IoT device reader may then attempt to re-establish an RRC connection with the network and forward the data onto a RAN node 5-1 and / or the CN 7.

[0311] In another example, the A-IoT device reader may be configured to only attempt to re-establish an RRC connection with the network to perform data forwarding when data transmission between the A-IoT devices 3-1 and the A-IoT device reader has completed or terminated. For example, the A-IoT device reader can determined whether data transmissions from the A-IoT devices 3-1 have come to an end based on the resource allocation for D2R transmissions (i.e., once all resource allocated have be used). Alternatively, the A-IoT devices 3-1 may send an appropriate indication to the A-IoT device reader when data transmissions have come to an end.

[0312] In yet another example, the A-IoT device reader may be configured to not attempt to re-establish an RRC connection with the network to perform data forwarding unless the network pages the A-IoT device reader requesting the A-IoT device reader to attempt to re-establish an RRC connection with the network.

[0313] In yet a further example, the A-IoT device reader may be configured to attempt to re-establish an RRC connection with the network only when cellular coverage is available.

[0314] Following the RRC connection re-establishment with a RAN node 5-1 (e.g., the initial RAN node 5-1 or another RAN node 5-1), the A-IoT device reader may forward the data first onto the RAN node 5-1 (step S914), which may in turn forward the data onto the CN 7 (step S916). It will be appreciated that steps S914 and S916 are synonymous with steps S518 and S520 respectively of the procedure shown in Fig. 5.

[0315] <Devices in the Communication System> <User Equipment> 　　Fig. 10 is a simplified block schematic illustrating the main components of a UE 3-2; 3-3 for implementation in the communication system 1. It will be appreciated that the UE 3-2; 3-3 may be configured to operate as an intermediate / assisting node 5-2 (i.e., and A-IoT device reader) in the communication system 1.

[0316] 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 RAN node 5-1 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-2; 3-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 (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.

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

[0318] 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 3 and / or core network nodes). The communication control module 43 is configured for the overall handling of uplink communication 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 communication 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-2; 3-3 for transmission / reception of UL / DL communication (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.

[0319] Where the UE 3-2, 3-3 is configured to operate as an intermediate / assisting node 5-2 (i.e., as an A-IoT device reader) the communication control module 43 may be operable to control the communication between the A-IoT device 3-1 and the UE 3-2, 3-3, for example, via the associated physical channels (e.g., via a physical D2R channel (PDRCH), random access channel (RACH), and / or a physical R2D channel (PRDCH)).

[0320] 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 UE 3-2, 3-3 may include sub-modules corresponding to the layers of a conventional protocol stack (PHY, MAC, RRC, RLC, PDCP etc.). Moreover, where the UE 3-2, 3-3 is configured to operate as an intermediate / assisting node 5-2, communication control module 43 may include sub-modules corresponding to the layers of a dedicated ambient IoT device protocol stack for controlling functions associated with those layers.

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

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

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

[0324] The transceiver circuit 331 may comprise energy harvesting circuitry 331-1 that is configured to harvest and / or collect energy from an ambient energy source such as an incoming signal and / or other ambient sources of energy (e.g., of light, vibrations, or heat). That collected energy may then be provided to other modules of A-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.

[0325] 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 A-IoT device 3-1. By way of example only, the A-IoT device 3-1 may harvest energy from solar cells such as dye-sensitised solar cells (DSSCs).

[0326] The transceiver circuit 331 also has modulation circuitry 331-2 which modulates an incoming unmodulated carrier signal to the A-IoT device 3-1 to produce the modulated backscatter signal to be reflected from the A-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 A-IoT device 3-1 by altering the impedance or reflectivity of the A-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 A-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.

[0327] 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 A-IoT device 3-1 for receipt at another device.

[0328] In this example, the A-IoT device 3-1 also has a controller 337 to control the overall operation of the A-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 A-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.

[0329] The controller 337 is configured to control overall operation of the A-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.

[0330] The communication control module 343 is operable to control the communication between the A-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 communication via associated physical channels (e.g., via a physical D2R channel (PDRCH), random access channel (RACH), and / or a physical R2D channel (PRDCH)).

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

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

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

[0334] 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, A-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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0369] For example, the whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes. 　　(Supplementary note 1) 　　A method performed by an intermediate device for relaying communication between a base station and a mobile device, the method comprising: 　　receiving, from the base station, a message for allocating at least one random access resource for communicating with the mobile device; 　　communicating with the mobile device using the at least one random access resource. 　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　the at least one random access resource includes at least one of: 　　　　a random access resource for transmitting an initial trigger message, or 　　　　a random access resource for communicating a data via a random access procedure. 　　(Supplementary note 3) 　　The method according to supplementary note 1 or 2, wherein 　　the at least one random access resource is shared with at least one mobile device which is connected with the intermediate device. 　　(Supplementary note 4) 　　The method according to supplementary note 1 or 2, wherein 　　the at least one random access resource is dedicated to each of with at least one mobile device which is connected with the intermediate device. 　　(Supplementary note 5) 　　The method according to any one of supplementary notes 1 to 4, wherein 　　the message is transmitted in at least one of: 　　　　a dedicated signaling, or 　　　　a system information block. 　　(Supplementary note 6) 　　The method according to any one of supplementary notes 1 to 4, wherein 　　the at least one random access resource for communicating with the mobile device is preconfigured at the intermediate device. 　　(Supplementary note 7) 　　The method according to any one of supplementary notes 1 to 6, wherein 　　the at least one random access resource includes a random access resource for communicating a data via a random access procedure, 　　the random access resource for communicating the data via the random access procedure is dedicated to each of with at least one mobile device which is connected with the intermediate device. 　　(Supplementary note 8) 　　The method according to any one of supplementary notes 1 to 7, wherein 　　the at least one random access resource includes: 　　　　a random access resource for transmitting an initial trigger message, and 　　　　a random access resource for communicating a data via a random access procedure, and the method comprises: 　　allocating the random access resource for communicating the data via the random access procedure, after successfully transmitting the initial trigger message using the random access resource for transmitting the initial trigger message. 　　(Supplementary note 9) 　　The method according to any one of supplementary notes 1 to 7, wherein 　　the at least one random access resource includes: 　　　　a random access resource for transmitting an initial trigger message, and 　　　　a random access resource for communicating a data via a random access procedure, and the method comprises: 　　allocating the random access resource for transmitting an initial trigger message and the random access resource for communicating the data via the random access procedure before transmitting the initial trigger message. 　　(Supplementary note 10) 　　The method according to any one of supplementary notes 1 to 9, wherein 　　the at least one random access resource includes a random access resource for both transmitting an initial trigger message and communicating a data via a contention free random access procedure. 　　(Supplementary note 11) 　　The method according to any one of supplementary notes 1 to 10, further comprising: 　　in a case where the intermediate device is in a radio resource control (RRC) idle state, receiving a paging message for moving to a RRC connected state before receiving the message. 　　(Supplementary note 12) 　　The method according to any one of supplementary notes 1 to 11, further comprising: 　　establishing a radio resource control (RRC) connection via a random access procedure before receiving the message. 　　(Supplementary note 13) 　　The method according to any one of supplementary notes 1 to 12, wherein 　　the message includes information indicating whether the intermediate device is for receiving the data from the mobile device or for transmitting the data to the mobile device, and 　　the communicating is performed based on the information. 　　(Supplementary note 14) 　　The method according to supplementary note 13, further comprising: 　　in a case where the information indicates the intermediate device is for transmitting the data, transmitting the initial trigger message to the mobile device. 　　(Supplementary note 15) 　　The method according to supplementary note 14, wherein 　　the initial trigger message includes information indicating an intermediate device for receiving the data and information indicating at least one random access resource for the mobile device in transmitting the data to the intermediate device for receiving the data. 　　(Supplementary note 16) 　　The method according to any one of supplementary notes 13 to 15, further comprising: 　　in a case where the information indicates the intermediate device is for receiving the data, monitoring the at least one random access resource for receiving the data from the mobile device. 　　(Supplementary note 17) 　　The method according to supplementary note 16, further comprising: 　　receiving the data via the at least one random access resource from the mobile device; 　　informing the base station of receiving the data from the mobile device, and wherein 　　the base station transmits, to an intermediate device for transmitting other data, a message for allocating at least one random access resource for transmitting the other data, upon the informing. 　　(Supplementary note 18) 　　The method according to supplementary note 16 or 17, wherein 　　establishing a radio resource control (RRC) connection with the base station after receiving the data. 　　(Supplementary note 19) 　　The method according to any one of supplementary notes 1 to 18, further comprising: 　　receiving the data via the at least one random access resource from the mobile device; 　　in a case where the intermediate device is out of coverage of the base station or experiences a radio link failure with a connection with the base station, storing the data until forwarding the data to the base station. 　　(Supplementary note 20) 　　The method according to supplementary note 19, wherein 　　the storing the data continues during a predetermined time duration. 　　(Supplementary note 21) 　　A method performed by a base station for communicating data to a mobile device via an intermediate device, the method comprising: 　　transmitting, to the intermediate device, a message for allocating at least one random access resource for the intermediate device in communicating with the mobile device, and wherein 　　the at least one random access resource is used by the intermediate device for communicating with the mobile device. 　　(Supplementary note 22) 　　An intermediate device for relaying communication between a base station and a mobile device, the intermediate device comprising: 　　means for receiving, from the base station, a message for allocating at least one random access resource for communicating with the mobile device; 　　means for communicating with the mobile device using the at least one random access resource. 　　(Supplementary note 23) 　　A base station for communicating data to a mobile device via an intermediate device, the base station comprising: 　　means for transmitting, to the intermediate device, a message for allocating at least one random access resource for the intermediate device in communicating with the mobile device, and wherein 　　the at least one random access resource is used by the intermediate device for communicating with the mobile device.

[0370] This application is based upon and claims the benefit of priority from Great Britain Patent Application No. 2413905.7, filed on September 20, 2024, the disclosure of which is incorporated herein in its entirety by reference.

[0371] 1 COMMUNICATION SYSTEM 3 USER EQUIPMENT 5 BASE STATION 7 CORE NETWORK 9 CELL 10 CONTROL PLANE FUNCTIONS 11 USER PLANE FUNCTIONS 21 EXTERNAL DATA NETWORK 31 TRANSCEIVER CIRCUIT 33 ANTENNA 35 USER INTERFACE 37 CONTROLLER 39 MEMORY 41 OPERATING SYSTEM 43 COMMUNICATIONS CONTROL MODULE 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 338 PROCESSING CIRCUITRY 339 MEMORY 341 OPERATING SYSTEM 343 COMMUNICATIONS CONTROL MODULE 345 DATA BUFFER 51 TRANSCEIVER CIRCUIT 53 ANTENNA 55 CORE NETWORK INTERFACE 57 CONTROLLER 59 MEMORY 61 OPERATING SYSTEM 63 COMMUNICATIONS CONTROL MODULE 151 TRANSCEIVER CIRCUIT 153 ANTENNA 155 RAN INTERFACE 157 CONTROLLER 159 MEMORY 161 OPERATING SYSTEM 163 COMMUNICATIONS CONTROL MODULE

Claims

A method performed by an intermediate device for relaying communication between a base station and a mobile device, the method comprising:　　receiving, from the base station, a message for allocating at least one random access resource for communicating with the mobile device;　　communicating with the mobile device using the at least one random access resource.　　The method according to claim 1, wherein　　the at least one random access resource includes at least one of:　　　　a random access resource for transmitting an initial trigger message, or　　　　a random access resource for communicating a data via a random access procedure.　　The method according to claim 1 or 2, wherein　　the at least one random access resource is shared with at least one mobile device which is connected with the intermediate device.　　The method according to claim 1 or 2, wherein　　the at least one random access resource is dedicated to each of with at least one mobile device which is connected with the intermediate device.　　The method according to any one of claims 1 to 4, wherein　　the message is transmitted in at least one of:　　　　a dedicated signaling, or　　　　a system information block.　　The method according to any one of claims 1 to 4, wherein　　the at least one random access resource for communicating with the mobile device is preconfigured at the intermediate device.　　The method according to any one of claims 1 to 6, wherein　　the at least one random access resource includes a random access resource for communicating a data via a random access procedure,　　the random access resource for communicating the data via the random access procedure is dedicated to each of with at least one mobile device which is connected with the intermediate device.　　The method according to any one of claims 1 to 7, wherein　　the at least one random access resource includes:　　　　a random access resource for transmitting an initial trigger message, and　　　　a random access resource for communicating a data via a random access procedure, and the method comprises:　　allocating the random access resource for communicating the data via the random access procedure, after successfully transmitting the initial trigger message using the random access resource for transmitting the initial trigger message.　　The method according to any one of claims 1 to 7, wherein　　the at least one random access resource includes:　　　　a random access resource for transmitting an initial trigger message, and　　　　a random access resource for communicating a data via a random access procedure, and the method comprises:　　allocating the random access resource for transmitting an initial trigger message and the random access resource for communicating the data via the random access procedure before transmitting the initial trigger message.　　The method according to any one of claims 1 to 9, wherein　　the at least one random access resource includes a random access resource for both transmitting an initial trigger message and communicating a data via a contention free random access procedure.　　The method according to any one of claims 1 to 10, further comprising:　　in a case where the intermediate device is in a radio resource control (RRC) idle state, receiving a paging message for moving to a RRC connected state before receiving the message.　　The method according to any one of claims 1 to 11, further comprising:　　establishing a radio resource control (RRC) connection via a random access procedure before receiving the message.　　The method according to any one of claims 1 to 12, wherein　　the message includes information indicating whether the intermediate device is for receiving the data from the mobile device or for transmitting the data to the mobile device, and　　the communicating is performed based on the information.　　The method according to claim 13, further comprising:　　in a case where the information indicates the intermediate device is for transmitting the data, transmitting the initial trigger message to the mobile device.　　The method according to claim 14, wherein　　the initial trigger message includes information indicating an intermediate device for receiving the data and information indicating at least one random access resource for the mobile device in transmitting the data to the intermediate device for receiving the data.　　The method according to any one of claims 13 to 15, further comprising:　　in a case where the information indicates the intermediate device is for receiving the data, monitoring the at least one random access resource for receiving the data from the mobile device.　　The method according to claim 16, further comprising:　　receiving the data via the at least one random access resource from the mobile device;　　informing the base station of receiving the data from the mobile device, and wherein　　the base station transmits, to an intermediate device for transmitting other data, a message for allocating at least one random access resource for transmitting the other data, upon the informing.　　The method according to claim 16 or 17, wherein　　establishing a radio resource control (RRC) connection with the base station after receiving the data.　　The method according to any one of claims 1 to 18, further comprising:　　receiving the data via the at least one random access resource from the mobile device;　　in a case where the intermediate device is out of coverage of the base station or experiences a radio link failure with a connection with the base station, storing the data until forwarding the data to the base station.　　The method according to claim 19, wherein　　the storing the data continues during a predetermined time duration.　　A method performed by a base station for communicating data to a mobile device via an intermediate device, the method comprising:　　transmitting, to the intermediate device, a message for allocating at least one random access resource for the intermediate device in communicating with the mobile device, and wherein　　the at least one random access resource is used by the intermediate device for communicating with the mobile device.　　An intermediate device for relaying communication between a base station and a mobile device, the intermediate device comprising:　　means for receiving, from the base station, a message for allocating at least one random access resource for communicating with the mobile device;　　means for communicating with the mobile device using the at least one random access resource.　　A base station for communicating data to a mobile device via an intermediate device, the base station comprising:　　means for transmitting, to the intermediate device, a message for allocating at least one random access resource for the intermediate device in communicating with the mobile device, and wherein　　the at least one random access resource is used by the intermediate device for communicating with the mobile device.

Images