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 triggering message for transmitting data using a random access procedure transmitting, to the reader device, data using a resource determined based on timing of an end of the receiving the triggering message.

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 in particular relates, in particular (but not exclusively), to time synchronisation requirements for 'Ambient' Internet-of-Things (IoT) during an initial access procedure (for example in the context of an adapted slotted Additive Links On-line Hawaii Area (ALOHA)-based access procedure between the A-IoT device and an A-IoT device reader).

[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), an Authentication Server Function (AUSF), a Unified Data Management (UDM) entity for managing user specific data, a Policy Control Function (PCF), an Application Function (AF), a Security Anchor Function (SEAF), an Authentication credential Repository and Processing Function (ARPF), and / or the like. The AMF generally corresponds to the MME in 4G and performs many of the functions performed by the MME. Each UPF combines functionality of both the S-GW and P-GW - specifically user plane functionality of the S-GW (SGW-U) and user plane functionality of the P-GW (PGW-U). The SMF provides session management functionality (that formed part of MME functionality in 4G). The SMF also combines the some of the functionality provided by the S-GW and P-GW - specifically control plane functionality of the S-GW (SGW-C) and control plane functionality of the P-GW (PGW-C). The SMF also allocates IP addresses to each UE.

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

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

[0015] <Ambient IoT> 　　'Ambient' IoT (A-IoT) attempts to address some of the above issues and relies on ultra-low complexity devices with ultra-low power. Such A-IoT devices (also herein referred to simply as an IoT device for simplicity) may be categorised as follows: -　　Type A devices: Any A-IoT device that has no means of energy storage and no independent signal generation / amplification capabilities. Such devices rely on backscatter communications (described below) to communicate with other devices. -　　Type B devices: Any A-IoT device that has means of energy storage but no independent signal generation capabilities. Such devices similarly rely on backscatter communications (described below) to communicate with other devices. However, beneficially they can use their stored energy to assist in those backscattering communications. For example, the device can use its stored energy to amplify backscattered signals. -　　Type C devices: Any A-IoT device that has means of energy storage and independent signal generation, i.e., the device has active radio frequency (RF) components that can generate signals for transmission. Typically, such type C devices are much reduced capabilities compared to a non-ambient IoT device.

[0016] Typically, type A, B, and C devices each 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).

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

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

[0019] With respect to data rate targets, for type A, B, and C devices, the user experienced maximum data rate for UL and DL is not less than 5 kbps and the user experienced minimum data rate for UL and DL is not less than 0.1 kbps. Furthermore, with respect to the data being transmitted on the UL and DL a design target of 1000 bits has been sent for the maximum message size that may be transmitted and / or received by type A, B, and C devices.

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

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

