Method performed by access network node, method performed by core network node, access network node and core network node

Abstract

An aspect of this disclosure includes a method performed by a mobile device,. The method includes receiving, from an access network node, information for configuring continuous measurements across a plurality of a Radio Resource Control (RRC) states of the mobile device, performing the continuous measurements in one or more of the plurality of the RRC states, based on the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device; and,transmitting, to the access network node, respective measurement reports corresponding to the one or more of the plurality of the RRC states, the respective measurement reports including information for tracing a process of the continuous measurements across the plurality of the RRC states.

Description

METHOD PERFORMED BY ACCESS NETWORK NODE, METHOD PERFORMED BY CORE NETWORK NODE, ACCESS NETWORK NODE AND CORE NETWORK NODE

[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 A-IoT device reader selection procedures in a communication system where multiple A-IoT device readers are capable of supporting / contacting A-IoT devices in the communication systems.

[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 the MME in 4G and performs many of the functions performed by the MME. Each UPF combines functionality of both the 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 3 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, in the A-IoT device: 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 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] 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.

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

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

[0040] To-date, much progress has been made in developing appropriate A-IoT-based procedures for: -　　Signalling (e.g., paging) A-IoT devices that an A-IoT device reader wishes to access; -　　Triggering A-IoT-based RA procedures between A-IoT devices and an A-IoT device reader to enable inventory / command requests and data transmissions between A-IoT devices and A-IoT device reader; and -　　Procedures for data transmissions between A-IoT devices and A-IoT device reader.

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

[0042] However, it will be appreciated that it may not be known in advance whether one or more A-IoT device readers will be within a specific region / area, nor which A-IoT device reader (or readers) will be in that specific region / area, e.g., a A-IoT device reader may move in or out of the specific region / area. Consequently, before triggering the above described A-IoT based procedure for an A-IoT service (e.g., for inventory of A-IoT devices in a specific area), one or multiple A-IoT device readers capable of contacting A-IoT devices in this specific region / area and in their respective vicinities should be discovered and selected first.

[0043] Additionally, it will be appreciated that in real world scenarios a communication system may comprise multiple A-IoT device readers capable of supporting A-IoT services with a plurality of A-IoT devices in their respective vicinities. For example, the plurality of A-IoT device readers may be are capable of contacting A-IoT devices that are distanced between each other within a specific region / area, and which have a limited communication range. Each A-IoT device reader of the plurality of A-IoT device readers may also able to contact a different respective subset of A-IoT devices (where different subsets of A-IoT devices may or may not overlap). In this scenario, it will be appreciated that it may be efficient to allow the selection of all of the A-IoT device readers for an A-IoT service targeting that specific region / area e.g., in this case the A-IoT service tragetted region / area may be bigger than a coverage region / area of any one A-IoT device reader.

[0044] In another example, in any one specific region / area a plurality of A-IoT devices may be contactable by any one or more of a plurality of A-IoT device readers. Yet, although any one or more of the plurality of A-IoT device readers are capable of contacting A-IoT devices in that specific region / area, to do so may result in high levels of signalling / data transmission redundancy, causing large inefficiencies in the communication system; for example if multiple A-IoT device readers attempt to contact the A-IoT devices at the same time.

[0045] Additionally, it will be appreciated that in the scenario described above where multiple A-IoT device readers attempt to contact the A-IoT devices at the same time, there is also a high risk of contention issues and transmission collisions occurring.

[0046] Furthermore, it will be appreciated that although any one or more of the plurality of A-IoT device readers may be capable of contacting the plurality of A-IoT devices in a specific region / area, it may be preferable for a particular one of the plurality of A-IoT device readers to contact the A-IoT devices e.g., based on a condition of the particular A-IoT device reader and / or A-IoT devices in question.

[0047] Appropriate procedures and enhancements are therefore needed to enable / support the network to discover and or select an A-IoT device reader (or readers) in scenarios where one or more than one A-IoT device readers are capable of contacting a plurality of A-IoT devices in a specific region / area.

[0048] Additionally, having provided procedures and enhancements to enable / support the network to select an A-IoT device reader (or readers) in scenarios where more than one A-IoT device readers are capable of contacting a plurality of A-IoT devices in a specific region / area, appropriate complementary procedures and enhancements may be needed to indicate whether any selected A-IoT device reader (or readers) has appropriate permissions / authentications.

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

[0050] The disclosure has a method performed by an access network node, the method comprising selecting at least one reader device for communicating carrier-wave for backscattering with a mobile device, based on interaction with a core network node.

[0051] The disclosure has a method performed by a core network node, the method comprising: 　　interacting, with an access network node for selecting at least one reader device for communicating carrier-wave for backscattering with a mobile device.

[0052] The disclosure has an access network node comprising means for selecting at least one reader device for communicating carrier-wave for backscattering with a mobile device, based on interaction with a core network node.

[0053] The disclosure has a core network node comprising means for interacting, with an access network node for selecting at least one reader device for communicating carrier-wave for backscattering with a mobile device.

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

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

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

[0057] Fig. 1 illustrates schematically a mobile (cellular or wireless) communication system to which example embodiments of the disclosure may be applied;Fig. 2 illustrates schematically a first connectivity topology that may be used in the communication system of Fig.1;Fig. 3 illustrates schematically a second connectivity topology that may be used in the communication system of Fig. 1;Fig. 4A illustrates schematically a third connectivity topology that may be used in the communication system of Fig. 1;Fig. 4B illustrates schematically another arrangement of the third connectivity topology of Fig. 4A;Fig. 5 is a simplified sequence diagram of an example A-IoT random access procedure that may be implemented in the communication system of Fig. 1;Fig. 6 is a simplified sequence diagram of another example A-IoT random access procedure that may be implemented in the communication system of Fig. 1;Fig. 7 is a simplified sequence diagram of an Access Stratum procedure between an A-IoT device and an A-IoT device reader that may be implemented in the communication system of Fig. 1;Fig. 8 illustrates an example simplified protocol stack architecture for communication between an A-IoT AMF, an A-IoT device reader, and A-IoT device, which may be used in the communication system of Fig. 1;Fig. 9 illustrates an example simplified protocol stack architecture for communication between a core network, a base station (RAN node), an A-IoT device reader, and an A-IoT device, which may be used in the communication system of Fig. 1;Fig. 10 illustrates an example of another simplified protocol stack architecture for communication between a core network, a base station (RAN node), an A-IoT device reader, and an A-IoT device, which may be used in the communication system of Fig. 1;Fig. 11 illustrates a one possible version of the simplified protocol stack architecture of Fig. 10 in more detail;Fig. 12 illustrates another possible version of the simplified protocol stack architecture of Fig. 10 in more detail;Fig. 13 schematically illustrates several cell coverage areas provided by several different RAN nodes of the communication system with different A-IoT device readers located within those several cell coverage areas;Fig. 14 illustrates a simplified sequence diagram of a procedure for selecting one or more RAN node-assisted A-IoT device readers for provision of an upcoming A-IoT service that may be implemented in the communication system of Fig. 1;Fig. 15 illustrates a simplified sequence diagram of another procedure for selecting one or more RAN node-assisted A-IoT device readers for provision of an upcoming A-IoT service that may be implemented in the communication system of Fig. 1;Fig. 16A illustrates a simplified sequence diagram of an example paging procedure for discovery of A-IoT device readers that may be implemented in the A-IoT device reader selection procedures of Fig. 14 and Fig. 15;Fig. 16B illustrates a simplified sequence diagram of an example RACH-less and RRC connection-less paging procedure for discovery of A-IoT device readers that may be implemented in the A-IoT device reader selection procedures of Fig. 14 and Fig. 15;Fig. 17 illustrates a simplified sequence diagram of an example A-IoT device reader authentication procedure that may be implemented in the communication system of Fig. 1;Fig. 18 illustrates a simplified sequence diagram of another example A-IoT device reader authentication procedure that may be implemented in the communication system of Fig. 1;Fig. 19 illustrates a simplified sequence diagram of yet another example A-IoT device reader authentication procedure that may be implemented in the communication system of Fig. 1;Fig. 20 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. 21 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. 22 is a simplified block schematic illustrating the main components of a RAN node that may be used in the communication system of Fig. 1;Fig. 23 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; andFig. 24 is a schematic block diagram illustrating the main components of a core network function for the communication system of Fig. 1.

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

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

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

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

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

[0063] 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 that communicates with the A-IoT device 3-1 via an appropriate reader-to-A-IoT device or air 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.

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

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

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

[0067] The core network (CN) 7 includes a number of logical nodes (or 'functions') for supporting communication in the communication system 1. In this example, the CN 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.

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

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

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

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

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

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

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

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

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

[0077] 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 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 3 to a connected state.

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

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

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

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

[0082] <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 4.

[0083] Fig. 2 illustrates schematically a first connectivity topology (topology 1) that may be used in the communication system 1.

[0084] As shown in Fig. 2, in 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 20 (20-1, 20-2) 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 20 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.

[0085] 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. This unmodulated carrier signal is, in turn, modulated and backscattered / reflected by the A-IoT device 3-1, as a backscattered signal 20-2, to the RAN node 5-1. Such transmission of an unmodulated carrier, and receipt of backscattering by the same RAN node (base station) 5-1 may, for example, be supported by topology 1 where full duplex operation is supported at that RAN node 5-1.

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

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

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

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

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

[0091] Fig. 3 illustrates schematically a second connectivity topology (topology 2) that may be used in the communication system 1.

[0092] As shown in Fig. 3, in 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. 3 as being a type of base station, the intermediate node 5-2 may in fact be any one of an IAB node, a UE 3, a repeater, or the like, or any other appropriate device, as described above, that can act as an intermediary between a RAN node 5-1 and an A-IoT device 3-1 and that is capable of supporting ambient IoT signalling.

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

[0094] Specifically, the communication 20-1, 20-2 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 or a dedicated interface.

[0095] 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-3 between the RAN node 5-1 and the intermediate node 5-2. The downlink signal, once received by the intermediate node 5-2, may trigger transmission of an unmodulated carrier signal 20-1 to the A-IoT device 3-1 (e.g., on a 'sidelink' or similar). The downlink signal may be (or may carry) the unmodulated carrier signal 20-1 that is to be transmitted (e.g. relayed) by the intermediate node 5-2 to the A-IoT device 3-1 or may be a trigger signal for triggering transmission of the unmodulated carrier signal 20-1.

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

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

[0098] Communication 20-3 between the RAN node 5-1 and the intermediate node 5-2 may occur over any appropriate interface. For example, the RAN node 5-1 and intermediate node 5-2 may communicate over an air interface (such as the Uu interface or the like), for example where the intermediate node 5-2 is a UE 3 (or at least acts like a UE 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.

[0099] It will be appreciated that the intermediate node 5-2 may be of a type that attempts to demodulate the received backscattered signal for subsequent forwarding of the data to the RAN node 5-1 (e.g., a layer-2 (L2) relay device that attempts to demodulate any layer-1 (L1) signals that it receives). Such an intermediate node 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 may be referred to as be a layer 1 ('L1') type intermediate node 5-2.

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

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

[0102] Topology 2 may also be deployed for outdoor scenarios with a type 1, 2a or 2b IoT device A-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.

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

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

[0105] 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 5-2). It will be appreciated that while the assisting node 5-2 is depicted in Fig. 4A and Fig. 4B as a type of base station, the assisting node 5-2 may in fact be any one of an IAB node, a UE 3, a repeater, or the like, or any other appropriate device that can act as an intermediary between a RAN node 5-1 and an A-IoT device 3-1.

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

[0107] As shown in Fig. 4A, the A-IoT device 3-1 may communicate with a RAN node 5-1 in a downlink direction and an assisting (intermediate) node 5-2 in an uplink direction (e.g., on a 'sidelink' or similar). The communication between the RAN node 5-1 and the 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.

[0108] In this example the RAN node 5-1 (base station / cell) is responsible for transmission of an unmodulated carrier signal 20-1 to the A-IoT device 3-1. This unmodulated carrier signal 20-1 may subsequently be modulated and backscattered, as a modulated backscattered signal 20-2, 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 signal 20-2 from the A-IoT device 3-1. The modulated backscattered signal 20-2 (or at least the information encoded in it), once received by the assisting node 5-2, may be relayed (forwarded / transmitted) to the RAN node 5-1. The modulated backscattered signal may be processed before being relayed / forwarded by the assisting node 5-2 to the RAN node 5-1. For example, the modulated backscattered signal may be processed by the assisting node 5-2 to extract information encoded in the modulated backscattered signal, and to encapsulate the extracted information into an appropriate message format (e.g., in accordance with a corresponding application protocol) for communication with the RAN node 5-1. Alternatively, the modulated backscattered signal may itself be processed by the assisting node 5-2 (without extracting any data encoded in it) to encapsulate it into an appropriate message format (e.g., in accordance with a corresponding application protocol) for communication with the RAN node 5-1.

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

[0110] 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 sent to the assisting node 5-2 for relaying / forwarding to the RAN node 5-1.

[0111] Alternatively, as shown in Fig. 4B, the A-IoT device 3-1 may communicate with a RAN node 5-1 in an uplink direction and an assisting (intermediate) node 5-2 in a downlink direction (e.g., on a 'sidelink' or similar). The communication between the RAN node 5-1 and 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.

[0112] 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. This unmodulated carrier signal 20-1 may be subsequently modulated and backscattered, as a modulated backscattered signal 20-2, 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 signal 20-2 from the A-IoT device 3-1. The transmission of the unmodulated carrier signal 20-1 may be triggered by a downlink signal 20-3 received by the assisting node 5-2 from the RAN node 5-1. For example, the downlink signal 20-3 may be (or may carry) the unmodulated carrier signal 20-1 that is to be transmitted (e.g. relayed) by the intermediate node 5-2 to the A-IoT device 3-1 or may be a trigger signal for triggering transmission of the unmodulated carrier signal 20-1.

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

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

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

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

[0117] <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) 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) acting as the A-IoT device reader and the A-IoT device 3-1. 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.

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

