Method of mobile device, method of reader device, mobile device and reader device

Abstract

A method performed by a mobile device is described, comprising receiving, from a reader device, a paging message setting a random number 'i' between 0 and n-1, where n is calculated using a number of access occasions configured by the paging message, to a counter; receiving, from the reader device, a triggering message triggering a subset of the access occasions in a case where a number set to the counter is less than a specific number, selecting an access occasion from the subset of the access occasions, based on the number set to the counter, used for transmitting a message to the reader device, decreasing the number set to the counter by the specific number, otherwise.

Description

METHOD OF MOBILE DEVICE, METHOD OF READER DEVICE, MOBILE DEVICE AND READER DEVICE

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

[0002] The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards, equivalents, or derivatives thereof (including Long Term Evolution (LTE)-Advanced, Next Generation or 5G networks, future generations, and beyond). The present disclosure relates, in particular but not exclusively, to random access procedures in an 'Ambient' Internet-of-Things (IoT) system, for example how to minimise the risk of contention in a contention based random access procedure and / or how to provide for contention free access for A-IoT devices.

[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 S-GW and P-GW - specifically user plane functionality of the S-GW (SGW-U) and user plane functionality of the P-GW (PGW-U). The SMF provides session management functionality (that formed part of MME functionality in 4G). The SMF also combines the some of the functionality provided by the S-GW and P-GW - specifically control plane functionality of the S-GW (SGW-C) and control plane functionality of the P-GW (PGW-C). The SMF also allocates IP addresses to each UE.

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

[0009] In summary, the four-step procedure typically involves the UE selecting random access resources (including, for example, a preamble) that it uses to initiate the RACH procedure. The UE sends the selected preamble in a first message ('Msg1') to a base station over a physical random access channel (PRACH). In response, the base station responds with a random access response (RAR) (or 'Msg2'). The RAR indicates reception of the preamble and includes, amongst other things, an uplink grant field indicating resources to be used in the uplink for a physical uplink shared channel (PUSCH). The UE 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 device is indoors.

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

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

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

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

[0028] Currently it is envisaged that, for A-IoT, fewer physical channels will be supported, and UL and DL physical layer (layer-1 (L1)) communication will be simplified significantly. For example, there may be a single physical R2D channel (PRDCH) for R2D communication and a single physical D2R channel (PDRCH) for D2R communication. For R2D, the PRDCH will typically carry any higher-layer payload, and any L1 R2D control information (if defined). For D2R, the PDRCH will typically carry any higher-layer payload, and any L1 D2R control information (if defined). The PDRCH may also carry, for example, a response transmitted from the A-IoT device to a reader during a contention-based access procedure.

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

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

[0031] 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. The Query command includes a 4-bit parameter referred to as the 'Q parameter' that specifies a value ranging from 0 to 15, which effectively indicates a total number of slots within a response 'frame' (i.e., the number of slots available for a possible reply), where the number of slots equals 2Q(e.g., 16 slots where Q=4).

[0032] The Q-parameter is subsequently used by the selected RFID tags (i.e., those that match the parameters in the Select command) to randomly determine a 'random access' slot to reply in. Specifically, each selected RFID tag respectively generates its own random 'slot' number between zero and 2Qminus one (e.g., between 0 and 15 for Q=4). The respective random slot number for each selected RFID tag is used to identify the slot within which that selected RFID tag should respond by loading that respective random slot number into a slot counter. Each slot counter is then decreased by one as each slot passes and when a slot counter for a given RFID tag reaches (or is initially set to) zero the corresponding RFID tag will respond. For example, where Q=4, an RFID that randomly selects '0' as its random slot number will respond immediately in the first slot (slot #0) whereas an RFID that randomly selects '15' as its random slot number will respond in the last (16th) slot (slot #15).

[0033] 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 or a QueryRep command. A QueryAdjust command may be used by the RFID reader to adjust the value of the Q parameter and trigger each selected RFID tag to store a new random slot value (based on the new Q parameter value) in their respective slot counters. A QueryRep command may be used by the RFID reader to trigger all the selected RFID tags to decrease their respective slot counters.

[0034] When a given selected RFID tag responds in a corresponding random access slot when its slot counter reaches (or is initially set to) zero, 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 generate the same random slot number (and so effectively select the same slot for response), and hence respond to the Query command simultaneously.

[0035] It will be appreciated that the larger the value of Q that is specified, the greater the number of slots that may be used by the RFID tags for their responses, and hence the lower the probability of collisions.

[0036] 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 a its 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).

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

[0038] When a slot counter for another selected RFID tag next reaches zero, these steps are repeated - i.e., that selected RFID tag sends the RN16; the RFID reader sends an acknowledgement (assuming no collisions); that selected RFID tag sends its EPC etc.; and the RFID reader sends a QueryAdjust or QueryRep.

[0039] For random access in the context of A-IoT devices and A-IoT device readers it is envisaged that contention-based random access procedures, which are similar to conventional four-step and two-step RACH procedures may be used, that also have some similarities with the RFID random access procedure.

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

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

[0042] Similarly, in the 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.

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

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

[0045] Whilst the overall contention based A-IoT two-step and four-step random access procedures have been developed, however, there is still a need for further enhancement to those procedures.

[0046] For example, there is a need for further development of the way in which the random access resources are selected for the transmission of the initial D2R message (A-IoT Msg1) to provide for improved, anti-contention based, access in which the risk of contention is minimised.

[0047] For example, whilst a random access resource selection mechanism similar to that used in RFID access procedures could, hypothetically, be used it cannot be directly implemented in A-IoT without significant adaptation.

[0048] Specifically, whilst the design of the RFID access procedure, and in particular of the initial message carrying the 16-bit random number (RN16) transmitted by the RFID tag, means that there is a very low probability that more than one device will transmit the same 16-bit random number in the same slot for a given query, it is not robust against mis-detection / false-alarms due to noise / interference. For example, the erroneous detection of a single bit of the 16 bit random number will still cause a miss-detection. Moreover, the fact that the RFID random access procedure is entirely based on time division multiplexing (TDM) inherently limits the maximum number of resources available for access and hence its capacity. It is therefore desirable, for A-IoT, that any random access resource selection mechanism should consider both TDM and frequency division multiplexing (FDM).

[0049] The RFID access procedure also provides no direct support for the possibility of contention-free random access which is desirable in the context of A-IoT.

[0050] Moreover, whilst a random access resource selection mechanism similar to that used in a conventional RACH procedures could, hypothetically, be used it also cannot be directly implemented in A-IoT without significant adaptation.

[0051] Specifically, whilst the RACH preambles used in conventional RACH procedures are sequences specifically designed to have good auto / cross-correlation properties and hence can provide robustness against miss-detection / false-alarms due to noise / interference and even collision, the number of available RACH preambles is limited (64 for each time-frequency RACH occasion, albeit that a RACH preamble can have either an 839 or 139 sequence length). Hence, contention, where multiple UEs select the same RACH preamble in the same time-frequency RACH occasion, can occur with a non-negligible probability. This is why, contention resolution based on Msg4 (which includes a unique radio network temporary identifier (C-RNTI)) is very important for a conventional RACH procedure. Moreover, a dedicated RACH channel is not assumed for A-IoT systems. In addition, the preamble sequence for a conventional RACH is based on a Zadoff Chu based sequence for which the overall sequence generation is relatively lengthy and complex, which may preclude its use in an A-IoT system.

[0052] Whilst A-IoT initial access is based on a slotted ALOHA algorithm that is inherently TDM based, as mentioned above it is desirable, for A-IoT, that any random access resource selection mechanism should consider both TDM and FDM. However, unlike conventional cellular communication in which multiplexing is OFDM-based, any FDM for A-IoT D2R will likely be realised by different square wave frequencies with asynchronous transmissions (and / or transmissions having a large timing difference), resulting in loss of orthogonality among A-IoT D2R signals at the A-IoT device reader. There is a need, therefore, to further develop the way in which the random access resources are selected to allow for selection of random access resources based on such a frequency shift / offset.

[0053] Moreover, as mentioned above, supporting the possibility of contention-free random access is desirable in the context of A-IoT. There is a need, therefore, to further develop the currently envisaged A-IoT random access procedures to allow the possibility of contention free access for one or more A-IoT devices.

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

[0055] The disclosure has a method performed by a mobile device, the method comprising receiving, from a reader device, a paging message setting a random number 'i' between 0 and n-1, where n is calculated using a number of access occasions configured by the paging message, to a counter; receiving, from the reader device, a triggering message triggering a subset of the access occasions in a case where a number set to the counter is less than a specific number, selecting an access occasion from the subset of the access occasions, based on the number set to the counter, used for transmitting a message to the reader device, decreasing the number set to the counter by the specific number, otherwise.

[0056] The disclosure has a method performed by a reader device, the method comprising transmitting, to a mobile device, a paging message for configuring a counter of the mobile device with a random number 'i' between 0 and n-1, where n is calculated using a number of access occasions transmitting, to the mobile device, a triggering message triggering a subset of the access occasions, and wherein in a case where a number set to the counter is less than a specific number, an access occasion from the subset of the access occasions is selected by the mobile device, based on the number set to the counter, used for transmitting a message to the reader device, the number set to the counter is decreased by the specific number, otherwise.

[0057] The disclosure has a method performed by a reader device, the method comprising transmitting, to a mobile device, a paging message including information for resources used for transmitting identity information of the mobile device receiving, from the mobile device, a message including the identity information via a contention free random access procedure.

[0058] The disclosure has a mobile device comprising means for receiving, from a reader device, a paging message means for setting a random number 'i' between 0 and n-1, where n is calculated using a number of access occasions configured by the paging message, to a counter; means for receiving, from the reader device, a triggering message triggering a subset of the access occasions means for, in a case where a number set to the counter is less than a specific number, selecting an access occasion from the subset of the access occasions, based on the number set to the counter, used for transmitting a message to the reader device, decreasing the number set to the counter by the specific number, otherwise.

[0059] The disclosure has a mobile device comprising means for receiving, from a reader device, a paging message including information for resources used for transmitting identity information of the mobile device means for transmitting, to the reader device, a message including the identity information via a contention free random access procedure.

[0060] The disclosure has a reader device comprising means for transmitting, to a mobile device, a paging message for configuring a counter of the mobile device with a random number 'i' between 0 and n-1, where n is calculated using a number of access occasions means for transmitting, to the mobile device, a triggering message triggering a subset of the access occasions, and wherein in a case where a number set to the counter is less than a specific number, an access occasion from the subset of the access occasions is selected by the mobile device, based on the number set to the counter, used for transmitting a message to the reader device, the number set to the counter is decreased by the specific number, otherwise.

[0061] The disclosure has a reader device comprising means for transmitting, to a mobile device, a paging message including information for resources used for transmitting identity information of the mobile device means for receiving, from the mobile device, a message including the identity information via a contention free random access procedure.

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

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

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

[0065] 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 (topology 1) that may be used in the communication system of Fig. 1;Fig. 3 illustrates schematically a second connectivity topology (topology 2) that may be used in the communication system of Fig. 1;Fig. 4A illustrates schematically a third connectivity topology (topology 3) that may be used in the communication system of Fig. 1;Fig. 4B illustrates schematically another arrangement of the third connectivity topology (topology 3) of Fig. 4A;Fig. 5 is 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 simplified sequence diagram of another example A-IoT random access procedure that may be implemented in the communication system of Fig. 1.Fig. 7 illustrates a first example random access occasion / resource design that may be implemented in the communication system of Fig. 1;Fig. 8 illustrates a second example random access occasion / resource design that may be implemented in the communication system of Fig. 1;Fig. 9 illustrates a third example random access occasion / resource design that may be implemented in the communication system of Fig. 1;Fig. 10 illustrates first and second examples of a random access occasion / resource selection that may be implemented in the communication system of Fig. 1;Fig. 11 illustrates a third example random access occasion / resource selection that may be implemented in the communication system of Fig. 1;Fig. 12 illustrates a fourth example random access occasion / resource selection that may be implemented in the communication system of Fig. 1;Fig. 13 is simplified sequence diagram of an example A-IoT procedure for supporting frequency shifted D2R transmissions that may be implemented in the communication system of Fig. 1;Fig. 14 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. 15 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. 16 is a simplified block schematic illustrating the main components of a RAN node that may be used in the communication system of Fig. 1; andFig. 17 is simplified block schematic illustrating the main components of an intermediate or assisting node that may be used in the communication system of Fig. 1.

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

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

[0068] In the communication system 1, user equipments (UEs) 3 (3-1, 3-2, 3-3) (e.g., mobile telephones and / or other mobile devices including (ambient) IoT devices) can communicate with each other via a corresponding radio access network (RAN) node 5-1 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN node 5-1 comprises a base station operating one or more associated cells 9. Communication via the RAN node 5-1 is typically routed through a core network 7 (e.g., a 5G / 6G / later generations core network or evolved packet core network (EPC)). 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). As those skilled in the art will appreciate, whilst three UEs 3, and one RAN node 5-1 are shown in Fig. 1 for illustration purposes, the system, when implemented, will typically include other RAN nodes 5-1 and UEs 3.

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