[0022] Typically, where such A-IoT devices are implemented in a communication network (also referred to as an A-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.

[0023] A-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 A-IoT device reader (in this example a base station or RAN node) and A-IoT device communicate with one another directly (including the possibility that the base station that transmits to the A-IoT device is different to the base station that receives from the A-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 signal are within the same radio frequency (RF) band. -　　Topology 2 in which a base station (or RAN node) and A-IoT device communicate with one another via an A-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 A-IoT operation). The intermediate node transfers A-IoT data and / or signalling between base station and the A-IoT device. Like Topology 1, this topology may require support of full duplex operation at intermediate node and hence faces similar associated challenges. -　　Topology 3 in which the A-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 A-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 A-IoT device.

[0024] It will be appreciated that for A-IoT devices such as those described above to perform communications with an A-IoT device reader (e.g., a RAN node / base station and / or intermediate / assisting node), access procedures (e.g., RACH procedures, or the like) may need to be performed initially between the A-IoT device and the base station.

[0025] Due to the simplicity of the types of communications capable between such A-IoT devices and the IoT device readers, access procedures that can be performed between A-IoT devices and the IoT device readers can typically be likened to an asynchronous random-access procedure that does not include indications of UL timing advance (TA) information, PRACH preambles, or accurate RACH occasion (RO) information. An example of such an asynchronous random-access procedure is the asynchronous random-access procedure used for radio frequency identification (RFID) devices. For completeness, an example of an asynchronous random-access procedure used for RFID devices will now be described with reference to Fig. 1.

[0026] Fig. 1 is a simplified sequence diagram illustrating a random-access procedure between an RFID device and a conventional RFID reader.

[0027] As shown in Fig. 1, there is provided an RFID device 1Deviceand a RFID reader 1Reader.

[0028] At step S102, the RFID reader 1Readertransmits, to the RFID device 1Device, a triggering message ('Msg0') that may include a temporary identifier (ID) associated with the RFID reader 1Readerand / or an ID associated with the RFID device 1Deviceto which the tiggering message is directed.

[0029] Having received the triggering message, the RFID device 1Deviceselects, at step S104, a random time slot to backscatter a random number (e.g., a 16-bit random number (RN16)) to the RFID reader 1Reader. For example, to select a random time slot for use in communication between the RFID device 1Deviceand the RFID reader 1Reader, the RFID device 1Devicemay select a random number to load into a slot counter, which is used to select a random time slot - e.g., a slot that is reached in time when the slot counter reaches zero. To prevent transmission collisions between multiple RFID devices, the random number selected to load into the slot counter is typically large, thereby reducing the probability of multiple RFID devices in the vicinity of the RFID reader 1Readerloading the same slot, and thus responding to the trigger message sent by the RFID reader 1Readersimultaneously.

[0030] At the same time, the RFID device 1Devicemay switch from an 'arbitrate' state to a 'reply' state. Once the RFID device 1Devicehas selected the RN16, it transmits said RN16 to the RFID reader 1Readerat step S106 in an appropriate message ('Msg1' which is analogous to the Msg1 of a conventional RACH procedure) .

[0031] At step S108, the RFID reader 1Readerdecodes the random number (RN16) backscattered from the RFID device 1Deviceand may echo that random number back to the RFID device 1Deviceto acknowledge successful receipt and decoding of the message. For example, the RFID reader 1Readermay attach the RN16 to the header of a response message ('Msg2' which is analogous to the Msg2 / RAR of a conventional RACH procedure) that it can send to the RFID device 1Devicewithin a specified turnaround time (T) at step S110.

[0032] Additionally, the response message sent at step S110 may include an appropriate grant (or appropriate grant information) to allow the RFID device 1Deviceto schedule further transmissions to the RFID reader 1Readerwhen appropriate. For example, the RFID device 1Devicemay wish to send, at step S112, upper layer data, and the like to the RFID reader 1Readerin an appropriate message ('Msg3' which is analogous to the Msg3 of a conventional RACH procedure) over resources indicated to the RFID device 1Devicein the grant (or grant information).

[0033] Asynchronous random-access procedures such as the one described above may also be used for random-access procedures performed between A-IoT devices and an A-IoT device reader (e.g., a RAN node).

[0034] For example, an A-IoT device and A-IoT device reader may be configured to use an initial access procedure based on, the asynchronous random-access procedure, which is similar to a conventional four-step RACH procedure. Specifically, in the context of A-IoT, random access may be triggered by the A-IoT device reader (e.g., using an appropriate trigger message ('Msg0'). The A-IoT device reader includes, in this 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, group of devices, or all devices in a cell / coverage area. It is also possible that contention-based and / or contention-free access procedures may be supported.

[0035] When triggered (e.g., by an R2D trigger message (e.g., 'Msg0')), the A-IoT device may send an initial device-to-reader (D2R) message ('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 (Msg1) back to the A-IoT device in a reader-to-device (R2D) response message ('Msg2') that may include additional useful information where appropriate. The A-IoT device may then send a further D2R message ('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 (Msg2) includes the same random identifier that was sent by that A-IoT device in the initial D2R message (Msg1). Hence the size of the random identifier needs to be sufficient for effective contention resolution purposes. A further R2D transmission ('Msg4') may then be sent by the A-IoT device reader to the A-IoT device after the further D2R message (Msg3) but does not always need to be sent. The further R2D transmission (Msg4) may, for example, be sent to handle a transmission failure (e.g., a failure of Msg3 due to any of a number of different reasons). It will be appreciated that the 'Msg' terms (e.g., 'Msg4') may or may not be used in practice.

[0036] Similarly, an A-IoT device and an A-IoT device reader may be configured to use an initial access procedure based on, the asynchronous random-access procedure, which is similar to a conventional two-step RACH procedure. Specifically, in the context of A-IoT, random access may be triggered by the A-IoT device reader (e.g., using an appropriate trigger message ('Msg0') as described above).

[0037] In the two-step scenario, when triggered (e.g., by an R2D trigger message (e.g., 'Msg0')), the A-IoT device may send an initial device-to-reader (D2R) message ('MsgA') 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 device-to-reader (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 (MsgA) back to the A-IoT device in a reader-to-device (R2D) response message ('MsgB') that may include additional useful information where appropriate.

[0038] The implementation of A-IoT gives rise to a number of time considerations. For example, in a communication system comprising A-IoT devices and an A-IoT device reader (e.g., a RAN node, or a UE) it is still to be established as to whether and how A-IoT devices will be able to count time with sufficient accuracy (i.e., with a certain timing error due to the initial SFO of up to 10Xppm (where the value of X may be 4 or 5)) at least for the purposes of time-division multiple access (TDMA). Furthermore, even if A-IoT devices are able to count time with sufficient accuracy, it is still to be established for how long the A-IoT devices are able to count time with sufficient accuracy after receiving a reader-to-device (R2D) transmission (e.g., an R2D trigger message, or the like). For example, it will be appreciated that after a certain period of time following an R2D transmission (which may act to help synchronise a clock at the A-IoT device with a clock at the A-IoT device reader), the clock at the receiving A-IoT device may become unsynchronised with respect to the clock at the A-IoT device reader. For example, the A-IoT device may lose approximately 1 ms of time synchronisation after every 10 ms have passed since reception of the R2D transmission. The occurrence of such a loss of time synchronisation between the A-IoT device and the A-IoT device reader may cause issues when the A-IoT device and the A-IoT device reader attempt to perform a random-access procedure; in particular the likely occurrence of decoding failures of device-to-reader (D2R) transmissions triggered in response to a R2D transmission (e.g., an R2D trigger message to trigger a random-access procedure, or the like) may increase.

[0039] One option being considered to help alleviate synchronisation issues is to limit the amount of time that passes between an R2D transmission and a subsequent D2R transmission in a communication system with A-IoT devices and device readers (i.e., the size of the timing gap between an R2D transmission and a subsequent D2R transmission is limited).

[0040] For example, a maximum time (TR2D_Max) between an R2D transmission and a corresponding D2R transmission following it may be defined such that the A-IoT device transmits the D2R transmission within a period [TR2D_Min, TR2D_Max], where TR2D_Min is a minimum gap required between an R2D transmission and a corresponding D2R transmission; for example a minimum time gap may be needed to facilitate synchronisation and / or to allow the A-IoT device reader to switch from signal transmission operation to signal reception operation.

[0041] The value of T2RD_Max may be common for all A-IoT devices in the communication system or may vary between A-IoT devices. TR2D_Max may also vary for different traffic types / command types (e.g., device terminated (DT) traffic or device-originated - device-terminated-triggered (DO-DTT) traffic), and / or different use cases of the transmissions (e.g., transmissions for inventory generation or transmissions for command issuance).

[0042] Another option being considered is that the timing (TR2D) of a D2R transmission following an R2D transmission may be determined based on control information in the R2D transmission (to ensure that TR2D > TR2D_Min). For example, the value of TR2D_Min may be determined based on control information (e.g., TR2D timing information) included in the R2D transmission.

[0043] These timing considerations are of particular relevance in the context of maintaining time synchronisation between the A-IoT device and the A-IoT reader during initial access type procedures.

[0044] Typically, for A-IoT devices, slotted-ALOHA is used as the baseline for ambient IoT random-access procedures. 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). Ideally, all communicating devices need to be appropriately synchronised so that whenever a device makes a transmission, it properly aligns with the next available slot thereby reducing collisions.

[0045] When a device has data to transmit, it waits until the next time available time slot and then sends the transmission. If the transmission is received successfully, the receiving device sends an acknowledgment. If an acknowledgment is not received within a given period, the transmitting device assumes that the transmission was not received and so performs a retransmission in the next available slot.

[0046] Timing considerations in the context of a slotted-ALOHA based random access procedure performed between an A-IoT device and an A-IoT reader will now be discussed with reference to Fig. 2, which illustrates an A-IoT device reader-sided clock line and an A-IoT device-sided clock line, each with a plurality of slots for reader-to-device (R2D) transmissions and corresponding device-to-reader (D2R) transmissions.

[0047] In the context of A-IoT, therefore, during a slotted-ALOHA based procedure (as shown in Fig. 2) an A-IoT device reader may initially send a R2D trigger message (i.e., an initial R2D transmission (e.g., Msg0)) to an A-IoT device in a specific slot (e.g., slot #X) to trigger a random-access procedure.

[0048] For example, to initiate a random-access procedure between an A-IoT device and an A-IoT device reader, the A-IoT device reader may send an R2D trigger message 202 (e.g., Msg0) to the A-IoT device that includes a temporary ID associated with the A-IoT device reader and / or an ID associated with the targeted A-IoT device, and / or an appropriate trigger for initiating the initial access procedure.

[0049] Upon receiving the R2D trigger message 202 (which includes a time acquisition part / indication), the A-IoT device synchronises its clock with a clock of the A-IoT device reader. For example, the R2D trigger message 202 may include an appropriate timing signal to allow the A-IoT device to synchronise with the A-IoT device reader.

[0050] In response to receiving that R2D trigger message 202 from the A-IoT device reader, the A-IoT device may then select a random slot (e.g., a slot between slot#0 and slot#N-1) to perform a corresponding D2R transmission to the A-IoT device reader. In the example shown in Fig. 2 the A-IoT device selects slot #7, which may be selected based on loading a random number in a slot counter, or slot countdown timer.

[0051] However, when the A-IoT device selects a random slot (e.g., a slot between slot#0 and slot#N-1) to perform a D2R transmission to the A-IoT device reader, the timing gap between when the A-IoT device last received an R2D trigger message 202 and when a D2R transmission occurs in response to that R2D trigger message 202 can be N*Slot_Length, where N is the number of slots between the slot in which the last R2D trigger message 202 was received and the slot in which the D2R transmission occurs in response to that R2D trigger message 202. 　　Where the timing gap between when the A-IoT device received the last timing signal and when the D2R transmission occurs is large (i.e., where N*Slot_Length is large), the likelihood of D2R transmission decoding failure is high, as synchronisation between the A-IoT device and the A-IoT device reader may be lost by the time the A-IoT device begins the D2R transmission in response to the last R2D trigger message 202 it received.

[0052] For example, when the R2D trigger message 202 is received by the A-IoT device in a slot #X, and the slot selected for D2R transmission by the A-IoT device in response to that R2D trigger message 202 (e.g., slot#7) is many slots since the R2D trigger message 202, there is a risk that the IoT device and the A-IoT device reader become out-of-synchronisation (as shown in Fig. 2) by a time difference T_us.

[0053] As a consequence of that lack of synchronisation, slot#7 selected by the A-IoT device for the D2R transmission may overlap with an incorrect slot (e.g., slot#6 in Fig. 2), as well as the correct slot (e.g., slot#7 in Fig. 2), on the clock-line of the A-IoT device reader. Thus the probability of contention (collisions) occurring in this scenario is increased when multiple A-IoT devices are contending for the same channel. Furthermore, the possibility of such a lack of synchronisation requires greater implementation complexity for the A-IoT device reader because the A-IoT device reader will need to be able to support scenarios where backscattered D2R transmissions from A-IoT devices can start at any (unaligned) time. This is a particularly significant issue when receiving backscattered signal in presence of interfering signals from other devices (with different synchronisation).

[0054] Appropriate enhancements are therefore needed to help maintain time synchronisation between an A-IoT device reader and the A-IoT devices and minimise the risk that conflicts occur.

[0055] The disclosure aims to provide one or more apparatus and / or one or more associated methods that at least partially addresses or contributes to addressing one or more of the above need.

[0056] The disclosure has a method performed by a mobile device, the method comprising receiving, from a reader device, a triggering message for transmitting data using a random access procedure transmitting, to the reader device, data using a resource determined based on timing of an end of the receiving the triggering message.

[0057] The disclosure has a method performed by a reader device, the method comprising transmitting, to a mobile device, a triggering message for the mobile device to transmit data using a random access procedure receiving, from the mobile device, data using a resource determined based on timing of an end of the receiving the triggering message.

[0058] The disclosure has a mobile device comprising means for receiving, from a reader device, a triggering message for transmitting data using a random access procedure means for transmitting, to the reader device, data using a resource determined based on timing of an end of the receiving the triggering message.

[0059] The disclosure has a reader device comprising means for transmitting, to a mobile device, a triggering message for the mobile device to transmit data using a random access procedure means for receiving, from the mobile device, data using a resource determined based on timing of an end of the receiving the triggering message.

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

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

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

[0063] Fig. 1 is a simplified sequence diagram illustrating a random-access procedure between an RFID device and an RFID reader.Fig. 2 illustrates an A-IoT device reader-sided clock line and an A-IoT device-sided clock line, each with a plurality of slots for reader-to-device (R2D) transmissions and corresponding device-to-reader (D2R) transmissions respectively;Fig. 3 illustrates schematically a mobile (cellular or wireless) communication system to which example embodiments of the disclosure may be applied;Fig. 4 illustrates schematically a first connectivity topology that may be used in the communication system of Fig. 3;Fig. 5 illustrates schematically a second connectivity topology that may be used in the communication system of Fig. 3;Fig. 6A illustrates schematically a third connectivity topology that may be used in the communication system of Fig. 3;Fig. 6B illustrates schematically another arrangement of the third connectivity topology of Fig. 6A;Fig. 7 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a R2D timing signal transmitted immediately prior to each slot;Fig. 8 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a R2D timing signal transmitted a (pre)configured time gap (T_process) prior to a D2R transmission occasion within each slot;Fig. 9 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion for a scenario in which the A-IoT device is able to perform synchronisation for D2R transmission in one D2R transmission occasion / slot, based on an R2D timing signal received before a different D2R transmission occasion;Fig. 10 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a timing margin provided following each D2R transmission occasion;Fig. 11 illustrates an example A-IoT device device-sided clock line with a plurality of non-uniformly distributed slots including D2R transmission occasions;Fig. 12 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a R2D timing signal transmitted immediately prior to a D2R transmission occasion in a first slot of a corresponding group of one or more slots;Fig. 13 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a R2D timing signal transmitted immediately prior to a D2R transmission occasion in a first slot of a corresponding group of one or more slots, with a timing margin provided following each D2R transmission occasion;Fig. 14 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a R2D timing signal transmitted in a dedicated slot for the R2D timing signal;Fig. 15 illustrates another example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a R2D timing signal transmitted immediately prior to groups of slots in a dedicated slot for the R2D timing signal, with a timing margin provided following each D2R transmission occasion;Fig. 16 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a R2D triggering message transmitted prior to subsets of slots;Fig. 17 illustrates an example co-ordination procedure that may be performed between an A-IoT device, an intermediate / assisting node (that acts as an A-IoT device reader), and a RAN node;Fig. 18 is a simplified block schematic illustrating the main components of a UE that may be implemented in the communication system of Fig. 3;Fig. 19 is a simplified block schematic illustrating the main components of an example of a UE comprising an ambient IoT device that may be implemented in the communication system of Fig. 3;Fig. 20 is a simplified block schematic illustrating the main components of an example of a RAN node that may be implemented in the communication system of Fig. 3; andFig. 21 is a simplified block schematic illustrating the main components of an example of an assisting (or intermediate) node that may be implemented in the communication system of Fig. 3.

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

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

[0066] In the communication system 2, user equipments (UEs) 3 (3-1, 3-2, 3-3) (e.g., mobile telephones and / or other mobile devices including (ambient) IoT devices) can communicate with each other via a corresponding radio access network (RAN) node 5-1 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN node 5-1 comprises a base station operating one or more associated cells 9. Communication via the RAN node 5-1 is typically routed through a core network 7 (e.g., a 5G / 6G or later generations core network or evolved packet core network (EPC)).

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

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

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

[0070] Each RAN node 5-1 controls one or more associated cells either directly, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, and / or the like). It will be appreciated that each RAN 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.

[0071] 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 appropriate interfaces (e.g. an F1-C interface and an F1-U interface (together forming an F1 interface (or 'reference point'))), and with one another via an appropriate interface (e.g. an E1 logical interface). It will be appreciated that while the DU may include the physical and virtual elements required to provide the functionality of the lower parts of the PHY layer and hence communicate with the UEs 3 over the air interface, the base station may alternatively (or additionally) include one or more separate radio units (RUs) (e.g., providing this functionality of the lower parts of the PHY layer). It will, nevertheless, be appreciated that the RAN node 5-1 may be a base station may of a non-distributed form, for example as an integrated base station 5-1.

[0072] 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 the so-called 'Uu' interface and / or the like). It will be appreciated that the IoT device 3-1 may, alternatively or additionally, be configured for indirect communication with the 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. 3).

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

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

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

[0076] 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. The AMF 10-1 receives user information sent through the network and forwards the information to the SMF 10-2.

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

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

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

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

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

[0082] Each ambient IoT device 3-1 (hereafter referred to as A-IoT device) 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 of functionality with which the A-IoT device 3-1 is configured is dependent on the type of A-IoT device 3-1.

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

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

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

[0086] <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. 4 to 6.

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

[0088] As shown in Fig. 4, in topology 1 the functionality of the 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.

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

[0090] Nevertheless, although not shown in Fig. 4, topology 1 allows for the possibility that the RAN node 5-1 (A-IoT device reader) transmitting to the A-IoT device 3-1 is a different RAN node 5-1 (A-IoT device reader) from the RAN node 5-1 (A-IoT device reader) receiving from the A-IoT device 3-1. For example, a first RAN node 5-1 (A-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 (A-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 (A-IoT device readers).

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

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

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

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

[0095] Fig. 5 illustrates schematically a second connectivity topology (topology 2) of a mobile (cellular or wireless) communication system 2.

[0096] As shown in Fig. 5, in topology 2 the functionality of the 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. 5 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.

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

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

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

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

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

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

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

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

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

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

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

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

[0109] As shown in Figs. 6A and 6B, in topology 3 part of the functionality of the 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 Figs. 6A and 6B as a type of base station, the assisting node 5-2 may in fact be any one of an IAB node, a UE 3, a repeater, or the like, or any other appropriate device that can act as an intermediary between the RAN node 5-1 and the A-IoT device 3-1.

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

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

[0112] In this example the RAN node 5-1 (base station / cell) is responsible for transmission of an unmodulated carrier signal 20-1 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 ambient 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.

[0113] The communication 20-3 between the RAN node 5-1 and the assisting node 5-2 occurs over an appropriate interface. For example, the RAN node 5-1 and the assisting node 5-2 may communicate over an air interface (such as the Uu interface or the like), for example where the 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.

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

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

[0116] In this example the assisting node 5-2 is responsible for transmission of an unmodulated carrier signal 20-1 to the A-IoT device 3-1. This unmodulated carrier signal 20-1 may be subsequently modulated and backscattered, as a modulated backscattered signal 20-2, from the ambient 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.

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

[0118] Similarly to Fig. 6A, in Fig. 6B 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.

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

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

[0121] <Initial Random Access Procedures> 　　The A-IoT device 3-1 and A-IoT device reader are mutually configured to support one or more initial access procedures (e.g., a procedure similar to a conventional four-step RACH procedure and / or a procedure similar to a conventional two-step RACH procedure). In the communication system the A-IoT initial access procedures are based on a slotted-ALOHA based protocol although it will be appreciated that the A-IoT initial access procedures may be based on other similar protocols (which may or may not be variants of slotted-ALOHA). Specifically, the A-IoT device reader is configured to trigger random access by sending an appropriate reader-to-device (R2D) trigger message (e.g., 'Msg0') to the A-IoT device 3-1 (and possibly other A-IoT device forming part of a group of devices, or all devices, in the cell / coverage area). The A-IoT device reader includes, in this message, information (appropriate parameters) that the A-IoT device 3-1 needs to respond to the random access trigger.

[0122] For a four-step access procedure, when triggered by the R2D trigger message (Msg0), the A-IoT device 3-1 sends an initial device-to-reader (D2R) message ('Msg1') carrying a corresponding identifier (e.g., a random ID generated by A-IoT device 3-1), and possibly other information, to the A-IoT device reader. The A-IoT device 3-1 sends this initial D2R message during a configured D2R transmission occasion selected by the A-IoT device 3-1, potentially from multiple possible configured D2R transmission occasions (i.e., the initial D2R message is transmitted in a slot in which that selected configured D2R transmission occasion occurs).

[0123] The A-IoT device reader echoes the identifier received in the initial D2R message (Msg1) back to the A-IoT device 3-1 in a reader-to-device (R2D) response message ('Msg2') that may include additional useful information where appropriate. The A-IoT device 3-1 then sends a further D2R message ('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 3-1 may consider contention resolution to be successful, if the received response message (Msg2) includes the same random identifier that was sent by that A-IoT device 3-1 in the initial D2R message (Msg1). If needed, a further R2D transmission ('Msg4') may then be sent by the A-IoT device reader to the A-IoT device after the further D2R message (Msg3). The further R2D transmission (Msg4) may, for example, be sent to handle a transmission failure (e.g., a failure of Msg3 due to any of a number of different reasons). It will be appreciated that the 'Msg' terms (e.g., 'Msg4') may or may not be used in practice.

[0124] For a two-step access procedure, when triggered (e.g., by an R2D trigger message (Msg0)), the A-IoT device 3-1 sends an initial device-to-reader (D2R) message ('MsgA') 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 device-to-reader (D2R) message may also include other appropriate information. The A-IoT device 3-1 sends this initial D2R message during a configured D2R transmission occasion selected by the A-IoT device 3-1, potentially from multiple possible configured D2R transmission occasions (i.e., the initial D2R message is transmitted in a slot in which that selected configured D2R transmission occasion occurs).

[0125] The A-IoT device reader the echoes some or all of the information received in the initial D2R message (MsgA) back to the A-IoT device in a reader-to-device (R2D) response message ( 'MsgB') that may include additional useful information where appropriate.

[0126] <Time Synchronisation Related Enhancements> 　　As described in further detail below, the communication system 2 is configured to implement one or more enhancements for assisting to ensure timing synchronisation between the A-IoT device 3-1 and the A-IoT device reader.

[0127] Beneficially, as described in more detail later, the A-IoT device 3-1 and the A-IoT device reader of the communication system 2 may be mutually configured to support one or more enhancements in which the A-IoT device reader is adapted to transmit a timing signal component / aspect of an R2D trigger message multiple times to maintain synchronisation between the A-IoT device 3-1 and the A-IoT device reader.

[0128] For example, as described in further detail below, the synchronisation between the A-IoT device 3-1 and the A-IoT device reader may be maintained by providing the timing signal component / aspect of the R2D trigger message before the D2R transmission occasion within each individual slot that includes such a D2R transmission occasion within which a D2R transmission may occur (e.g., at the start of each individual slot before a corresponding D2R transmission occasion occurs).

[0129] Nevertheless, as described in further detail below, the synchronisation between the A-IoT device 3-1 and the A-IoT device reader may be maintained by providing each timing signal component / aspect of the R2D trigger message before a respective group of slots, where each slot within that group of slots includes a D2R transmission occasion within which a D2R transmission may occur.

[0130] Beneficially, as described in more detail later, the A-IoT device 3-1 and the A-IoT device reader of the communication system 2 may be mutually configured to support an enhancement in which the synchronisation between the A-IoT device 3-1 and the A-IoT device reader is maintained by limiting a number of slots and / or a length of slots that contain D2R transmission occasions within which a D2R transmissions may occur after an R2D trigger message such that insufficient time elapses between each R2D trigger message for the A-IoT device 3-1 and the A-IoT device reader to move out-of-sync with one another.

[0131] Several different approaches for maintaining synchronisation between the A-IoT device 3-1 and the A-IoT device reader will now be described in detail with reference to Figs. 7 to 16. It will be appreciated that while the approaches are described in the specific context of a slotted-ALOHA based initial random-access procedure, the principles and associated benefits are more widely applicable (e.g., to other communication procedures between a UE 3 / A-IoT device 3-1 and A-IoT device reader / RAN node 5-1 that are based on slotted ALOHA or any other suitable slot based protocol).

[0132] <Enhanced Slotted-ALOHA-based Initial Access Procedures for Ambient IoT Devices> 　　As mentioned above, synchronisation between the A-IoT device 3-1 and the A-IoT device reader may be maintained by providing a timing signal component / aspect of an R2D trigger message before a D2R transmission occasion within each individual slot. Examples of how this may be implemented will now be described with reference to Figs. 7 to 11.

[0133] <R2D timing signal provided per slot for synchronization> 　　Fig. 7 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a R2D timing signal transmitted immediately prior to the D2R transmission occasion within each slot.

[0134] As shown in Fig. 7, to facilitate initial time synchronisation between the A-IoT device 3-1 and the A-IoT device reader of the communication system 2, an R2D trigger message 702 (e.g., Msg0 for triggering a four-step or two-step A-IoT initial access procedure) may be provided in a slot #X. That R2D trigger message 702 may, by way of example only, include a temporary ID associated with the A-IoT device reader and / or an ID associated with the targeted A-IoT device 3-1, and / or an appropriate trigger for initiating an initial access procedure between the A-IoT device reader and the A-IoT device 3-1.

[0135] Upon receiving the R2D trigger message 702 (which includes a time acquisition part / indication), the A-IoT device 3-1 synchronises its clock with a clock of the A-IoT device reader. For example, the R2D trigger message 702 may include an appropriate timing signal to allow the A-IoT device 3-1 to synchronise with the A-IoT device reader.

[0136] In response to receiving that R2D trigger message 702 from the A-IoT device reader, the A-IoT device 3-1 may then select a random slot (e.g., a slot between slot#0 and slot#N-1) to perform a corresponding D2R transmission to the A-IoT device reader.

[0137] However, as the selected random slot may occur a long time after the R2D trigger message 702, the A-IoT device 3-1 and the A-IoT device reader may no longer be synchronised by the time the A-IoT device 3-1 reaches that slot for performing a D2R transmission in response to the R2D trigger message 702.

[0138] Therefore, as shown in Fig. 7, to maintain synchronisation between the A-IoT device 3-1 and the A-IoT device reader, an R2D timing signal 704a - 704e (e.g., comprising a timing acquisition part of an R2D trigger message) is transmitted by the A-IoT device reader, and received by the A-IoT device 3-1. In the example of Fig. 7, the R2D timing signal 704a - 704e is transmitted immediately before the D2R transmission occasion within each slot that includes an associated D2R transmission occasion 706a - 706e within which a D2R transmission may occur. Each one of those R2D timing signals may thus be used to help facilitate timing synchronisation between the A-IoT device 3-1 and the A-IoT device reader.

[0139] It will be appreciated that by providing an R2D timing signal immediately before each D2R transmission occasion 706a - 706e, time synchronisation between an A-IoT device reader and the A-IoT device 3-1 is maintained, and the risk of D2R transmission decoding failures occurring due to a lack of timing synchronisation between the A-IoT device reader and the A-IoT devices 3-1 is significantly reduced (if not removed completely).

[0140] For example, irrespective of the D2R transmission occasion / slot that the A-IoT device 3-1 selects to transmit a D2R transmission in response to the R2D trigger message 702 (for example D2R occasion 706c), the A-IoT device 3-1 and the A-IoT device reader will be synchronised in time when the A-IoT device 3-1 reaches that slot (e.g., D2R transmission occasion 706c) thanks to the R2D timing signal transmitted immediately before the D2R transmission occasion within that slot (e.g., R2D timing signal 704c).

[0141] Each R2D timing signal may, by way of example only, include a unique sequence for assisting identification of the start of a slot including a corresponding D2R transmission occasion that follows the R2D timing signal (i.e. to map a specific R2D timing signal to a specific slot containing a D2R transmission occasion). For example, each R2D timing signal may include a preamble that differs from the preamble that is typically included in standard (i.e., typical) R2D transmissions (e.g., R2D trigger messages).

[0142] Optionally, the R2D timing signal may include additional information associated with the slot with which the R2D timing signal is associated. For example, the additional information included in the R2D timing signal may include a slot number of the slot with which the R2D timing signal is associated. This information can be separately indicated from a time acquisition part of the R2D timing signal (e.g., by transmitting a sequence indicating the slot number) or can be embedded within time acquisition part of the R2D timing signal (e.g., the time acquisition signal used may be based on the slot number). It will be appreciated that having the additional information within the R2D timing signal can increase the processing time of the R2D timing signal by the A-IoT device 3-1. Nevertheless, the additional information can be useful when the number of slots is large, or if the A-IoT device 3-1 decides to go into a sleep mode until the start time of a required slot is reached.

[0143] Information pertaining to the R2D timing signals, such as their duration and the like, may be provided to the A-IoT device 3-1 in the R2D trigger message 702 or may be predefined. For example, information pertaining to the duration of each R2D timing signal that will be transmitted by the A-IoT device reader before the D2R transmission occasion within each slot may be provided to the A-IoT device 3-1 in the R2D trigger message 702. That information may be explicitly included in the R2D trigger message 702 via an appropriate indicator / information element. Alternatively, that information may be implicitly indicated in the R2D trigger message 702.

[0144] <Introducing a time gap between each R2D timing signal and a subsequent D2R transmission occasion> 　　It will be appreciated that, depending on how A-IoT is implemented, in the procedure of Fig. 7 there may be insufficient time for the A-IoT device 3-1 to process the R2D timing signal, to perform associated time synchronisation, and to transmit the D2R signal in the corresponding D2R transmission occasion / slot. To allow for this possibility, a time gap may be introduced between the R2D timing signal and the start of the subsequent D2R transmission occasion (T_process).

[0145] Fig. 8 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a R2D timing signal transmitted a (pre)configured time gap (T_process) prior to the D2R transmission occasion within each slot.

[0146] As shown in Fig. 8, to facilitate initial time synchronisation between the A-IoT device 3-1 and the A-IoT device reader of the communication system 2, an R2D trigger message 702 (e.g., Msg0 for triggering a four-step or two-step A-IoT initial access procedure) may be provided in a slot #X. That R2D trigger message 702 may, by way of example only, include a temporary ID associated with the A-IoT device reader and / or an ID associated with the targeted A-IoT device 3-1, and / or an appropriate trigger for initiating an initial access procedure between the A-IoT device reader and the A-IoT device 3-1.

[0147] Upon receiving the R2D trigger message 702 (which includes a time acquisition part / indication), the A-IoT device 3-1 synchronises its clock with a clock of the A-IoT device reader. For example, the R2D trigger message 702 may include an appropriate timing signal to allow the A-IoT device 3-1 to synchronise with the A-IoT device reader.

[0148] In response to receiving that R2D trigger message 702 from the A-IoT device reader, the A-IoT device 3-1 may then select a random slot (e.g., a slot between slot#0 and slot#N-1) to perform a corresponding D2R transmission to the A-IoT device reader.

[0149] However, as the selected random slot may occur a long time after the R2D trigger message 702, the A-IoT device 3-1 and the A-IoT device reader may no longer be in synch by the time the A-IoT device 3-1 reaches that slot for performing a D2R transmission in response to the R2D trigger message 702.

[0150] Therefore, similarly to the scenario depicted in Fig. 7, as shown in Fig. 8, to maintain synchronisation between the A-IoT device 3-1 and the A-IoT device reader, an R2D timing signal 704a - 704e (e.g., comprising a timing signal acquisition part of an R2D trigger message) is transmitted by the A-IoT device reader. In the example of Fig. 8, the R2D timing signal 704a - 704e is transmitted, and received by the A-IoT device 3-1, before the D2R transmission occasion within each slot containing a D2R transmission occasion 706a - 706e within which an D2R transmission may occur. Each one of those R2D timing signals may thus be used to help facilitate timing synchronisation between the A-IoT device 3-1 and the A-IoT device reader.

[0151] However, unlike the scenario depicted in Fig. 7, as shown in Fig. 8, the system may additionally be configured such that a time gap (T_process) is provided between the end of a R2D timing signal and the start of a subsequent D2R transmission occasion.

[0152] It will be appreciated that by providing an R2D timing signal before each D2R transmission occasion 706a - 706e, with an appropriate (small) time gap between them, time synchronisation between an A-IoT device reader and the A-IoT device 3-1 is maintained, and the risk of D2R transmission decoding failures occurring due to a lack of timing synchronisation between the A-IoT device reader and the A-IoT devices 3-1 is significantly reduced (if not removed completely).

[0153] For example, irrespective of the D2R transmission occasion / slot that the A-IoT device 3-1 selects to transmit a D2R transmission in response to the R2D trigger message 702 (for example D2R transmission occasion 706d), the A-IoT device 3-1 and the A-IoT device reader will be synchronised in time when the A-IoT device 3-1 reaches that slot (e.g., D2R transmission occasion 706d) thanks to the R2D timing signal transmitted before the D2R transmission occasion within that slot (e.g., R2D timing signal 704d).

[0154] The duration of the time gap (T_process) between the end of a R2D timing signal and the start of a subsequent D2R transmission occasion may be determined / selected to provide the A-IoT device 3-1 with sufficient time to process the R2D timing signal it received and perform time synchronisation between the A-IoT device 3-1 and the A-IoT device reader, prior to performing a D2R transmission in the corresponding D2R transmission occasion (e.g., D2R transmission occasion 706d).

[0155] It will be appreciated that the duration of the time gap also allows switching time within which the A-IoT device reader can switch from a transmission operation / mode for R2D timing signal transmission to a reception operation / mode for receiving a corresponding D2R transmission from the A-IoT device 3-1.

[0156] The duration of the time gap may be pre-configured, or alternatively it may be provided by the A-IoT device reader to the A-IoT device 3-1 in the R2D trigger message 702 transmitted by the A-IoT device reader.

[0157] The duration of the time gap may, by way of example, range between a minimum value and a maximum value, and a corresponding subsequent D2R transmission by the A-IoT device 3-1 may start anytime which satisfies the minimum and maximum values for the time gap (i.e., anytime within the minimum and maximum values for the time gap).

[0158] It will be appreciated that in the scenario depicted in Fig. 8, each R2D timing signal may include a unique sequence as described above with reference to Fig. 7. Additionally, each R2D timing signal may optionally include additional information associated with the slot within which a D2R transmission occasion should be used for a D2R transmission in response to the R2D trigger message 702 as described above with reference to Fig. 7. Furthermore, information pertaining to the R2D timing signals, such as their duration and the like, may be provided to the A-IoT device 3-1 in advance of receiving the R2D timing signal as described above with reference to Fig. 7.

[0159] <Synchronising D2D transmission in one D2R transmission occasion / slot based on R2D timing signal received before an earlier D2R transmission occasion / slot> 　　As mentioned above, depending on how A-IoT is implemented, where no gap is present between the R2D timing signal and the corresponding D2R transmission occasion (e.g., as described with reference to Fig. 7) there may be insufficient time for the A-IoT device 3-1 to process the R2D timing signal, to perform associated time synchronisation, and to transmit the D2R signal in the corresponding D2R transmission occasion / slot.

[0160] Similarly, where a gap is configured between the R2D timing signal and the corresponding D2R transmission occasion (e.g., similar to that described with reference to Fig. 8), and the size of that gap is set to a value (T_switch) that is set to be sufficient to allow the A-IoT device reader to switch from a transmission mode (for transmitting the R2D timing signal) to a receiving mode (for receiving a D2R transmission), that gap value (e.g., T_switch) may not be sufficiently long enough for the A-IoT device 3-1 to process the R2D timing signal, to perform associated time synchronisation, and to transmit the D2R signal in the corresponding D2R transmission occasion / slot.

[0161] To allow for this possibility, the A-IoT device 3-1 may be configured to be able to perform synchronisation for a D2D transmission in one D2R transmission occasion / slot, based on an R2D timing signal received before an earlier (different) D2R transmission occasion.

[0162] Fig. 9 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion for a scenario in which the A-IoT device is able to perform synchronisation for D2R transmission in one D2R transmission occasion / slot, based on an R2D timing signal received before a different D2R transmission occasion.

[0163] As shown in Fig. 9, to facilitate initial time synchronisation between the A-IoT device 3-1 and the A-IoT device reader of the communication system 2, an R2D trigger message 702 (e.g., Msg0 for triggering a four-step or two-step A-IoT initial access procedure) may be provided in a slot #X. That R2D trigger message 702 may, by way of example only, include a temporary ID associated with the A-IoT device reader and / or an ID associated with the targeted A-IoT device 3-1, and / or an appropriate trigger for initiating an initial access procedure between the A-IoT device reader and the A-IoT device 3-1.

[0164] Upon receiving the R2D trigger message 702 (which includes a time acquisition part / indication), the A-IoT device 3-1 synchronises its clock with a clock of the A-IoT device reader. For example, the R2D trigger message 702 may include an appropriate timing signal to allow the A-IoT device 3-1 to synchronise with the A-IoT device reader.

[0165] In response to receiving that R2D trigger message 702 from the A-IoT device reader, the A-IoT device 3-1 may then select a random slot (e.g., a slot between slot#0 and slot#N-1) to perform a corresponding D2R transmission to the A-IoT device reader.

[0166] However, as the selected random slot may occur a long time after the R2D trigger message 702, the A-IoT device 3-1 and the A-IoT device reader may no longer be in synch by the time the A-IoT device 3-1 reaches that slot for performing a D2R transmission in response to the R2D trigger message 702.

[0167] Therefore, similarly to the scenario depicted in Fig. 8, as shown in Fig. 9, to maintain synchronisation between the A-IoT device 3-1 and the A-IoT device reader, an R2D timing signal 704a - 704e (e.g., comprising a timing signal acquisition part of an R2D trigger message) is transmitted by the A-IoT device reader. In the example of Fig. 9, the R2D timing signal 704a - 704e is transmitted, and received by the A-IoT device 3-1, before the D2R transmission occasion within each slot containing a D2R transmission occasion 706a - 706e within which an D2R transmission may occur. Each one of those R2D timing signals may thus be used to help facilitate timing synchronisation between the A-IoT device 3-1 and the A-IoT device reader.

[0168] Like the scenario depicted in Fig. 8, as shown in Fig. 9, the system may be configured such that a time gap is present between the end of a R2D timing signal and the start of a subsequent D2R transmission occasion. However, in this example, the time gap is set to a value (T_switch) that is only sufficient to allow the A-IoT device reader to switch from a transmission mode (for transmitting the R2D timing signal) to a receiving mode (for receiving a D2R transmission). It will, nevertheless, be appreciated that this example is equally applicable to a scenario in which no such gap is provided (e.g., like the example shown in Fig. 7).

[0169] Accordingly, whilst providing an R2D timing signal before each D2R transmission occasion 706a - 706e with the small time gap (T_switch) between them helps with time synchronisation between an A-IoT device reader and the A-IoT device 3-1 there may still be insufficient time for the A-IoT device 3-1 to process the R2D timing signal, to perform associated time synchronisation, and to transmit the D2R signal in the corresponding D2R transmission occasion / slot immediately following the R2D timing signal.

[0170] To allow for such a possibility, as shown in Fig. 9, the A-IoT device 3-1 in this example is configured to be able the A-IoT device 3-1, if needed, to use an R2D timing signal transmitted immediately before one D2R transmission occasion for performing timing synchronisation for the purposes of making a D2R transmission in a different (later) D2R transmission occasion / slot selected by the A-IoT device 3-1 in response to receiving the R2D trigger message 702. Accordingly, the A-IoT device 3-1 performs the D2R transmission within a (pre)configured time period (which may be referred to as a 'slot gap'), that includes a set number of one or more slots, after reception of the R2D timing signal used for synchronisation purposes.

[0171] For example, if the A-IoT device 3-1 selects slot #N for D2R transmission (e.g., D2R transmission occasion 706e) following reception of the R2D trigger message 702, then the A-IoT device 3-1 may perform time acquisition using an R2D timing signal transmitted to the A-IoT device prior to the D2R transmission occasion within slot #N-1 or slot #N-2 (e.g., R2D timing signal 704d) to provide the A-IoT device 3-1 sufficient time to synchronise with the A-IoT device reader.

[0172] The duration of (e.g., number of slots in) the slot gap may be determined / selected to provide the A-IoT device 3-1 with sufficient time to process a R2D timing signal and perform time synchronisation between the A-IoT device 3-1 and the A-IoT device reader, prior to performing a D2R transmission in a selected D2R transmission occasion (e.g., D2R transmission occasion 706e).

[0173] The duration of the slot gap may be pre-configured, or alternatively it may be provided by the A-IoT device reader to the A-IoT device 3-1 in the R2D trigger message 702.

[0174] The duration of the slot gap may, by way of example, range between a minimum value and a maximum value, and a corresponding subsequent D2R transmission by the A-IoT device 3-1 may start anytime within a range from the minimum value to the maximum value for the slot gap.

[0175] It will be appreciated that in the scenario depicted in Fig. 9, each R2D timing signal may include a unique sequence as described above with reference to Fig. 7. Additionally, each R2D timing signal may optionally include additional information associated with the slot within which a D2R transmission occasion should be used for a D2R transmission in response to the R2D trigger message 702 as described above with reference to Fig. 7. Furthermore, information pertaining to the R2D timing signals, such as their duration and the like, may be provided to the A-IoT device 3-1 in advance of receiving the R2D timing signal as described above with reference to Fig. 7.

[0176] <Introducing a time margin within D2R transmission occasions> 　　It will be appreciated that depending on how A-IoT is implemented, it may be appropriate to provide an (additional) time gap after the end of a D2R transmission occasion to allow for the possibility that a D2R transmission may inadvertently extend beyond the D2R transmission occasion length (e.g., due to de-synchronisation associated with the sampling offset of A-IoT device).

[0177] Fig. 10 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a timing margin provided following each D2R transmission occasion. As shown in Fig. 10, to facilitate initial time synchronisation between the A-IoT device 3-1 and the A-IoT device reader of the communication system 2, an R2D trigger message 702 (e.g., Msg0 for triggering a four-step or two-step A-IoT initial access procedure) may be provided in a slot #X. That R2D trigger message 702 may, by way of example only, include a temporary ID associated with the A-IoT device reader and / or an ID associated with the targeted A-IoT device 3-1, and / or an appropriate trigger for initiating an initial access procedure between the A-IoT device reader and the A-IoT device 3-1.

[0178] Upon receiving the R2D trigger message 702 (which includes a time acquisition part / indication), the A-IoT device 3-1 synchronises its clock with a clock of the A-IoT device reader. For example, the R2D trigger message 702 may include an appropriate timing signal to allow the A-IoT device 3-1 to synchronise with the A-IoT device reader.

[0179] In response to receiving that R2D trigger message 702 from the A-IoT device reader, the A-IoT device 3-1 may then select a random slot (e.g., a slot between slot#0 and slot#N-1) to perform a corresponding D2R transmission to the A-IoT device reader.

[0180] However, as the selected random slot may occur a long time after the R2D trigger message 702, the A-IoT device 3-1 and the A-IoT device reader may no longer be in synch by the time the A-IoT device 3-1 reaches that slot for performing a D2R transmission in response to the R2D trigger message 702.

[0181] Therefore, similarly to the scenario depicted in Fig. 8, as shown in Fig. 10, to maintain synchronisation between the A-IoT device 3-1 and the A-IoT device reader, an R2D timing signal 704a - 704e (e.g., comprising a timing signal acquisition part of an R2D trigger message) is transmitted by the A-IoT device reader. In the example of Fig. 10, the R2D timing signal 704a - 704e is transmitted, and received by the A-IoT device 3-1, before the D2R transmission occasion within each slot containing a D2R transmission occasion 706a - 706e within which an D2R transmission may occur, with a time gap (T_process) between the end of a R2D timing signal and the start of a subsequent D2R transmission occasion. Each one of those R2D timing signals may thus be used to help facilitate timing synchronisation between the A-IoT device 3-1 and the A-IoT device reader.

[0182] Additionally, however, unlike the scenario depicted in Fig. 8, as shown in Fig. 10, within each slot, an additional timing gap (T_margin) may be (pre)configured between the end of an D2R transmission occasion used for the D2R transmission and a subsequent R2D timing signal. That additional timing gap (T_margin) may be provided to account for the scenario where a scheduled D2R transmission extends beyond a D2R transmission occasion due to, for example, a sampling offset of the A-IoT device 3-1.

[0183] It will be appreciated that, the duration of the time gap (T_margin) may also be configured to allow sufficient switching time within which the A-IoT device reader can switch from a reception operation / mode for receiving a corresponding D2R transmission from the A-IoT device 3-1 to a transmission operation / mode for R2D timing signal transmission.

[0184] The duration of the additional timing gap (T_margin) may have a single (pre)configured value common for all slot lengths. In this scenario, the single (pre)configured value for the additional timing gap (T_margin) may be determined based on requirements associated with a largest possible slot duration for D2R transmissions and R2D timing signals for timing acquisition. Alternatively, different durations (or the same duration) of the additional timing gap (T_margin) may be (pre)configured for different slot lengths. It will be appreciated that the duration (or durations) may be predefined or may be indicated to the A-IoT device 3-1 by the A-IoT device reader via an appropriate message (e.g., the R2D trigger message, or the like).

[0185] Alternatively, rather than indicating the duration of the additional timing gap (T_margin) to the A-IoT device 3-1 via an appropriate message (e.g., the R2D trigger message, or the like), a minimum duration of the additional timing gap (T_margin) may be predefined or indicated to the A-IoT device 3-1 by the A-IoT device reader via an appropriate message (e.g., the R2D trigger message, or the like). In this scenario, the A-IoT device 3-1 may perform D2R transmissions such that they satisfy the indicated minimum duration of the additional timing gap (T_margin).

[0186] It will be appreciated that in the scenario depicted in Fig. 10, each R2D timing signal may include a unique sequence as described above with reference to Fig. 7. Additionally, each R2D timing signal may optionally include additional information associated with the slot within which a D2R transmission occasion should be used for a D2R transmission in response to the R2D trigger message 702 as described above with reference to Fig. 7. Furthermore, information pertaining to the R2D timing signals, such as their duration and the like, may be provided to the A-IoT device 3-1 in advance of receiving the R2D timing signal as described above with reference to Fig. 7.

[0187] <A-IoT device detection of one, or multiple R2D timing signals> 　　It will be appreciated that, depending on how A-IoT is implemented, the A-IoT device 3-1 may be configured to detect the R2D timing signal every Nthslot (which may be every slot (N=1) or every two (or more) slots N > 1) to maintain time synchronisation with the A-IoT device reader (even if the A-IoT device 3-1 is not intending to transmit in the corresponding D2R transmission occasion / slot). This may be particularly beneficial, for example, in a scenario in which the time difference between consecutive slots including D2R transmission occasions is non-uniform (for example because the A-IoT device reader may be performing other transmission / reception between those consecutive slots).

[0188] Fig. 11 illustrates an example A-IoT device device-sided clock line with a plurality of non-uniformly distributed slots including D2R transmission occasions.

[0189] As shown in Fig. 11, to facilitate initial time synchronisation between the A-IoT device 3-1 and the A-IoT device reader of the communication system 2, an R2D trigger message 702 (e.g., Msg0 for triggering a four-step or two-step A-IoT initial access procedure) may be provided in a slot #X. That R2D trigger message 702 may, by way of example only, include a temporary ID associated with the A-IoT device reader and / or an ID associated with the targeted A-IoT device 3-1, and / or an appropriate trigger for initiating an initial access procedure between the A-IoT device reader and the A-IoT device 3-1.

[0190] Upon receiving the R2D trigger message 702 (which includes a time acquisition part / indication), the A-IoT device 3-1 synchronises its clock with a clock of the A-IoT device reader. For example, the R2D trigger message 702 may include an appropriate timing signal to allow the A-IoT device 3-1 to synchronise with the A-IoT device reader.

[0191] In response to receiving that R2D trigger message 702 from the A-IoT device reader, the A-IoT device 3-1 may then select a random slot (e.g., a slot between slot#0 and slot#N-1) to perform a corresponding D2R transmission to the A-IoT device reader.

[0192] However, as the selected random slot may occur a long time after the R2D trigger message 702, the A-IoT device 3-1 and the A-IoT device reader may no longer be in synch by the time the A-IoT device 3-1 reaches that slot for performing a D2R transmission in response to the R2D trigger message 702.

[0193] Therefore, similarly to the scenario depicted in Fig. 8, as shown in Fig. 11, to maintain synchronisation between the A-IoT device 3-1 and the A-IoT device reader, an R2D timing signal 704a - 704e (e.g., comprising a timing signal acquisition part of an R2D trigger message) is transmitted by the A-IoT device reader. In the example of Fig. 11, the R2D timing signal 704a - 704e is transmitted, and received by the A-IoT device 3-1, before the D2R transmission occasion within each slot containing a D2R transmission occasion 706a - 706e within which an D2R transmission may occur. Each one of those R2D timing signals may thus be used to help facilitate timing synchronisation between the A-IoT device 3-1 and the A-IoT device reader.

[0194] However, unlike the scenario depicted in Fig. 8, as shown in Fig. 11, the slots, each comprising a D2R transmission occasion, are configured such that they are distributed in time in a non-uniform manner. It will be appreciated that in this scenario the A-IoT device reader may attempt to use the channel for other types of transmissions and / or receptions in between consecutive slots including the D2R transmission occasions. In this case, appropriate adaptations may be required to enable other types of transmissions and / or receptions to be performed by the A-IoT device reader in between the consecutive slots including the D2R transmission occasions, while also ensuring that time synchronisation between the A-IoT device 3-1 and the A-IoT device reader is maintained for performing D2R transmissions.

[0195] In this example, the A-IoT device 3-1 attempts to detect (and to receive) an R2D timing signal for every Nthconfigured slot (where N may be an integer greater than or equal to 1). N may, for example, be determined / selected by the A-IoT device 3-1, or configured by the A-IoT device reader, for helping to maintain synchronisation between the A-IoT device 3-1 and the A-IoT device reader.

[0196] Once the A-IoT device 3-1 detects an R2D timing signal for a slot including a D2R transmission occasion, the A-IoT device 3-1 may then determine the availability of the next slot for a D2R initial access transmission.

[0197] It will be appreciated that by attempts to detect (and to receive) an R2D timing signal for every Nthconfigured slot (where N may be an integer greater than or equal to 1), time synchronisation between an A-IoT device reader and the A-IoT device 3-1 may be maintained, and the risk of D2R transmission decoding failures occurring due to a lack of timing synchronisation between the A-IoT device reader and the A-IoT devices 3-1 is significantly reduced (if not removed completely).

[0198] For example, irrespective of the D2R transmission occasion / slot that the A-IoT device 3-1 selects to transmit a D2R transmission in response to the R2D trigger message 702 (for example D2R occasion 706d), the A-IoT device 3-1 and the A-IoT device reader will be synchronised in time when the A-IoT device 3-1 reaches that slot (e.g., D2R transmission occasion 706d) thanks to the R2D timing signal transmitted before the D2R transmission occasion within that slot (e.g., R2D timing signal 704d).

[0199] It will be appreciated that, in this example, a time gap (e.g., T_process / T_Switch) may also be implemented between the end of a R2D timing signal and the start of a subsequent D2R transmission opportunity (e.g., as described with reference to Fig. 8 or Fig. 9).

[0200] In one example, where R2D timing signals 704a - 704e transmitted by the A-IoT device reader are the same (identical), the A-IoT device 3-1, may, having selected a D2R transmission occasion that it wishes to use to respond to the R2D trigger message 702, initiate a countdown until it reaches the slot containing the selected D2R transmission occasion, and may use the R2D timing signal immediately before the D2R transmission occasion within that selected slot to synchronise with the A-IoT device reader prior to performing the D2R transmission in the selected D2R transmission occasion.

[0201] Nevertheless, where the R2D timing signals 704a - 704e include slot specific information (e.g., for example a slot number, or the like), the A-IoT device 3-1 may perform a D2R transmission in a D2R transmission occasion / slot that immediately follows an R2D timing signal that includes an indication that matches that of the D2R transmission occasion / slot selected by the A-IoT device.

[0202] In this scenario, if for one reason or another the A-IoT device 3-1 misses the R2D timing signal mapped to / associated with the selected slot / D2R transmission occasion, the A-IoT device 3-1 may perform the D2R transmission in any D2R transmission occasion of any subsequent slot. For example, if the A-IoT device 3-1 selected the Mthslot for D2R transmission but it only detects the R2D timing signal of a later (e.g., the (M+1)th) slot then the A-IoT device 3-1 may perform D2R transmission on that slot, or a subsequent slot.

[0203] It will be appreciated that in the scenario depicted in Fig. 11, each R2D timing signal may include a unique sequence as described above with reference to Fig. 7. Additionally, each R2D timing signal may optionally include additional information associated with the slot within which a D2R transmission occasion should be used for a D2R transmission in response to the R2D trigger message 702 as described above with reference to Fig. 7. Furthermore, information pertaining to the R2D timing signals, such as their duration and the like, may be provided to the A-IoT device 3-1 in advance of receiving the R2D timing signal as described above with reference to Fig. 7.

[0204] <R2D timing signal provided per subset of slots for synchronization> 　　As mentioned above, synchronisation between the A-IoT device 3-1 and the A-IoT device reader may alternatively be maintained by providing a timing signal component / aspect of an R2D trigger message before groups of one or more slots. Examples of how this may be implemented will now be described with reference to Figs. 12 to 15.

[0205] Fig. 12 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a R2D timing signal transmitted immediately prior to a D2R transmission occasion in a first slot of a corresponding group of one or more slots.

[0206] As shown in Fig. 12, to facilitate initial time synchronisation between the A-IoT device 3-1 and the A-IoT device reader of the communication system 2, an R2D trigger message 702 (e.g., Msg0 for triggering a four-step or two-step A-IoT initial access procedure) may be provided in a slot #X. That R2D trigger message 702 may, by way of example only, include a temporary ID associated with the A-IoT device reader and / or an ID associated with the targeted A-IoT device 3-1, and / or an appropriate trigger for initiating an initial access procedure between the A-IoT device reader and the A-IoT device 3-1.

[0207] Upon receiving the R2D trigger message 702 (which includes a time acquisition part / indication), the A-IoT device 3-1 synchronises its clock with a clock of the A-IoT device reader. For example, the R2D trigger message 702 may include an appropriate timing signal to allow the A-IoT device 3-1 to synchronise with the A-IoT device reader.

[0208] In response to receiving that R2D trigger message 702 from the A-IoT device reader, the A-IoT device 3-1 may then select a random slot (e.g., a slot between slot#0 and slot#N-1) to perform a corresponding D2R transmission to the A-IoT device reader.

[0209] However, as the selected random slot may occur a long time after the R2D trigger message 702, the A-IoT device 3-1 and the A-IoT device reader may no longer be in synch by the time the A-IoT device 3-1 reaches that slot for performing a D2R transmission in response to the R2D trigger message 702.

[0210] Therefore, as shown in Fig. 12, to maintain synchronisation between the A-IoT device 3-1 and the A-IoT device reader, an R2D timing signal 704a - 704c (e.g., comprising a timing signal acquisition part of an R2D trigger message) is transmitted by the A-IoT device reader. In the example of Fig. 12, the R2D timing signal 704a - 704c is transmitted, and received by the A-IoT device 3-1, before a group (subset) of slots (e.g., immediately before a D2R transmission occasion in a first slot of a corresponding group of one or more slots), each slot containing a D2R transmission occasion 706a - 706g within which an D2R transmission may occur. Each one of those R2D timing signals may thus be used to help facilitate timing synchronisation between the A-IoT device 3-1 and the A-IoT device reader.

[0211] In this scenario, it will also be appreciated that the slot within which the A-IoT device 3-1 should expect to receive R2D timing signals (e.g., a first slot a group of slots) may be indicated to the A-IoT device 3-1 in the R2D trigger message 702.Furthermore, in this scenario, as the D2R transmission occasions / slots are grouped together and a single R2D timing signal is transmitted prior to a D2R transmission occasion in a first slot of each group (subset) of D2R transmission occasions / slots, the grouping of those D2R transmission occasions / slots, and thus the time prior to a D2R transmission occasion in a first slot of each group (subset) of D2R transmission occasions / slots at which the A-IoT device 3-1 should expect to receive a suitable R2D timing signal may be indicated to the A-IoT device 3-1 in advance in the R2D trigger message 702.

[0212] Additionally, a time gap (T_process) between the end of a R2D timing signal and the start of a first D2R transmission occasion of a subsequent group (subset) of D2R transmission occasions may be configured to provide an appropriate (small) time gap between the end of the R2D timing signal and the start of the subsequent group (subset) of D2R transmission occasions sufficient to process the received R2D timing signal and perform time synchronisation between the A-IoT device 3-1 and the A-IoT device reader, prior to performing a D2R transmission in a corresponding D2R transmission occasion of the group of D2R transmission occasions.

[0213] It will be appreciated that the duration of the time gap also allows switching time within which the A-IoT device reader can switch from a transmission operation / mode for R2D timing signal transmission to a reception operation / mode for receiving a corresponding D2R transmission from the A-IoT device 3-1.

[0214] The duration of the time gap may be pre-configured, or alternatively it may be provided by the A-IoT device reader to the A-IoT device 3-1 in the R2D trigger message 702 transmitted by the A-IoT device reader.

[0215] The duration of the time gap may, by way of example, range between a minimum value and a maximum value, and a corresponding subsequent D2R transmission by the A-IoT device 3-1 may start anytime which satisfies the minimum and maximum values for the time gap (i.e., anytime within the minimum and maximum values for the time gap).

[0216] Beneficially by providing R2D timing signals for subsets of D2R transmission occasions, signalling overhead associated with R2D timing signals is reduced. Furthermore, by not transmitting R2D timing signals prior to a D2R transmission occasion in every slot, cross link interference can be reduced where different A-IoT device readers (e.g., different RAN nodes, and / or UEs) are operating in proximity with one another and can use the same set of slots for D2R transmissions, but which are not transmitting R2D timing signals at the same time.

[0217] It will be appreciated that in the scenario depicted in Fig. 12, each R2D timing signal may include a unique sequence as described above with reference to Fig. 7. Additionally, each R2D timing signal may optionally include additional information associated with the slot within which a D2R transmission occasion should be used for a D2R transmission in response to the R2D trigger message 702 as described above with reference to Fig. 7. Furthermore, information pertaining to the R2D timing signals, such as their duration and the like, may be provided to the A-IoT device 3-1 in advance of receiving the R2D timing signal as described above with reference to Fig. 7.

[0218] <Introducing time margins within groups of D2R transmission occasions / slots> 　　It will be appreciated that depending on how A-IoT is implemented, it may be appropriate to provide (additional) time gaps after the end of each D2R transmission occasion / slot of a group of D2R transmission occasions / slots to allow for the possibility that a D2R transmission in one or more of those D2R transmission occasions may inadvertently extend beyond the D2R transmission occasion length (e.g., due to de-synchronisation associated with the sampling offset of A-IoT device).

[0219] Fig. 13 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a R2D timing signal transmitted immediately prior to a D2R transmission occasion in a first slot of a corresponding group of one or more slots, with a timing margin provided following each D2R transmission occasion.

[0220] As shown in Fig. 13, to facilitate initial time synchronisation between the A-IoT device 3-1 and the A-IoT device reader of the communication system 2, an R2D trigger message 702 (e.g., Msg0 for triggering a four-step or two-step A-IoT initial access procedure) may be provided in a slot #X. That R2D trigger message 702 may, by way of example only, include a temporary ID associated with the A-IoT device reader and / or an ID associated with the targeted A-IoT device 3-1, and / or an appropriate trigger for initiating an initial access procedure between the A-IoT device reader and the A-IoT device 3-1.

[0221] Upon receiving the R2D trigger message 702 (which includes a time acquisition part / indication), the A-IoT device 3-1 synchronises its clock with a clock of the A-IoT device reader. For example, the R2D trigger message 702 may include an appropriate timing signal to allow the A-IoT device 3-1 to synchronise with the A-IoT device reader.

[0222] In response to receiving that R2D trigger message 702 from the A-IoT device reader, the A-IoT device 3-1 may then select a random slot (e.g., a slot between slot#0 and slot#N-1) to perform a corresponding D2R transmission to the A-IoT device reader.

[0223] However, as the selected random slot may occur a long time after the R2D trigger message 702, the A-IoT device 3-1 and the A-IoT device reader may no longer be in synch by the time the A-IoT device 3-1 reaches that slot for performing a D2R transmission in response to the R2D trigger message 702.

[0224] Therefore, as shown in Fig. 13, to maintain synchronisation between the A-IoT device 3-1 and the A-IoT device reader, an R2D timing signal 704a - 704c (e.g., comprising a timing signal acquisition part of an R2D trigger message) is transmitted by the A-IoT device reader. In the example of Fig. 13, the R2D timing signal 704a - 704c is transmitted, and received by the A-IoT device 3-1, before each group (subset) of slots (e.g., immediately before a D2R transmission occasion in a first slot of a corresponding group of one or more slots), each slot containing a D2R transmission occasion 706a - 706g within which an D2R transmission may occur.

[0225] In this scenario, it will also be appreciated that the slot within which the A-IoT device 3-1 should expect to receive R2D timing signals (e.g., a first slot of a group of slots) may be indicated to the A-IoT device 3-1 in the R2D trigger message 702.

[0226] Furthermore, in this scenario, as the D2R transmission occasions / slots are grouped together and a single R2D timing signal is transmitted prior to a D2R transmission occasion in a first slot of each group (subset) of D2R transmission occasions / slots, the grouping of those D2R transmission occasions / slots, and thus the time prior to a D2R transmission occasion in a first slot of each group (subset) of D2R transmission occasions / slots at which the A-IoT device 3-1 should expect to receive a suitable R2D timing signal may be indicated to the A-IoT device 3-1 in advance in the R2D trigger message 702.

[0227] A time gap (T_process) between the end of a R2D timing signal and the start of a subsequent group (subset) of D2R transmission occasions may be configured to provide an appropriate (small) time gap, between the end of the R2D timing signal and the start of the first D2R transmission occasion of a subsequent group (subset) of D2R transmission occasions, sufficient to process the received R2D timing signal and perform time synchronisation between the A-IoT device 3-1 and the A-IoT device reader, prior to performing a D2R transmission in a corresponding D2R transmission occasion of the group of D2R transmission occasions.

[0228] It will be appreciated that the duration of the time gap also allows switching time within which the A-IoT device reader can switch from a transmission operation / mode for R2D timing signal transmission to a reception operation / mode for receiving a corresponding D2R transmission from the A-IoT device 3-1.

[0229] The duration of the time gap may be pre-configured, or alternatively it may be provided by the A-IoT device reader to the A-IoT device 3-1 in the R2D trigger message 702 transmitted by the A-IoT device reader.

[0230] The duration of the time gap may, by way of example, range between a minimum value and a maximum value, and a corresponding subsequent D2R transmission by the A-IoT device 3-1 may start anytime which satisfies the minimum and maximum values for the time gap (i.e., anytime within the minimum and maximum values for the time gap).

[0231] Moreover, as shown in Fig. 13, within each slot, one or more additional timing gaps (e.g., T_margin 1 and T_margin 2) may be (pre)configured. For example, one timing gap (T_margin 1) may be provided between the end of one D2R transmission occasion of a group of D2R transmission occasions, and the start of another. Similarly, another timing gap (T_margin 2) may be provided between the last D2R transmission occasion of a group of D2R transmission occasions and a subsequent R2D timing signal. It will be appreciated that T_margin 1 and T_margin 2 may be the same (i.e., T_margin 1 = T_margin 2 = T_margin).

[0232] That additional timing gap or gaps (T_margin / T_margin 1 / T_margin 2) may be provided to account for the scenario where a scheduled D2R transmission extends beyond a D2R transmission occasion due to, for example, a sampling offset of the A-IoT device 3-1.

[0233] It will be appreciated that, the duration of the additional timing gap or gaps (T_margin / T_margin 1 / T_margin 2) may also be configured to allow sufficient switching time within which the A-IoT device reader can switch from a reception operation / mode for receiving a corresponding D2R transmission from the A-IoT device 3-1 to a transmission operation / mode for R2D timing signal transmission.

[0234] The duration of the additional timing gap or gaps (T_margin / T_margin 1 / T_margin 2) may each have a respective single (pre)configured value common for all slot lengths. In this scenario, each single (pre)configured value for a corresponding timing gap (T_margin / T_margin 1 / T_margin 2) may be determined based on requirements associated with a largest possible slot duration for D2R transmissions and R2D timing signals for timing acquisition. Alternatively, different durations (or the same duration) for a corresponding timing gap (T_margin / T_margin 1 / T_margin 2) may be (pre)configured for different slot lengths. It will be appreciated that the duration (or durations) may be predefined or may be indicated to the A-IoT device 3-1 by the A-IoT device via an appropriate message (e.g., the R2D trigger message, or the like). It will also be appreciated that the A-IoT device 3-1 may be configured for determining one additional timing gap (e.g., T_margin 1 or T_margin 2) from another additional timing gap (e.g., T_margin 2 or T_margin 1) that is configured by the A-IoT device reader.

[0235] Alternatively, rather than indicating the duration of an additional timing gap (e.g., T_margin 2 or T_margin 1) to the A-IoT device 3-1 via an appropriate message (e.g., the R2D trigger message, or the like), a minimum duration of that additional timing gap (e.g., T_margin 2 or T_margin 1) may be predefined or indicated to the A-IoT device 3-1 by the A-IoT device reader via an appropriate message (e.g., the R2D trigger message, or the like). In this scenario, the A-IoT device 3-1 may perform D2R transmissions such that they satisfy the indicated minimum duration of that additional timing gap (e.g., T_margin 2 or T_margin 1).

[0236] Beneficially by providing R2D timing signals for subsets of D2R transmission occasions / slots, signalling overhead associated with R2D timing signals is reduced. Furthermore, by not transmitting R2D timing signals prior to a D2R transmission occasion in every slot, cross link interference can be reduced where different A-IoT device readers (e.g., different RAN nodes, and / or UEs) are operating in proximity with one another and can use the same set of slots for D2R transmissions, but which are not transmitting R2D timing signals at the same time.

[0237] It will be appreciated that in the scenario depicted in Fig. 13, each R2D timing signal may include a unique sequence as described above with reference to Fig. 7. Additionally, each R2D timing signal may optionally include additional information associated with the slot within which a D2R transmission occasion should be used for a D2R transmission in response to the R2D trigger message 702 as described above with reference to Fig. 7. Furthermore, information pertaining to the R2D timing signals, such as their duration and the like, may be provided to the A-IoT device 3-1 in advance of receiving the R2D timing signal as described above with reference to Fig. 7.

[0238] Additionally, as shown in Fig. 13, to allow more capacity for D2R transmissions, the duration of D2R transmission occasions may be increased for the slots where an R2D timing signal is not transmitted to the A-IoT device 3-1. For example, the A-IoT device 3-1 may determine the length / duration of each D2R transmission occasion in a slot based on determining whether a R2D timing signal is present before the D2R transmission occasion in the slot.

[0239] For example, where the A-IoT device 3-1 determines that a R2D timing signal is present prior to a D2R transmission within a slot, the A-IoT device 3-1 may determine that the D2R transmission occasion in that slot has a length / duration equal to:

[0240] Conversely, where the A-IoT device 3-1 determines that a R2D timing signal is not present in a slot, the A-IoT device 3-1 may determine that the D2R transmission occasion in that slot has a length / duration equal to:

[0241] In both of the calculations above: -　　T_margin 1 (or T_margin 2) is a time gap in each slot after a D2R transmission occasion that is needed to account for scenarios where a D2R transmission extends beyond the D2R transmission occasion length of the D2R transmission occasion (e.g., due to a sampling offset at the A-IoT device 3-1). As mentioned above T_margin 1 may be equal to, or different from, T_margin 2; -　　T_process is a time gap between a R2D timing signal and a subsequent D2R transmission occasion.; -　　R2D signal length is a length / duration of the R2D timing signal sent to the A-IoT device 3-1 by the A-IoT device reader.

[0242] It will be appreciated that as the duration of D2R transmission occasions in slots may be extended as described above, the A-IoT device 3-1 may select a specific slot for performing a D2R transmission depending on data requirements (e.g., the size of the data to be transmitted) it has for performing the D2R transmission.

[0243] <Embedding R2D timing signals in dedicated slots separate form slots for D2R transmissions occasions> 　　Fig. 14 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a R2D timing signal transmitted in a dedicated slot for the R2D timing signal.

[0244] As shown in Fig. 14, to facilitate initial time synchronisation between the A-IoT device 3-1 and the A-IoT device reader of the communication system 2, an R2D trigger message 702 (e.g., Msg0 for triggering a four-step or two-step A-IoT initial access procedure) may be provided in a slot #X. That R2D trigger message 702 may, by way of example only, include a temporary ID associated with the A-IoT device reader and / or an ID associated with the targeted A-IoT device 3-1, and / or an appropriate trigger for initiating an initial access procedure between the A-IoT device reader and the A-IoT device 3-1.

[0245] Upon receiving the R2D trigger message 702 (which includes a time acquisition part / indication), the A-IoT device 3-1 synchronises its clock with a clock of the A-IoT device reader. For example, the R2D trigger message 702 may include an appropriate timing signal to allow the A-IoT device 3-1 to synchronise with the A-IoT device reader.

[0246] In response to receiving that R2D trigger message 702 from the A-IoT device reader, the A-IoT device 3-1 may then select a random slot (e.g., a slot between slot#0 and slot#N-1) to perform a corresponding D2R transmission to the A-IoT device reader.

[0247] However, as the selected random slot may occur a long time after the R2D trigger message 702, the A-IoT device 3-1 and the A-IoT device reader may no longer be in synch by the time the A-IoT device 3-1 reaches that slot for performing a D2R transmission in response to the R2D trigger message 702.

[0248] Therefore, as shown in Fig. 14, to maintain synchronisation between the A-IoT device 3-1 and the A-IoT device reader, an R2D timing signal 704a - 704c (e.g., comprising a timing signal acquisition part of an R2D trigger message) is transmitted by the A-IoT device reader, and received by the A-IoT device 3-1, before each group (subset) of slots (e.g., in a dedicated slot before the first slot of a corresponding group of one or more slots containing a D2R transmission occasions 706a - 706g within which an D2R transmission may occur).

[0249] In this scenario, it will also be appreciated that the slot within which the A-IoT device 3-1 should expect to receive R2D timing signals (e.g., a first slot of a group of slots) may be indicated to the A-IoT device 3-1 in the R2D trigger message 702.

[0250] Furthermore, in this scenario, as the D2R transmission occasions / slots are grouped together and a single R2D timing signal is transmitted prior to a D2R transmission occasion in a first slot of each group (subset) of D2R transmission occasions / slots, the grouping of those D2R transmission occasions / slots, and thus the time prior to a D2R transmission occasion in a first slot of each group (subset) of D2R transmission occasions / slots at which the A-IoT device 3-1 should expect to receive a suitable R2D timing signal may be indicated to the A-IoT device 3-1 in advance in the R2D trigger message 702.

[0251] Moreover, as shown in Fig. 14, within each slot, one or more additional timing gaps (e.g., T_margin 1 and T_margin 2) may be (pre)configured. For example, one timing gap (T_margin 1) may be provided between the end of one D2R transmission occasion of a group of D2R transmission occasions, and the start of another. Similarly, another timing gap (T_margin 2) may be provided between the last D2R transmission occasion of a group of D2R transmission occasions and a subsequent R2D timing signal. It will be appreciated that T_margin 1 and T_margin 2 may be the same (i.e., T_margin 1 = T_margin 2 = T_margin).

[0252] That additional timing gap or gaps (T_margin / T_margin 1 / T_margin 2) may be provided to account for the scenario where a scheduled D2R transmission extends beyond a D2R transmission occasion due to, for example, a sampling offset of the A-IoT device 3-1.

[0253] It will be appreciated that, the duration of the additional timing gap or gaps (T_margin / T_margin 1 / T_margin 2) may also be configured to allow sufficient switching time within which the A-IoT device reader can switch from a reception operation / mode for receiving a corresponding D2R transmission from the A-IoT device 3-1 to a transmission operation / mode for R2D timing signal transmission.

[0254] The duration of the additional timing gap or gaps (T_margin / T_margin 1 / T_margin 2) may each have a respective single (pre)configured value common for all slot lengths. In this scenario, each single (pre)configured value for a corresponding timing gap (T_margin / T_margin 1 / T_margin 2) may be determined based on requirements associated with a largest possible slot duration for D2R transmissions and R2D timing signals for timing acquisition. Alternatively, different durations (or the same duration) for a corresponding timing gap (T_margin / T_margin 1 / T_margin 2) may be (pre)configured for different slot lengths. It will be appreciated that the duration (or durations) may be predefined or may be indicated to the A-IoT device 3-1 by the A-IoT device via an appropriate message (e.g., the R2D trigger message, or the like). It will also be appreciated that the A-IoT device 3-1 may be configured for determining one additional timing gap (e.g., T_margin 1 or T_margin 2) from another additional timing gap (e.g., T_margin 2 or T_margin 1) that is configured by the A-IoT device reader.

[0255] Alternatively, rather than indicating the duration of an additional timing gap (e.g., T_margin 2 or T_margin 1) to the A-IoT device 3-1 via an appropriate message (e.g., the R2D trigger message, or the like), a minimum duration of that additional timing gap (e.g., T_margin 2 or T_margin 1) may be predefined or indicated to the A-IoT device 3-1 by the A-IoT device reader via an appropriate message (e.g., the R2D trigger message, or the like). In this scenario, the A-IoT device 3-1 may perform D2R transmissions such that they satisfy the indicated minimum duration of that additional timing gap (e.g., T_margin 2 or T_margin 1).

[0256] Beneficially by providing R2D timing signals for subsets of D2R transmission occasions (i.e., slots), signalling overhead associated with R2D timing signals is reduced. Furthermore, by not transmitting R2D timing signals prior to a D2R transmission occasion in every slot, cross link interference can be reduced where different A-IoT device readers (e.g., different RAN nodes, and / or UEs) are operating in proximity with one another and can use the same set of slots for D2R transmissions, but which are not transmitting R2D timing signals at the same time.

[0257] However, unlike the scenarios depicted in Figs. 12 and 13, in this case as shown in Fig. 14, rather than embedding a R2D timing signal immediately before a D2R transmission occasion in a first slot of a corresponding group of one or more slots with D2R transmission occasions, a respective dedicated slot may be reserved for the respective transmission of an R2D timing signal prior to the corresponding group of slot comprising D2R transmission occasions.

[0258] It will be appreciated that reserving entire slots for R2D timing signals can result in additional signalling overhead in the system. As such appropriate methods / approaches can be used to improve resource utilisation in the system to address that significant signalling overhead. For example, slot lengths for those slots within which an R2D timing signals are transmitted and / or the slots within which D2R transmission occasions occur may be reduced in length compared to the slot length of a slot used for the R2D trigger message 702.

[0259] Additionally (or alternatively), the slot length for the slots within which an R2D timing signal transmission occurs may be reduced (or different) compared to the slot length of slots with D2R transmission occasions. In this case, the A-IoT device reader may provide the A-IoT device 3-1 with an appropriate indication of the different slot lengths for slots used for R2D timing signals and slots used for D2R transmission occasions.

[0260] Additionally (or alternatively), slots used for R2D timing signals may be used / configured for other R2D timing signals such as R2D timing signals from other A-IoT devices). For example, where multiple A-IoT devices in the communication system 2 share a common R2D timing signal for timing acquisition and synchronisation with a A-IoT device reader, multiple R2D timing signals, each directed toward a specific one of the A-IoT devices of the communication system may be included in each slot for R2D timing signals.

[0261] Additionally, similarly to the scenario shown in Fig. 13, to allow more capacity for D2R transmissions, the duration of D2R transmission occasions may be increased for the slots where a R2D timing signal is not transmitted to the A-IoT device 3-1. In this case, the A-IoT device 3-1 may determine the length / duration of each D2R transmission occasion in a slot based on determining whether a R2D timing signal is present after the slot and / or before a subsequent slot as already described above with reference to Fig. 13.

[0262] It will be appreciated that in the scenario depicted in Fig. 14, each R2D timing signal may include a unique sequence as described above with reference to Fig. 7. Additionally, each R2D timing signal may optionally include additional information associated with the slot within which a D2R transmission occasion should be used for a D2R transmission in response to the R2D trigger message 702 as described above with reference to Fig. 7. Furthermore, information pertaining to the R2D timing signals, such as their duration and the like, may be provided to the A-IoT device 3-1 in advance of receiving the R2D timing signal as described above with reference to Fig. 7.

[0263] < R2D timing signal provided per subset of slots for synchronisation with each R2D timing signal indicating a start of N consecutive slots > 　　Fig. 15 illustrates another example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a R2D timing signal transmitted in a dedicated slot for the R2D timing signal, with a timing margin provided following each D2R transmission occasion.

[0264] As shown in Fig. 15, to facilitate initial time synchronisation between the A-IoT device 3-1 and the A-IoT device reader of the communication system 2, an R2D trigger message 702 (e.g., Msg0 for triggering a four-step or two-step A-IoT initial access procedure) may be provided in a slot #X. That R2D trigger message 702 may, by way of example only, include a temporary ID associated with the A-IoT device reader and / or an ID associated with the targeted A-IoT device 3-1, and / or an appropriate trigger for initiating an initial access procedure between the A-IoT device reader and the A-IoT device 3-1.

[0265] Upon receiving the R2D trigger message 702 (which includes a time acquisition part / indication), the A-IoT device 3-1 synchronises its clock with a clock of the A-IoT device reader. For example, the R2D trigger message 702 may include an appropriate timing signal to allow the A-IoT device 3-1 to synchronise with the A-IoT device reader.

[0266] In response to receiving that R2D trigger message 702 from the A-IoT device reader, the A-IoT device 3-1 may then select a random slot (e.g., a slot between slot#0 and slot#N-1) to perform a corresponding D2R transmission to the A-IoT device reader.

[0267] However, as the selected random slot may occur a long time after the R2D trigger message 702, the A-IoT device 3-1 and the A-IoT device reader may no longer be in synch by the time the A-IoT device 3-1 reaches that slot for performing a D2R transmission in response to the R2D trigger message 702.

[0268] Therefore, as shown in Fig. 15, to maintain synchronisation between the A-IoT device 3-1 and the A-IoT device reader, an R2D timing signal 704a - 704c (e.g., comprising a timing signal acquisition part of an R2D trigger message) is transmitted by the A-IoT device reader, and received by the A-IoT device 3-1, before each group (subset) of slots (e.g., in a dedicated slot before the first slot of a corresponding group of one or more slots containing a D2R transmission occasions 706a - 706g within which an D2R transmission may occur).

[0269] In this scenario, it will also be appreciated that the slot within which the A-IoT device 3-1 should expect to receive R2D timing signals (e.g., a first slot of a group of slots) may be indicated to the A-IoT device 3-1 in the R2D trigger message 702.

[0270] Furthermore, in this scenario, as the D2R transmission occasions / slots are grouped together and a single R2D timing signal is transmitted prior to each group (subset) of D2R transmission occasions / slots, the grouping of those D2R transmission occasions / slots, and thus the time prior to each group (subset) of D2R transmission occasions / slots at which the A-IoT device 3-1 should expect to receive a suitable R2D timing signal may be indicated to the A-IoT device 3-1 in advance in the R2D trigger message 702.

[0271] Additionally, a time gap (T_process) between the end of a R2D timing signal and the start of a subsequent group (subset) of D2R transmission occasions may be configured to provide an appropriate (small) time gap between the end of the R2D timing signal and the start of the subsequent group (subset) of D2R transmission occasions sufficient to process the received R2D timing signal and perform time synchronisation between the A-IoT device 3-1 and the A-IoT device reader, prior to performing a D2R transmission in a corresponding D2R transmission occasion of the group of D2R transmission occasions.

[0272] It will be appreciated that the duration of the time gap also allows switching time within which the A-IoT device reader can switch from a transmission operation / mode for R2D timing signal transmission to a reception operation / mode for receiving a corresponding D2R transmission from the A-IoT device 3-1.

[0273] The duration of the time gap may be pre-configured, or alternatively it may be provided by the A-IoT device reader to the A-IoT device 3-1 in the R2D trigger message 702 transmitted by the A-IoT device reader.

[0274] The duration of the time gap may, by way of example, range between a minimum value and a maximum value, and a corresponding subsequent D2R transmission by the A-IoT device 3-1 may start anytime which satisfies the minimum and maximum values for the time gap (i.e., anytime within the minimum and maximum values for the time gap).

[0275] Additionally, within each slot, an additional timing gap (T_margin) may be (pre)configured between the end of one D2R transmission occasion of the D2R transmission occasions in the corresponding group of slots, and the start of another. That additional timing gap (T_margin) may be provided to account for the scenario where a scheduled D2R transmission extends beyond a D2R transmission occasion due to, for example, a sampling offset of the A-IoT device 3-1.

[0276] The duration of the additional timing gap (T_margin) may have a single (pre)configured value common for all slot lengths. In this scenario, the single (pre)configured value for the additional timing gap (T_margin) may be determined based on requirements associated with a largest possible slot duration for D2R transmissions and R2D timing signals for timing acquisition. Alternatively, the duration of different durations (or the same duration) of the additional timing gap (T_margin) may be (pre)configured for different slot lengths. It will be appreciated that the duration (or durations) may be predefined or may be indicated to the A-IoT device 3-1 by the A-IoT device via an appropriate message (e.g., the R2D trigger message, or the like).

[0277] Alternatively, rather than indicating the duration of the additional timing gap (T_margin) to the A-IoT device 3-1 via an appropriate message (e.g., the R2D trigger message, or the like), a minimum duration of the additional timing gap (T_margin) may be predefined or indicated to the A-IoT device 3-1 by the A-IoT device reader via an appropriate message (e.g., the R2D trigger message, or the like). In this scenario, the A-IoT device 3-1 may perform D2R transmissions such that they satisfy the indicated minimum duration of the additional timing gap (T_margin).

[0278] However, unlike the scenario depicted in Figs. 12 to 14, in the case as shown in Fig. 15, each R2D timing signal may also include an appropriate indication to indicate a number N of consecutive slots with D2R transmission occasions that are to be grouped together following the R2D timing signal.

[0279] For example, in the case where a time gap between groups of slots with D2R transmission occasions is non-uniform, it may be beneficial for the R2D timing signal before each group of slots with D2R transmission occasions to indicate both a) whether a subsequent group of slots with D2R transmission occasions are available, and b) how many (N) slots with D2R transmission occasions of the group are available i.e., how many slots with D2R transmission occasions forms the subsequent group of slots with available D2R transmission occasions.

[0280] It will be appreciated that in this case, the A-IoT device 3-1 may need to receive the associated R2D timing signal sent before each group of slots with D2R transmission occasions to be able to identify which groups of slots with D2R transmission occasions are available.

[0281] It will also be appreciated that the R2D timing signals may optionally include an appropriate indication of a slot group number, or the like, to allow the A-IoT device 3-1 to identify if a slot selected by the A-IoT device 3-1 for performing a D2R transmission is within a specific group of slots or not.

[0282] It will be appreciated that in the scenario depicted in Fig. 15, each R2D timing signal may include a unique sequence as described above with reference to Fig. 7. Additionally, each R2D timing signal may optionally include additional information associated with the slot within which a D2R transmission occasion should be used for a D2R transmission in response to the R2D trigger message 702 as described above with reference to Fig. 7. Furthermore, information pertaining to the R2D timing signals, such as their duration and the like, may be provided to the A-IoT device 3-1 in advance of receiving the R2D timing signal as described above with reference to Fig. 7.

[0283] < Selecting slots to maintain synchronisation> 　　As mentioned above, synchronisation between the A-IoT device 3-1 and the A-IoT device reader may alternatively be maintained by selecting / limiting the number of slots that may be used for D2R transmissions following a R2D trigger message before another R2D trigger message is needed. For example, the number of slots that may be used for D2R transmissions following a R2D trigger message may be limited to a number of slots within which the A-IoT device 3-1 and the A-IoT device reader will remain synchronised. An example of how this may be implemented will now be described with reference to Fig. 16.

[0284] Fig. 16 illustrates an example A-IoT device device-sided clock line with a plurality of slots, each slot comprising a D2R transmission occasion, with a R2D triggering message transmitted prior to subsets of slots.

[0285] In all of the previous examples described above with reference to Figs. 7 to 15, synchronisation between the A-IoT device 3-1 and the A-IoT device reader is achieved by sending R2D timing signals either: a) before a D2R transmission occasion in each slot including a D2R transmission occasion, and / or b) before a D2R transmission occasion in a first slot of a group of one or more slots including a D2R transmission occasion.

[0286] However, it will nevertheless be appreciated that rather than regularly triggering synchronisation between the A-IoT device 3-1 and the A-IoT device reader by an R2D timing signal, instead a number of slots, each comprising a D2R transmission occasion, (i.e., a subset of slots) after each R2D trigger messages 702 may be selected (and / or limited) to ensure maintenance of synchronisation between the A-IoT device 3-1 and the A-IoT device reader, thereby removing the need to send an R2D timing signal either a) before each slot comprising a D2R transmission occasion, and / or b) before groups of slots, each comprising a D2R transmission occasion.

[0287] As shown in Fig. 16, by way of example only, the number of slots used for D2R transmission occasions (e.g., Slot #1 - Slot #4) may be limited after each R2D trigger message such that sufficient time does not elapse between R2D trigger messages for de-synchronisation between the A-IoT device 3-1 and the A-IoT device reader to occur.

[0288] Additionally (or alternatively), the length of the slots used for D2R transmission occasions (e.g., Slot #1 - Slot #4) may be limited after each R2D trigger message such that sufficient time does not elapse between R2D trigger messages for de-synchronisation between the A-IoT device 3-1 and the A-IoT device reader to occur. For example, the length of the slots used for D2R transmission occasions may be less than the slot length used for typical D2R communications (i.e., D2R communications not associated with initial access).

[0289] Additionally (or alternatively), the A-IoT device reader may send an R2D trigger message for each A-IoT device 3-1 that wishes to access the channel. For example, a first R2D trigger message 702a may be sent by the A-IoT device reader to a first set of A-IoT devices 3-1 (e.g., A-IoT devices with a specific device ID; for example a device ID mod 2 = 0), and a second R2D trigger message 702b may be sent by the A-IoT device reader to a second set of A-IoT devices 3-1 (e.g., A-IoT devices 3-1 with a specific device ID; for example a device ID mod 2 = 1).

[0290] Additionally, the A-IoT device reader may send an R2D trigger message such that: wherein Xusis a preconfigured / predefined limit required for a successful D2R transmission to occur in a slot with a specific slot length, considering any possible timing error that may exist.

[0291] Additionally, the A-IoT device reader may indicate in the R2D trigger message it sends to the A-IoT device 3-1, a type of A-IoT device 3-1 that can respond to the R2D trigger message by sending D2R transmissions (e.g., a Type A, B, and / or C A-IoT device 3-1). For example, each R2D trigger message transmitted by the A-IoT device reader may include an appropriate indication that the R2D trigger message is for triggering a random-access procedure for type B and / or type C A-IoT devices 3-1 only where they have a better clock accuracy than type A A-IoT devices 3-1.

[0292] Alternatively, the A-IoT device reader may indicate in the R2D trigger message it sends to the A-IoT device 3-1 a required / desired clock accuracy requirement for initiating initial access with a A-IoT device 3-1. Accordingly, only A-IoT devices 3-1 that meet that clock accuracy requirement may then respond to the R2D trigger message.

[0293] Upon receiving an R2D trigger message from an A-IoT device reader, an A-IoT device 3-1 may, based on its clock accuracy, select a subset of slots for D2R transmissions that are indicated to the A-IoT device 3-1 in the R2D trigger message. For example, an A-IoT device 3-1 with a lower clock accuracy, upon receiving an R2D trigger message, may select only the first set N of slots among the M slots (where M > N) indicated by the A-IoT device reader for random access in the R2D trigger message.

[0294] In this case, the value of N may be selected by the A-IoT device 3-1 based on its own clock accuracy performance, its device type, and / or the duration of the slots for D2R transmissions. Alternatively, the value of N may be indicated by the A-IoT device reader within the R2D trigger message for specific A-IoT device types (e.g., Type A, B, or C).

[0295] It will be appreciated that all of the methods described above for ensuring and / or maintaining synchronisation between an A-IoT device reader and an A-IoT device 3-1 to reduce the risk of D2R transmission failures during an initial access procedure are particularly relevant to A-IoT topology 1. It will also be appreciated that for such methods to be implemented in A-IoT topology 2, some adaptation may be appropriate.

[0296] In A-IoT topology 2, an intermediate / assisting node 5-2 (that acts as an A-IoT device reader) is present which communicates with the A-IoT device 3-1 and a RAN node 5-1 of the communication system 2. For example, in A-IoT topology 2, the A-IoT device 3-1 and the RAN node 5-1 may engage in communication with one another via an intermediate / assisting node (that acts as an 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. Accordingly appropriate adaptations of the methods described above may be appropriate to facilitate co-ordination between the RAN node 5-1, the A-IoT device 3-1, and intermediate / assisting node (that acts as an A-IoT device reader).

[0297] Fig. 17 depicts an example co-ordination procedure that may be performed between an A-IoT device 3-1, an intermediate / assisting node 5-2 (that acts as an A-IoT device reader), and a RAN node 5-1. As shown in Fig. 17, there is provided the A-IoT device 3-1, the A-IoT device reader (in this example an intermediate / assisting node 5-2), and the RAN node 5-1.

[0298] At step S1702, the RAN node 5-1 may indicate to the A-IoT device reader (i.e., the intermediate / assisting node 5-2), in an appropriate message (e.g., a random-access configuration, or the like), parameters to be included in an R2D trigger message for transmission by the A-IoT device reader to the A-IoT device 3-1. The random-access configuration may, for example, include any of the information included in the R2D trigger message provided by the A-IoT device reader to the A-IoT device 3-1 according to any of the examples previously described (e.g., with reference to Figs. 7 to 16). For example, the random-access configuration, or the like, may include an indication of: a slot length for an R2D timing signal and / or a slot length for D2R transmissions; a time gap (e.g., T_process / T_switch) between an R2D timing signal and a corresponding D2R transmission occasion in a slot; a time gap (e.g., T_margin) between the end of a D2R transmission occasion used for the D2R transmission in a slot and any subsequent R2D timing signal in that slot; and / or any other appropriate timing gap or the like.

[0299] Hence the A-IoT device reader (i.e., the intermediate / assisting node 5-2) can provide the R2D trigger messages (and / or receive D2R transmissions from the A-IoT device 3-1) in the manner required for implementing any of the example procedures / enhancements previously described (e.g., with reference to Figs. 7 to 16).

[0300] Additionally, the random-access configuration, or the like, may include an indication of a number of slots that may be used for R2D timing signals and / or D2R transmission occasions.

[0301] Additionally, the random-access configuration, or the like, may include an indication of one or more characteristics of the R2D timing signals that are to be sent by the A-IoT device reader to the A-IoT device 3-1. For example, the random-access configuration, or the like, may include an indication of a duration, and / or a sequence identifier, or the like, of the R2D timing signals that are to be sent by the A-IoT device reader to the A-IoT device 3-1.

[0302] Additionally, the random-access configuration, or the like, may include an indication of the type of A-IoT device 3-1 for which an R2D trigger message is directed, and / or any other appropriate physical layer parameters necessary for the A-IoT device reader to receive D2R transmissions from the A-IoT device 3-1.

[0303] It will be appreciated that some of the information included in the random-access configuration (e.g., time gaps, slot lengths, the number of slots, etc.) may be determined either by the RAN node 5-1 and indicated to the A-IoT device reader or determined by the A-IoT device reader itself (e.g., based on requirements of the A-IoT device reader). It will be appreciated that the random-access configuration may include an appropriate indication that some of the information defining a random-access configuration (e.g., time gaps, slot lengths, the number of slots, and / or the like) is to be determined by the A-IoT device reader itself based on requirements of the A-IoT device reader.

[0304] It will also be appreciated that the random-access configuration, or the like, may include the parameters described above for, either a) each instance that an R2D trigger message is to be transmitted (i.e., for each individual random-access procedure), or b) multiple R2D trigger messages to be transmitted (i.e., for multiple instances of a random-access procedure).

[0305] In a scenario where the random-access configuration, or the like, includes parameters for multiple R2D trigger message to be transmitted, the RAN node 5-1 may also indicate to the A-IoT device reader (e.g., in the random-access configuration, or the like), time occasions and / or periodicities with which the random-access procedure (and / or the R2D trigger message transmission) needs to be triggered. In this case, the RAN node 5-1 may also indicate (e.g., in the random-access configuration, or the like) how long the A-IoT device reader should continue transmitting the R2D trigger messages.

[0306] Alternatively, the RAN node 5-1 may also indicate how long the A-IoT device reader should continue transmitting the R2D trigger messages via appropriate activation / deactivation signalling by, for example, an RRC message, or a DCI, or a MAC control element (CE) command, or the like.

[0307] Following receipt of the random-access configuration, or the like, sent at step S1702, the A-IoT device reader may transmit a trigger message (e.g., an R2D trigger message) at step S1704 at a periodicity indicated in random-access configuration. It will be appreciated that the R2D trigger message sent at step S1702 is similar to the R2D trigger messages 702 previously described above.

[0308] Following that R2D trigger message, the A-IoT device reader and the A-IoT device 3-1 may perform an appropriate random-access procedure (at step S1706). For example, the A-IoT device 3-1 may respond to the R2D trigger message with a D2R transmission in accordance with any of the enhanced slotted-ALOHA approaches described above with reference to Figs. 7 to 16.

[0309] <Devices in the Communication System> <User Equipment> 　　Fig. 18 is a simplified block schematic illustrating the main components of a UE 3-2; 3-3 for implementation in the communication system 2. 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 2.

[0310] 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 2 or from a removable data storage device (RMD), for example.

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

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

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

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

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

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

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

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

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

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

[0321] In this example, the A-IoT device 3-1 also has a controller 337 to control the overall operation of the IoT device 3-1. The controller 337 is associated with a memory 339 and is coupled to the transceiver circuit 331. Although not necessarily required for its operation, the 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 2 or from a removable data storage device (RMD), for example.

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

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

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

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

[0326] <RAN node> 　　Fig. 20 is a simplified block schematic illustrating the main components of a RAN node 5-1 (e.g., a base station / IoT device reader) for implementation in the communication system 2 of Fig. 3. 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 2.

[0327] 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 2 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.

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

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

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

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

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

[0333] <Assisting (or intermediate) node> 　　Fig. 21 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 2 of Fig. 3.

[0334] As shown, the assisting node 5-2 may comprise a UE (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 A-IoT device 3-1) via one or more antenna 153 (e.g., comprising one or more antenna elements), and a RAN interface 155 for transmitting signals to and for receiving signals from the RAN node 5-1 (which may also be over the air via the antenna 153, or via a different antenna).

[0335] 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 2 or from a removable data storage device (RMD), for example.

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

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

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

[0339] 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 63 may include, sub-modules corresponding to the layers of a dedicated ambient IoT device protocol stack for controlling functions associated with those layers.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0363] 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 triggering message for transmitting data using a random access procedure; 　　transmitting, to the reader device, data using a resource determined based on timing of an end of the receiving the triggering message. 　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　the resource is included in a time duration from the timing of the end of the receiving the triggering message in which the mobile device and the reader device may be synchronized. 　　(Supplementary note 3) 　　The method according to supplementary note 1 or 2, wherein 　　the resource is included in at least one time resource from the timing of the end of the receiving the triggering message in which the mobile device and the reader device may be synchronized. 　　(Supplementary note 4) 　　The method according to any one of supplementary notes 1 to 3, wherein 　　the resource is started after a time interval from the end of the receiving the triggering message. 　　(Supplementary note 5) 　　The method according to supplementary note 4, wherein 　　the time interval is determined from at least one predefined parameter. 　　(Supplementary note 6) 　　The method according to supplementary note 4, wherein 　　information indicating the time interval is received from the reader device. 　　(Supplementary note 7) 　　The method according to any one of supplementary notes 1 to 6, further comprising: 　　receiving, from the reader device, at least one timing acquisition signal used for synchronizing, and wherein 　　timing of transmitting the data is determined using the at least one timing acquisition signal. 　　(Supplementary note 8) 　　The method according to any one of supplementary notes 1 to 7, wherein 　　the resource includes two or more time resources, and 　　a time interval is within one of the two or more time resources and another of the two or more time resources. 　　(Supplementary note 9) 　　The method according to supplementary note 8, wherein 　　a timing acquisition signal is received for two or more time resources. 　　(Supplementary note 10) 　　The method according to any one of supplementary notes 1 to 9, wherein 　　the triggering message includes at least one of: 　　　　information indicating a length of slots corresponding to the resource, 　　　　information indicating a length of slots corresponding to a time interval from the end of the receiving the triggering message, 　　　　information indicating characteristics of the triggering message, or 　　　　information indicating a type of mobile devices for the triggering message. 　　(Supplementary note 11) 　　The method according to any one of supplementary notes 1 to 10, wherein 　　the triggering message is transmitted based on configuration information indicating types of information in which the triggering message includes. 　　(Supplementary note 12) 　　The method according to supplementary note 11, wherein 　　the configuration information is transmitted in at least one of: 　　　　a Radio Resource Control (RRC) message, 　　　　downlink controk information (DCI), or 　　　　a medium access control (MAC) control element (CE) command. 　　(Supplementary note 13) 　　A method performed by a reader device, the method comprising: 　　transmitting, to a mobile device, a triggering message for the mobile device to transmit data using a random access procedure; 　　receiving, from the mobile device, data using a resource determined based on timing of an end of the receiving the triggering message. 　　(Supplementary note 14) 　　A mobile device comprising: 　　means for receiving, from a reader device, a triggering message for transmitting data using a random access procedure; 　　means for transmitting, to the reader device, data using a resource determined based on timing of an end of the receiving the triggering message. 　　(Supplementary note 15) 　　A reader device comprising: 　　means for transmitting, to a mobile device, a triggering message for the mobile device to transmit data using a random access procedure; 　　means for receiving, from the mobile device, data using a resource determined based on timing of an end of the receiving the triggering message.

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

[0365] 1 RADIO FREQUENCY IDENTIFICATION (RFID) 2 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

1. A method performed by a mobile device, the method comprising: 　　receiving, from a reader device, a triggering message for transmitting data using a random access procedure; 　　transmitting, to the reader device, data using a resource determined based on timing of an end of the receiving the triggering message.

2. The method according to claim 1, wherein 　　the resource is included in a time duration from the timing of the end of the receiving the triggering message in which the mobile device and the reader device may be synchronized.

3. The method according to claim 1 or 2, wherein 　　the resource is included in at least one time resource from the timing of the end of the receiving the triggering message in which the mobile device and the reader device may be synchronized.

4. The method according to any one of claims 1 to 3, wherein 　　the resource is started after a time interval from the end of the receiving the triggering message.

5. The method according to claim 4, wherein 　　the time interval is determined from at least one predefined parameter.

6. The method according to claim 4, wherein 　　information indicating the time interval is received from the reader device.

7. The method according to any one of claims 1 to 6, further comprising: 　　receiving, from the reader device, at least one timing acquisition signal used for synchronizing, and wherein 　　timing of transmitting the data is determined using the at least one timing acquisition signal.

8. The method according to any one of claims 1 to 7, wherein 　　the resource includes two or more time resources, and 　　a time interval is within one of the two or more time resources and another of the two or more time resources.

9. The method according to claim 8, wherein 　　a timing acquisition signal is received for two or more time resources.

10. The method according to any one of claims 1 to 9, wherein 　　the triggering message includes at least one of: 　　　　information indicating a length of slots corresponding to the resource, 　　　　information indicating a length of slots corresponding to a time interval from the end of the receiving the triggering message, 　　　　information indicating characteristics of the triggering message, or 　　　　information indicating a type of mobile devices for the triggering message.

11. The method according to any one of claims 1 to 10, wherein 　　the triggering message is transmitted based on configuration information indicating types of information in which the triggering message includes.

12. The method according to claim 11, wherein 　　the configuration information is transmitted in at least one of: 　　　　a Radio Resource Control (RRC) message, 　　　　downlink controk information (DCI), or 　　　　a medium access control (MAC) control element (CE) command.

13. A method performed by a reader device, the method comprising: 　　transmitting, to a mobile device, a triggering message for the mobile device to transmit data using a random access procedure; 　　receiving, from the mobile device, data using a resource determined based on timing of an end of the receiving the triggering message.

14. A mobile device comprising: 　　means for receiving, from a reader device, a triggering message for transmitting data using a random access procedure; 　　means for transmitting, to the reader device, data using a resource determined based on timing of an end of the receiving the triggering message.

15. A reader device comprising: 　　means for transmitting, to a mobile device, a triggering message for the mobile device to transmit data using a random access procedure; 　　means for receiving, from the mobile device, data using a resource determined based on timing of an end of the receiving the triggering message.

Images