[0119] 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, 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, that act as A-IoT device readers in a scenario in which two intermediate nodes 5-2 (or intermediate UEs 3) provide A-IoT device reader functions for a given A-IoT device 3-1. For example a scenario in which one intermediate node acts as a transmitter A-IoT device reader that transmits R2D signals to the A-IoT device 3-1, and one intermediate node acts as a receiver A-IoT device reader that receives D2R signals from the A-IoT device 3-1.

[0120] 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) acting as an A-IoT device reader; and / or for handling a scenario in which one or more intermediate nodes (e.g., intermediate UEs 3) acting as A-IoT device readers are temporarily outside the coverage area of the RAN node 5-1.

[0121] There now follows a detailed description of a four-step and a two-step A-IoT random access procedure (A-IoT RA) that may be implemented in the communication system 1.

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

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

[0124] <Four-Step A-IoT RA> 　　Fig. 5 is a simplified sequence diagram of an example A-IoT 'four-step' random access procedure that may be implemented in the communication system 1.

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

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

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

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

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

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

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

[0132] <Two-Step A-IoT RA> 　　Fig. 6 is a simplified sequence diagram of an example A-IoT 'two-step' random access procedure that may be implemented in the communication system 1.

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

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

[0135] Having been triggered by an R2D initial trigger message (A-IoT Msg0), the A-IoT device sends, at S606, an initial device-to-reader (D2R) message ('A-IoT Msg1') using the selected RA occasion (time / frequency resources). The initial D2R message (A-IoT Msg1) carries the A-IoT device's device identifier (or possibly a short version of that identifier) (and / or a (sub)group identifier), and possibly other information, to the A-IoT device reader. The A-IoT device's device identifier may be at least locally unique and / or may be a temporary identifier allocated by the network.

[0136] If the initial D2R message (A-IoT Msg1) is received successfully at the A-IoT device reader (e.g., because there is no contention or other interference that causes a reception failure), then the A-IoT device reader sends, at S608, an appropriate R2D transmission / message ('A-IoT Msg2') as an access response. The R2D transmission / message (A-IoT Msg2) may, for example, carry all (or part) of the identity information received in the initial D2R message (A-IoT Msg1). Accordingly, the R2D response message (A-IoT Msg2) effectively serves as contention resolution - the A-IoT device 3-1 assumes contention resolution to have been successful, if a received R2D response message (A-IoT Msg2) includes corresponding identity information that was sent by that A-IoT device in the initial D2R message (A-IoT Msg1).

[0137] The R2D transmission / message (A-IoT Msg2) may also (or alternatively) comprise an R2D data message (e.g., an inventory command or inventory request) or possibly an upper layer configuration. It will be appreciated that an inventory command may be used to configure the device (in which case there may be no follow-up message from the A-IoT device reader and so that access cycle / RA procedure may end). An inventory request, on the other hand requests a response from the A-IoT device 3-1 and so there will be a follow-up D2R message ('A-IoT Msg3'). In a case where an R2D data transmission (A-IoT Msg2) is received by the A-IoT device 3-1 that comprises an inventory request, then the A-IoT device 3-1 may respond appropriately (as seen at S514). For example, the A-IoT device 3-1 may send a D2R data transmission / message ('A-IoT Msg3') to the A-IoT device reader - for example to respond to an inventory request if provided with the previous R2D data transmission (A-IoT Msg2).

[0138] < Overall Access Stratum (AS) Procedure> 　　Fig. 7 is a simplified sequence diagram of an example AS procedure between A-IoT devices and an A-IoT device reader that may be implemented in the communication system 1.

[0139] As shown in Fig, 7, the RA procedure of Fig. 5 and / or Fig. 6 may form part of an overall AS procedure between the A-IoT devices and an A-IoT device reader.

[0140] At step S702 (which is part of 'Step A: A-IoT Paging'), the A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like), having decided that it wishes to perform an operation with respect to one or more A-IoT devices 3-1, may send an appropriate paging message to those A-IoT devices 3-1. For example, the A-IoT device reader may wish to perform an inventory procedure, or the like, to discover which A-IoT devices 3-1 are in its vicinity with which it can communicate.

[0141] Alternatively (or additionally), the A-IoT device reader may wish to send an appropriate A-IoT command to one or more A-IoT devices 3-1 with which it can communicate in order to perform an action such as reading data from the one or more A-IoT devices 3-1, writing data to the one or more A-IoT devices 3-1, and / or enabling / disabling one or more of the A-IoT devices 3-1.

[0142] The paging message sent by the A-IoT device reader to the A-IoT devices 3-1 may, for example, be any appropriate message capable of triggering the one or more A-IoT devices 3-1 to switch from a 'sleep' state to an 'awake' state where the A-IoT devices 3-1 are asleep to reduce power and energy consumption when not being accessed. Additionally (or alternatively), the paging message may inform the A-IoT devices 3-1 that the A-IoT device reader wishes to access one or more of the A-IoT devices 3-1. The paging message may also, by an appropriate ID, or the like, indicate which A-IoT devices 3-1 the A-IoT device reader wishes to access. It will be appreciated that the paging message may be the same, or similar to, the initial trigger message (A-IoT Msg0) described with reference to Fig. 5 or Fig. 6 above.

[0143] Having received the paging message at step S702, the A-IoT device reader and the A-IoT devices 3-1 that it paged may begin an RA procedure at step S704 (first step of 'Step B: D2R data transmission). It will be appreciated that the RA procedure performed between the A-IoT device reader and the A-IoT devices 3-1 may be the same, or similar to, a corresponding part or parts of the two-step or four-step RA procedure described above with reference to Figs. 5 and 6. It will also be appreciated that the RA procedure at step S704 may not be performed between the A-IoT device reader and the A-IoT devices 3-1 paged at step S702 if those specific A-IoT devices 3-1 are already in RRC connected state with the A-IoT device reader.

[0144] At step S706 (after successfully completing an RA procedure where necessary), the A-IoT devices 3-1 may begin to transmit data to the A-IoT device reader on a D2R data transmission link.

[0145] At step S708, the A-IoT device reader may, following the data transmissions from the A-IoT devices 3-1 on the D2R data transmission link, send a data transmission to the A-IoT devices 3-1 via a R2D data transmission link (e.g., a (further) read command, write command, or the like). Similarly, at step S710, the A-IoT devices 3-1 may, following the data transmissions from the A-IoT device reader on the R2D data transmission link, send subsequent data transmissions to the A-IoT device reader via the D2R data transmission link.

[0146] It will be appreciated that the steps S708 and S710 may be repeated as many times as necessary to facilitate data transmission between the A-IoT devices 3-1 and the A-IoT device reader.

[0147] <Protocol Stack Architectures for A-IoT Topologies> A description of simplified protocol stack architectures for A-IoT topology 1 and 2, that may be implemented in the communication system 1, will now be described by way of example only with reference to Figs. 8 to 12.

[0148] The protocol stack architecture of Fig. 8 is a protocol stack architecture that may be implemented in the communication system 1 with respect to topology 1 described above, while the protocol stack architectures of Figs. 9 to 12 may be implemented in the communication system 1 with respect to topology 2 described above.

[0149] Fig. 8 illustrates an example simplified protocol stack architecture for communication between an A-IoT AMF 10-3, an A-IoT device reader (e.g., RAN node 5-1), and an A-IoT device 3-1, which may be used in the communication system 1 of Fig. 1;

[0150] In the protocol stack architecture of Fig. 8, an A-IoT device protocol stack comprises an A-IoT non-access stratum (A-IoT NAS) layer 31-2 and an A-IoT access stratum (A-IoT AS) layer 31-4.

[0151] It will be appreciated that the A-IoT device 3-1 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission and / or the like) of that layer.

[0152] The protocol stack architecture also comprises an A-IoT device reader protocol stack. The A-IoT device reader protocol stack includes A-IoT device side layers for communication with corresponding layers of the A-IoT device protocol stack over one or more associated interfaces. The A-IoT device reader protocol stack also includes a number of A-IoT AMF side layers for communication with the A-IoT AMF 10-3 over one or more associated interfaces.

[0153] The A-IoT device-side layers of the A-IoT device reader protocol stack include: an A-IoT AS layer 51-4 for communication with a corresponding A-IoT AS layer 31-4 of the A-IoT device 3-1. Communication between the A-IoT AS layer 51-4 of the A-IoT device reader, and the A-IoT AS layer 31-4 of the A-IoT device 3-1 is facilitated over an appropriate interface therebetween (e.g., an air interface, Uu A-IoT interface, or the like).

[0154] The A-IoT AMF side layers include: an A-IoT application protocol (A-IoT AP) layer 51-6 (which may be part of a radio network layer) for communication with a corresponding A-IoT AP layer 103-6 (e.g., an 'A-IoT NGAP layer') of the A-IoT AMF 10-3. Communication between the A-IoT AP layer 51-6 of the A-IoT device reader, and the A-IoT AP layer 103-6 of A-IoT AMF 10-3 is facilitated over an appropriate interface therebetween (e.g., an NG' or N2' interface, or the like).

[0155] It will be appreciated that the A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like) has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer.

[0156] The protocol stack architecture also comprises an A-IoT AMF protocol stack comprising: an A-IoT non-access stratum (A-IoT NAS) layer 103-2 for communication with a corresponding A-IoT NAS layer 31-2 of the A-IoT device 3-1 and an A-IoT AP layer 103-6 (which may be part of a radio network layer) for communication with a corresponding A-IoT AP layer 51-6 of the A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like). Communication between the A-IoT AP layer 51-6 of the A-IoT device reader, and the A-IoT AP layer 103-6 of A-IoT AMF 10-3 is facilitated over an appropriate interface therebetween (e.g., an N2' interface, or the like), whilst communication between the A-IoT NAS layer 31-2 of the A-IoT device 3-1 and the A-IoT NAS layer 103-2 of A-IoT AMF 10-3 may be facilitated over an appropriate interface therebetween (e.g., an optional N1' interface, or the like), where such communications are necessary.

[0157] It will be appreciated that the CN 7 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer. The core network functional entities may form part of the same or different core network functions. The purpose of the layers mentioned above will be understood by the skilled person and so are only briefly introduced below for the purposes of completeness:

[0158] A-IoT NAS layers 31-2, 103-2: Each A-IoT NAS layer entity of the A-IoT NAS layers 31-2, 103-2, of the A-IoT device 3-1 and the A-IoT AMF 10-3, performs operations and functions associated with the NAS layer such as supporting traffic and signalling messages between the A-IoT AMF 10-3 (i.e., the CN 7) and the A-IoT device 3-1. The A-IoT NAS layer entities also manage the establishment of communication sessions and maintain continuous communication with the A-IoT device 3-1 as it moves.

[0159] Where the respective A-IoT NAS layer entities of the A-IoT NAS layers 31-2 103-2 are responsible for supporting traffic and signalling messages between the A-IoT AMF 10-3 and the A-IoT device 3-1, they may also be responsible for encapsulating data packets received from the application layer (not shown) into specific NAS packet data units (PDUs) for both the DL and UL.

[0160] Specifically, for the UL, e.g., 'device-to-reader' ('D2R') link, at the A-IoT device 3-1, data packets from an application layer (not shown) may be encapsulated, by the associated application layer entity, into specific NAS PDUs, which in turn are delivered to the A-IoT lower layers such as the A-IoT AS layer 31-4 for transmission to the A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like). In that scenario, the corresponding AS entity at the A-IoT device 3-1 may thus perform data segmentation on the data as appropriate. The AS entity of A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like), may in turn perform corresponding data aggregation on the received data segments, before forwarding the data to A-IoT AMF 10-3 as appropriate, e.g., via an appropriate AP message.

[0161] For the DL, e.g., 'reader-to-device' ('R2D') link, the A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like) may firstly receive the data (encapsulated into a NAS PDU) from the A-IoT AMF 10-3 via a specific AP message. Subsequently, AS layer entity of the A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like) may perform data segmentation at the corresponding AS layer 51-4 as appropriate. The AS layer entity of the A-IoT device 3-1, upon receiving the segmented data, may in turn perform data aggregation with the received data segments as appropriate before delivering them to its A-IoT NAS layer 31-2.

[0162] It will be appreciated that from a data forwarding perspective, the data may be encapsulated into a transparent container within the signalling message sent over the corresponding interface (e.g., an NG / N2 or NG / N2 like interface such as a dedicated A-IoT related NG / N2 / XX interface (NG' / N2' / XX)) between the A-IoT AMF 10-3 and RAN node 5-1.

[0163] A-IoT AS layers 31-4, 51-4: Each A-IoT AS layer entity of the A-IoT AS layers 31-4, 51-4, of the A-IoT device 3-1 and the A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like), performs operations and functions associated with the AS layer such as supporting traffic and signalling messages between the A-IoT device reader (e.g., the RAN node 5-1) and the A-IoT device 3-1 over an appropriate interface (e.g., an appropriate air interface).