[0070] 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 device-to-device interface (e.g., D2D, sidelink, PC5 or the like). The intermediate, or assisting, node 5-2 may, for example, be a relay node (e.g., a dedicated relay or UE-relay), an integrated access and backhaul (IAB) node, a repeater and / or the like, which is capable of ambient IoT operation including receiving backscatter / reflected signals from, and / or transmitting unmodulated carrier signals to, the A-IoT device 3-1.

[0071] 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 generations, and / or any other 3GPP or non-3GPP communication protocols.

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

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

[0074] The core network 7 includes a number of logical nodes (or 'functions') for supporting communication in the communication system 1. In this example, the core network 7 comprises control plane functions (CPFs) 10 and one or more network node entities for the communication of user data (e.g. user plane functions (UPFs) 11). The CPFs 10 include one or more network node entities for the communication of control signalling (e.g. Access and Mobility Management Functions (AMFs) 10-1), one or more network node entities for session management (e.g. Session Management Functions (SMFs) 10-2) and a number of other functions 10-n. Additional functions may include, for example: an Authentication Server Function (AUSF) which facilitates security processes; a Unified Data Management (UDM) entity for managing user specific data (e.g., for access authorisation, user registration, and data network profiles); a Policy Control Function (PCF); an Application Function (AF); a Security Anchor Function (SEAF) which is in a serving network and acts as a "middleman" during an authentication process between a UE 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.

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

[0076] 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., an N6 reference point) for communication of the user data.

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

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

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

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

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

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

[0083] 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) the UE 3 is able to attempt access to that cell and / or beam using an initial radio resource control (RRC) connection setup procedure comprising a random access procedure with the RAN node 5-1.

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

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

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

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

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

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

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

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

[0092] 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) may, for example, be supported by topology 1 where full duplex operation is supported at that RAN node 5-1.

[0093] 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 5-1 (IoT device reader) from the RAN node 5-1 (IoT device reader) receiving from the A-IoT device 3-1. For example, a first RAN node 5-1 (IoT device reader) may transmit an unmodulated carrier signal 20-1 to the A-IoT device 3-1, and a second RAN node 5-1 (IoT device reader) 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 5-1 (IoT device readers).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0127] 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 target / selected A-IoT device 3-1 (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 target / selected A-IoT 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.

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

[0129] 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 3-1), and possibly other information, to the A-IoT device reader. The identifier may, for example, be a 16-bit random number (RN16) as used in RFID access procedures but may be some other form of (random) identifier.

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

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

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

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

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