[0164] A-IoT AP layers 51-6, 103-6: Each A-IoT AP layer entity of the A-IoT AP layers 51-6, 103-6, of the A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like) and the A-IoT AMF 10-3, perform operations and functions associated with the radio network layer such as the establishment, maintenance, and release of the NG-RAN part of PDU sessions between the A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like) and the A-IoT AMF 10-3. Signalling between the respective A-IoT AP layers 51-6, 103-6, at the A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like) and the A-IoT AMF 10-3, may be via any appropriate application protocol (AP) associated with the interface (e.g., AP messages via the NG interface / XX interface) between the A-IoT device reader, and the A-IoT AMF 10-3.

[0165] The A-IoT AP layers 51-6, 103-6 thus control the behavior of A-IoT device reader. For example, the A-IoT AP layers 51-6, 103-6 may control the start of an inventory request, the continuation of an inventory request, and / or the end / termination of an inventory request. In addition, the A-IoT AP layers 51-6, 103-6 provide transport of the A-IoT NAS messages between the A-IoT devices 3-1 and the A-IoT AMF 10-3 (e.g., of the CN 7).

[0166] The protocol architecture of Fig. 8 supports connection management (e.g., 'A-IoT AP connection management') for A-IoT services, which may be used to transfer A-IoT NAS messages and A-IoT inventory requests / commands in corresponding (e.g., 'A-IoT AP') messages.

[0167] It will be appreciated that the description above of the various layers and associated entities are by way of example only, and that those layers and associated entities may also be able to support performance of any other appropriate operations associated with their respective layers, as would be known by the skilled person.

[0168] Fig. 9 illustrat es an example simplified protocol stack architecture for communication between the CN 7, the RAN node 5-1, the A-IoT device reader (e.g., intermediate node 5-2), and the A-IoT device 3-1, which may be used in the communication system 1 of Fig. 1;

[0169] In the protocol stack architecture of Fig, 9, an A-IoT device protocol stack comprises A-IoT upper layers 31-5, and an A-IoT access stratum (A-IoT AS) layer 31-4.

[0170] It will be appreciated that the A-IoT device 3-1 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer.

[0171] The protocol stack architecture also comprises an A-IoT device reader protocol stack. The A-IoT device reader protocol stack includes a number of A-IoT device side layers for communication with corresponding layers of the A-IoT device protocol stack over one or more associated interfaces. The A-IoT device reader protocol stack also includes a number of RAN node side layers for communication with a RAN node (e.g., RAN node 5-1) over one or more associated interfaces.

[0172] The A-IoT device-side layers of the A-IoT device reader protocol stack includes an A-IoT AS layer 52-4 for communication with a corresponding A-IoT AS layer 31-4 of the A-IoT device 3-1.

[0173] The RAN node-side layers of the A-IoT device reader protocol stack include: an RRC layer 52-7 for communication with a corresponding RRC layer 51-7 of the RAN node 5-1; a PDCP layer 52-8 for communication with a corresponding PDCP layer 51-8 of the RAN node 5-1; an RLC layer 52-10 for communication with a corresponding RLC layer 51-10 of the RAN node 5-1; a MAC layer 52-12 for communication with a corresponding MAC layer 51-12 of the RAN node 5-1; and a PHY layer 52-14 for communication with a corresponding PHY layer 51-14 of the RAN node 5-1.

[0174] It will be appreciated that the A-IoT device reader (e.g., intermediate node 5-2) has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer. The A-IoT device reader functional entities may form part of the same or different A-IoT device reader functions.

[0175] The protocol stack architecture also comprises a RAN node protocol stack. The RAN node protocol stack includes a number of A-IoT device reader side layers for communication with corresponding layers of the A-IoT device reader protocol stack over one or more associated interfaces. The RAN node protocol stack also includes a number of core network side layers for communication with the CN 7 over one or more associated interfaces.

[0176] The A-IoT device reader side layers of the RAN node protocol stack include: an RRC layer 51-7 for communication with a corresponding RRC layer 52-7 of the A-IoT device reader; a PDCP layer 51-8 for communication with a corresponding PDCP layer 52-8 of the A-IoT device reader; an RLC layer 51-10 for communication with a corresponding RLC layer 52-10 of the A-IoT device reader; a MAC layer 51-12 for communication with a corresponding MAC layer 52-12 of the A-IoT device reader; and a PHY layer 51-14 for communication with a corresponding PHY layer 52-14 of the A-IoT device reader.

[0177] The core network side layers include: an (e.g., 'NG' / 'XX') application protocol (AP) layer 51-6 (which may be part of a radio network layer) for communication with a corresponding AP layer 7-6 of a corresponding function of the CN 7 (e.g., an A-IoT AMF 10-3 or the like).

[0178] It will be appreciated that the RAN node 5-1 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission and / or the like) of that layer.

[0179] The protocol stack architecture also comprises a core network protocol stack comprising upper layers 7-5 for communication with a corresponding A-IoT upper layers 31-5 of the A-IoT device 3-1; and a (e.g., 'NG' / 'XX') AP layer 7-6 (which may be part of a radio network layer) for communication with a corresponding ('NG' / 'XX') AP layer 51-6 of the the A-IoT device reader (e.g., the RAN node 5-1, intermediate node 5-2, or the like).

[0180] It will be appreciated that the CN 7 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer. The core network functional entities may form part of the same or different core network functions. The purpose of the layers mentioned above will be understood by the skilled person and so are only briefly introduced below for the purposes of completeness:

[0181] ('NG' / 'XX') A-IoT AP layers 51-6, 7-6: Each A-IoT AP layer entity of the A-IoT AP layers 51-6, 7-6, of the A-IoT device reader (e.g., the RAN node 5-1, intermediate node 5-2, or the like) and the corresponding function of the CN 7, perform operations and functions associated with the radio network layer such as the establishment, maintenance, and release of the RAN part of PDU sessions between the A-IoT device reader (e.g., intermediate node 5-2, or the like) and the CN 7. Signalling between the respective A-IoT AP layers 51-6, 7-6, at the A-IoT device reader (e.g., the RAN node 5-1, intermediate node 5-2, or the like) and the CN 7, may be via any appropriate application protocol (AP) associated with the interface (e.g., NG-AP messages via the NG / N2 / XX interface) between the A-IoT device reader, and the CN 7.

[0182] A-IoT AS layers 31-4, 52-4: Each A-IoT AS layer entity of the A-IoT AS layers 31-4, 52-4, of the A-IoT device 3-1 and the A-IoT device reader (e.g., intermediate node 5-2, or the like), performs operations and functions associated with the AS layer such as supporting traffic and signalling messages between the A-IoT device reader (e.g., intermediate node 5-2) and the A-IoT device 3-1 over an appropriate interface (e.g., an appropriate air interface).

[0183] A-IoT RRC layers 51-7, 52-7: Each A-IoT RRC layer entity of the A-IoT RRC layers 51-7, 52-7 performs operations and functions associated with connection establishment and release functions, broadcast of system information, radio bearer establishment, reconfiguration, and release, RRC connection mobility procedures, paging notification.

[0184] A-IoT PDCP layers 51-8, 52-8: Each A-IoT PDCP layer entity of the A-IoT PDCP layers 51-8, 52-8, of the A-IoT device readers (e.g., the RAN node 5-1, intermediate node 5-2, or the like) performs operations and functions associated with the MAC layer (i.e., part of the data link layer) such as the transfer of user plane data between layers, the transfer of control plane data between layers, header compression, ciphering, integrity protection, and / or the like.

[0185] A-IoT RLC layers 51-10, 52-10: Each A-IoT RLC layer entity of the A-IoT RLC layers 51-10, 52-10 transfer of upper layer PDUs (in acknowledged mode (AM), unacknowledged mode (UM) and / or transparent Mode (TM)); error correction through automatic repeat request (ARQ) (for AM data transfer); concatenation, segmentation and reassembly of RLC service data units (SDUs) (UM and AM); re-segmentation of RLC data PDUs (AM); reordering of RLC data PDUs (UM and AM); duplicate detection (UM and AM); RLC SDU discard (UM and AM); RLC re-establishment; protocol error detection and recovery, and / or the like.

[0186] A-IoT MAC layers 51-12, 52-12: Each A-IoT MAC layer entity of the A-IoT MAC layers 51-12, 52-12, of the A-IoT device readers (e.g., the RAN node 5-1, intermediate node 5-2, or the like), performs operations and functions associated with the MAC layer (i.e., part of the data link layer) such as ensuring reliable and efficient communication between two or more devices, and providing unique identification of each device. In particular, the A-IoT MAC layer entities assist in the transferal of data packets over the network. In existing NR MAC functionalities, different logical channels are defined to carry different kinds of information, for example, common control channel (CCCH) and dedicated control channel (DCCH) are defined for control plane signalling, and dedicated traffic channel (DTCH) is defined for user plane data. However, the A-IoT MAC layer may just support a single channel (e.g., with the name of A-IoT MAC-layer channel), as a counterpart for legacy logical channel, for each A-IoT transmission direction to transmit / receive the upper layer SDU.

[0187] A-IoT physical (PHY) layers 51-14, 52-14: Each A-IoT PHY layer entity of the A-IoT PHY layers 51-14, 52-14, of the A-IoT device readers (e.g., the RAN node 5-1, intermediate node 5-2, or the like), performs operations and functions associated with the PHY layer such as establishing, maintaining, and deactivating the physical connection among the A-IoT device readers, and the transmission of individual bits among the A-IoT device readers.

[0188] In the protocol architecture of Fig. 9 there is no direct end-to-end protocol layer between the A-IoT device reader (e.g., an intermediate node 5-2, intermediate UE 3, or the like) and the CN 7 for A-IoT services. Instead, the (Uu) RRC layer 51-7, 52-7 is used to forward the A-IoT NAS messages / A-IoT data of the A-IoT devices 3-1.

[0189] It will be appreciated that the description above of the various layers and associated entities are by way of example only, and that those layers and associated entities may also be able to support performance of any other appropriate operations associated with their respective layers, as would be known by the skilled person.

[0190] Fig. 10 illustrates another example simplified protocol stack architecture for communication between the CN 7, the RAN node 5-1, the A-IoT device reader (e.g., intermediate node 5-2, which in the case of Fig. 10 may be an intermediate UE 3, or the like), and the A-IoT device 3-1, which may be used in the communication system 1 of Fig. 1.

[0191] In the protocol stack architecture of Fig. 10, an A-IoT device protocol stack comprises A-IoT upper layers 8, and an A-IoT access stratum (A-IoT AS) layers 31-4.

[0192] It will be appreciated that the A-IoT device 3-1 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer.

[0193] The protocol stack architecture also comprises an A-IoT device reader protocol stack. The A-IoT device reader protocol stack includes a number of A-IoT device side layers for communication with corresponding layers of the A-IoT device protocol stack over one or more associated interfaces. The A-IoT device reader protocol stack also includes a number of RAN node side layers for communication with a RAN node (e.g., RAN node 5-1) and / or the CN 7 over one or more associated interfaces.

[0194] The A-IoT device-side layers of the A-IoT device reader protocol stack includes A-IoT upper layers 8, and an A-IoT AS layer 52-4 for communication with a corresponding A-IoT AS layer 31-4 of the A-IoT device 3-1.

[0195] The RAN node-side layers of the A-IoT device reader protocol stack include UE upper layers 52-16 for communication with a corresponding set of UE upper layers 7-16 of one or more functions in the CN 7; and a Uu layer 52-18 for communication with a corresponding Uu layer 51-18 of the RAN node 5-1.

[0196] It will be appreciated that the A-IoT device reader (e.g., an intermediate node 5-2) has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer. The A-IoT device reader functional entities may form part of the same or different A-IoT device reader functions.

[0197] The protocol stack architecture also comprises an RAN node protocol stack. The RAN node protocol stack includes a number of A-IoT device reader side layers for communication with corresponding layers of the A-IoT device reader protocol stack over one or more associated interfaces. The RAN node protocol stack also includes a number of core network side layers for communication with the CN 7 over one or more associated interfaces.

[0198] The A-IoT device reader side layers of the RAN node protocol stack includes A-IoT upper layers 8; and an Uu layer 51-18 for communication with the corresponding Uu layer 52-18 of the A-IoT device reader.

[0199] It will be appreciated that the RAN node 5-1 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer.

[0200] The protocol stack architecture also comprises a core network protocol stack comprising: UE upper layers 7-16 for communication with a corresponding UE upper layers 52-16 of the A-IoT device reader; and A-IoT upper layers 8.

[0201] It will be appreciated that the CN 7 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer. The core network functional entities may form part of the same or different core network functions. The purpose of the layers mentioned above will be understood by the skilled person and some of those layers have also already been briefly introduced above. Therefore only some of the layers mentioned above are briefly introduced below for the purposes of completeness:

[0202] UE upper layers 52-16, 7-16: UE upper layers 52-16, 7-16 may, for example, include N1 NAS layers, where each N1 NAS layer entity of the NAS layers that forms part of the UE upper layers 52-16, 7-16, performs operations and functions associated with the NAS layer such as supporting traffic and signalling messages between the CN 7 and the A-IoT device reader. Alternatively (or additionally), UE upper layers 52-16, 7-16 may, for example, include protocol data unit (PDU) layers, where each entity of the PDU layers that forms part of the UE upper layers 52-16, 7-16, perform operations and functions associated with receiving data for packaging into PDU for transmission between the A-IoT device reader (e.g., an intermediate node 5-2) and the CN7, as well as operations and functions associated with de-packaging data they receive from one another.

[0203] Uu layers 51-18, 52-18: Uu layer 51-18 may, for example, include, some or all of the base station side layers of the A-IoT device reader described above with reference to Fig. 9. Similarly Uu layers 52-18 may, for example, include, some or all of the A-IoT device reader side layers of the base station described above with reference to Fig. 9. For example, an RRC layer, a PDCP layer, an RLC layer, a MAC layer, and / or a PHY layer. It will be appreciated that depending on which of those layers are provided in the Uu layers 51-18, 52-18 appropriate layer entities will be provided to perform the operations and functions associated with those layers.

[0204] It will be appreciated that the description above of the various layers and associated entities are by way of example only, and that those layers and associated entities may also be able to support performance of any other appropriate operations associated with their respective layers, as would be known by the skilled person.

[0205] Fig. 11 illustrates a one possible version of the simplified protocol stack architecture of Fig. 10 in more detail. The simplified protocol stack architecture of Fig. 11 is one possible more specific example of the more generic simplified protocol stack architecture shown in Fig. 10 in that the UE upper layers of Fig. 10 are N1 NAS layers in Fig. 11.

[0206] In the protocol stack architecture of Fig. 11, an A-IoT device protocol stack comprises an A-IoT NAS layer 31-2, and an A-IoT access stratum (A-IoT AS) layers 31-4.

[0207] It will be appreciated that the A-IoT device 3-1 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer.

[0208] The protocol stack architecture also comprises an A-IoT device reader protocol stack. The A-IoT device reader protocol stack includes a number of A-IoT device side layers for communication with corresponding layers of the A-IoT device protocol stack over one or more associated interfaces. The A-IoT device reader protocol stack also includes a number of RAN node side layers for communication with a RAN node (e.g., RAN node 5-1) and / or the CN 7 over one or more associated interfaces.

[0209] The A-IoT device-side layers of the A-IoT device reader protocol stack includes an A-IoT AS layer 52-4 for communication with a corresponding A-IoT AS layer 31-4 of the A-IoT device 3-1.

[0210] The RAN node-side layers of the A-IoT device reader protocol stack include: an N1 NAS layer 52-20 for communication with a corresponding N1 NAS layer 7-20 of the CN 7; an Uu-RRC layer 52-7 for communication with a corresponding Uu-RRC layer 51-7 of the RAN node 5-1; and a lower layer (or layers) 52-24 for communication with a corresponding lower layer (or layers) 51-24 of the RAN node 5-1. It will be appreciated that the A-IoT device reader (e.g., an intermediate node 5-2) has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer. The A-IoT device reader functional entities may form part of the same or different A-IoT device reader functions.

[0211] The protocol stack architecture also comprises an RAN node protocol stack. The RAN node protocol stack includes a number of A-IoT device reader side layers for communication with corresponding layers of the A-IoT device reader protocol stack over one or more associated interfaces. The RAN node protocol stack also includes a number of core network side layers for communication with the CN 7 over one or more associated interfaces.

[0212] The A-IoT device reader side layers of the RAN node protocol stack includes an Uu-RRC layer 51-7 for communication with the corresponding Uu-RRC layer 52-7 of the A-IoT device reader; and a lower layer (or layers) 51-24 for communication with the corresponding lower layer (or layers) 52-24 of the A-IoT device reader.

[0213] The core network-side layers of the RAN node protocol stack include: an (NG)AP-C layer 51-26 for communication with a corresponding (NG)AP-C layer 7-26 of the CN 7.

[0214] It will be appreciated that the RAN node 5-1 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer.

[0215] The protocol stack architecture also comprises a core network protocol stack comprising: an A-IoT NAS layer 7-2 for communication with the corresponding A-IoT NAS layer 31-2 of the A-IoT device 3-1; an N1 NAS layer 7-20 for communication with the corresponding N1 NAS layer 52-20 of the A-IoT device reader; and an (NG)AP-C layer 7-26 for communication with a corresponding (NG)AP-C layer 51-26 of the A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like).

[0216] It will be appreciated that the CN 7 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer. The core network functional entities may form part of the same or different core network functions. The purpose of the layers mentioned above will be understood by the skilled person and some of those layers have also already been briefly introduced above. Therefore only some of the layers mentioned above are briefly introduced below for the purposes of completeness:

[0217] N1 NAS layers 52-20, 7-20: Each N1 NAS layer entity of the N1 NAS layers 52-20; 7-20 performs operations and functions associated with the NAS layer such as supporting traffic and signalling messages between the CN 7 and the A-IoT device reader.

[0218] Lower layers 51-24, 52-24: Lower layer 51-24, which may form part of Uu layer 51-18 may, for example, include, some or all of the base station side layers of the A-IoT device reader described above with reference to Fig. 9. Similarly Lower layer 52-24, which may form part of Uu layer 52-18 may, for example, include, some or all of the A-IoT device reader side layers of the base station described above with reference to Fig. 9. For example, an RRC layer (when a separate RRC layer - also referred to as an Uu-RRC layer - is not provided) a PDCP layer, an RLC layer, a MAC layer, and / or a PHY layer. It will be appreciated that depending on which of those layers are provided in the Lower layers 51-24, 52-24, appropriate layer entities will be provided to perform the operations and functions associated with those layers.

[0219] (NG)AP-C layers 51-26, 7-26: Each A-IoT (NG)AP-C layer entity of the A-IoT (NG)AP-C layers 51-26, 7-26, of the A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like) and the CN 7, perform operations and functions associated with the radio network layer such as the establishment, maintenance, and release of the RAN part of PDU sessions between the A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like) and the CN 7. Signalling between the respective A-IoT (NG)AP-C layers 51-26, 7-26, at the A-IoT device reader (e.g., a RAN node 5-1, intermediate node 5-2, or the like) and the CN 7, may be via any appropriate application protocol (AP) associated with the interface (e.g., NG-AP messages via the NG interface / XX interface) between the A-IoT device reader and the CN 7. In the protocol architecture of Fig. 11 the transmission of inventory / command messages are contained in the DL NAS message and sent towards the A-IoT device reader. After receiving a response from A-IoT device / devices 3-1, the A-IoT device reader packages the received A-IoT NAS packet into an UL NAS message, which is forwarded to CN 7. The UL / DL transfer between A-IoT device reader and RAN node 5-1 can rely on legacy NAS transfer mechanisms.

[0220] It will be appreciated that the description above of the various layers and associated entities are by way of example only, and that those layers and associated entities may also be able to support performance of any other appropriate operations associated with their respective layers, as would be known by the skilled person.

[0221] Fig. 12 illustrates a one possible version of the simplified protocol stack architecture of Fig. 10 in more detail. The simplified protocol stack architecture of Fig. 12 is another possible more specific example of the more generic simplified protocol stack architecture shown in Fig. 10 in that the UE upper layers of Fig. 10 are PDU layers in Fig. 12.

[0222] In the protocol stack architecture of Fig. 12, an A-IoT device protocol stack comprises a command layer 31-6, and an A-IoT access stratum (A-IoT AS) layers 31-4.

[0223] It will be appreciated that the A-IoT device 3-1 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer.

[0224] The protocol stack architecture also comprises an A-IoT device reader protocol stack. The A-IoT device reader protocol stack includes a number of A-IoT device side layers for communication with corresponding layers of the A-IoT device protocol stack over one or more associated interfaces. The A-IoT device reader protocol stack also includes a number of RAN node side layers for communication with a RAN node (e.g., RAN node 5-1) over one or more associated interfaces.

[0225] The A-IoT device-side layers of the A-IoT device reader protocol stack includes an A-IoT AS layer 52-4 for communication with a corresponding A-IoT AS layer 31-4 of the A-IoT device 3-1;

[0226] The RAN node-side layers of the A-IoT device reader protocol stack include: a PDU layer 52-26 for communication with a corresponding PDU layer 11-26 of the UPF 11; and a lower layer (or layers) 52-24 for communication with a corresponding lower layer (or layers) 51-24 of the RAN node 5-1.

[0227] It will be appreciated that the A-IoT device reader (e.g., an intermediate node 5-2) has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer. The A-IoT device reader functional entities may form part of the same or different A-IoT device reader functions.

[0228] The protocol stack architecture also comprises an RAN node protocol stack. The RAN node protocol stack includes a number of A-IoT device reader side layers for communication with corresponding layers of the A-IoT device reader protocol stack over one or more associated interfaces. The RAN node protocol stack also includes a number of core network side layers for communication with the CN 7 over one or more associated interfaces.

[0229] The A-IoT device reader side layers of the RAN node protocol stack includes a lower layer (or layers) 51-24 for communication with the corresponding lower layer (or layers) 52-24 of the A-IoT device reader.

[0230] The core network-side layers of the RAN node protocol stack includes: a GPT-U layer 51-28 for communication with a corresponding GPT-U layer 11-28 of the UPF 11; and a lower layer (or layers) 51-24' for communication with a corresponding lower layer (or layers) 11-24 of the UPF 11.

[0231] It will be appreciated that the RAN node 5-1 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer.

[0232] The protocol stack architecture also comprises a UPF protocol stack comprising: a PDU layer 11-26 for communication with the corresponding PDU layer 52-26 of the A-IoT device reader; a GPT-U layer 11-28 for communication with the corresponding GPT-U 51-28 of the RAN node 5-1; and a lower layer (or layers) 11-24 for communication with the corresponding lower layer (or layers) 51-24' of the RAN node 5-1.

[0233] It will be appreciated that the UPF 11 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer. The protocol stack architecture also comprises an AF comprising: a command layer 104-6 for communication with the corresponding command layer 31-6 of the A-IoT device 3-1; and a lower layer (or layers) 104-24.

[0234] It will be appreciated that the AF 10-4 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer. The core network functional entities may form part of the same or different core network functions.

[0235] The purpose of the layers mentioned above will be understood by the skilled person and some of those layers have also already been briefly introduced above. Therefore only some of the layers mentioned above are briefly introduced below for the purposes of completeness:

[0236] Command Layers 31-6, 104-6: Each command layer entity of the Command layers 31-6, 104-6, of the A-IoT device 3-1 and the CN 7, perform operations and functions associated A-IoT read functions to read data / information from an A-IoT device 3-1, A-IoT write functions to write data to an A-IoT device 3-1, an A-IoT execute functions to execute inventory requests and / or commands.

[0237] PDU layers 52-26, 11-26: Each PDU layer entity of the PDU layers 52-26, 11-26 of the A-IoT device reader (e.g., an intermediate node 5-2) and the UPF 11 of the communication system 1 perform operations and functions associated with receiving data for packaging into a packet data unit for transmission between the A-IoT device reader (e.g., the intermediate node 5-2) and the UPF 11, as well as operations and functions associated with de-packaging data they receive from one another.

[0238] GPT-U layers 51-28, 11-28: Each GPT-U layer entity of the GPT-U layers 51-28, 11-28 of the RAN node 5-1 and the UPF 11 perform operations and functions associated with carrying data GPRS core network and between the radio access network and the CN 7. The user data transported can typically be packets in any of IPv4, IPv6, or PPP formats.

[0239] In the protocol architecture of Fig. 12, the A-IoT device reader can establish a PDU session for the A-IoT service. An inventory / command request raised by the CN 7 / AF 10-4 is contained within PDU sessions established by A-IoT device reader. After receiving the response from A-IoT devices 3-1, the A-IoT device reader forwards the received package towards CN 7 / AF 10-4 via the PDU session. The UL / DL transfer between A-IoT device reader and RAN node 5-1 can rely on legacy PDU session transmission.

[0240] It will be appreciated that the description above of the various layers and associated entities are by way of example only, and that those layers and associated entities may also be able to support performance of any other appropriate operations associated with their respective layers, as would be known by the skilled person.

[0241] <Distribution of Multiple A-IoT Device Readers with an A-IoT System> 　　By way of example, Fig. 13 schematically illustrates how several cell coverage areas may be provided by several different RAN nodes 5-1 in the communication system 1 of Fig. 1, with different A-IoT device readers located within those several cell coverage areas.

[0242] As shown in Fig. 13, a first RAN node 5-1A provides a first cell 9-1A within which is located three A-IoT device readers (e.g., intermediate nodes 5-2A, 5-2B, 5-2C). There is also a second RAN node 5-1B that provides a second cell 9-1B, within which is located two other A-IoT device readers (e.g., intermediate nodes 5-2D, 5-2E), and a third RAN node 5-1C that provides a third cell 9-1C, within which is located two more A-IoT device readers (e.g., intermediate nodes 5-2F, 5-2G).

[0243] When the network (e.g., CN 7) is due to provide an A-IoT service to one or more A-IoT devices 3-1, the network, when faced with a plurality of A-IoT device readers (e.g., intermediate nodes 5-2) spread over a plurality of different cells 9 provided by different RAN nodes 5-1 as in Fig. 13, needs to decide / select one or more A-IoT device readers (e.g., intermediate nodes 5-2B, 5-2C, 5-2D) with which to communicate with the one or more A-IoT devices 3-1 with which the network is due to provide an A-IoT service. It will be appreciated however that the selection of one or more A-IoT device readers, and the appropriate signalling to those selected A-IoT device readers to indicate that they have been selected is non-trivial and will vary depending on both the topology of the A-IoT system and the specific protocol stack architecture implemented.

[0244] For example, in the case of a topology 2 A-IoT system that implements the protocol stack architecture of Fig. 9, there will be direct end-to-end protocol layer between the A-IoT device readers (e.g., intermediate nodes 5-2) and the CN 7 for A-IoT services. Instead, the Uu RRC layer is used to forward the A-IoT NAS messages / A-IoT data of the A-IoT devices 3-1. Whereas in the case of a topology 2 A-IoT system that implements one of the protocol stack architectures generalised in Fig. 10, there is a direct end-to-end protocol layer between the A-IoT device readers (e.g., intermediate nodes 5-2) and the CN 7 for A-IoT services and the A-IoT NAS messages / A-IoT data of the A-IoT devices 3-1 can be communicated directly.