[0135] 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 target / selected A-IoT device 3-1 (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 target / selected A-IoT 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.

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

[0137] Having been triggered by an R2D initial trigger message (A-IoT Msg0), the A-IoT device 3-1 sends, at S606, an initial device-to-reader (D2R) message ('A-IoT Msg1') using the selected RA occasion (time / frequency resources). The initial D2R message (A-IoT Msg1) carries 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.

[0138] 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 3-1 in the initial D2R message (A-IoT Msg1).

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

[0140] <Enhancements for Supporting Contention Based / Contention Free Random Access> 　　Beneficially, 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 implementing one or more mechanisms / techniques for supporting enhanced contention based random access (CBRA) and / or contention free random access (CFRA).

[0141] A number of possible mechanisms / techniques for supporting enhanced contention based random access (CBRA) and / or contention free random access (CFRA) 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.

[0142] 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 (e.g., load / capacity, radio quality / interference levels, A-IoT device 3-1 or A-IoT device reader capability, and / or the like).

[0143] For example, as described in more detail later, the communication system 1 may support one or more of a number of different possible enhanced A-IoT random access (RA) occasion / resource designs. The various different A-IoT RA occasion / resource designs have the potential to help: to reduce the probability / risk of contention (e.g., compared to a conventional cellular RACH procedure); and to support division of the A-IoT RA occasions both in time and frequency and hence increase access capacity (compared to conventional slotted ALOHA based RFID access procedures).

[0144] Moreover, as described in more detail later, the communication system 1 may support one or more of a number of different possible resource selection related enhancements for an A-IoT RA procedure (e.g., as described with reference to Fig. 5 and / or 6) that may contribute to provision of anti-contention by supporting selection of different RA occasions at different frequency locations within same slot. It will be appreciated that one or more of the various different A-IoT RA occasion / resource designs mentioned above may be supported for possible use in an A-IoT RA procedure that incorporates one or more of the enhancements described herein. Nevertheless, it is not essential that an A-IoT RA procedure that incorporates one or more of the enhancements uses an A-IoT RA occasion / resource design described herein. Similarly, it is not essential that an A-IoT RA procedure that benefits from an A-IoT RA occasion / resource design described herein also incorporates one or more of the enhancements described herein.

[0145] It will be appreciated that, due to A-IoT device capabilities, the R2D link may be single carrier frequency based. Nevertheless, as the D2R link is a backscattered transmission, based on a modulated version of the unmodulated carrier wave transmitted by the A-IoT device reader, it is possible for an A-IoT device 3-1 to apply a frequency shift / frequency offset to a backscattered D2R transmission. Accordingly, since different frequency shifts may be allowed based on the unmodulated carrier wave, the communication system 1 may beneficially support D2R transmission using any of a plurality of different frequency shifts. Beneficially, therefore, multiple FDM transmissions are possible in the communication system 1 from multiple A-IoT devices 3-1 substantially simultaneously. Moreover, a single A-IoT device 3-1 may use different frequency locations for different (possibly consecutive) D2R transmissions.

[0146] Beneficially, as described in more detail later, the communication system 1 may implement one or more enhancements for enabling an A-IoT device 3-1 to apply a frequency shift based D2R transmission. It will be appreciated that these enhancements are not restricted to random access procedures over the D2R link but are more generally applicable to any D2R transmission.

[0147] Beneficially, as described in more detail later, the communication system 1 may implement one or more enhancements for enabling contention free access for a single A-IoT device 3-1 and / or for multiple A-IoT devices 3-1.

[0148] <Random Access (RA) Occasion / Resource Design> 　　As mentioned above the communication system 1 is configured for supporting one or more of a number of different possible enhanced A-IoT random access (RA) occasion / resource designs.

[0149] Various different A-IoT RA occasion / resource designs that may be supported by the communications system 1 will now be described, by way of example only, with reference to Figs. 7 to 9.

[0150] Fig. 7 illustrates a first example random access occasion / resource design that may be implemented in the communication system 1.

[0151] As seen in Fig. 7, in this example, the resources (RA occasions (ROs)) available for selection for transmission of a D2R message (e.g., an initial access D2R message (A-IoT Msg1) or other similar message) are divided in time into a number ('M') of slots (slot#0, slot#1, … slot#9). Each slot is divided, in frequency, into the same number ('K') of frequency locations (each slot having a common set of frequency locations). Each RA occasion respectively corresponds to time / frequency resources within one of the M slots and within one of the K frequency locations. Accordingly, in the example of Fig. 7 the total number of available RA occasions is M x K. It will be appreciated that whilst, in the illustrated example, there are ten (M=10) slots and eight (K=8) frequency locations, there may be any appropriate number of slots and frequency locations. It will also be appreciated that whilst the slots are shown as being contiguous in time, and the frequency locations are shown as being contiguous in frequency, adjacent slots and / or adjacent frequency locations may not be contiguous.

[0152] It can be seen that this example has the benefit of simplicity, which may be particularly important for at least some A-IoT device types.

[0153] Fig. 8 illustrates a second example random access occasion / resource design that may be implemented in the communication system 1.

[0154] As seen in Fig. 8, in this example, the resources (RA occasions (ROs)) available for selection for transmission of a D2R message (e.g., an initial access D2R message (A-IoT Msg1) or other similar message) are divided in time into a number ('M') of slots (slot#0, slot#1, … slot#9) in a similar manner to that shown in Fig. 7. However, in this example, whilst each slot is divided in frequency into a number ('K') of different frequency locations, not all of the frequency locations are configured for use as corresponding time / frequency RA occasions. Accordingly, different slots have different numbers of frequency locations (or no frequency locations) that are configured for use as corresponding time / frequency RA occasions. Accordingly, the different slots in the example of Fig. 8 do not have a common set of frequency locations.

[0155] Specifically, in the example of Fig. 8, each slot (slot#m, where m is an integer from 0 to M-1) has a corresponding number of frequency locations (Km, where Kmmay have a value from 0 to K) that are configured for use as an RA occasion. Accordingly, in the example of Fig. 8, the total of RA occasions is given by:

[0156] It will be appreciated that the specific frequency locations configured for use as RO occasions may, beneficially, be configurable depending on requirements. For example, in a scenario where greater access capacity / a reduced contention probability is desirable (e.g., because many A-IoT devices are targeted ) a greater proportion of the total (M x K) frequency locations may be configured for use as RO occasions. Similarly, in a scenario in which fewer A-IoT devices are targeted, a smaller proportion of the total (M x K) frequency locations may be configured for use as RO occasions. Allowing such configurability thus allows for greater flexibility. Moreover whilst, in the example of Fig. 8, none of the slots have all K frequency locations configured for use as RO occasions this does not preclude the possibility that one or more slots may have all K frequency locations configured for use as RO occasions.

[0157] It will also be appreciated that whilst, in the example of Fig. 8, there are ten (M=10) slots and eight (K=8) frequency locations, there may be any appropriate number of slots and frequency locations. It will also be appreciated that whilst the slots are shown as being contiguous in time, and the frequency locations are shown as being contiguous in frequency, adjacent slots and / or adjacent frequency locations may not be contiguous. Moreover, in each slot having a plurality of frequency locations configured for use as RA occasions, the frequency locations for use as RA occasions may be separated in frequency (e.g., the frequency locations for use as RA occasions may be separated by one or more frequency locations that are not configured for use as RA occasions).

[0158] It can be seen that this example has the benefit of flexibility compared to the example of Fig. 7.

[0159] Fig. 9 illustrates a third example random access occasion / resource design that may be implemented in the communication system 1.

[0160] As seen in Fig. 9, in this example, the resources (RA occasions (ROs)) available for selection for transmission of a D2R message (e.g., an initial access D2R message (A-IoT Msg1) or other similar message) are divided in time into a number ('M') of slots (slot#0, slot#1, … slot#9) in a similar manner to that shown in Figs. 7 and 8. Moreover in the example of Fig. 9, like the example of Fig. 8, whilst each slot is divided in frequency into a number ('K') of different frequency locations, not all of the frequency locations are configured for use as corresponding time / frequency RA occasions. Specifically, different slots have different subsets of frequency locations that are configured for use as corresponding time / frequency RA occasions. Accordingly, the different slots in the example of Fig. 9 do not have a common set of frequency locations.

[0161] Specifically, in the example of Fig. 9, each slot (slot#m, where m is an integer from 0 to M-1) has a corresponding subset of frequency locations (Km, where Kmis less than K) that are configured for use as an RA occasion. Accordingly, in the example of Fig. 9 (as in the example of Fig. 8) the total of RA occasions is given by:

[0162] However, whilst the example of Fig. 9 has similarities with that of Fig. 8, a frequency-hopping like / staggered pattern is applied for to the frequency locations configured for use as RA occasions, from one slot to the next slot (in time). The pattern is configured to ensure that the subset of frequency locations respectively configured for use as RA occasions in each slot of a given set of (N) consecutive (adjacent / neighbouring) slots do not include any frequency location in common with the other slots of that set of (N) adjacent (neighbouring) slots. It will be appreciated that whilst N=4 in the illustrated example N, N may be any suitable integer greater than two. Effectively, the pattern is non-overlapping (staggered) between the consecutive neighbouring slots of the set.

[0163] It will be appreciated that the specific frequency locations configured for use as RO occasions may, beneficially, be configurable depending on requirements (e.g., to use a different hopping / staggered pattern). It will also be appreciated that whilst, in the example of Fig. 9, there are ten (M=10) slots and eight (K=8) frequency locations, there may be any appropriate number of slots and frequency locations. It will also be appreciated that whilst the slots are shown as being contiguous in time, and the frequency locations are shown as being contiguous in frequency, adjacent slots and / or adjacent frequency locations may not be contiguous (albeit that this example is particularly beneficial when the slots are contiguous or near-contiguous in time). Moreover, in each slot having a plurality of frequency locations configured for use as RA occasions, the frequency locations for use as RA occasions may be separated in frequency (e.g., the frequency locations for use as RA occasions may be separated by one or more frequency locations that are not configured for use as RA occasions).

[0164] It can be seen that whilst this example may provide fewer RA occasions than the examples of Fig. 7 and Fig. 8, it has the benefit that it ensures frequency isolation between RA attempts in adjacent slots and hence potential interference arising from frequency drift (e.g., associated with synchronisation differences between different A-IoT devices 3-1 and the A-IoT device reader).

[0165] <Anti-Contention based on Different Frequency Locations for Same Slot> 　　As mentioned above, the communication system 1 may support one or more of a number of different possible enhancements resource selection related enhancements for an A-IoT RA procedure that may contribute to provision of anti-contention by supporting selection of different RA occasions at different frequency locations within same slot.

[0166] Various different resource selection related enhancements that may be supported by the communication system 1 will now be described, by way of example only.

[0167] <Bandwidth Considerations for A-IoT access> 　　As A-IoT devices 3-1 may have different capabilities, resource selection for random access may have to take place in the context of A-IoT devices 3-1 that support different bandwidths (e.g., one or more different A-IoT specific bandwidth parts or the like).

[0168] For example, a basic D2R bandwidth (or bandwidth part (BWP)) may be defined for A-IoT, which may be used to support A-IoT device access. All A-IoT devices 3-1 served by a particular A-IoT device reader may be expected to support this basic D2R bandwidth (or bandwidth part (BWP)), as a minimum A-IoT device bandwidth capability for communication via the D2R link. However, this does not preclude the possibility that, in addition to this basic D2R bandwidth (or bandwidth part (BWP)), some A-IoT device 3-1 may have the capability to also support one or more 'additional' or 'extended' A-IoT bandwidths (or bandwidth parts (BWPs)) for A-IoT device access.

[0169] Accordingly, in one enhancement that may be supported by the communication system 1, the A-IoT device reader may be configured for sending an initial triggering message (A-IoT Msg0) that either: indicates a possible set of frequency domain resources (frequency locations) available for A-IoT device access within only the basic D2R bandwidth (or bandwidth part (BWP)); or indicates a (larger) possible set of frequency domain resources (frequency locations) available for A-IoT device access within both the basic D2R bandwidth (or bandwidth part (BWP)) and any additional / extended bandwidths (or bandwidth parts (BWPs)). The additional / extended bandwidths (or bandwidth parts (BWPs)) can be one or more frequency shift / frequency offsets based on the basic D2R bandwidth.

[0170] When an A-IoT device 3-1 subsequently selects a frequency bandwidth (or frequency location) for a random access attempt, based on an indicated set of frequency domain resources (frequency locations) within a basic and / or additional / enhanced D2R bandwidth (or bandwidth part (BWP)) within the initial triggering message (A-IoT Msg0) before A-IoT access, A-IoT device 3-1 bases the selection on that A-IoT device's actual bandwidth capability for D2R communication (which may be defined according to its radio-frequency (RF) capability). Specifically, when the A-IoT device 3-1 randomly selects a frequency location to use for sending an initial D2R (access) message (A-IoT Msg1), the A-IoT device 3-1 ensures that the selected frequency location is confined with that A-IoT device's RF capability.

[0171] For a given access round for A-IoT device's random access, the A-IoT device reader may receive more than one initial D2R (access) message (A-IoT Msg1), from more than one A-IoT device, in more than one frequency domain location (having a corresponding D2R frequency location bandwidth) in a given random access slot. Accordingly, in another enhancement, the A-IoT device reader may be configured to respectively map the D2R frequency location bandwidth (frequency location) in which each initial D2R (access) message (A-IoT Msg1) was received to a corresponding R2D transmission bandwidth (frequency location). The A-IoT device reader can then respectively provide each subsequent R2D access response (A-IoT Msg2) in the corresponding R2D transmission bandwidth (frequency location) for each A-IoT device 3-1. It will be appreciated that the mapping relationship between the D2R frequency location / bandwidth and the corresponding R2D transmission frequency location / bandwidth may be predefined (fixed) or may be indicated in the initial triggering message (A-IoT Msg0). It will be appreciated that this approach beneficially helps an A-IoT device 3-1 to monitor for an R2D access response (A-IoT Msg2) in a correct time domain and frequency domain location.

[0172] <RACH resource selection - Example 1> 　　Fig. 10 illustrates first and second examples of an enhanced random access occasion / resource selection that may be implemented in the communication system 1.

[0173] In the first example, FDM handling (for frequency location selection) is supported in addition to an (RFID like) slotted ALOHA based RA slot selection mechanism.

[0174] Specifically, in the first example, when the A-IoT device reader decides to initiate an access procedure for a set of A-IoT devices 3-1 (in this example, A-IoT devices 3-11 and 3-12), it sends an initial triggering message (A-IoT Msg0) targeting that set of A-IoT devices 3-11, 3-12, the initial triggering message (A-IoT Msg0) includes a slot selection parameter (e.g., 'Q' like RFID or a similar A-IoT specific parameter). The slot selection parameter may be set to an appropriate value (e.g., an integer in the range 0 to 15 as in RFID, or possibly a different A-IoT specific range). The initial triggering message (A-IoT Msg0) also carries information indicating the time slots allocated for RA and, for each time slot, the set of frequency locations allocated for RA (e.g., based on one of the random access occasion / resource designs described with reference to Figs. 7 to 9, or some other random access occasion / resource pattern). The value of the slot selection parameter (e.g., 'Q') may, optionally, correspond to the number of time slots allocated for RA (i.e., 2Qis equal to the number of allocated time slots).

[0175] Each A-IoT device 3-11, 3-12 targeted by, and that receives, the initial triggering message (A-IoT Msg0) uses the slot selection parameter received in the initial triggering message (A-IoT Msg0) (when performing RA resource / occasion selection - e.g., as indicated at S504 or S604 in Figs. 5 and 6 respectively) to generate a corresponding slot selection random number in the range 0 to 2Q-1 (if 'Q' is the slot selection parameter). In the illustrated example it is assumed that both A-IoT devices 3-11, 3-12 have selected the same random number (2) for the purposes of illustration. Each targeted A-IoT device 3-11, 3-12, then starts an RA slot counter that counts down from the corresponding generated slot selection random number in successive RA slots (which may also be referred to as "RACH-slots") after receiving the initial triggering message (A-IoT Msg0) - except if the generated number were zero in which case the A-IoT device 3-11, 3-12 that selected zero would transmit its initial D2R message (A-IoT Msg1) substantially immediately in the first RA slot (slot#0).

[0176] A decrease in the respective RA slot counter in each A-IoT device 3-11, 3-12, in this example, is triggered by a 'repeat' message / command (or the like) sent from the A-IoT device reader at the transition to the next RA slot. The 'repeat' message / command may, for example, be a repeated transmission of the initial triggering message (A-IoT Msg0) which may (optionally) include an indication that the following access cycle is a repetition and forms part of the current (same) access round. Thus, the respective RA slot counter in each A-IoT device 3-11, 3-12, decrements by one every time a 'repeat' message / command (or the like) is received from the A-IoT device reader. It can be seen that the 'repeat' message / command is analogous to the QueryRep command for RFID.

[0177] When the generated slot selection random number reaches zero, after the reception of a given 'repeat' message / command (e.g., as indicated for the A-IoT devices 3-11, 3-12, in Fig. 10 at the transition to slot #(K+2)), the corresponding A-IoT device 3-11, 3-12, considers the next slot (or current slot) to be the selected RA slot for transmission of an initial D2R message (A-IoT Msg1).

[0178] Before transmitting the initial D2R message (A-IoT Msg1) in the selected RA slot, however, each A-IoT device 3-11, 3-12, for which the respective RA slot counter has reached zero, randomly selects one frequency location among the available frequency locations for that RA slot (assuming that the selected frequency location is supported by the A-IoT device 3-11, 3-12, for access according to its device capability) within which to send the initial D2R message (A-IoT Msg1) to the A-IoT device reader. The A-IoT device 3-11, 3-12, then sends the initial D2R message (A-IoT Msg1) to the A-IoT device reader using the selected RA occasion (i.e., the selected RA slot and selected frequency location). The initial D2R message (A-IoT Msg1) may, for example, include a random number based identifier (e.g., RN16 or the like) as in the procedure of Fig. 5, or the A-IoT device identifier as in the procedure of Fig. 6. It will be appreciated that the frequency location may be selected at any suitable time before transmission of the initial D2R message (A-IoT Msg1) including after the RA slot counter reaches zero, or when the A-IoT device 3-11, 3-12 generates the slot selection random number.

[0179] In this example, the A-IoT devices 3-11, 3-12, select different frequency locations and hence whilst the same RA slot is selected contention between those devices is avoided.

[0180] The A-IoT device reader may then echo the identifier sent by the A-IoT device 3-11, 3-12, in the R2D transmission / message (A-IoT Msg2) sent as an access response (e.g., at S508 in the procedure of Fig. 5, or at S608 in the procedure of Fig. 6). When the device receives the R2D transmission / message (A-IoT Msg2) from the A-IoT device reader, the RA is considered successful, otherwise, there may have been some form of contention related failure for that A-IoT device 3-11, 3-12 (in which case the affected A-IoT device 3-11, 3-12 may repeat the random access procedure from the first step).

[0181] It can be seen that, in the first example, the frequency domain is better utilised during A-IoT random access compared to RFID access techniques. In this example, by sending the repeat command / message at every RA slot, synchronisation with the R2D link is updated every RA slot, which helps the A-IoT devices 3-11, 3-12 to maintain accurate clock tracking before attempted access (e.g., even if a relatively large slot selection random number is selected). It will be appreciated that whilst in this example the ALOHA based slot counting was assumed to apply within a single frame, which corresponds to one access round, the slot counting may, nevertheless, be applied across a plurality of frames.

[0182] It will be appreciated that in the first example the slot selection parameter (e.g., 'Q') needs careful selection. As the slot selection parameter (e.g., 'Q') value results in a slot selection random number range with a power factor of 2, too large a value of the slot selection parameter (e.g., 'Q') will reduce the probability of contention but the resulting RA occasions may not be sufficiently utilised within a single access round (because it may take a long time to count down to zero before an A-IoT device can initiate an access attempt). Conversely, too small a value of the slot selection parameter (e.g., 'Q') will increase contention among the A-IoT devices significantly. Moreover, there is a risk that some slots may never be used by the A-IoT devices 3-11, 3-12. For example, even when there are more than two RA slots allocated, the access attempts may be squeezed within the first two RA slots.

[0183] In order to help ensure the random access resources are evenly used, the value of the slot selection parameter (e.g., 'Q') may be determined according to the number of RA slots (or RA occasions in time and frequency) allocated for random access. Moreover, the slot selection random number generated for counting purposes may be based on the number of slots (or RA occasions in time and frequency) allocated for random access within a single frame or a single access round. Nevertheless, use of a slot selection parameter (e.g., 'Q') based on a power factor of 2 does impose some restrictions on slot counting.

[0184] <RACH resource selection - Example 2> 　　A second example of an enhanced random access occasion / resource selection that may be implemented in the communication system 1 is similar to that described with reference to Fig. 10 above, and the illustration of Fig. 10 is still generally applicable.

[0185] In the second example, however, RA slot selection by the A-IoT devices 3-11, 3-12 is based on the slots available for RA.

[0186] Specifically, in the second example, the initial triggering message (A-IoT Msg0) includes information indicating the time slots allocated for RA (e.g. M slots), for example within a single frame, and / or a single access round, and also the set of one or more frequency locations (e.g., Kmfor slot#m) allocated for RA, for each allocated RA time slot (slot#0, slot#1, …, slot#M-1) of the (M) RA slots (e.g., based on one of the random access occasion / resource designs described with reference to Figs. 7 to 9, or some other random access occasion / resource pattern).

[0187] Each A-IoT device 3-11, 3-12 targeted by, and that receives, the initial triggering message (A-IoT Msg0) generates a corresponding slot selection random number, based on the number of available time slots (e.g. M) indicated in the initial triggering message (A-IoT Msg0), in the range 0 to M-1. In the illustrated example in Fig. 10, it is assumed that both A-IoT devices 3-11, 3-12 have selected the same random number (2) for the purposes of illustration.

[0188] Each target A-IoT device 3-11, 3-12, may then start an RA slot counter that counts down from the corresponding generated slot selection random number in successive RA slots (which may also be referred to as "RACH-slots") after receiving the initial triggering message (A-IoT Msg0) - except if the generated number were zero in which case the A-IoT device that selected zero would transmit its initial D2R message (A-IoT Msg1) substantially immediately in the first RA slot (slot#0).

[0189] A decrease in the respective RA slot counter in each A-IoT device 3-11, 3-12, in this example, may be triggered by a 'repeat' message / command (or the like) sent from the A-IoT device reader at the transition to the next RA slot. The 'repeat' message / command may, for example, be a repeated transmission of the initial triggering message (A-IoT Msg0) which may (optionally) include an indication that the following access cycle is a repetition and forms part of the current (same) access round. Thus, the respective RA slot counter in each A-IoT device 3-11, 3-12, decrements by one every time a 'repeat' message / command (or the like) is received from the A-IoT device reader.

[0190] When the generated slot selection random number reaches zero, after the reception of a given 'repeat' message / command (e.g., as indicated for the A-IoT devices 3-11, 3-12, in Fig. 10 at the transition to slot #(K+2)), the corresponding A-IoT device 3-11, 3-12, considers the next slot (i.e., slot #(K+2)) to be the selected RA slot for transmission of an initial D2R message (A-IoT Msg1).

[0191] Alternatively, rather than using an RA slot counter to count down from the slot selection random number, the A-IoT device 3-11, 3-12, may decide which RA slot to use directly based on the slot selection random number, for example by using a direct mapping between each value of the slot selection random number within its range of possible values, and the available RA slots.

[0192] Before transmitting the initial D2R message (A-IoT Msg1) in the selected RA slot, however, each A-IoT device 3-11, 3-12, for which the respective RA slot counter has reached zero, randomly selects one frequency location among the available frequency locations for that RA slot (assuming that the selected frequency location is supported by the A-IoT device 3-11, 3-12, for access according to its device capability) within which to send the initial D2R message (A-IoT Msg1) to the A-IoT device reader. The A-IoT device 3-11, 3-12, then sends the initial D2R message (A-IoT Msg1) to the A-IoT device reader using the selected RA occasion (i.e., the selected RA slot and selected frequency location). The initial D2R message (A-IoT Msg1) may, for example, include a random number based identifier (e.g., RN16 or the like) as in the procedure of Fig. 5, or the A-IoT device identifier as in the procedure of Fig. 6. It will be appreciated that the frequency location may be selected at any suitable time before transmission of the initial D2R message (A-IoT Msg1) including after the RA slot counter reaches zero, or when the A-IoT device generates the slot selection random number.

[0193] In this example, the A-IoT devices 3-11, 3-12, select different frequency locations and hence whilst the same RA slot is selected contention between those devices is avoided.

[0194] The A-IoT device reader may then echo the identifier sent by the A-IoT device 3-11, 3-12, in the R2D transmission / message (A-IoT Msg2) sent as an access response (e.g., at S508 in the procedure of Fig. 5, or at S608 in the procedure of Fig. 6). When an A-IoT device 3-11, 3-12, receives the R2D transmission / message (A-IoT Msg2) from the A-IoT device reader, the RA is considered successful, otherwise, there may have been some form of contention related failure for that A-IoT device 3-11, 3-12 (in which case the affected A-IoT device 3-11, 3-12 may repeat the random access procedure from the first step).

[0195] It can be seen that, in the second example, flexible random slots can be configured and indicated to the target A-IoT devices 3-11, 3-12, compared to an RFID slotted-ALOHA based mechanism for access. Moreover, in this example, by sending the repeat command / message at every RA slot, synchronisation with the R2D link is updated every RA slot, which helps the A-IoT devices 3-11, 3-12 to maintain accurate clock tracking before attempted access (e.g., even if a relatively large slot selection random number is selected).

[0196] It will be appreciated that this second example is flexible enough for further options to be developed to allow even greater flexibility for RA resource selection at the A-IoT devices 3-11, 3-12.

[0197] <RACH resource selection - Example 3> 　　Fig. 11 illustrates a third example of an enhanced random access occasion / resource selection that may be implemented in the communication system 1.

[0198] In this third example, all the slots available for RA are subdivided into a plurality of subsets of RA slots, each subset of RA slots corresponding to a subset of RA occasions (in time and frequency) in that subset of RA slots. RA slot and frequency location for an RA occasion (RA resources) are respectively selected by each target A-IoT device 3-1 (in this example there are three target A-IoT devices 3-11, 3-12, 3-13) from within a specific subset of RA slots that form part of a full set of the slots available for RA within a given access round (which can be (within) a single time frame or may extend across a plurality of time frames). A plurality of initial triggering messages (A-IoT Msg0s) are used to delimit each of these subsets of RA slots during that access round.

[0199] Specifically, in this second example, a first initial triggering message (A-IoT Msg0) includes information indicating a number (e.g., 'P') of subsets of RA occasions into which a full set of RA occasions are divided. Each initial triggering message (A-IoT Msg0), including the first initial triggering message (A-IoT Msg0) and each initial triggering message (A-IoT Msg0) that follows in the access round, includes information indicating each RA occasion of a corresponding subset of RA occasions, from among the full set of the available RA occasions (within the given access round), that are located within a corresponding subset of time slots. Each initial triggering message (A-IoT Msg0) also includes information indicating which subset of RA occasions (or slots), within the full set of RA occasions (or slots). For example, one message (e.g., initial triggering message #3 (A-IoT Msg0) #3 in Fig. 11) may indicate that it is associated with the 3rd subset of the full set (which includes a total of 3 subsets (P=3)).

[0200] For example, if there are 10 RA slots within a given D2R frame (or a given access round). The first initial triggering message (A-IoT Msg0 #1) may only indicate the RA occasions of a subset of RA occasions that are located within a first subset of RA slots comprising the two RA slots that follow that first initial triggering message (A-IoT Msg0 #1). RA occasion selection by an A-IoT device 3-1 (e.g., A-IoT device 3-12 in Fig. 11) that selects the first subset of RA occasions is then based on the RA occasions of that subset of RA occasions located within the two RA slots of the first subset of RA slots.

[0201] Similarly, the second initial triggering message (A-IoT Msg0 #2) may only indicate the RA occasions of a subset of RA occasions that are located within a second subset of RA slots comprising the two RA slots that follow that second initial triggering message (A-IoT Msg0 #2). RA occasion selection by an A-IoT device 3-1 (e.g., A-IoT device 3-13 in Fig. 11) that selects the second subset of RA occasions is then based on the RA occasions of that subset of RA occasions located within the two RA slots of the second subset of RA slots.

[0202] Similarly, the third initial triggering message (A-IoT Msg0 #3) may only indicate the RA occasions of a subset of RA occasions that are located within a third subset of RA slots comprising the two RA slots that follow that third initial triggering message (A-IoT Msg0 #3). RA occasion selection by an A-IoT device 3-1 (e.g., A-IoT device 3-13 in Fig. 11) that selects the third subset of RA occasions is then based on the RA occasions of that subset of RA occasions located within the two RA slots of the third subset of RA slots.

[0203] It will be appreciated that within each subset of time slots, the target A-IoT devices 3-11, 3-12, 3-13 are still able to maintain clock accuracy without any further synchronisation signal / assistance from the A-IoT device reader because there are still only relatively few slots between consecutive initial triggering messages (A-IoT Msg0s). For example, in Fig. 11, as only two slots are available for access within each subset of slots delimited by consecutive initial triggering messages (A-IoT Msg0s), there is insufficient time for significant desynchronisation to occur.

[0204] It will be appreciated that, in this third example, each A-IoT device 3-11, 3-12, 3-13 can randomly select which subset of RA occasions / slots is to be used for access following its reception of the first initial triggering message. To do this the device may generate a random number in the range 0 to K-1 (where K is the number of slot subsets / RA occasion subsets / initial triggering messages) for each access round (or for the access occasions for each radio frame). Each A-IoT device 3-11, 3-12, 3-13 can then count down using a counter (e.g., a slot / RA occasion subset selection counter or the like) each time a new initial triggering message (A-IoT Msg0) is received. Each A-IoT device 3-11, 3-12, 3-13 can also randomly select one of the slots within the selected RA occasion / slot subset, when the counter counts down to zero, from the slots of the corresponding slot subset. Each A-IoT device 3-11, 3-12, 3-13 can also randomly select one frequency location among the available frequency locations for the selected RA slot before sending an initial D2R message (A-IoT Msg1) to the A-IoT device reader.

[0205] <RACH resource selection - Example 4> 　　Fig. 12 illustrates a fourth example of an enhanced random access occasion / resource selection that may be implemented in the communication system 1.

[0206] In the example shown in Fig. 12, four A-IoT devices 3-11, 3-12, 3-13, 3-14 each randomly selects a different respective RA occasion for access with a current access around (covering six time slots in the illustrated example).

[0207] Specifically, in this fourth example, RA slot and frequency location for an RA occasion (RA resources) are respectively selected by each target A-IoT device 3-11, 3-12, 3-13, 3-14, from within a full set of available RA occasions (e.g., within a given access round). Whilst the RA occasion selection of the fourth example may be implemented in the communication system 1 as an independent mechanism for RA resource selection, it may also be implemented as part of the mechanism for resource selection within a slot subset (or RA occasion subset) described in respect of the third example with reference to Fig. 11.

[0208] It will be appreciated that the initial triggering message (A-IoT Msg0) may be configured to indicate the time slot / frequency location information for a limited (sub)set of time slots allocated for RA for which sufficient synchronisation can be maintained.

[0209] Each target A-IoT device 3-11, 3-12, 3-13, 3-14, may then determine the total number of available RA occasions N as follows:

[0210] Each A-IoT device 3-11, 3-12, 3-13, 3-14, targeted by, and that receives, the initial triggering message (A-IoT Msg0) generates then generates a corresponding RA occasion selection random number, in the range 0 to N-1. It can be seen that this RA occasion selection random number corresponds to an associated RA occasion index / number where the RA occasions are sequentially numbered (e.g., in a time first, or a frequency first manner). For example, the RA occasions may be sequentially numbered first in the order of slot number, and then in order of frequency location number (from the lowest to the highest value).

[0211] Based on the RA occasion selection random number generated, each target A-IoT device 3-11, 3-12, 3-13, 3-14, can respectively calculate and locate the exact RA occasion, based on the time slots allocated for RA and also the set of frequency locations configured for RA within each time slot. Effectively, therefore, each A-IoT device 3-11, 3-12, 3-13, 3-14, respectively selects an RA slot (which may be referred to as a "RACH-slot") and the frequency location for RA from among the available frequency locations for RA within that RA slot. Each target A-IoT device 3-11, 3-12, 3-13, 3-14, can then respectively send an initial D2R message (A-IoT Msg1) to the A-IoT device reader using the selected RA occasion. The initial D2R message (A-IoT Msg1) may, for example, include a random number based identifier (e.g., RN16 or the like) as in the procedure of Fig. 5, or the A-IoT device identifier as in the procedure of Fig. 6.

[0212] The A-IoT device reader may then echo the respective identifier sent by each A-IoT device 3-11, 3-12, 3-13, 3-14, in the R2D transmission / message (A-IoT Msg2) sent as an access response (e.g., at S508 in the procedure of Fig. 5, or at S608 in the procedure of Fig. 6). When an A-IoT device 3-11, 3-12, 3-13, 3-14 receives the R2D transmission / message (A-IoT Msg2) from the A-IoT device reader, the RA is considered successful, otherwise, there may have been some form of contention related failure for that A-IoT device 3-11, 3-12, 3-13, 3-14, (in which case the affected A-IoT device 3-11, 3-12, 3-13, 3-14, may repeat the random access procedure from the first step).

[0213] It will be appreciated that as an alternative to selecting an RA occasion in this way, each A-IoT device 3-11, 3-12, 3-13, 3-14, may initially randomly select an RA slot and then randomly a frequency location for RA among the available frequency locations for RA within that selected RA slot (e.g., based on the RF bandwidth capability of that A-IoT device 3-11, 3-12, 3-13, 3-14). Each A-IoT device 3-11, 3-12, 3-13, 3-14 may then respectively send the initial D2R message (A-IoT Msg1) including a random number based identifier (e.g., RN16 or the like) or the A-IoT device identifier.

[0214] It can be seen that, in this fourth example, there is no need to run a counter (e.g., an RA slot counter) that counts down. Moreover there is no need to send a repeat command / message between neighbouring slots for the purpose of clock tracking / synchronisation.

[0215] < Frequency Shift Based D2R Transmission> 　　As mentioned above, the communication system 1 may implement one or more enhancements for enabling an A-IoT device 3-1 to apply a frequency shift based D2R transmission. A number of these enhancements will now be described in more detail, by way of example only.

[0216] It will be appreciated that these enhancements are not restricted to random access procedures over the D2R link (e.g., random access procedures like those referred to above) but are more generally applicable to any D2R transmission.

[0217] It will also be appreciated that although the term 'frequency shift' is generally used in the description of the possible enhancements, any technology that can be used to generate multiple D2R transmissions at different frequencies may be used including, for example, technologies for providing frequency hopping, frequency offsets, support for multiple frequencies, support for multiple bandwidths, support for multiple carriers, and / or the like.

[0218] <Single Message Based Frequency Shift Indication> 　　In one example, a single A-IoT R2D message (e.g., an initial triggering message (A-IoT Msg0) or other suitable A-IoT R2D message) may be used to initiate the application of frequency shifts for all (or a subset of) the A-IoT devices 3-1 within the A-IoT device reader's coverage area. This message may also include information indicating all of the possible set of frequency shifts that a recipient A-IoT device 3-1 can apply.

[0219] Based on the set of frequency shifts, a recipient A-IoT device 3-1 may select one of the frequency shifts for a follow up D2R transmission from the A-IoT device 3-1 (e.g., within a current A-IoT communication session).

[0220] When a further R2D message is sent by the A-IoT device reader (e.g. an R2D message that schedules and / or triggers a further D2R transmission) an indication may be included on the continued applicability of the frequency shift selected by the A-IoT device 3-1 for a further D2R transmission.

[0221] It will be appreciated that, in practice, different A-IoT devices 3-1 may choose different frequency shifts (and hence the associated D2R transmissions using those frequency shifts do not interfere with one another). Each A-IoT device 3-1 can therefore, beneficially, perform (continuous) D2R transmissions based on a one-off random selection of the frequency shift. Nevertheless, the A-IoT device 3-1 can select a different frequency shift for each of its follow up D2R transmissions.

[0222] The implementation of a single A-IoT R2D message based frequency shift indication, in the context of an initial access procedure, will now be described in more detail, by way of example only, with reference to Fig. 13, which is a simplified sequence diagram of one example of an A-IoT procedure for supporting frequency shifted / multiplexed D2R transmissions that may be implemented in the communication system 1.

[0223] It will be appreciated that whilst the single A-IoT R2D message based frequency shift indication is described in the context of an initial access procedure, the use of such an indication is not limited to random access procedures over the D2R link (e.g., random access procedures like those referred to above) but are more generally applicable to any D2R transmission.

[0224] The procedure of Fig. 13 is based on the 'four-step' A-IoT procedure of Fig. 5, and the general description of that procedure also applies here and will not be repeated in the interests of conciseness. It will be appreciated that whilst the procedure of Fig. 13 is based on the 'four-step' A-IoT procedure of Fig. 5, a similar procedure could be based on the 'two-step' A-IoT procedure of Fig. 6.

[0225] In the example of Fig. 13, the A-IoT device reader sends (at S1302) an initial triggering message (A-IoT Msg0) targeted at multiple A-IoT devices 3-1 within the A-IoT device reader's coverage area. This an initial triggering message (A-IoT Msg0) announces (i.e., includes information representing) an order to request that the recipient A-IoT devices 3-1 begin to apply frequency shifts, together with information indicating the set of possible frequency shifts (e.g., each allowed frequency shift number / index and its respective value) that the recipient A-IoT devices 3-1 may apply. Whilst, in the illustrated example the R2D message sent at S1302 is an initial triggering message (A-IoT Msg0) it will be appreciated that any suitable R2D message may carry the order to request application of frequency shifts (e.g., an A-IoT paging message or the like). It will also be appreciated that whilst an initial triggering message (A-IoT Msg0) sent at S1302 may, beneficially, be targeted at all A-IoT devices 3-1 within the A-IoT device reader's coverage area, the initial triggering message (A-IoT Msg0) may, nevertheless, be targeted at a subset of one or more A-IoT devices 3-1 within the coverage area.

[0226] Based on the indicated set of frequency shifts, each target A-IoT device 3-1 that receives the initial triggering message (A-IoT Msg0) respectively selects (at S1304) one of the frequency shifts for a follow up D2R transmissions (e.g. for a current A-IoT communication session of the A-IoT device 3-1).

[0227] For example, upon receiving the R2D message sent at S1302, each A-IoT device 3-1 of the target A-IoT devices 3-1 (e.g., all A-IoT devices 3-1 or a subset of the A-IoT devices 3-1 that exhibit a matching filter criteria) respectively pick two random values - a slot selection random value for the time domain and a frequency selection random value and loads the slot selection random value into a corresponding slot counter. The slot selection random value is selected from the range 0 to a maximum number of slots / time domain access occasions in the access round-1 (inclusive). The frequency selection random value is selected from the range 0 to the maximum number of frequency shifts -1 (inclusive) (assuming that the A-IoT device reader is able to receive D2R transmission at all possible frequency-shifted carrier frequencies indicated in the initial triggering message (or A-IoT paging message) (A-IoT Msg0)). For example, a frequency selection random value of '0' may represent a frequency-shift of '- α', a value of '1' may represent a frequency-shift of '0', and a value of '2' may represents a frequency-shift of '+ α' (or any other appropriate indication scheme).

[0228] Having been triggered by an initial trigger message (A-IoT Msg0), the A-IoT device 3-1 sends, at S1306, an initial device-to-reader (D2R) message ('A-IoT Msg1') based on the selected slot and frequency shift. It will be appreciated that, if the A-IoT device 3-1, in response to the initial trigger message (A-IoT Msg0), loads its slot counter with zero, then the initial D2R message (A-IoT Msg1) sent in reply to the initial trigger message (A-IoT Msg0) may be transmitted immediately based on the randomly selected frequency-shift, otherwise the A-IoT device 3-1 will not transmit until the slot counter reaches zero. In this regard it will be appreciated that a respective R2D message (e.g., an "Access Occasion start message", a "Repeat" command / message, and / or the like) may be sent, at the transition to each subsequent slot, to trigger each targeted A-IoT device 3-1 to decrement their respective slot counter by 1 (regardless randomly selected frequency shift) and when a given A-IoT device's slot counter reaches zero, that A-IoT device 3-1 will transmit an associated initial D2R message (A-IoT Msg1) to the A-IoT device reader based on the randomly selected frequency shift value. The initial D2R message (A-IoT Msg1) carries a corresponding identifier (e.g., a random number / random ID generated by A-IoT device 3-1), and possibly other information, to the A-IoT device reader. The identifier may, for example, be a 16-bit random number (RN16) but may be some other form of (random) identifier.

[0229] 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 S1308, the identifier received in the initial D2R message (A-IoT Msg1) back to the A-IoT device 3-1 in THE R2D access response message (A-IoT Msg2). The R2D access response message (A-IoT Msg2) may include a frequency shift indication to indicate the applicability of the frequency shift selected by the A-IoT device 3-1 for a further D2R transmission.

[0230] The A-IoT device 3-1 then sends, at S1310, a further D2R message (A-IoT Msg3) including that A-IoT device's A-IoT device identifier based on the selected frequency shift (assuming that the frequency shift remains applicable).

[0231] 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 S1312), 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). The R2D data transmission / message (A-IoT Msg4) may include a frequency shift indication to indicate the applicability of the frequency shift selected by the A-IoT device 3-1 for a further D2R transmission.

[0232] 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 S1314). For example, the A-IoT device 3-1 may send a D2R data transmission / message (A-IoT Msg5) to the A-IoT device reader based on the selected frequency shift (assuming that the frequency shift remains applicable). Any such D2R data transmission / message (A-IoT Msg5) may, for example, 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).

[0233] <Multiple Message Based Frequency Shift Indication> 　　In another example, multiple A-IoT R2D messages may be used to initiate the application of frequency shifts for one or a fixed number of target A-IoT devices 3-1 within the A-IoT device reader's coverage area.

[0234] In this example, each R2D message (which may include an initial triggering message (A-IoT Msg0)) can be respectively configured to announce (i.e., include information representing) an order to a targeted set of one or more A-IoT devices 3-1 to request that each target A-IoT devices 3-1 applies a frequency shift and / or one or more frequency shifts that a targeted recipient A-IoT device 3-1 can apply for a following D2R transmission (e.g. a D2R transmission scheduled by that R2D message). The recipient A-IoT device 3-1 then applies the indicated frequency shift (or selects one of the indicated frequency shifts from a set of the indicated frequency shifts) when performing a follow up D2R transmission (e.g. the D2R transmission scheduled by that R2D message).

[0235] It will be appreciated that (optionally) a dedicated R2D message (e.g., a dedicated "Access Occasion start" message or differently named message) may be used to indicate that use of a frequency shift should be started (or stopped) for a single target A-IoT device's following D2R transmission. Alternatively (or additionally) a single common R2D message (e.g., a common "Access Occasion start" message or differently named message) may be used to indicate that use of a frequency shift should be started (or stopped) for the respective following D2R transmission of each A-IoT device 3-1 of a group of multiple A-IoT devices 3-1.

[0236] It will be appreciated that, a given R2D message indicating that one or more A-IoT devices 3-1 should apply a frequency shift for a follow up D2R transmission may not carry any frequency shift parameters. In this case, the R2D message may simply indicate that each target A-IoT device 3-1 should apply a frequency shift for a follow up D2R transmission based on that target A-IoT device's previous selection of a frequency shift (e.g., based on set of frequency shifts indicated in an initial triggering message (A-IoT Msg0)).

[0237] It will also be appreciated that a given R2D message may not carry any frequency shift parameter and may instead simply indicate that each target A-IoT device 3-1 should stop applying a frequency shift for a follow up D2R transmission.

[0238] <Support for Contention Free Access> 　　As mentioned above the communication system 1 may implement one or more enhancements for enabling contention free access for a single A-IoT device 3-1 and / or for multiple A-IoT devices 3-1. A number of possible enhancements for enabling contention free access will now be described in more detail, by way of example only.

[0239] In summary, as described in more detail below, for contention free access using dedicated resources, an A-IoT device reader may directly indicate (e.g., in an initial triggering message (A-IoT Msg0) or the like) one or more dedicated A-IoT access resources (e.g., time / frequency resources for one or more dedicated access occasions), for contention free access, to one or more A-IoT devices 3-1 for performing random access. This is particularly beneficial for a scenario in which that A-IoT device reader is able to identify a single specific target A-IoT device 3-1, or a group of target A-IoT devices 3-1, to act upon the command / message including the dedicated A-IoT access resources. It will be appreciated that the A-IoT device reader may obtain the target A-IoT device ID (or IDs) via one or more inventory requests or may obtain the target A-IoT device ID (or IDs) from the core network.

[0240] The A-IoT device reader may, nevertheless, be configured to support contention free access for a single device either using contention based access resources or using contention-free (dedicated) access resources.

[0241] The A-IoT device reader may be configured to support contention free access for multiple devices using dedicated access resources. Specifically, the A-IoT device reader may be configured to allocate multiple contention-free resources to multiple devices in a dedicated allocation manner within a single message (e.g., an initial triggering message (A-IoT Msg0) or the like). Nevertheless, the A-IoT device reader may be configured to sequentially trigger each A-IoT device 3-1 of multiple A-IoT devices 3-1, one-by-one, with multiple triggering messages to support contention free access for multiple devices (in which case the use of contention-free resources may not be necessary).

[0242] During contention free access, an A-IoT device may provide a D2R message that carries more information / data than for contention based access. The D2R message may, for example, carry the A-IoT device's available D2R data in addition to an A-IoT device identifier and a specific response of the R2D signalling (e.g. R2D command) from the A-IoT device reader (subject to the capacity of the access resource (or resources) allocated for access).

[0243] <Contention Free Access for a Single A-IoT Device (Using Contention Based Procedure)> 　　As mentioned above, an A-IoT device reader may be configured to support contention free access for a single A-IoT device 3-1 utilising a contention based access procedure by limiting it to a single target A-IoT device 3-1.

[0244] To facilitate contention free access for a single A-IoT device 3-1 using contention based resources, an initial triggering message (A-IoT Msg0) may indicate a targeted device 'group' that incudes a single device, or may specifically indicate a single A-IoT device identifier as part of a normal (usually contention based) access procedure (e.g., as described with reference to Fig. 5 or 6 above). The initial triggering message (A-IoT Msg0) may include an indication that a contention-free resource selection applies to the indicated A-IoT device 3-1 - for example, the initial triggering message (A-IoT Msg0) may be configured to set a parameter normally used to indicate the number of access occasions to a value of '0'. On receipt of an initial triggering message (A-IoT Msg0) including such an indication that a contention-free resource selection applies to the indicated A-IoT device 3-1, the A-IoT device 3-1 can determine not to run a slotted ALOHA based procedure to randomly select an access resource for its access (or can select zero as the random number for slot counting during a slotted ALOHA based procedure).

[0245] The initial triggering message (A-IoT Msg0) may indicate a single random access resource (e.g. a single RA occasion comprising a single slot and a single frequency location) for the device's access. Nevertheless, the initial triggering message may indicate multiple random access resources.

[0246] In a case where a single random access resource is indicated by the initial triggering message (A-IoT Msg0), the target (single) A-IoT device 3-1 will select that resource for its access. In a case where multiple random access resources are indicated by the initial triggering message (A-IoT Msg0), the target (single) A-IoT device 3-1 may be configured to select the earliest available slot for its access and, if there is frequency domain resource division within that slot, to randomly select the frequency domain location for its access. Alternatively, the target A-IoT device 3-1 may be configured to select the lowest numbered of the frequency domain locations within the (earliest) slot for its access.

[0247] <Contention Free Access for a Single A-IoT Device (Using Contention Free Procedure)> 　　As mentioned above, an A-IoT device reader may be configured to support contention free access for a single A-IoT device 3-1 using a dedicated contention free access procedure for A-IoT access.

[0248] It will be appreciated that a dedicated contention free procedure can enable faster access to an A-IoT device reader by an A-IoT device 3-1.

[0249] To facilitate contention free access for a single A-IoT device 3-1 using a dedicated contention free procedure, an initial triggering message (A-IoT Msg0) either indicates a targeted device 'group' identifier for a group that includes a single A-IoT device 3-1, or specifically indicates a single A-IoT device identifier.

[0250] The initial triggering message (A-IoT Msg0) also explicitly indicates that the indicated resource is a contention free resource and hence that the indicated resource should only be used by the target A-IoT device 3-1 - i.e., other A-IoT devices 3-1 should not use the indicated resource for access.

[0251] The initial triggering message (A-IoT Msg0) may indicate a single dedicated random access resource (e.g. a single RA occasion comprising a single slot and a single frequency location) for the device's access. This single dedicated random access resource may be configured to be able (to have sufficient capacity) to host both A-IoT device access information and the data available at the A-IoT device 3-1.

[0252] The target (single) A-IoT device 3-1 will select that single contention free resource for its access. Nevertheless, if access fails, the target A-IoT device 3-1 may select a contention based access resource later.

[0253] It will be appreciated that, in this example, during contention free access, the A-IoT device 3-1 may beneficially be able to perform a single step / single D2R message based access-and-response, for example by including one or more of the following information in the D2R message: -　　Any suitable form of A-IoT device ID; -　　A response to the R2D signalling (e.g., R2D command / request) from the A-IoT device reader; and / or -　　Available D2R data stored within the device (which may be deprioritised comparing with device ID and Response of the signalling).

[0254] <Contention Free Access for Multiple A-IoT Devices> 　　As mentioned above, the A-IoT device reader may be configured to support contention free access for multiple devices using dedicated access resources.

[0255] Specifically, an A-IoT device reader can be configured to use a set of dedicated access resources to direct multiple A-IoT devices to perform a contention free access procedure. To facilitate this the A-IoT device reader may be configured to use a dedicated contention free procedure to support the multiple A-IoT device-based contention free random access.

[0256] There are a number of ways in which the set of dedicated access resources, targeted at multiple A-IoT devices 3-1, may be indicated.

[0257] For example, the A-IoT device reader may include, within the initial triggering message (A-IoT Msg0), a set of target A-IoT device identities and may indicate, for each target A-IoT device 3-1, a respective dedicated random access resource using a slot number (index) and frequency location number (index) (for a current frame, or access around) based on a one-to-one resource-device mapping.

[0258] Alternatively, the A-IoT device reader may include, within the initial triggering message (A-IoT Msg0), a set of target A-IoT device identities and may indicate, for each target A-IoT device 3-1, a dedicated resource (with an independent time slot) using the associated slot number (index) - i.e., the slot of the dedicated resource will be chosen to be different for the different A-IoT devices 3-1. Then each target A-IoT device 3-1 may be able to randomly to select the frequency location, within the corresponding indicated slot, to use (if multiple frequency locations are available for that slot) according to the target A-IoT device's capability.

[0259] Alternatively, the A-IoT device reader may include, within the initial triggering message (A-IoT Msg0), a set of target A-IoT device 3-1 identities and may indicate, for each target A-IoT device 3-1, a dedicated resource using an associated indication of a slot subset, slot number (index) (and possibly frequency location number (index)) (i.e., where the resource selection techniques described with reference to Fig. 11 are implemented).

[0260] It will be appreciated that, in this example, during contention free access, the A-IoT device 3-1 may beneficially be able to perform a single step / single D2R message based access-and-response, for example by including one or more of the following information in the D2R message: -　　Any suitable form of A-IoT device ID; -　　A response to the R2D signalling (e.g., R2D command / request) from the A-IoT device reader; and / or -　　Available D2R data stored within the device (which may be deprioritised comparing with device ID and Response of the signalling).

[0261] <Energy based Access for A-IoT Devices> 　　It will be appreciated that in the contention-free access procedures described above, after sending an initial triggering message (A-IoT Msg0) to trigger contention free access (for a single or multiple A-IoT devices 3-1), the target A-IoT device / devices 3-1 may not be able to respond to the A-IoT device reader using a configured (dedicated) contention-free access resource due to, for example, there being insufficient energy stored at an A-IoT device 3-1 for the A-IoT device 3-1 to perform access during the slot of the configured (dedicated) contention-free access resource.

[0262] To alleviate this issue, the communication system 1 may be configured to support an energy based access mechanism for A-IoT devices 3-1.

[0263] In this energy based access mechanism, when an A-IoT device 3-1 is selected / targeted by an initial triggering message (A-IoT Msg0), the A-IoT device 3-1 checks its stored energy level and uses this information to decide whether to initiate random access (i.e., respond to the initial triggering message (A-IoT Msg0)) before selecting any random access resource for its access to the A-IoT device reader. If the energy status indicates that there is (or will be) insufficient energy to perform access during the slot of the configured (dedicated) contention-free access resource, then the A-IoT device 3-1 may skip its access attempt.

[0264] Moreover, if an A-IoT device reader is unable to receive a response from a target A-IoT device 3-1 in a given time window (e.g., defined by a lower bound time point and / or an upper bound time point), the A-IoT device reader may resend an initial triggering message (A-IoT Msg0) indicating a new (set of) configured random resource (resources) for the A-IoT device (devices) 3-1 to perform contention free access, after the expiration of the timer (which can, beneficially, be defined according to a duration required for charging an A-IoT device 3-1). Correspondingly, the A-IoT device 3-1 can delay monitoring for an initial triggering message (A-IoT Msg0) and / or delay initiating an access attempt until charging is completed (to a (pre)configured level), or until the expiration of a timer at the A-IoT device 3-1 (similar to the timer run by the A-IoT device reader).

[0265] Optionally, the A-IoT device 3-1 can indicate a reason / cause for not previously responding (e.g. energy status, decoding error, etc), to the A-IoT device reader in a response sent using the new resource.

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

[0267] 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 3-2; 3-3 (e.g., a user interface 35, such as a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 39 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

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

[0269] The communication control module 43 is operable to control the communication between the UE 3-2; 3-3 and its serving RAN node or RAN nodes 5-1 (and other communication devices connected to the RAN node 5-1, such as further UEs and / or core network nodes). The communication control module 43 is configured for the overall handling of uplink 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.

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

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

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

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

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

[0275] 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 the 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.

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

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

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

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

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

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

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

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

[0284] <RAN node> 　　Fig. 16 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 of Fig. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0312] A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and / or system, a weapon, an item of cutlery, a hand tool, or the like. A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).

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

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

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

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

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

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

[0319] 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 a mobile device, the method comprising: 　　receiving, from a reader device, a paging message; 　　setting a random number 'i' between 0 and n-1, where n is calculated using a number of access occasions configured by the paging message, to a counter; 　　receiving, from the reader device, a triggering message triggering a subset of the access occasions; 　　in a case where a number set to the counter is less than a specific number, selecting an access occasion from the subset of the access occasions, based on the number set to the counter, used for transmitting a message to the reader device, decreasing the number set to the counter by the specific number, otherwise. 　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　the selecting the access occasion is performed based on a capability of the mobile device. 　　(Supplementary note 3) 　　The method according to supplementary note 2, wherein 　　the capability includes a capability of a radio frequency. 　　(Supplementary note 4) 　　The method according to any one of supplementary notes 1 to 3, wherein 　　the specific number is 1. 　　(Supplementary note 5) 　　The method according to any one of supplementary notes 1 to 4, further comprising: 　　transmitting the message including identity information indicating a random number and / or the mobile device. 　　(Supplementary note 6) 　　The method according to supplementary note 5, further comprising: 　　receiving a response message including the identity information; and 　　determining that the transmitting the message is succesful upon receiving the identity information. 　　(Supplementary note 7) 　　The method according to any one of supplementary notes 1 to 6, wherein 　　the triggering message includes information for causing the mobile device to perform frequency shift of frequencies for use in transmitting data. 　　(Supplementary note 8) 　　The method according to supplementary note 7, further comprising: 　　setting another random number between 0 and a max number of frequency shift - 1, to another counter, wherein 　　in a case where a number set to the another counter is less than another specific number, performing the frequency shift for transmitting the message based on the number set to the another counter, decreasing the number set to the another counter by the another specific number, otherwise. 　　(Supplementary note 9) 　　A method performed by a mobile device, the method comprising: 　　receiving, from a reader device, a paging message including information for resources used for transmitting identity information of the mobile device; 　　transmitting, to the reader device, a message including the identity information via a contention free random access procedure. 　　(Supplementary note 10) 　　The method according to supplementary note 9, wherein 　　the paging message includes information indicating at least one mobile device including the mobile device. 　　(Supplementary note 11) 　　The method according to supplementary note 10, wherein 　　the paging message includes information indicating resources per at least one mobile device for a respective mobile device transmitting the identity information of the respective mobile device. 　　(Supplementary note 12) 　　The method according to any one of supplementary notes 1 to 11, wherein 　　the paging message includes information of at least one of a number for time resources or a number of frequency resources. 　　(Supplementary note 13) 　　The method according to any one of supplementary notes 1 to 11, wherein 　　the paging message includes information of a dedicated resource for each of at least one mobile device with information indicating a respective mobile device and information indicating a time resource. 　　(Supplementary note 14) 　　The method according to any one of supplementary notes 1 to 11, wherein 　　the paging message includes information of a dedicated resource for each of at least one mobile device with information indicating a respective mobile device and information indicating a subset of time resources. 　　(Supplementary note 15) 　　The method according to any one of supplementary notes 1 to 14, further comprising: 　　determining to initiate the transmitting the message based on an energy stored in the mobile device. 　　(Supplementary note 16) 　　The method according to supplementary note 15, further comprising: 　　receiving another paging message after an expiration of a timer or a time duration for charging the mobile device. 　　(Supplementary note 17) 　　A method performed by a reader device, the method comprising: 　　transmitting, to a mobile device, a paging message for configuring a counter of the mobile device with a random number 'i' between 0 and n-1, where n is calculated using a number of access occasions; 　　transmitting, to the mobile device, a triggering message triggering a subset of the access occasions, and wherein 　　in a case where a number set to the counter is less than a specific number, an access occasion from the subset of the access occasions is selected by the mobile device, based on the number set to the counter, used for transmitting a message to the reader device, the number set to the counter is decreased by the specific number, otherwise. 　　(Supplementary note 18) 　　A method performed by a reader device, the method comprising: 　　transmitting, to a mobile device, a paging message including information for resources used for transmitting identity information of the mobile device; 　　receiving, from the mobile device, a message including the identity information via a contention free random access procedure. 　　(Supplementary note 19) 　　A mobile device comprising: 　　means for receiving, from a reader device, a paging message; 　　means for setting a random number 'i' between 0 and n-1, where n is calculated using a number of access occasions configured by the paging message, to a counter; 　　means for receiving, from the reader device, a triggering message triggering a subset of the access occasions; 　　means for, in a case where a number set to the counter is less than a specific number, selecting an access occasion from the subset of the access occasions, based on the number set to the counter, used for transmitting a message to the reader device, decreasing the number set to the counter by the specific number, otherwise. 　　(Supplementary note 20) 　　A mobile device comprising: 　　means for receiving, from a reader device, a paging message including information for resources used for transmitting identity information of the mobile device; 　　means for transmitting, to the reader device, a message including the identity information via a contention free random access procedure. 　　(Supplementary note 21) 　　A reader device comprising: 　　means for transmitting, to a mobile device, a paging message for configuring a counter of the mobile device with a random number 'i' between 0 and n-1, where n is calculated using a number of access occasions; 　　means for transmitting, to the mobile device, a triggering message triggering a subset of the access occasions, and wherein 　　in a case where a number set to the counter is less than a specific number, an access occasion from the subset of the access occasions is selected by the mobile device, based on the number set to the counter, used for transmitting a message to the reader device, the number set to the counter is decreased by the specific number, otherwise. 　　(Supplementary note 22) 　　A reader device comprising: 　　means for transmitting, to a mobile device, a paging message including information for resources used for transmitting identity information of the mobile device; 　　means for receiving, from the mobile device, a message including the identity information via a contention free random access procedure.

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

[0321] 1 COMMUNICATION SYSTEM 3 USER EQUIPMENT 5 BASE STATION 7 CORE NETWORK 9 CELL 10 CONTROL PLANE FUNCTIONS 11 USER PLANE FUNCTIONS 21 EXTERNAL DATA NETWORK 31 TRANSCEIVER CIRCUIT 33 ANTENNA 35 USER INTERFACE 37 CONTROLLER 39 MEMORY 41 OPERATING SYSTEM 43 COMMUNICATIONS CONTROL MODULE 331 TRANSCEIVER CIRCUIT 331-1 ENERGY HARVESTING CIRCUITRY 331-2 MODULATION CIRCUITRY 331-3 SIGNAL AMPLIFIER 332 DATA SOURCE 333 ANTENNA 335 USER INTERFACE 337 CONTROLLER 338 PROCESSING CIRCUITRY 339 MEMORY 341 OPERATING SYSTEM 343 COMMUNICATIONS CONTROL MODULE 345 DATA BUFFER 51 TRANSCEIVER CIRCUIT 53 ANTENNA 55 CORE NETWORK INTERFACE 57 CONTROLLER 59 MEMORY 61 OPERATING SYSTEM 63 COMMUNICATIONS CONTROL MODULE 151 TRANSCEIVER CIRCUIT 153 ANTENNA 155 RAN INTERFACE 157 CONTROLLER 159 MEMORY 161 OPERATING SYSTEM 163 COMMUNICATIONS CONTROL MODULE

Claims

A method performed by a mobile device, the method comprising:　　receiving, from a reader device, a paging message;　　setting a random number 'i' between 0 and n-1, where n is calculated using a number of access occasions configured by the paging message, to a counter;　　receiving, from the reader device, a triggering message triggering a subset of the access occasions;　　in a case where a number set to the counter is less than a specific number, selecting an access occasion from the subset of the access occasions, based on the number set to the counter, used for transmitting a message to the reader device, decreasing the number set to the counter by the specific number, otherwise.　　The method according to claim 1, wherein　　the selecting the access occasion is performed based on a capability of the mobile device.　　The method according to claim 2, wherein　　the capability includes a capability of a radio frequency.　　The method according to any one of claims 1 to 3, wherein　　the specific number is 1.　　The method according to any one of claims 1 to 4, further comprising:　　transmitting the message including identity information indicating a random number and / or the mobile device.　　The method according to claim 5, further comprising:　　receiving a response message including the identity information; and　　determining that the transmitting the message is succesful upon receiving the identity information.　　The method according to any one of claims 1 to 6, wherein　　the triggering message includes information for causing the mobile device to perform frequency shift of frequencies for use in transmitting data.　　The method according to claim 7, further comprising:　　setting another random number between 0 and a max number of frequency shift - 1, to another counter, wherein　　in a case where a number set to the another counter is less than another specific number, performing the frequency shift for transmitting the message based on the number set to the another counter, decreasing the number set to the another counter by the another specific number, otherwise.　　A method performed by a mobile device, the method comprising:　　receiving, from a reader device, a paging message including information for resources used for transmitting identity information of the mobile device;　　transmitting, to the reader device, a message including the identity information via a contention free random access procedure.　　The method according to claim 9, wherein　　the paging message includes information indicating at least one mobile device including the mobile device.　　The method according to claim 10, wherein　　the paging message includes information indicating resources per at least one mobile device for a respective mobile device transmitting the identity information of the respective mobile device.　　The method according to any one of claims 1 to 11, wherein　　the paging message includes information of at least one of a number for time resources or a number of frequency resources.　　The method according to any one of claims 1 to 11, wherein　　the paging message includes information of a dedicated resource for each of at least one mobile device with information indicating a respective mobile device and information indicating a time resource.　　The method according to any one of claims 1 to 11, wherein　　the paging message includes information of a dedicated resource for each of at least one mobile device with information indicating a respective mobile device and information indicating a subset of time resources.　　The method according to any one of claims 1 to 14, further comprising:　　determining to initiate the transmitting the message based on an energy stored in the mobile device.　　The method according to claim 15, further comprising:　　receiving another paging message after an expiration of a timer or a time duration for charging the mobile device.　　A method performed by a reader device, the method comprising:　　transmitting, to a mobile device, a paging message for configuring a counter of the mobile device with a random number 'i' between 0 and n-1, where n is calculated using a number of access occasions;　　transmitting, to the mobile device, a triggering message triggering a subset of the access occasions, and wherein　　in a case where a number set to the counter is less than a specific number, an access occasion from the subset of the access occasions is selected by the mobile device, based on the number set to the counter, used for transmitting a message to the reader device, the number set to the counter is decreased by the specific number, otherwise.　　A method performed by a reader device, the method comprising:　　transmitting, to a mobile device, a paging message including information for resources used for transmitting identity information of the mobile device;　　receiving, from the mobile device, a message including the identity information via a contention free random access procedure.　　A mobile device comprising:　　means for receiving, from a reader device, a paging message;　　means for setting a random number 'i' between 0 and n-1, where n is calculated using a number of access occasions configured by the paging message, to a counter;　　means for receiving, from the reader device, a triggering message triggering a subset of the access occasions;　　means for, in a case where a number set to the counter is less than a specific number, selecting an access occasion from the subset of the access occasions, based on the number set to the counter, used for transmitting a message to the reader device, decreasing the number set to the counter by the specific number, otherwise.　　A mobile device comprising:　　means for receiving, from a reader device, a paging message including information for resources used for transmitting identity information of the mobile device;　　means for transmitting, to the reader device, a message including the identity information via a contention free random access procedure.　　A reader device comprising:　　means for transmitting, to a mobile device, a paging message for configuring a counter of the mobile device with a random number 'i' between 0 and n-1, where n is calculated using a number of access occasions;　　means for transmitting, to the mobile device, a triggering message triggering a subset of the access occasions, and wherein　　in a case where a number set to the counter is less than a specific number, an access occasion from the subset of the access occasions is selected by the mobile device, based on the number set to the counter, used for transmitting a message to the reader device, the number set to the counter is decreased by the specific number, otherwise.　　A reader device comprising:　　means for transmitting, to a mobile device, a paging message including information for resources used for transmitting identity information of the mobile device;　　means for receiving, from the mobile device, a message including the identity information via a contention free random access procedure.

Images