[0245] It will be appreciated that such differences in the design of the protocol stack architecture of the A-IoT system implemented may require different methods / approaches to be adopted when selecting one or more A-IoT device readers, and signalling to those selected A-IoT device readers to indicate that they have been selected for provision of an A-IoT service.

[0246] Beneficially, the communications system 1 is configured to support one or more possible mechanisms / techniques for A-IoT device reader selection that take into account the possible differences in the protocol stack architecture that may be used to implement A-IoT functionality in the communications.

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

[0248] 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 between the RAN node 5-1, 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.

[0249] For example, as described in more detail later, the communication system 1 may be configured to support one or more procedures that allow the network to select one or more of a plurality of A-IoT device readers for communicating with one or more A-IoT devices 3-1 in a specific region / area. The one or more procedures may, for example, comprise a procedure to allow the CN 7 to select one or more A-IoT device readers from a plurality of A-IoT device readers that are supported by a RAN node 5-1 of the communication system 1 for communicating with one or more A-IoT devices 3-1 in a specific region / area.

[0250] Beneficially, as described in more detail later, the communication system 1 may additionally (or alternatively) support one or more procedures that allow the CN 7 to select a RAN node 5-1 of the communication system 1 that supports a plurality of A-IoT device readers. Having selected a specific RAN node 5-1, that particular RAN node 5-1 may then subsequently select one or more A-IoT device readers from a plurality of A-IoT device readers that are supported by the selected RAN node 5-1 for communicating with one or more A-IoT devices 3-1 in a specific region / area.

[0251] Beneficially, as described in more detail later, the communication system 1 may additionally support one or more procedures that allow a RAN node 5-1 supporting one or more selected A-IoT device readers to determine whether or not any of the selected A-IoT device readers are authorised by the network to act as such prior to the allocation of resources by the network.

[0252] The various mechanisms / techniques will now be described in further detail, by way of example only, with reference to Figs. 14 to 19.

[0253] <A-IoT Device Reader Selection Procedures for A-IoT> <A-IoT Device Reader Selection at / by Core Network with RAN Node assistance> 　　Fig. 14 illustrates a simplified sequence diagram of a procedure for selecting one or more A-IoT device readers for provision of an upcoming A-IoT service that may be implemented in the communication system 1 of Fig. 1.

[0254] As shown in Fig. 14, there is provided the CN 7 (e.g., 5GC) in communication with a plurality RAN nodes 5-1 (e.g., a base station, or the like). There is also provided a plurality of intermediate / assisting nodes 5-2 that each operates as a different respective 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 this does not preclude the A-IoT device reader being any other appropriate intermediate device capable to acting as an A-IoT device reader.

[0255] At step S1402, the CN 7 (e.g., an appropriate CPF 10 of the CN 7) selects one or more candidate RAN nodes 5-1 / cells 9 (e.g., RAN node 5-1) for an upcoming A-IoT service (e.g., an A-IoT inventory request, an A-IoT command, or the like).

[0256] For example, the CN 7 (e.g., CPF 10) may select one or more candidate RAN nodes 5-1 / cells 9 for an upcoming A-IoT service based on information it has pertaining to the location of the candidate RAN nodes / cells. More specifically, the CN 7 may use third party information that it has such as a mapping between 'inventory area' information, and the like, and the IDs of the RAN nodes 5-1 / cells 9 to determine which RAN nodes 5-1 / cells 9 may be used to access A-IoT devices 3-1 in a specific area / region.

[0257] At step S1404, the CN 7 sends a respective request message to each candidate RAN node (e.g., RAN node 5-1). The appropriate request message may be a new dedicated message (e.g., an A-IoT Device Reader Discovery Request message, a new NAGP message, or the like), or alternatively may comprise a new information element (IE) (e.g. an e.g., an A-IoT Device Reader Discovery Request IE) in an existing (e.g., NGAP) message, or the like.

[0258] The request message to the one or more candidate RAN nodes 5-1 may include, for example, an indication that the request message is for the purposes of A-IoT device reader discovery.

[0259] Additionally (or alternatively) each request message sent to a corresponding candidate RAN node 5-1 may include, for example, an indication of a target geographical area (or other appropriate target geographical area information) to indicate a geographical area within which the request message is directed i.e., to indicate that the request message is directed toward one or more candidate RAN nodes 5-1 in a specific geographical area.

[0260] Additionally (or alternatively) each request message to a corresponding candidate RAN node 5-1 may include, for example, an appropriate indication of a recommended candidate A-IoT device reader (e.g., an ID of a candidate A-IoT device reader), and / or a recommended candidate group of A-IoT device readers (e.g., an ID of a candidate group of A-IoT device readers) via which the CN 7 wishes to provide an A-IoT service.

[0261] At step S1406, each candidate RAN node (e.g., RAN node 5-1) respectively sends a paging message, or the like, to one or more candidate A-IoT device readers that are served by that candidate RAN node 5-1. It will be appreciated that at step S1406 each RAN node 5-1 may send a plurality of paging messages, one for each A-IoT device reader served by the RAN node 5-1, or alternatively a more generic type paging message may be sent by each RAN node 5-1 that is applicable to any, or a group of A-IoT device readers in the vicinity of that RAN node 5-1.

[0262] In the case of a generic type paging, the RAN node 5-1 may send the paging message in all (or multiple) paging occasions (POs) in a paging cycle. Each A-IoT device reader, which may be in RRC idle / inactive mode, may use Discontinuous Reception (DRX) to help conserve power. In this scenario, each A-IoT device reader may enter a sleep state between periodic POs and may only monitor for paging messages from a RAN node 5-1 in specific POs, the specific POs being determined by that A-IoT device reader based on, for example, and ID of the A-IoT device reader and an idle DRX parameter (which may be indicated to the A-IoT device reader in appropriate system information, or the like).

[0263] Alternatively, dedicated periodical POs for A-IoT device reader paging may be (pre)defined. In this case, the RAN node 5-1 may send the paging message in those dedicated periodical POs only and each A-IoT device reader may be configured to monitor those specific dedicated POs for paging messages. It will be appreciated that the paging messages sent by the one or more candidate RAN nodes (e.g., RAN node 5-1) may, for example, be based on an existing RRC message, or the like, carried in the PDSCH. Alternatively, the paging messages sent by the one or more RAN nodes 5-1 may, for example, be a new RRC message, or the like, carried in the PDSCH. Alternatively, the paging messages sent by the one or more RAN nodes 5-1 may, for example, be a short message, or the like, carried in the PDCCH.

[0264] Further details on the paging procedure between the one or more candidate RAN nodes 5-1 and the A-IoT device readers they serve, and the format of the paging messages used, will be described later on with respect to Fig. 16A and Fig. 16B.

[0265] When the RAN nodes 5-1 have sent the paging messages at step S1406, it is possible that none of the A-IoT device readers respond with an appropriate paging response message. In this case the candidate RAN nodes 5-1 may assume that no intermediate node 5-2 is able to act as an A-IoT device reader at that time.

[0266] Alternatively, having received at least one paging message sent at step S1406, one or more A-IoT device readers may respond with an appropriate paging response message (or messages) at step S1408. In sending the appropriate paging response messages it will be appreciated that each A-IoT device reader that wishes to respond to a paging message it received will send an appropriate paging response message to the specific (candidate) RAN node 5-1 from which it received the paging message.

[0267] Each paging response message sent at step S1408 may, for example, indicate that the corresponding A-IoT device reader that sent that paging response message is available to / capable of acting as an A-IoT device reader at that time and can provide A-IoT services.

[0268] Additionally (or alternatively), each paging response message sent at step S1408 may, for example, respectively include other appropriate information such as an ID of the A-IoT device reader sending the paging response message, an indication of a location (e.g., coarse location) of the A-IoT device reader sending the paging message, a mobility status of the A-IoT device reader sending the paging message, an indication of cell upon which the A-IoT device reader sending the paging message is camped, beam information associated with the cell upon which the A-IoT device reader sending the paging message is camped, RRM measurement information, and / or the like.

[0269] It will be appreciated that the possible information listed above that may be included in the paging response messages sent at step S1408 is by way of example only and that any appropriate additional information may be included in the paging response messages to facilitate the A-IoT device reader selection step at S1412 performed by the CN 7 (discussed below).

[0270] It will be appreciated that as not all A-IoT device readers that respond to a paging message may be selected by the CN 7, different A-IoT device reader behaviours / procedures may be implemented following the transmission of a paging response message by an A-IoT device reader to achieve energy savings and efficiencies. For example, following an A-IoT device reader sending a paging response message at step S1408, that A-IoT device reader may immediately enter an RRC idle mode to achieve energy savings and efficiencies.

[0271] In another example, following an A-IoT device reader sending a paging response message at step S1408, the RAN node (e.g., RAN node 5-1) that receives the paging response message may trigger the A-IoT device reader to immediately enter an RRC idle mode to achieve energy savings and efficiencies.

[0272] In yet another example, following an A-IoT device reader sending a paging response message at step S1408, the RAN node (e.g., RAN node 5-1) that receives the paging response message may wait for a predefined period of time for the CN 7 to initiate an A-IoT service request with the A-IoT device reader. If after expiry of that predefined period of time the CN 7 does not initiate an A-IoT service request with the A-IoT device reader, the RAN node 5-1 may trigger the A-IoT device reader to enter an RRC idle mode to achieve energy savings and efficiencies. Alternatively, if after expiry of that predefined period of time the CN 7 does not initiate an A-IoT service request with the A-IoT device reader, the RAN node 5-1 may release an RRC connection that has been established between the RAN node 5-1 and the A-IoT device reader. At step S1410, each candidate RAN node (e.g., RAN node 5-1) that receives one or more paging response messages may send an appropriate acknowledgement message, or the like (e.g., an A-IoT device reader discovery ACK message) to the CN 7 indicating each A-IoT device reader discovered by that RAN node 5-1 (if any). Additionally, where a paging response message sent to each of the RAN nodes 5-1 included other (additional) appropriate information described above (e.g., IDs, coarse locations, etc), that information may be forwarded to the CN 7 in the corresponding acknowledgement message to assist the CN 7 in selecting one or more A-IoT device readers for provision of an A-IoT service.

[0273] It will be appreciated that as not all A-IoT device readers that respond to a paging message may be selected by the CN 7, different A-IoT device reader behaviours / procedures may be implemented by the CN 7 following reception of associated acknowledgement messages at step S1410 to achieve energy savings and efficiencies. For example, following reception of an associated acknowledgement message at step S1410, the CN 7 may ask one or more RAN nodes 5-1 in communication with one or more A-IoT device readers to release the RRC connection for specific A-IoT device readers or a specific group of A-IoT device readers.

[0274] At step S1412, the CN7 may, based on any acknowledgement messages it has received from the one or more candidate RAN nodes 5-1, select one or more A-IoT device readers for use in providing an A-IoT service.

[0275] It will be appreciated that in the case of A-IoT device readers which are in an RRC connected mode / RRC inactivate mode, the CN 7 can select one or more of those A-IoT device readers directly based on context information, including a location (at least cell level) of the A-IoT device readers, reader relevant capability information, and the like. For example, in a case where the A-IoT device readers being selected are intermediate UEs 3, the CN 7 can select one or more of those A-IoT device readers directly based on UE context information, UE location information, UE capability information, and the like.

[0276] At step S1414, having selected one or more A-IoT device readers for use in providing an A-IoT service, the CN 7 sends one or more appropriate messages (e.g., one or more A-IoT Service Request messages, or the like) to the selected A-IoT device reader (or readers) to indicate that each recipient A-IoT device reader has been selected for provision of an A-IoT service.

[0277] It will be appreciated that the procedure of Fig. 14 may be particularly suitable for implementation in a topology 2 based A-IoT system that operates using an upper layer-based protocol stack architecture such as, for example, the protocol stack architecture of Fig. 10. For example, as the protocol stack architecture of Fig. 10 has a direct (end-to-end) layer between the A-IoT device readers and the CN 7 (e.g., A-IoT upper layer 8 of Fig. 10), the CN 7 is able to send A-IoT Service Request messages, or the like, directly to selected A-IoT device readers. Accordingly, it is efficient for the CN 7 itself to select A-IoT device readers for the provision of A-IoT services following confirmation by the RAN nodes 5-1 of the A-IoT device readers that are available / capable of providing A-IoT services.

[0278] <A-IoT Device Reader selection at / by RAN Node> 　　Fig. 15 illustrates a simplified sequence diagram of another procedure for selecting one or more A-IoT device readers for provision of an upcoming A-IoT service that may be implemented in the communication system 1 of Fig. 1.

[0279] As shown in Fig. 15, there is provided the CN 7 (e.g., 5GC) in communication with a plurality RAN nodes 5-1 (e.g., a base station, or the like). There is also provided a plurality of intermediate / assisting nodes 5-2 that each operates as a different respective 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 this does not preclude the A-IoT device reader being any other appropriate intermediate device capable to acting as an A-IoT device reader.

[0280] At step S1502, the CN 7 (e.g., an appropriate CPF 10 of the CN 7) selects one or more candidate RAN nodes 5-1 / cells 9 (e.g., RAN node 5-1) for an upcoming A-IoT service (e.g., an A-IoT inventory request, an A-IoT command, or the like).

[0281] For example, the CN 7 (e.g., CPF 10) may select one or more candidate RAN nodes 5-1 / cells 9 for an upcoming A-IoT service based on information it has pertaining to the location of the candidate RAN nodes 5-1 / cells 9. More specifically, the CN 7 may use third party information that it has such as a mapping between 'inventory area' information, and the like, and the IDs of the RAN nodes 5-1 / cells 9 to determine which RAN nodes 5-1 / cells 9 may be used to access A-IoT devices 3-1 in a specific area / region. At step S1504, the CN 7 respectively sends an appropriate A-IoT service request message to each of candidate RAN node (e.g., RAN node 5-1) to request that candidate RAN node 5-1 to discover and select one or more A-IoT device readers for provision of the A-IoT service.

[0282] The appropriate service request message may be a new dedicated message (e.g., an A-IoT Device Service Request message, a new NAGP message, or the like), or alternatively may comprise a new information element (IE) (e.g. an e.g., an A-IoT Service Request IE) in an existing (e.g., NGAP) message, or the like.

[0283] The request message to the one or more candidate RAN nodes 5-1 may include, for example, an appropriate indication of an A-IoT device (or devices) 3-1 - e.g., an ID of an A-IoT device (or devices ) 3-1 - and / or a group of A-IoT devices 3-1 (e.g., an ID of a candidate group of A-IoT devices 3-1) to which the CN 7 wishes to provide an A-IoT service.

[0284] Additionally (or alternatively) each service request message sent to a corresponding candidate RAN nodes may include, for example, an indication of the type of A-IoT service that the CN 7 is requesting to be provided. For example, the request message may include an indication that the A-IoT service to be provided is an A-IoT inventory-based service and / or an A-IoT command-based service, and / or some other appropriate type of A-IoT service.

[0285] Additionally (or alternatively) each request message to a corresponding candidate RAN node 5-1 may (optionally) include, for example, appropriate higher layer data that is to be provided to the A-IoT device (or devices) 3-1 / group of A-IoT devices 3-1 with which the CN 7 wishes to provide an A-IoT service.

[0286] Additionally (or alternatively) each request message to a corresponding candidate RAN node 5-1 may include, for example, an indication of a target geographical area (or other appropriate target geographical area information) to indicate a geographical area within which the request message is directed i.e., to indicate that the request message is directed toward one or more A IoT device in a specific geographical area.

[0287] Additionally , the request message to the one or more candidate RAN nodes 5-1 may include, for example, an indication that the request message can further trigger intermediate A-IoT device reader discovery (and / or selection).

[0288] Additionally (or alternatively) each request message to a corresponding candidate RAN node 5-1 may include, for example, an appropriate indication of a recommended candidate A-IoT device reader (or readers) - e.g., an ID of a candidate A-IoT device reader (or readers) - and / or a recommended candidate group of A-IoT device readers (e.g., an ID of a candidate group of A-IoT device readers) via which the CN 7 wishes to provide an A-IoT service.

[0289] Upon receiving A-IoT service request at S1504, it will be appreciated that each RAN node 5-1 may act as A-IoT device reader to communicate with an A-IoT device directly to provide the A-IoT service requested by the CN 7.

[0290] Additionally (or alternatively), each RAN node 5-1 may trigger paging for A-IoT device reader discovery as in step S1506 to discover an A-IoT device reader to communicate with an A-IoT device 3-1 to provide the A-IoT service requested by the CN 7, e.g., when the geographical area indicated in the message received at step S1504 is out of the reachability of the RAN node 5-1, and thus the RAN node 5-1 cannot act as an A-IoT device reader itself. In this scenario, the message received at step S1504 may include an indication that a further A-IoT device reader (other than the RAN node 5-1) needs to be discovered.

[0291] At step S1506, each candidate RAN node (e.g., RAN node 5-1) respectively sends a paging message, or the like, to one or more candidate A-IoT device readers that are served by that candidate RAN node 5-1. It will be appreciated that at step S1506 each RAN node 5-1 may send a plurality of paging messages, one for each A-IoT device reader served by the RAN node 5-1, or alternatively a more generic type paging message may be sent by each RAN node 5-1 that is applicable to any, or a group of A-IoT device readers in the vicinity of that RAN node 5-1.

[0292] Alternatively, where a request message sent at step S1504 includes an appropriate indication of one or more recommended candidate A-IoT devices reader, a corresponding paging message sent by the candidate RAN node 5-1 at step S1506 may be specifically targeted toward one or more recommended candidate A-IoT devices reader. For example, where the recommended candidate A-IoT device (or devices) reader is an intermediate UE 3 (are intermediate UEs 3), each corresponding paging message may respectively include one or more UE's international mobile service identities (IMSIs) to indicate each A-IoT device 3-1 to which the paging message is directed.

[0293] In the case of a generic type paging, the RAN node 5-1 may send the paging message in all (or multiple) paging occasions (POs) in a paging cycle. Each A-IoT device reader, which may be in RRC idle / inactive mode, may use Discontinuous Reception (DRX) to help conserve power. In this scenario, each A-IoT device reader may enter a sleep state between periodic POs and may only monitor for paging messages from a RAN node 5-1 in specific POs, the specific POs being determined by that A-IoT device reader based on, for example, and ID of the A-IoT device reader and an idle DRX parameter (which may be indicated to the A-IoT device reader in appropriate system information, or the like).

[0294] Alternatively, dedicated periodical POs for A-IoT device reader paging may be (pre)defined. In this case, the RAN node 5-1 may send the paging message in those dedicated periodical POs only and each A-IoT device reader may be configured to monitor those specific dedicated POs for paging messages.

[0295] It will be appreciated that the paging messages sent by the one or more candidate RAN nodes (e.g., RAN node 5-1) may, for example, be based on an existing RRC message, or the like, carried in the PDSCH. Alternatively, the paging messages sent by the one or more RAN nodes 5-1 may, for example, be a new RRC message, or the like, carried in the PDSCH. Alternatively, the paging messages sent by the one or more RAN nodes 5-1 may, for example, be a short message, or the like, carried in the PDCCH. Further details on the paging procedure between the one or more candidate RAN nodes 5-1 and the A-IoT device readers they serve, and the format of the paging messages used, will be described later on with respect to Fig. 16A and Fig. 16B.

[0296] When the RAN nodes 5-1 have sent the paging messages at step S1506, it is possible that none of the A-IoT device readers may respond with an appropriate paging response message. In this case the candidate RAN nodes 5-1 may assume that no intermediate node 5-2 is able to act as an A-IoT device reader at that time.

[0297] Alternatively, having received at least one paging messages at step S1506, one or more A-IoT device readers may respond with an appropriate paging response message (or messages) at step S1508. In sending the appropriate paging response messages it will be appreciated that each A-IoT device reader that wishes to respond to a paging message it received will send an appropriate paging response message to the specific (candidate) RAN node 5-1 from which it received the paging message.

[0298] Each paging response message sent at step S1508 may, for example, indicate that the corresponding A-IoT device reader that sent that paging response message is available to / capable of acting as an A-IoT device reader at that time and can provide A-IoT services.

[0299] Additionally (or alternatively), each paging response message sent at step S1508 may, for example, respectively include other appropriate information such as an ID of the A-IoT device reader sending the paging response message, an indication of a location (e.g., coarse location) of the A-IoT device reader sending the paging message, a mobility status of the A-IoT device reader sending the paging message, an indication of cell upon which the A-IoT device reader sending the paging message is camped, beam information associated with the cell upon which the A-IoT device reader sending the paging message is camped, RRM measurement information, and / or the like.

[0300] It will be appreciated that the possible information listed above that may be included in the paging response messages sent at step S1508 is by way of example only and that any appropriate additional information may be included in the paging response messages to facilitate the A-IoT device reader selection step at S1510 performed by the RAN node 5-1 (discussed below).

[0301] At step S1510, each candidate RAN node (e.g., RAN node 5-1) that receives one or more paging response messages may, based on the received paging response message (or messages), select one or more A-IoT device readers for use in providing an A-IoT service.

[0302] It will be appreciated that in the case of A-IoT device readers which are in an RRC connected mode / RRC inactivate mode, the RAN nodes can select one or more of those A-IoT device readers directly based on context information, including a location (at least cell level) of the A-IoT device readers, reader relevant capability information, and the like. For example, in a case where the A-IoT device readers being selected are intermediate UEs 3, the RAN nodes 5-1 can select one or more of those A-IoT device readers directly based on UE context information, UE location information, UE capability information, and the like. If however the UE context information is insufficient, a RAN node 5-1 may request additional information from the A-IoT device readers and / or the CN 7 over the existing connections there between.

[0303] Having selected those one or more A-IoT device readers, a given RAN node (e.g., RAN node 5-1) may perform an appropriate RRC connection establishment procedure with each of the selected A-IoT device readers (not shown), while any A-IoT device reader not selected may be triggered by the RAN nodes 5-1 to enter an RRC idle mode. Alternatively, any A-IoT device reader not selected may be ignored by the corresponding RAN node 5-1, and any such A-IoT device reader may automatically enter RRC idle mode after the expiration of a predefined period of time.

[0304] At step S1512, having selected one or more A-IoT device readers for use in providing an A-IoT service, the corresponding RAN node 5-1 sends one or more appropriate messages (e.g., one or more A-IoT Service Request messages, or the like) to the selected A-IoT device reader (or readers) (e.g., over an appropriate interface such as a Uu interface, or the like) to indicate that each recipient A-IoT device 3-1 has been selected for provision of an A-IoT service.

[0305] The A-IoT Service Request message, or the like, may include all of the information that the RAN node 5-1 received from the CN 7 pertaining to the A-IoT Service Request message, or the like. Alternatively, the A-IoT Service Request message may include only a portion of the information that the RAN node 5-1 received from the CN 7. For example, the A-IoT Service Request message, or the like, sent to the selected A-IoT device reader (or readers) at step S1512 may only include information received from the CN 7 that is relevant to the A-IoT service to be provided (e.g., target A-IoT devices, indications of an A-IoT service type, upper A-IoT messages / data, etc.).

[0306] It will be appreciated that the procedure of Fig. 15 may be particularly suitable for implementation in a topology 2 based A-IoT system that operates using an RRC layer-based protocol stack architecture such as, for example, the protocol stack architecture of Fig. 9. For example, as the protocol stack architecture of Fig. 9 does not have a direct (end-to-end) layer between the A-IoT device readers and the CN 7. The CN 7 is thus not able to send A-IoT Service Request messages, or the like, directly to selected A-IoT device readers, but must send such messages via, for example, one or more RAN nodes 5-1. Accordingly, it is more efficient for the one or more RAN nodes 5-1 to select A-IoT device readers for the provision of A-IoT services following confirmation by the A-IoT device readers that they are available / capable of providing A-IoT services.

[0307] <Paging for A-IoT Device Reader Discovery> 　　In both the procedures shown in Fig. 14 and Fig. 15 paging messages are transmitted / broadcast to A-IoT device readers to facilitate their discovery in the A-IoT system (e.g., step S1406 in the procedure of Fig. 14, and step S1506 in the procedure of Fig. 15).

[0308] Sub-procedures that may be implemented during the transmission / broadcast of those paging messages will now described in more detail with reference to Figs. 16A and 16B.

[0309] Fig. 16A illustrates a simplified sequence diagram of an example of a typical paging procedure for discovery of A-IoT device readers that may be implemented in the A-IoT device reader selection procedures of Fig. 14 and Fig. 15

[0310] As shown in Fig. 16A, there is provided a RAN node (e.g., RAN node 5-1) and one or more A-IoT device readers (e.g., one or more intermediate nodes 5-2) in communication with one another. As will be appreciated, although the following description relates to a paging procedure between a single RAN node 5-1 and the A-IoT device readers it can communicate with, the procedure may be performed by a plurality of RAN nodes 5-1 that can communicate with a respective plurality of A-IoT device readers when implemented in the A-IoT device reader selection procedures of Fig. 14 and Fig. 15.

[0311] In a typical paging procedure for A-IoT device reader discovery such as that shown in Fig. 16A, the RAN node (e.g., RAN node 5-1) may initiate the procedure by sending an appropriate paging message for A-IoT device reader discovery at step S1602 to the A-IoT device readers in its vicinity. It will be appreciated that step S1602 in Fig. 16A may be equivalent to step S1406 of Fig. 14, or step S1506 of Fig. 15. An example of the content of the paging message is described below.

[0312] Having received a paging message, each A-IoT device reader may then perform an appropriate random access procedure with the RAN node 5-1 that sent it the paging message. For example, in response to receiving a paging message, each A-IoT device reader may send a random access (RA) preamble in a first message ('Msg1') to the RAN node 5-1 over a physical random access channel (PRACH) at step S1604.

[0313] In response, the RAN node may respond with a random access response (RAR) (or 'Msg2') at step S1606. The RAR may indicate reception of the preamble and include, amongst other things, an uplink grant field indicating resources to be used in the uplink for a physical uplink shared channel (PUSCH).

[0314] The A-IoT device reader may then send a third message ('Msg3') to the RAN node 5-1 at step S1608 over a physical uplink shared channel (PUSCH) based on the information in the RAR. The specific message sent by the A-IoT device reader 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 identifier (e.g., a UE identifier in the case where the A-IoT device reader is an intermediate UE 3).

[0315] The RAN node may then respond with a fourth message ('Msg4') at step S1610 which carries the randomly generated identifier received in Msg3 for contention purposes to resolve any collisions between different A-IoT device readers using the same preamble sequence. When successful, Msg4 also transfers the A-IoT device reader to a connected state as shown in Fig. 16A.

[0316] Having transferred the A-IoT device reader to a connected state, the A-IoT device reader may send, a paging response message at step S1612 ('Msg5') following or typically together with RRC setup complete message which is to indicate that the RRC setup procedure is completed and the A-IoT device reader is in an RRC connected state with the RAN node 5-1. It will be appreciated that paging response message at step S1612 may be equivalent to step S1408 of Fig. 14, or S1508 of Fig. 15.

[0317] However, it will be appreciated that the implementation of a typical paging procedure such as that described above with reference to Fig. 16A may result in inefficiencies in the A-IoT device discovery procedures of Fig. 14 and Fig. 15. For example, as some of the A-IoT device readers that are paged readers may not be selected after being discovered it may not be necessary to keep those A-IoT device readers in RRC connected mode after responding to the paging for UE reader discovery. Accordingly, it may be more efficient for the paging procedure to be adapted into a RACH-less and RRC connection-less paging procedure that keeps the A-IoT device readers in an RRC idle mode until after the A-IoT device reader is selected for use in the provision of an A-IoT service.

[0318] Fig. 16B illustrates a simplified sequence diagram of an example of a RACH-less and RRC connection-less paging procedure for discovery of A-IoT device readers that may be implemented in the A-IoT device reader selection procedures of Fig. 14 and Fig. 15.

[0319] As shown in Fig. 16B, there is provided a RAN node (e.g., RAN node 5-1) and one or more A-IoT device readers (e.g., one or more intermediate nodes 5-2) in communication with one another. As will be appreciated, although the following description relates to a paging procedure between a single RAN node 5-1 and the A-IoT device readers it can communicate with, the procedure may be performed by a plurality of RAN nodes 5-1 that can communicate with a respective plurality of A-IoT device readers when implemented in the A-IoT device reader selection procedures of Fig. 14 and Fig. 15. An example of the content of the paging message is described below.

[0320] At step S1702, the RAN node (e.g., RAN node 5-1) sends a paging message for A-IoT device reader discovery to one or more A-IoT device readers (e.g., intermediate node 5-2) in the vicinity of the RAN node 5-1.

[0321] At step S1704, the A-IoT device reader (or readers) having received a paging message for A-IoT device reader discovery from a RAN node 5-1, may respond with an appropriate paging response message without performing a RACH procedure and / or an RRC setup procedure.

[0322] For example, where the paging message sent at step S1702 indicates an appropriate UL grant / UL resource as described below, the A-IoT device readers may use the UL grant / UL resources to send a paging response (e.g., a message comprising, for example, an ID of the A-IoT device reader, etc.) without needing to perform a RACH procedure with the RAN node 5-1. In this way, the A-IoT device reader can confirm whether it has received a paging message and whether it is capable of providing an A-IoT service while remaining in an RRC idle state.

[0323] It will be appreciated that where the procedure of Fig. 16B is implemented in place of the procedure of Fig. 16A efficiencies may be achieved as those A-IoT device readers that are capable of providing an A-IoT service, but which are ultimately not selected by a RAN node 5-1 to do so never have to enter an RRC connected state and / or perform a RACH procedure with the RAN node 5-1.

[0324] It will also therefore be appreciated that in the event that an A-IoT device reader is selected by the CN 7 or RAN node 5-1, following selection of that A-IoT device reader, an appropriate RACH procedure and / or RRC setup procedure will be triggered by the RAN node 5-1 with that A-IoT device reader (e.g., by triggering the procedure of Fig. 16A).

[0325] <Paging Message Contents> 　　The paging message for A-IoT device reader discovery transmitted / broadcast at step S1602 in Fig. 16A and step S1702 of Fig. 16B, may, for example, be an existing type of paging message (e.g., an appropriate RRC message, or the like) which has been adapted to include an additional IE to indicate that the message is specifically for A-IoT device reader discovery (e.g., an PagingforUEReader IE, or the like).

[0326] The sub-IEs of such an IE may comprise the following by way of example only: Paging-v1900-IEs ::=　　　　　　SEQUENCE { pagingForUEreader-v1900　　pagingForUEreader-v1900　　OPTIONAL, --Need N … } Paging-v1900-IEs ::=　　　　　　SEQUENCE { AreaInfo 　　 FFS　　OPTIONAL, --Need N UEreaderIDMask　　FFS　　OPTIONAL, --Need N UEGroup　　FFS　　OPTIONAL, --Need N CandidateUEreaderList　　FFS　　OPTIONAL, --Need N ULgrantsForPagingResponse　　FFS　　OPTIONAL, --Need N … }

[0327] Alternatively, the paging message for A-IoT device reader discovery may, for example, be a separately defined new RRC message, similar to the paging message described above, but which is specifically dedicated for use in A-IoT device reader discovery. In this case, the new RRC message may include appropriate IEs such as those outlined above, and an A-IoT device reader that is capable of providing A-IoT services, and which meet any conditions set in those IEs (e.g., meets the AreaInfo IE information, the UEreaderIDMask IE information, etc.), then that A-IoT device reader may respond to the paging message for A-IoT device discovery with an appropriate paging response message.

[0328] Additionally, in the case where the paging procedure used is the RACH-less and RRC connected-less procedure of Fig. 16B, additional IEs may be included in the paging message sent / broadcast to the A-IoT device readers. For example, an appropriate IE (e.g., ULgrantsForPagingResponse IE) that indicates multiple UL grants / paging response occasions / resources that may be used by the A-IoT device reader to respond to a paging message it receives from a RAN node 5-1.

[0329] <A-IoT Device Reader Authentication Procedures for A-IoT> 　　A number of A-IoT device reader authentication procedures for A-IoT that may be implemented in the communication system 1 will now be described, by way of example only, with reference to Figs. 17 to 19. It will be appreciated that the authentication procedures described below may, where appropriate, be combined with the A-IoT device reader selection procedures described above.

[0330] Fig. 17 illustrates a simplified sequence diagram of an example A-IoT device reader authentication procedure that may be implemented in the communication system 1 of Fig. 1.

[0331] As shown in Fig. 17, there is provided the CN 7 (e.g., 5GC) in communication with a plurality RAN nodes 5-1 (e.g., a base station, or the like). There is also provided a plurality of intermediate / assisting nodes 5-2 that each operates as a different respective A-IoT device reader (for example an intermediate / assisting UE 3, or the like). As shown in Fig. 17, the CN 7, the plurality of RAN nodes 5-1, and the plurality of intermediate / assisting nodes 5-2 are in a connected state (e.g., an evolved packet system (EPS) connection management (ECM) state or the like).

[0332] It will be appreciated that whilst the following description refers to the A-IoT device reader specifically as an intermediate UE 3 this does not preclude the A-IoT device reader being any other appropriate intermediate device capable to acting as an A-IoT device reader.

[0333] At step S1802, the CN 7 (e.g., an appropriate CPF 10 of the CN 7) sends one or more A-IoT service request messages, or the like, directly to one or more A-IoT device readers. It will be appreciated that each A-IoT service request message sent at step S1802 may, for example, respectively correspond to the A-IoT service request message sent at step S1414 in the procedure of Fig. 14. As such, the procedure of Fig. 17 may be implemented as a follow-on to the procedure shown in Fig. 14.

[0334] At step S1804, having received an A-IoT service request message at step S1802, a recipient A-IoT device reader may send an A-IoT resource request message, or the like, to a corresponding RAN node 5-1 in communication with that A-IoT device reader to request resources for providing an A-IoT service (e.g., resources for performing R2D / D2R communications, and the like).

[0335] Having received a request for resources from an A-IoT device reader, the recipient RAN node 5-1 may, at step S1806, checks with the CN 7 whether or not the corresponding A-IoT device reader that sent the request for resources is authorised to receive such resources. For example, the recipient RAN node 5-1 may send an appropriate message (e.g., an A-IoT device reader authentication message, or the like) to the CN 7 to request / check whether the corresponding A-IoT device reader that sent the request for resources is authorised to do so.

[0336] At step S1808, in response to receiving the A-IoT device reader authentication message , the CN 7 may respond with an appropriate acknowledgement / negative acknowledgement message (e.g., an appropriate ACK / NACK message) to indicate whether or not the corresponding A-IoT device reader is authorised / authenticated or not i.e., whether or not the resource request should or should not be fulfilled.

[0337] At step S1810, in response to the ACK / NACK message received at step S1808, the recipient RAN node 5-1 may send an appropriate A-IoT resource response / reject message to the A-IoT device reader that requested resources to indicate whether or not the request will be fulfilled.

[0338] Where the request is fulfilled, the A-IoT device reader may begin communication with one or more A-IoT devices 3-1 at step S1812.

[0339] It will be appreciated that the procedure of Fig. 17 may be particularly suitable for implementation in a topology 2 based A-IoT system that operates using an upper layer-based protocol stack architecture such as, for example, the protocol stack architecture of Fig. 10.

[0340] Fig. 18 illustrates a simplified sequence diagram of another example A-IoT device reader authentication procedure that may be implemented in the communication system 1 of Fig. 1.

[0341] As shown in Fig. 18, there is provided the CN 7 (e.g., 5GC) in communication with a plurality RAN nodes 5-1 (e.g., a base station, or the like). There is also provided a plurality of intermediate / assisting nodes 5-2 that each operates as a different respective A-IoT device reader (for example an intermediate / assisting UE 3, or the like).

[0342] It will be appreciated that the steps S1902 to S1908 are equivalent to the steps S1602 to S1608 of the procedure shown in Fig. 16A and Fig 16B. As such the description of steps S1602 to S1608 apply equally to steps S1902 to S1908.

[0343] At step S1910, the RAN node 5-1 checks with the CN 7 (e.g., an appropriate CPF 10 of the CN 7) whether or not each respective A-IoT device reader is authorised to provide A-IoT services. For example, the RAN nodes 5-1 may send one or more appropriate messages (e.g., one or more A-IoT device reader authentication messages, or the like) to the CN 7 to request / check whether each respective A-IoT device reader is authorised to act as an A-IoT device reader to provide a corresponding A-IoT service (e.g., whether or not a given UE 3 that is capable of operating as an A-IoT device reader is authorised to do so).

[0344] At step S1912, the CN 7 may respond to the message (e.g., A-IoT device reader authentication message) sent to the CN 7 at step S1910 (e.g., an appropriate ACK / NACK message) to indicate whether or not each respective A-IoT device reader is authorised / allowed to act as an A-IoT device reader for the provision of the requested A-IoT service.

[0345] Alternatively, at step S1910, the RAN node 5-1 may send a message (e.g., an 'initial UE message' or the like) to the CN 7 to require the CN 7 to begin a UE context setup / modification procedure for the corresponding A-IoT device reader. For example, where the A-IoT device reader is an intermediate UE 3, at step S1910, the RAN node 5-1 may send an initial UE message to the CN 7 to require UE context setup / modification, or the like. The initial UE message to the CN 7 may also include an appropriate cause value to indicate that the message pertains to an intermediate UE 3 that is to act as an A-IoT device reader e.g., a 'being UE reader for A-IoT service" cause indicator, or the like.

[0346] In this scenario, at step S1912, the CN 7 may perform an initial context setup / UE context update procedure for the A-IoT device reader, with the corresponding RAN node 5-1, if the A-IoT device reader (e.g., an intermediate UE 3) is authenticated / allowed to act as an A-IoT device reader for the A-IoT service to be provided. As part of that initial context setup / UE context update procedure, the CN 7 may provide the corresponding RAN node 5-1 with all necessary information, including, for example, additional UE context information where appropriate. Otherwise, where the A-IoT device reader (e.g., an intermediate UE 3) is not authenticated / allowed to act as an A-IoT device reader, the CN 7 may reject the UE context setup / modification requested by the initial UE message.

[0347] At S1914, the RAN node 5-1 may select one or more A-IoT device readers from those A-IoT device readers that are authorised / authenticated / capable of providing an A-IoT service for use in providing that A-IoT service. Alternatively, (or additionally) the RAN node 5-1 may select one or more A-IoT device readers from those A-IoT device readers whose context information was provided to the RAN node 5-1 at step S1912.

[0348] At step S1916, the RAN node 5-1 may send a message to the CN 7 (e.g., a report message, or the like), to indicate to the CN 7 which of the A-IoT device readers were selected for the provision of the A-IoT service.

[0349] Optionally, at the same time, the RAN node 5-1 may also allocate appropriate resources to the A-IoT device readers which can be used between the A-IoT device readers and A-IoT devices 3-1 for D2R and R2D communications.

[0350] It will be appreciated that steps S1916, S1918, and / or S1920 may occur in any order, or some or all of those steps may occur concurrently.

[0351] It will also be appreciated that the procedure of Fig. 18 may be particularly suitable for implementation in a topology 2 based A-IoT system that operates using an RRC layer-based protocol stack architecture such as, for example, the protocol stack architecture of Fig. 9.

[0352] Fig. 19 illustrates a simplified sequence diagram of yet another example A-IoT device reader authentication procedure that may be implemented in the communication system 1 of Fig. 1. As shown in Fig. 18, there is provided the CN 7 (e.g., 5GC) in communication with a plurality RAN nodes 5-1 (e.g., a base station, or the like). There is also provided a plurality of intermediate / assisting nodes 5-2 that each operates as a different respective A-IoT device reader (for example an intermediate / assisting UE 3, or the like).

[0353] At step S2001 the CN 7 may select an A-IoT device reader to execute / perform an upcoming A-IoT service. It will be appreciated that in this scenario, the A-IoT device reader in question may be in RRC idle mode.

[0354] At step S2002a, having selected an A-IoT device reader with which to execute / perform an upcoming A-IoT service, the CN 7 may send a paging message, or the like, to a RAN node 5-1 serving the selected A-IoT device reader, which may then be forwarded on to the A-IoT device reader by the RAN node 5-1 at step S2002b.

[0355] Having received the paging message at step S2002b, the A-IoT device reader may trigger an appropriate RRC connection setup procedure, with the RAN node 5-1 that sent the paging message, to enter RRC connected state with that RAN node 5-1.

[0356] For example, at step S2004, the A-IoT device reader may send an RRC message to the RAN node 5-1 to request / trigger an RRC setup procedure between the RAN node 5-1 and the A-IoT device reader (e.g., an RRC Setup Request message, or the like).

[0357] Following receipt of the RRC message to request / trigger an RRC setup procedure between the RAN node 5-1 and the A-IoT device reader, the RAN node 5-1, at step S2006 may send an RRC setup message, or the like, to the A-IoT device reader to provide the A-IoT device reader with appropriate resources and the like with which to communicate with the RAN node 5-1, and to transfer the A-IoT device reader from its RRC idle state to an RRC connected state. Having completed its transition from RRC idle to RRC connected, the A-IoT device reader may then, at step S2008, send a response message (e.g., an RRC complete message, or the like) to the RAN node 5-1 to indicate / confirm completion of the RRC setup procedure that was requested, and to indicate that the A-IoT device reader is in RRC connected state.

[0358] At step S2010, having received the RRC complete message (e.g., a paging response message) from the A-IoT device reader, the RAN node 5-1 may forward that paging response message to the CN 7 packaged in an appropriate message (e.g., an initial UE message, or the like) over an appropriate interface (e.g., an NG interface).

[0359] The CN 7, in response to the initial UE message received at step S2010 may then trigger an appropriate UE context setup procedure, and may send a UE context setup request message, or the like, to the RAN node 5-1 to trigger the UE context setup procedure at step S2012. As part of the UE context setup procedure, the CN 7 may, for example, forward appropriate UE capability information to the RAN node 5-1 indicating the required capabilities of the selected one or more A-IoT device readers, including an appropriate indication that the selected one or more A-IoT device readers should be capable of acting as an A-IoT device reader.

[0360] Additionally (or alternatively), the CN 7 may, for example, forward relevant authentication information to the RAN node 5-1 pertaining to the selected one or more A-IoT device readers, which may, for example, include an indication that the selected one or more A-IoT device readers are authenticated / allowed / activated as a reader.

[0361] At step S2014, the RAN node 5-1 may optionally perform an SMC and / or RRC re-configuration procedure to configure appropriate security contexts, radio bearers, and the like, necessary for facilitating communications between the A-IoT device reader and the RAN node 5-1. Alternatively, at step S2014, where the RAN node 5-1 that received the UE context setup request message at step S2012 does not support A-IoT device readers, the procedure of Fig. 19 may terminate.

[0362] At step S2016, in response to the UE context setup request message sent at step S2012, the RAN node 5-1 sends an appropriate response message (e.g., an initial UE context setup response message, or the like) to the CN 7 to confirm whether or not the RAN node 5-1 is able to support the selected A-IoT device readers and, where the RAN node 5-1 supports the selected A-IoT device reader, the response message may also confirm completion of the UE context setup procedure.

[0363] At step S2018, the CN 7 and the A-IoT device reader may begin to perform A-IoT communications with one another. For example, the CN 7 may send an A-IoT service request message, or the like, to the A-IoT device reader to request it to participate in the upcoming provision of an A-IoT service. It will be appreciated that the A-IoT service request message may, for example, be encapsulated in NAS signalling, or as a PDU in an A-IoT data transmission to the A-IoT device reader from the CN 7.

[0364] At step S2020, A-IoT device reader may request the RAN node 5-1 that it is in communication with to allocate resources for use in D2R and R2D communications between the A-IoT device reader and one or more A-IoT devices 3-1.

[0365] In response to receiving that request from the A-IoT device reader, the RAN node 5-1 may check the stored UE context that it received from the CN 7 at step S2012, and if the A-IoT device reader is authenticated / allowed / activated as a reader, then the RAN node may determine to allocated radio resources to the A-IoT device reader for use in D2R and R2D communications between the A-IoT device reader and one or more A-IoT devices 3-1 at step S2022. Otherwise, the RAN node 5-1 rejects the request for the allocation of radio resources.

[0366] <Devices in the Communication System> <User Equipment> 　　Fig. 20 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.

[0367] As shown, the UE 3-2; 3-3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a base station 5-1 via one or more antenna 33 (e.g., comprising one or more antenna elements). The UE 3-2; 3-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 or from a removable data storage device (RMD), for example.

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

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

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

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

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

[0373] <Ambient IoT device> 　　Fig. 21 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.

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

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

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

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

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

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

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

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

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

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

[0384] <RAN node> 　　Fig. 22 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.

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

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

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

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

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

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

[0391] <Assisting (or intermediate) node> 　　Fig. 23 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.

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

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

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

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

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

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

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

[0399] <Core Network Function> 　　Fig. 24 is a schematic block diagram illustrating the main components of a core network function 10 / 11 at may be used in the communication system 1.

[0400] As shown, the core network function 10 / 11 has a transceiver circuit 711 for transmitting signals to and for receiving signals from nodes of the communication system 1 (such as other nodes / functions of the core network 7, and / or RAN nodes 5) via one or more network interfaces 721.

[0401] The core network function 10 / 11 has a controller 713 to control the operation of the core network function 10 / 11 in accordance with the specific functions that that core network function 10 / 11 is required to provide (e.g., when operating as an AMF 10-1 / 10-3, SMF 10-2, UDM, AUSF, PCF, AF, SEAF, ARPF, UPF and / or the like). The controller 713 is configured to control the overall operation of the core network function 10 / 11 by, in this example, program instructions or software instructions stored within memory 714. Software may, for example, be pre-installed in the memory 714 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD). As shown, these software instructions include, among other things, an operating system 715, and a communications control module 716.

[0402] The communications control module 716 is operable to control the communication between the core network function 10 / 11 and other network entities. The communication control module 716 is configured, in particular, to control the communication of core network function 10 / 11, where applicable, in accordance with any of the methods described herein.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0424] 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 access network node, the method comprising: 　　selecting at least one reader device for communicating carrier-wave for backscattering with a mobile device, based on interaction with a core network node. 　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　the interaction includes receiving, from the core network node, information indicating at least one of: 　　　　it is for discovery of the at least one reader device, 　　　　a target geography area in which the at least one reader device is, 　　　　at least one recommended reader device, 　　　　at least one target reader device, 　　　　a service type, or 　　　　higher layer data to the at least one reader device. 　　(Supplementary note 3) 　　The method according to supplementary note 1 or 2, wherein 　　the interaction includes transmitting, to the core network node, acknowledge information for all discovered reader devices in a case where each of the all discovered reader devices sends a response message in response to a paging message from the access network node. 　　(Supplementary note 4) 　　The method according to supplementary note 3, wherein 　　the response message includes at least one of: 　　　　information indicating one of the all discovered reader devices, 　　　　information indicating a location of the one of the all discovered reader devices, 　　　　information indicating a mobility state of the one of the all discovered reader devices, 　　　　information indicating cell / beam which the one of the all discovered reader devices is camping, or 　　　　information for a radio resource management (RRM) measurement. 　　(Supplementary note 5) 　　The method according to supplementary note 3 or 4, further comprising: 　　performing, to at least one reader device which does not respond to the paging message from the access network node, a specific procedure for releasing connections to the at least one reader device or sending the at least one reader device to an idle mode. 　　(Supplementary note 6) 　　The method according to any one of supplementary notes 3 to 5, wherein 　　a service request message is transmitted from the core network node to one or more reader devices from the all discovered reader devices, based on the acknowledge information. 　　(Supplementary note 7) 　　The method according to any one of supplementary notes 3 to 5, further comprising: 　　transmitting, to one or more reader devices, a service request message based on respective response messages from the all discovered reader devices, the service request message having been transmitted from the core network node to the access network node. 　　(Supplementary note 8) 　　The method according to any one of supplementary notes 3 to 7, wherein 　　the paging message is transmitted in a specific paging occasion dedicated for discovering the at least one reader device. 　　(Supplementary note 9) 　　The method according to any one of supplementary notes 1 to 8, wherein 　　the interaction includes checking whether each of the at least one reader device is authorized to operate for communicating carrier-wave for backscattering with the mobile device. 　　(Supplementary note 10) 　　The method according to supplementary note 9, wherein 　　the checking is performed: 　　　　before allocating radio resources for the communicating carrier-wave for backscattering with the mobile device, 　　　　before the selecting the at least one reader device, or 　　　　during user equipment (UE) context setup / modification / resume procedure. 　　(Supplementary note 11) 　　A method performed by a core network node, the method comprising: 　　interacting, with an access network node for selecting at least one reader device for communicating carrier-wave for backscattering with a mobile device. 　　(Supplementary note 12) 　　An access network node comprising: 　　means for selecting at least one reader device for communicating carrier-wave for backscattering with a mobile device, based on interaction with a core network node. 　　(Supplementary note 13) 　　A core network node comprising: 　　means for interacting, with an access network node for selecting at least one reader device for communicating carrier-wave for backscattering with a mobile device.

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

[0426] 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 3-1 A-IoT DEVICES 31-2 A-IoT NAS LAYER 31-4 A-IoT AS LAYERS 31-5 A-IoT UPPER LAYER 31-6 DOMMAND LAYER 5-1 RAN NODE 51-4 A-Io AS 51-6 A-Io AP 51-7 RRC 51-8 PDCP 51-10 RLC 51-12 MAC 51-14 PHY 51-18 Uu LAYER 51-24 LOWER LAYER 51-26 NGAP-C 51-28 GPT-U 52-4 A-IoT AS LAYTERS 52-7 RRC 52-8 PDCP 52-10 RLC 52-12 MAC 52-14 PHY 52-16 UE UPPER LAYERS 52-18 Uu LAYERS 52-20 N1NAS 52-24 LOWERLAYER 52-26 PDU ALYER 5-2 INTERMEDIATE NODE 7-2 A-IoT NAS 7-5 UPPER LAYER / LAYERS 7-6 NG / XX AP 7-16 UE UPPER LAYERS 7-20 N1 NAS 7-26 NGAP-C 10-3 A-IoT AMF 103-2 A-IoT NAS 103-6 A-IoT AP 10-4 AF 104-6 COMMAND LAYER 104-24 LOWER LAYER 11-24 LOWER LAYER 11-26 PDU LAYER 11-28 GPT-U 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 711 TRANSCEIVER CIRCUIT 712 NETWORK INTERFACE 713 CONTROLLER 714 MEMORY 715 OPERATING SYSTEM 716 COMMUNICATIONS CONTROL MODULE

Claims

1. A method performed by an access network node, the method comprising: 　　selecting at least one reader device for communicating carrier-wave for backscattering with a mobile device, based on interaction with a core network node.

2. The method according to claim 1, wherein 　　the interaction includes receiving, from the core network node, information indicating at least one of: 　　　　it is for discovery of the at least one reader device, 　　　　a target geography area in which the at least one reader device is, 　　　　at least one recommended reader device, 　　　　at least one target reader device, 　　　　a service type, or 　　　　higher layer data to the at least one reader device.

3. The method according to claim 1 or 2, wherein 　　the interaction includes transmitting, to the core network node, acknowledge information for all discovered reader devices in a case where each of the all discovered reader devices sends a response message in response to a paging message from the access network node.

4. The method according to claim 3, wherein 　　the response message includes at least one of: 　　　　information indicating one of the all discovered reader devices, 　　　　information indicating a location of the one of the all discovered reader devices, 　　　　information indicating a mobility state of the one of the all discovered reader devices, 　　　　information indicating cell / beam which the one of the all discovered reader devices is camping, or 　　　　information for a radio resource management (RRM) measurement.

5. The method according to claim 3 or 4, further comprising: 　　performing, to at least one reader device which does not respond to the paging message from the access network node, a specific procedure for releasing connections to the at least one reader device or sending the at least one reader device to an idle mode.

6. The method according to any one of claims 3 to 5, wherein 　　a service request message is transmitted from the core network node to one or more reader devices from the all discovered reader devices, based on the acknowledge information.

7. The method according to any one of claims 3 to 5, further comprising: 　　transmitting, to one or more reader devices, a service request message based on respective response messages from the all discovered reader devices, the service request message having been transmitted from the core network node to the access network node.

8. The method according to any one of claims 3 to 7, wherein 　　the paging message is transmitted in a specific paging occasion dedicated for discovering the at least one reader device.

9. The method according to any one of claims 1 to 8, wherein 　　the interaction includes checking whether each of the at least one reader device is authorized to operate for communicating carrier-wave for backscattering with the mobile device.

10. The method according to claim 9, wherein 　　the checking is performed: 　　　　before allocating radio resources for the communicating carrier-wave for backscattering with the mobile device, 　　　　before the selecting the at least one reader device, or 　　　　during user equipment (UE) context setup / modification / resume procedure.

11. A method performed by a core network node, the method comprising: 　　interacting, with an access network node for selecting at least one reader device for communicating carrier-wave for backscattering with a mobile device.

12. An access network node comprising: 　　means for selecting at least one reader device for communicating carrier-wave for backscattering with a mobile device, based on interaction with a core network node.

13. A core network node comprising: 　　means for interacting, with an access network node for selecting at least one reader device for communicating carrier-wave for backscattering with a mobile device.

Images