Mobile device, reader device and method

Abstract

A method performed by a mobile device, the method comprising: receiving, from a reader device via a Medium Access Control (MAC) layer, a first message for scheduling a transmission from the mobile device to the reader device; transmitting, to the reader device via the MAC layer, a second message including a part of uplink data in a buffer and first information indicating that the mobile device has remaining of the uplink data transmitted via the MAC layer, based on the first message; receiving, from the reader device via the MAC layer, a further first message for scheduling the transmission of the remaining of the uplink data in the buffer via the MAC layer, upon transmitting the first information; and transmitting, to the reader device via the MAC layer, a further second message including at least a part of the remaining of the uplink data.

Description

MOBILE DEVICE, READER DEVICE AND METHOD

[0001] The present disclosure relates to a communication system and to parts thereof. The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards, 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 to scheduling within an 'Ambient' Internet-of-Things (IoT) system, for example by an A-IoT device reader for data transmission by an A-IoT device (also sometimes referred to simply as an IoT device).

[0002] 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, NPL 1 (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.

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

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

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

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

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

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

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

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

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

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

[0013] It is envisaged that a coverage design target for A-IoT devices will have a maximum distance of between 10m and 50m when the device is indoors.

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

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

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

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

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

[0019] It is also possible that repetition of data sent via the PRDCH and / or PDRCH may be implemented. To this end, a number of different repetition types are possible and are under consideration.

[0020] For R2D communication, the repetition types that may be implemented include, for example, one or more of the following: 　　- Block level repetition in which an entire block of bits received from a higher layer and / or physical layer (according to what is present) are repeated 'blockwise' a (pre)configured (e.g., Rblock) number of times. Where cyclic-redundancy-check (CRC) bits are used the blockwise repetition may occur for blocks after CRC attachment; 　　- Bit level repetition (type 1) in which each bit after CRC attachment (if used) is repeated 'bitwise' a (pre)configured (e.g., Rbit) number of times; 　　- Bit level repetition (type 2) in which each bit after both CRC attachment (if used) and forward error correction (FEC) is repeated 'bitwise' a (pre)configured (e.g., Rbit) number of times; and / or 　　- Chip level repetition in which each chip after line coding (if used) or after square wave modulation (if used) is repeated 'chipwise' a (pre)configured (e.g., Rchip) number of times. It will be appreciated that this is essentially equivalent to extending the duration of each chip by Rchiptimes.

[0021] Similarly, for D2R communication, the repetition types that may be implemented include, for example, (at least) block level and bit level repetition (type 1 and type 2).

[0022] Generally, for A-IoT communication, it is envisaged that multiple A-IoT logical channels for communication of upper layer data need not be supported. It is yet to be determined whether the concept of A-IoT logical channels is used (e.g., depending on final modeling issues). It is also envisaged that the use of legacy NR type buffer status reporting / scheduling request (BSR / SR) for indicating the available data within a device is not required for A-IoT communication. It is yet to be determined whether some other form of indication of message size / status is needed. It is also envisaged that access stratum (AS) layer (above the PHY layer) RLC-like retransmission / repetition will not be supported for A-IoT. Nevertheless, this does not preclude the reader and device resending the payload again as new transmission from the perspective of the MAC layer. It is yet to be determined how segmentation is to be handled (if needed).

[0023] For the purposes of scheduling a D2R transmission, it is envisaged that the following information will typically be needed, which can be carried by a PRDCH over an R2D link: 　　- Modulation and coding scheme (MCS) related information / parameters identifying, for example, the modulation to be used (on-off keying (OOK) or binary phase shift keying (BPSK)), the coding scheme to be used, and / or the chip length to be used; 　　- Transport block size (TBS) related information / parameters, which may be used, for example, to help indicate / identify the end of a transmission; 　　- Time domain resource allocation (TDRA) related information / parameters to identify, for example, the time domain resource to be used and / or the timing of the transmission; 　　- Frequency domain resource allocation (FDRA) related information / parameters, which may include, for example, a small frequency shift (SFS) modulation and / or uplink frequency offset; 　　- Repetition related information; and / or 　　- Power control related information.

[0024] It will be appreciated that as there may be no special control channel for this scheduling related information, the information may be carried as a higher layer message within the PRDCH.

[0025] It is still to be determined how a device reader will determine the end of a PDRCH transmission and how an A-IoT device will determine the end of a PDRCH transmission.

[0026] For the determination, by a device reader, of the end of a transmission on the PDRCH, a number of options are possible including, for example: based on a D2R 'postamble' that immediately follows a PDRCH transmission; and / or the use of control information within a physical channel (e.g., the PDRCH and / or the PRDCH) from which the end of a transmission can be determined.

[0027] For example, as the device reader is already aware of the TBS and the amount of time domain resources required for the PDRCH transmission the device reader can potentially use this information to figure out when the transmission is expected to end. However, the expected end of the PDRCH transmission may not correspond exactly to the actual end of the PDRCH transmission (e.g., due to a large sampling frequency offset (SFO) that may arise due to an accumulated timing offset). A postamble can be used to assist the device reader to determine the final accumulated time offset (to help counter the potentially large SFO) and thus achieve fine timing recovery. The device reader can then use the amount of time domain resources required for the PDRCH transmission (known to the device reader as the device reader scheduled the transmission), in combination with the final accumulated time offset, to determine the actual end of the PDRCH transmission. In this case it may be that additional control information is not required in a physical channel.

[0028] Nevertheless, control information provided over the D2R link (e.g., in the PDRCH) may be used to assist the device reader to determine the end of a D2D transmission. The nature of any such control information has not yet been determined but if such control information is implemented, then the configuration of that control information for the D2R transmission will need to take into account a number of factors. For example, the configuration of the control information will need to consider whether the control information remains the same for all the devices in a given coverage area, or whether each of the different D2R transmissions will use (potentially different) fixed control information. Where the control information is different for different transmissions, the respective control information for each transmission will need to be provided separately before that transmission for every device in the coverage area. Furthermore, as different D2R transmission from the same device may have different sizes, the configuration of the control parameters will need to take this into account.

[0029] Similarly, for the determination, by an A-IoT device, of the end of a transmission on the PRDCH, a number of options are possible including, for example: based on an R2D 'postamble' that immediately follows a PDRCH transmission; and / or the use of R2D control information indicating the end of a transmission either explicitly or implicitly (e.g., from which the end of the transmission can be derived).

[0030] It can be seen, therefore, that there are still a number of issues that need to be resolved in the development of A-IoT devices and their associated device readers.

[0031] Moreover, the various constraints imposed on A-IoT type communication raises further issues that need to be resolved. For example, if use of a conventional SR / BSR is excluded as a possibility for indicating the amount of available data within the device, as suggested above, then the question arises as to how the A-IoT device indicates the available data to the device reader / network during data transmission? Moreover, if there is no physical control channel like a conventional physical uplink control channel (PUCCH), then the question arises as to how the A-IoT device should report the control information to the device reader / network, for example for assisting scheduling by the device reader?

[0032] Moreover, as a result of the constraints placed on A-IoT type communication, there may be cases where an A-IoT device cannot finish a D2R transmission for all the available data (e.g., in a transmission buffer of the A-IoT device). The question thus arises as to how the A-IoT device can notify such a scenario / status to the device reader / network to ensure accurate scheduling for completing D2R transmission of all the available data. For example, as a result of the transmission constraints imposed on the A-IoT device due to energy harvesting reasons, the A-IoT device may be able to transmit only part of the available data at a given time, and hence the A-IoT device may need to send the remaining data to the device reader / network when the A-IoT device has harvested sufficient energy to make another transmission.

[0033] Furthermore, the A-IoT device may need to transmit a particularly long data packet, in which case the A-IoT device may not be able to include the full data packet within a single transport block (TB). Accordingly, that long data packet may be segmented into a plurality of (e.g., into multiple-shot) D2R transmissions.

[0034] NPL 1: 'NGMN 5G White Paper' V1.0, NGMN Alliance, 2015

[0035] The present disclosure aims to provide a mobile device, a reader device and a method that at least partially addresses or contributes to meeting one or more of the above needs and / or addressing one or more of the above issues.

[0036] According to a first aspect, there is provided a method performed by a mobile device, the method comprising: receiving, from a reader device via a Medium Access Control (MAC) layer, a first message for scheduling a transmission from the mobile device to the reader device; transmitting, to the reader device via the MAC layer, a second message including a part of uplink data in a buffer and first information indicating that the mobile device has remaining of the uplink data transmitted via the MAC layer, based on the first message; receiving, from the reader device via the MAC layer, a further first message for scheduling the transmission of the remaining of the uplink data in the buffer via the MAC layer, upon transmitting the first information; and transmitting, to the reader device via the MAC layer, a further second message including at least a part of the remaining of the uplink data.

[0037] According to a second aspect, there is provided a method performed by a reader device, the method comprising: transmitting, to a mobile device via a Medium Access Control (MAC) layer, a first message for scheduling a transmission from the mobile device to the reader device; receiving, from the mobile device via the MAC layer, a second message including a part of uplink data in a buffer and first information indicating that the mobile device has remaining of the uplink data transmitted via the MAC layer, based on the first message; transmitting, to the mobile device via the MAC layer, a further first message for scheduling the transmission of the remaining of the uplink data in the buffer via the MAC layer, upon transmitting the first information; and receiving, from the mobile device via the MAC layer, a further second message including at least a part of the remaining of the uplink data.

[0038] According to a third aspect, there is provided a mobile device, the mobile device comprising: means for receiving, from a reader device via a Medium Access Control (MAC) layer, a first message for scheduling a transmission from the mobile device to the reader device; means for transmitting, to the reader device via the MAC layer, a second message including a part of uplink data in a buffer and first information indicating that the mobile device has remaining of the uplink data transmitted via the MAC layer, based on the first message; means for receiving, from the reader device via the MAC layer, a further first message for scheduling the transmission of the remaining of the uplink data in the buffer via the MAC layer, upon transmitting the first information; and means for transmitting, to the reader device via the MAC layer, a further second message including at least a part of the remaining of the uplink data.

[0039] According to a fourth aspect, there is provided a reader device, the reader device comprising: means for transmitting, to a mobile device via a Medium Access Control (MAC) layer, a first message for scheduling a transmission from the mobile device to the reader device; means for receiving, from the mobile device via the MAC layer, a second message including a part of uplink data in a buffer and first information indicating that the mobile device has remaining of the uplink data transmitted via the MAC layer, based on the first message; means for transmitting, to the mobile device via the MAC layer, a further first message for scheduling the transmission of the remaining of the uplink data in the buffer via the MAC layer, upon transmitting the first information; and means for receiving, from the mobile device via the MAC layer, a further second message including at least a part of the remaining of the uplink data.

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

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

[0042] According to the aspects described above, it is possible to provide a mobile device, a reader device and a method that at least partially addresses or contributes to addressing one or more of the above needs.

[0043] Examples of apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:Fig. 1 illustrates schematically a mobile (cellular or wireless) communication system to which example embodiments of the disclosure may be applied;Fig. 2 illustrates schematically a first connectivity topology (topology 1) that may be used in the communication system of Fig. 1;Fig. 3 illustrates schematically a second connectivity topology (topology 2) that may be used in the communication system of Fig. 1;Fig. 4A illustrates schematically a third connectivity topology (topology 3) that may be used in the communication system of Fig. 1;Fig. 4B illustrates schematically another arrangement of the third connectivity topology (topology 3) of Fig. 4A;Fig. 5 illustrates a simplified sequence diagram of an example A-IoT device transmission scheduling mechanism that may be implemented in the communication system of Fig. 1;Fig. 6 illustrates an example scheduling information MAC PDU for R2D scheduled transmissions that may be implemented in the A-IoT device transmission scheduling mechanism of Fig. 5;Fig. 7 illustrates an example control information MAC PDU for D2R scheduled transmissions that may be implemented in the A-IoT device transmission scheduling mechanism of Fig. 5;Fig. 8 illustrates a scheduling example that may take place in the communication system of Fig. 1 when the A-IoT device wishes to perform an energy harvesting procedure;Fig. 9 is a simplified block schematic illustrating the main components of a user equipment that may be used in the communication system of Fig. 1;Fig. 10 is a simplified block schematic illustrating the main components of an ambient IoT device that may be used in the communication system of Fig. 1;Fig. 11 is a simplified block schematic illustrating the main components of a RAN node that may be used in the communication system of Fig. 1; andFig. 12 is simplified block schematic illustrating the main components of an intermediate or assisting node that may be used in the communication system of Fig. 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0057] 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-IoT UE 3-2, 3-3. The SMF 10-2 uses user information provided via the AMF 10-1 to determine what session manager would be best assigned to the user. The SMF 10-2 may be considered effectively to be a gateway from the user plane to the control plane of the network. The SMF 10-2 also allocates IP addresses to at least each non-IoT UE 3-2, 3-3.

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

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

[0060] The DL physical signals may include, for example, reference signals (RSs) and synchronization signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the base station 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).

[0061] Similarly, the at least the non-IoT UEs 3-2, 3-3 are configured for transmission of, and the base station 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.

[0062] Each A-IoT device 3-1 may be completely passive or may be active and configured with at least a subset of the functionality of the non-IoT UEs 3-2, 3-3. It will be appreciated that the specific functionality with which the A-IoT device 3-1 is configured is dependent on the type of A-IoT device 3-1 as described already above.

[0063] It will, nevertheless, be appreciated that regardless of the non-IoT UE functionality that an A-IoT device 3-1 may be configured with, each A-IoT device 3-1 is respectively configured with A-IoT specific functionality and each RAN node 5-1 is configured with corresponding functionality for communication with A-IoT devices 3-1.

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

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

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

[0067] As shown in Fig. 2, in topology 1 the functionality of an A-IoT device reader is implemented as part of a RAN node 5-1. An A-IoT device 3-1 and the RAN node 5-1 engage in direct communication with one another (i.e., without the presence of an assisting or intermediate node 5-2). Specifically, as shown, the A-IoT device 3-1 directly and bidirectionally communicates with the RAN node 5-1. The communication 20 (20-1, 20-2) between the RAN node 5-1 and the 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.

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

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

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

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

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

[0073] Topology 2: RAN node ←→ Intermediate node ←→ IoT device: 　　Fig. 3 illustrates schematically a second connectivity topology (topology 2) that may be used in the communication system 1 of Fig. 1.

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

[0075] 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. Specifically, the communication 20-1, 20-2 between the intermediate node 5-2 and the A-IoT device 3-1 may occur over an appropriate air interface. For example, they may communicate over a Uu or a dedicated interface.

[0076] In a first (downlink) direction (RAN node 5-1 → intermediate node 5-2 → A-IoT device 3-1) a downlink signal may be transmitted from the RAN node 5-1 to the intermediate node 5-2 as part of communication 20-3 between the RAN node 5-1 and the intermediate node 5-2. The downlink signal, once received by the intermediate node 5-2, may trigger transmission of an unmodulated carrier signal 20-1 to the 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.

[0077] In a second (uplink) direction (A-IoT device 3-1 → intermediate node 5-2 → RAN node 5-1) the intermediate node 5-2 is responsible for receiving a modulated backscattered signal 20-2 from 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.

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

[0079] Communication 20-3 between the RAN node 5-1 and the intermediate node 5-2 may occur over any appropriate interface. For example, the RAN node 5-1 and intermediate node 5-2 may communicate over an air interface (such as the Uu interface or the like), for example where the intermediate node 5-2 is a UE 3 (or at least acts like a UE 3 in its communication with the RAN node 5-1). The RAN node 5-1 and intermediate node 5-2 may communicate over a direct base station to base station interface (such as X2 or Xn), for example where the intermediate node 5-2 is a base station 5-1 (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.

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

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

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

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

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

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

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

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

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

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

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

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

[0092] Alternatively, as shown in Fig. 4B, the A-IoT device 3-1 may communicate with the RAN node 5-1 in an uplink direction and 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.

[0093] In this example the assisting node 5-2 is responsible for transmission of an unmodulated carrier signal 20-1 to the A-IoT device 3-1. This unmodulated carrier signal 20-1 may be subsequently modulated and backscattered, as a modulated backscattered signal 20-2, from the A-IoT device 3-1 and received at the RAN node 5-1. That is, the RAN node 5-1 (base station / cell) is responsible for receiving the backscattered signal 20-2 from the A-IoT device 3-1. The transmission of the unmodulated carrier signal 20-1 may be triggered by a downlink signal 20-3 received by the assisting node 5-2 from the RAN node 5-1. For example, the downlink signal 20-3 may be (or may carry) the unmodulated carrier signal 20-1 that is to be transmitted (e.g. relayed) by the intermediate node 5-2 to the A-IoT device 3-1 or may be a trigger signal for triggering transmission of the unmodulated carrier signal 20-1.

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

[0095] Similarly to Fig. 4A, in Fig. 4B the communication 20-3 between the RAN node 5-1 and the assisting node 5-2 occurs over an appropriate interface. For example, the RAN node 5-1 and the assisting node 5-2 may communicate over an air interface (such as the Uu interface or the like), for example where the intermediate node 5-2 is a UE 3 (or at least acts like a UE 3 in its communication with the RAN node 5-1). The RAN node 5-1 and assisting node 5-2 may communicate over an appropriate IAB interface (such as F1), for example where the RAN node 5-1 acts as an IAB donor base station and the intermediate node 5-2 is an IAB node. Nevertheless, the RAN node 5-1 and the assisting node 5-2 may communicate over a dedicated interface for the purpose of ambient IoT. The downlink communication, comprising the unmodulated carrier signal 20-1 sent from the assisting node 5-2 to the A-IoT device 3-1, also occurs over an appropriate air interface. For example, they may communicate over a Uu or a dedicated interface. 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. In either scenario (illustrated in Fig. 4A or 4B), backscattering may be supported even if the RAN node 5-1 and / or the assisting node 5-2 do not support full duplex operation.

[0096] Beneficially, as described in more detail later, the communication system 1 is configured to implement a scheduling procedure by which an A-IoT device reader can effectively and efficiently schedule data transmission by an A-IoT device 3-1.

[0097] Beneficially, as described in more detail later, the scheduling procedure takes into account the fact that the use of a conventional SR / BSR is excluded as a possibility for indicating the amount of available data within the device and that there is no physical control channel like a conventional physical uplink control channel (PUCCH).

[0098] Moreover, as described in more detail later, the scheduling procedure may (optionally) include enhancements that allow for scenarios in which the A-IoT device 3-1 cannot finish a D2R transmission for all the available data (e.g., in a transmission buffer of the A-IoT device 3-1) - for example as a result of the transmission constraints imposed on the A-IoT device 3-1 due to energy harvesting reasons.

[0099] Furthermore, as described in more detail later, the scheduling procedure may (optionally) include enhancements that allow the A-IoT device 3-1 to transmit the content of a particularly long data packet that cannot be included within a single transport block (TB).

[0100] The scheduling procedures and associated techniques will now be described in more detail, by way of example only, with reference to Figs. 5 to 8.

[0101] Transmission Scheduling Mechanisms in Ambient IoT Systems 　　Fig. 5 illustrates a simplified sequence diagram of an example A-IoT device transmission scheduling mechanism that may be implemented in the communication system 1 of Fig. 1.

[0102] As shown in Fig. 5, there is provided an A-IoT device 3-1 in communication with an A-IoT device reader. That A-IoT device reader may, by way of example only, be a RAN node 5-1, and intermediate node 5-2, or any other device in the communication system 1 that is capable of transmitting to, and receiving signals from, the A-IoT device 3-1.

[0103] As a brief summary Fig. 5 shows, at step S502, that an A-IoT device reader (e.g., the RAN node 5-1, the intermediate node 5-2, or some other node or device) may send a first reader-to-device (R2D) message (e.g., R2D Msg#1) to the A-IoT device 3-1. At step S504 the A-IoT device 3-1 that received R2D Msg#1 at step S502 may respond by sending a first device-to-reader (D2R) transmission (D2R Msg#1) to the A-IoT device reader.

[0104] Following the transmission of D2R Msg#1, the A-IoT device reader may (optionally) transmit, at step S506, a subsequent (second) R2D message (R2D Msg#2) to the A-IoT device 3-1 if needed, and the A-IoT device 3-1 may send a corresponding D2R transmission (D2R Msg#2) in response at step S508.

[0105] Those steps and R2D / D2R transmissions will now be described in further detail.

[0106] Step S502 　　At step S502, the A-IoT reader sends a first R2D message to the A-IoT device 3-1 over a physical reader-to-device channel (PRDCH). That first message (R2D Msg#1) may be any appropriate type of message that can be transmitted by an A-IoT device reader to an A-IoT device 3-1 over an R2D link.

[0107] Upon receipt of R2D Msg#1, the A-IoT device 3-1 may first detect a clock signal from R2D Msg#1, and then use that clock signal to obtain information necessary to decode the remainder of R2D Msg#1.

[0108] In one example, R2D Msg#1 may be an initial triggering message, or the like. For example R2D Msg#1 may be an appropriate triggering message to trigger the A-IoT device 3-1 to initiate an access procedure with the A-IoT device reader.

[0109] In another example, R2D Msg#1 may be an appropriate message for resolving random access between the A-IoT device reader and the A-IoT device 3-1 during an appropriate RACH procedure between the A-IoT device reader and the A-IoT device 3-1.

[0110] It will be appreciated that R2D Msg#1 may carry an appropriate R2D command; an appropriate configuration; an appropriate inventory request message; and / or any form of data that the A-IoT device reader wishes to transmit to the A-IoT device 3-1.

[0111] R2D Msg#1 may also carry an appropriate scheduling information (or other control information) MAC control element (CE) used to schedule subsequent (follow-up) D2R transmissions by the A-IoT device 3-1 to the A-IoT device reader (e.g., D2R Msg#1 sent at step S504). It will be appreciated that the MAC CE may be used for transmission of any suitable control information and may have any suitable corresponding name. Alternatively, R2D Msg#1 may include appropriate layer-1 (L1) control signalling, or other higher layer messages / signals used to schedule subsequent (follow-up) D2R transmissions by the A-IoT device 3-1 to the A-IoT device reader (e.g., transmission of D2R Msg#1 at step S504).

[0112] In the case where R2D Msg#1 includes a scheduling information MAC CE used to schedule subsequent (follow-up) D2R transmissions by the A-IoT device 3-1 to the A-IoT device reader, that MAC CE may be multiplexed within a MAC service data unit (SDU), or another MAC CE, carrying A-IoT signalling (e.g., coming from higher-layer).

[0113] For example, the MAC CE may be multiplexed within a MAC SDU (e.g., a MAC SDU carrying some form of data). Alternatively, that MAC CE may be multiplexed within another MAC CE carrying a command message, an inventory message, or the like.

[0114] It will nevertheless be appreciated that, where R2D Msg#1 includes a scheduling information MAC CE, that MAC CE may be sent to the A-IoT device 3-1 independently as a MAC packet data unit (PDU) within a transport block (TB). In this case, the scheduling information may be provided to the A-IoT device 3-1 following a clock acquisition part (i.e., for synchronisation) of the signal transmitted to the A-IoT device 3-1 on the PRDCH (i.e., the PRDCH on which R2D Msg#1 is transmitted), and before a data portion of R2D Msg#1 is transmitted on the PRDCH. In this way, the scheduling information coded as a MAC CE may be encapsulated as a MAC PDU within a TB that is independent from the data portion of a PRDCH message.

[0115] Where R2D Msg#1 includes a scheduling information MAC CE, the scheduling information MAC CE may include, by way of example only, any appropriate form of A-IoT device ID of the A-IoT device 3-1 to which the scheduling information is assigned / associated if the A-IoT device 3-1 is unable to identify the MAC CE from scrambling information enforced at the physical layer.

[0116] Additionally (or alternatively), the scheduling information MAC CE may include modulation and coding scheme (MCS) related information / parameters that may be used for follow-up D2R transmissions (e.g., D2R Msg#1 transmission at step S504). The scheduling information MAC CE may carry multiple sets of allowed MCS related information / parameters. Additionally (or alternatively), the scheduling information MAC CE may include a chip length for follow-up D2R transmissions (e.g., D2R Msg#1 transmission at step S504). The scheduling information MAC CE may carry multiple sets of chip lengths. Alternatively, the chip length information can be part of the allowed MCS related information / parameters.

[0117] Additionally (or alternatively), the scheduling information MAC CE may include transport block size (TBS) related information / parameters. The scheduling information MAC CE may carry multiple sets of TBSs parameters. Alternatively, the transport block size (TBS) information can be part of the allowed MCS related information / parameters.

[0118] It will be appreciated that where the scheduling information MAC CE includes MCS related information / parameters, and chip length related information / parameters, and / or TBS related information / parameters, that information / those parameters may be mixed together into a single set of related information / parameters.

[0119] Additionally (or alternatively), the scheduling information MAC CE may include time domain resource allocation (TDRA) related information / parameters. Additionally (or alternatively), the scheduling information MAC CE may include frequency domain resource allocation (FDRA) related information / parameters. Additionally (or alternatively), the scheduling information MAC CE may include frequency shift, frequency offset and / or frequency hopping information, which may include multiple allowed frequency shifts, frequency offsets and / or frequency hoppings.

[0120] Additionally (or alternatively), the scheduling information MAC CE may include repetition related information / parameters, which may include multiple allowed repetition levels. It will be appreciated that the scheduling information carried in R2D Msg#1 may be scheduling information for, or associated with, one or more specific types of A-IoT device 3-1. For example, when the A-IoT device reader schedules the transmission of R2D Msg#1, the contents of that R2D Msg#1 (e.g., scheduling information) may be set by the A-IoT device reader based on a characteristic of the one or more A-IoT devices 3-1 for which the R2D Msg#1 is scheduled. For example, the contents of R2D Msg#1 may be set by the A-IoT device reader based on a capability of one or more A-IoT devices 3-1 for which the R2D Msg#1 is scheduled, and / or based on a type of the one or more A-IoT devices 3-1 for which the R2D Msg#1 is scheduled.

[0121] An example scheduling information MAC PDU for R2D scheduled transmissions is shown in Fig. 6. That figure shows that a MAC PDU transmitted over an R2D link may comprise, by way of example only, two (or more) MAC subPDUs (e.g., MAC subPDU #X and #Y). One MAC subPDU (e.g., MAC subPDU #X) may include an appropriate MAC subheader and a MAC SDU or a MAC CE that includes A-IoT higher layer signalling (e.g., a command, an inventory, or the like). Another MAC subPDU (e.g., MAC subPDU #Y) may include an appropriate MAC subheader and a MAC CE that includes scheduling information such as that already described above.

[0122] In the scenario where R2D Msg#1 is an initial triggering message (e.g., an inventory request message, a command, or the like), a subsequent follow up D2R transmission from the A-IoT device 3-1 to the A-IoT device reader (e.g., D2R Msg#1), sent at step S504, may be a message associated with a contention-free RACH procedure, or alternatively a follow-up D2R transmission where RACH is not required.

[0123] Additionally (or alternatively), where R2D Msg#1 is an initial triggering message (e.g., an inventory request message, a command, or the like), R2D Msg#1 may be used to configure whether or not the A-IoT device 3-1 (or A-IoT devices) should include control information in a subsequent D2R transmission (e.g., D2R Msg#1 sent at step S504) by the A-IoT device 3-1 to the A-IoT device reader.

[0124] It will be appreciated that whether or not the A-IoT device 3-1 includes control information in a subsequent D2R transmission sent by the A-IoT device 3-1 to the A-IoT device reader may depend on whether or not the A-IoT device reader is able to decode a D2R transmission from an A-IoT device 3-1 without control information. For example, where the A-IoT device reader is able to decode messages from the A-IoT device 3-1 without control information, R2D Msg#1 sent by the A-IoT device reader to the A-IoT device 3-1 may include an appropriate indication to configure the A-IoT device 3-1 to send a D2R transmission (e.g., send D2R Msg#1 at step S504) to the A-IoT device reader without control information. In this scenario, the A-IoT device 3-1 may also not expect to receive any scheduling information from the A-IoT device reader, instead the A-IoT device 3-1 may use pre-allocated resources to generate D2R transmissions to the A-IoT device reader. This type of R2D message may be referred to as a 'Type A' R2D message, which is described in more detail below.

[0125] In another example, where the A-IoT device reader is not able to decode messages from the A-IoT device 3-1 without control information, R2D Msg#1 sent by the A-IoT device reader to the A-IoT device 3-1 may include an appropriate indication to configure the A-IoT device 3-1 to send a D2R transmission (e.g., send D2R Msg#1 at step S504) to the A-IoT device reader with control information.

[0126] Furthermore, it will be appreciated that where R2D Msg#1 is an initial triggering message (e.g., an inventory request message, a command, or the like), a D2R transmission (e.g., D2R Msg#1 at step S504) may be configured by the A-IoT device 3-1 to include a variety of different content, which will now be described.

[0127] In one example (case 1), D2R Msg#1 sent at step S504 may include an appropriate A-IoT device ID of the A-IoT device 3-1 sending D2R Msg#1; appropriate higher layer data; and / or optionally D2R control information. It will be appreciated that in this scenario, a subsequent D2R message sent by the A-IoT device reader to an A-IoT device 3-1 (e.g., D2R Msg#2 sent at S508) may also include an appropriate A-IoT device ID sending D2R Msg#2; and / or remaining higher layer data (e.g., when the A-IoT device 3-1 still has data to send to the A-IoT device reader after it has sent D2R Msg#1 at step S504).

[0128] In another example (case 2), D2R Msg#1 sent at step S504 may include an appropriate A-IoT device ID of the A-IoT device 3-1 sending D2R Msg#1; and / or appropriate D2R control information. It will be appreciated that in this scenario, a subsequent D2R message sent by the A-IoT device reader to an A-IoT device 3-1 (e.g., D2R Msg#2 sent at S508) may also include an appropriate A-IoT device ID sending D2R Msg#2; appropriate higher layer data; and / or optionally D2R control information.

[0129] Alternatively, D2R Msg#1 may be configured to be sent as part of a contention-based RACH (CBRA)-like procedure in which D2R Msg#1 does not necessarily use uplink resources scheduled by the A-IoT device reader. In this scenario, D2R Msg#1 may be configured to have different content or format depending on the volume of data to be transmitted. For example, if the data volume is greater than (or possibly equal to) a default / preconfigured threshold (or a threshold configured by R2D Msg#1), then D2R Msg#1 may include: the information described for 'case 1' above (D2R control information in addition to data); or the information described for 'case 2' above (D2R control information only). Otherwise the A-IoT device 3-1 may only include data. It will be appreciated that this transmission principle may be applicable to any (e.g., subsequent) D2R transmission.

[0130] Additionally (or alternatively), where R2D Msg#1 is an initial triggering message (e.g., an inventory request message, a command, or the like), R2D Msg#1 may include an appropriate indication of a format and / or size of D2R Msg#1 that should be used (e.g., by different types of A-IoT devices 3-1) to send control information to the A-IoT device reader in the D2R transmission at step S504.

[0131] For example, having received R2D Msg#1 with an indication of a format and / or size of D2R Msg#1 that should be used to send control information to the A-IoT device reader in a D2R transmission (e.g., D2R Msg#1 at step S504), an A-IoT device 3-1 that wishes to send control information to the A-IoT device reader may use a correct control information format for D2R Msg#1 which is based on a defined size of the control information when generating D2R Msg#1 and as indicated in R2D Msg#1.

[0132] It will be appreciated that, where an R2D message is not an initial triggering message it may indicate the contents for a subsequent D2R transmission to the A-IoT device reader.

[0133] It will be appreciated that different R2D messages (which may be sent as R2D Msg#1 or R2D Msg#2) may be associated with different type of follow-up D2R transmission / message (which may be sent as D2D Msg#2). For example, where the R2D message is associated with an initial D2R message to be sent to the A-IoT device reader at step S504 (e.g., D2R Msg#1) that does not include control information, then the R2D message used may be of a first type (e.g., referred to as a 'Type A' R2D massage or R2D message A). Where the R2D message is associated with an initial D2R transmission to be sent to the A-IoT device reader at step S504 (e.g., D2R Msg#1) that includes control information (e.g., corresponding to case 1 or case 2 described above), then the R2D message used may be of a second type (e.g., referred to as a 'Type B' R2D massage or R2D message B). Where, the R2D message is associated with a second D2R transmission to be sent to the A-IoT device reader at step S508 (e.g., D2R Msg#2) that includes control information (e.g., corresponding to case 1 or case 2 described above), then the R2D message used may be of a third type (e.g., referred to as a 'Type C' R2D massage or R2D message C).

[0134] It will be appreciated that in the examples immediately above, the type of R2D message that is sent at a given time may be associated with the type of A-IoT device 3-1 that is to receive those R2D messages. For example, type 1 A-IoT devices (i.e., A-IoT devices that have means of energy storage but no independent signal generation or downlink (DL) / uplink (UL) amplification capabilities), and type 2a A-IoT devices (i.e., A-IoT devices that have means of energy storage, and no independent signal generation capabilities, but that do have both DL and UL amplification capabilities), may only respond to Type B and Type C R2D messages, since those R2D messages may be configured to include control information transmission within any D2R transmissions (e.g., D2R Msg#1 at step S504 and / or D2R Msg#2 at step S508).

[0135] In a similar vein, other A-IoT device types (e.g., type 2b A-IoT devices that have means of energy storage and independent signal generation) may be able to respond to Type A R2D messages (possibly, but not necessarily, in addition to being able to respond Type B / C R2D messages), since those A-IoT device types may not support transmission of (may not be required to transmit) control information.

[0136] It will be appreciated that the A-IoT device reader sending an R2D message (e.g., R2D Msg#1 at step S502) can signal / distinguish its intention to transmit a specific type of R2D message (e.g., an initial triggering message, an appropriate resolution message, an R2D command, or the like) by adapting the signal on which the R2D message occurs.

[0137] For example, depending on the type of R2D message that the A-IoT device reader intends to send to an A-IoT device 3-1 (e.g., an initial triggering message, an appropriate resolution message, an R2D command, or the like), the A-IoT device reader may use a specific signal sequence; a specific signal waveform; a specific time-space configuration for the signal; a specific power level for the signal; and / or specific transmission resources to indicate to A-IoT devices 3-1 the type of R2D message that the A-IoT device reader is sending. It will also be appreciated that by adapting the signal upon which the R2D message is sent, the A-IoT device reader may target specific R2D messages to specific A-IoT devices 3-1.

[0138] Upon transmission of the R2D message by the A-IoT device reader, the A-IoT device 3-1 (e.g., a type 1 and / or a type 2a A-IoT device 3-1) receiving the R2D message can identify the type of R2D message that it is receiving from the A-IoT device reader, and may determine the need to respond without needing to look into the contents of the R2D message since the necessary control information for the R2D message may have been received earlier by the A-IoT device 3-1, or pre-configured, or specified in the specification associated with A-IoT devices 3-1.

[0139] Step S504 　　At step S504, having received the first R2D message (e.g., R2D Msg#1) at step S502, the A-IoT device 3-1 sends a follow-up (first) D2R transmission (e.g., D2R Msg#1) over a physical device-to-reader channel (PDRCH).

[0140] For example, the A-IoT device 3-1, upon receiving R2D Msg#1 may send a response message D2R Msg#1 to the A-IoT device reader which may, by way of example only, include: a response to an inventory request message; a response message to another command sent in R2D Msg#1; any form of data to be transmitted to the A-IoT device reader and / or the like.

[0141] Upon receipt of D2R Msg#1, the A-IoT device reader may first receive a clock signal from D2R Msg#1, and then use that clock signal to obtain information necessary to decode the remainder of D2R Msg#1.

[0142] D2R Msg#1 may follow a suggested time and / or frequency domain resource allocation (TDRA / FDRA) indicated by the A-IoT device reader in its initial R2D message (e.g., R2D Msg#1 at step S502). Additionally (or alternatively), D2R Msg#1 may also use a chip length indicated by the A-IoT device reader in its initial R2D message (e.g., R2D Msg#1 at step S502).

[0143] D2R Msg#1 may, for example, include an appropriate control information MAC CE (or L1 control signalling or other higher layer message), which may be used to help the A-IoT device reader to correctly decode D2R Msg#1, and / or help the A-IoT device reader to determine if it needs to schedule further D2R transmissions. In this scenario, the control information MAC CE may be multiplexed with a MAC SDU carrying A-IoT data, and / or the control information MAC CE may be multiplexed with another MAC CE carrying A-IoT high level signalling (e.g., a command response and / or inventory response).

[0144] Alternatively, the control information MAC CE may be sent independently as a MAC PDU within a TB. It will be appreciated that the control information may be provided to the A-IoT device reader after a clock acquisition part, and before a data portion, of a PDRCH transmission (e.g., D2R Msg#1) is transmitted on the PRDCH. In this way, the control information coded as a MAC CE may be a MAC PDU within a TB that is independent from the data portion of a PDRCH message.

[0145] D2R Msg#1 may include, within its control information MAC CE, MCS related information / parameters that indicate a selected MCS from the set of MCSs that were indicated to the A-IoT device 3-1 in the R2D message sent to the A-IoT device 3-1 at step S402 (e.g., R2D Msg#1). That selected MCS may be the MCS used by the A-IoT device 3-1 for the D2R transmission at step S504 (e.g., D2R Msg#1). It will be appreciated that the A-IoT device reader may use that indicated MCS to fully decode the data transmitted in the D2R transmission.

[0146] Additionally (or alternatively), the control information MAC CE of D2R Msg#1 may include a chip length for the data part of the D2R transmission (e.g., D2R Msg#1 at step S504).

[0147] Additionally (or alternatively), the control information MAC CE of D2R Msg#1 may include TBS related information / parameters that indicate a selected TBS from a set of TBSs that were indicated to the A-IoT device 3-1 in the R2D message sent to the A-IoT device 3-1 at step S502 (e.g., R2D Msg#1). That selected TBS may be the TBS used by the A-IoT device 3-1 for the D2R transmission at step S504 (e.g., D2R Msg#1). It will be appreciated that the A-IoT device reader may use that indicated TBS to determine / identify the end of the data transmission in D2R Msg#1.

[0148] It will be appreciated that where the control information MAC CE includes MCS related information / parameters, and chip length related information / parameters, and / or TBS related information / parameters, that information / those parameters may be mixed together into a single set of related information / parameters.

[0149] Additionally (or alternatively), the control information MAC CE of D2R Msg#1 may include repetition related information / parameters that indicate a selected repetition level from a set of (allowed) repetition levels that were indicated to the A-IoT device 3-1 in the R2D message sent to the A-IoT device 3-1 at step S502 (e.g., R2D Msg#1). That selected repetition level may, for example, be the repetition level used by the A-IoT device 3-1 for one or more subsequent (repeated) D2R transmissions.

[0150] It will be appreciated that where D2R Msg#1 includes data and control information (e.g., in a MAC CE), the control information MAC CE of D2R Msg#1 may include other appropriate information (or indications) to indicate whether or not further D2R transmissions (e.g., D2R Msg#2 at step S508) are required / desired. For example, the control information MAC CE of D2R Msg#1 may also include an appropriate indication that remaining data is at the A-IoT device 3-1 and that transmission of that remaining data needs to be scheduled. For example, the control information MAC CE of D2R Msg#1 may also include a simple indication (e.g., a single bit indication or the like) that indicates if there is still remaining data held in a buffer (or the like) of the A-IoT device 3-1 that needs to be transmitted to the A-IoT device reader after the transmission of the first D2R transmission.

[0151] Additionally (or alternatively), the control information MAC CE of D2R Msg#1 may also include an appropriate indication of the amount of remaining data at the A-IoT device 3-1 for which transmissions need to be scheduled. For example, the control information MAC CE of D2R Msg#1 may include a code of appropriate length (e.g., four bits), or the like, that points to an entry in a newly defined buffer status report (BSR) table which may be used to express different levels of remaining data (e.g., 16 different levels in the case of a four-bit code) with each four-bit code value representing a respective volume of remaining data (or a remaining data volume range) at the A-IoT device 3-1.

[0152] Additionally (or alternatively), the control information MAC CE of D2R Msg#1 may also include an indication of a number of transmission occasions that may be required for the transmission of the remaining data at the A-IoT device 3-1. It will be appreciated that the number of transmission occasions that it may take for the A-IoT device 3-1 to transmit its remaining data to the A-IoT device reader may, for example, be calculated based on how much data can be hosted within a single transmission occasion for a preconfigured set of transmission parameters. For example, the calculation may be based on how much data can be hosted within a single transmission occasion with a specific modulation scheme, coding scheme, chip level, repetition level, etc. For example, if the TBS is fixed for D2R transmissions, the A-IoT device 3-1 may calculate how many transmission occasions are needed to schedule the transmission of any remaining data at the A-IoT device 3-1 if the capacity of transmission occasions is fixed via a predefined MCS, chip length, TBS, and / or repetition level. It will be appreciated that the A-IoT device 3-1 may thus expect the same number of transmissions occasions to be scheduled by one or more subsequent R2D messages (including e.g., R2D Msg#2) as the A-IoT device indicated. Those transmission occasions scheduled by one or more subsequent R2D messages (including e.g., R2D Msg#2) may be used to allow the required follow-up data transmissions, after current data transmission, to transmit the remaining data).

[0153] It will be appreciated that where D2R Msg#1 includes control information (e.g., in a MAC CE (but does not include data), the control information MAC CE of D2R Msg#1 may include an appropriate indication of a number of transmission occasions that it may take for the A-IoT device 3-1 to transmit all its available data to the A-IoT device reader. It will be appreciated that the number of transmission occasions that it may take for the A-IoT device 3-1 to transmit its available data to the A-IoT device reader may, for example, be calculated based on how much data can be hosted within a single transmission occasion with a preconfigured set of transmission parameters. For example, the calculation may be based on how much data can be hosted within a single transmission occasion with a specific modulation scheme, coding scheme, chip level, repetition level, etc.

[0154] Additionally (or alternatively), the control information MAC CE of D2R Msg#1 may also include an indication of information pertaining to data segmentation. For example, if the packets of data in the D2R transmissions are segmented, then the control information MAC CE of D2R Msg#1 may include an appropriate indication that provides appropriate information to the A-IoT device reader on that data segmentation.

[0155] Additionally (or alternatively), the control information MAC CE of D2R Msg#1 may also include an indication of a remaining energy status of the A-IoT device 3-1. For example, the control information MAC CE of D2R Msg#1 may include an appropriate indication to indicate to the A-IoT device reader the energy status of the A-IoT device 3-1, and the amount of energy (or a percentage of the energy) remaining at the A-IoT device 3-1. Such an indication may, by way of example only, inform the A-IoT device reader if the A-IoT device 3-1 is able to monitor for R2D messages and / or generate follow-up D2R transmissions. The A-IoT device reader (and / or the network) may use the remaining energy status information to appropriately schedule transmissions to and from the A-IoT device 3-1.

[0156] The A-IoT device 3-1 may also be able to inform the A-IoT device reader, via that indication on remaining energy status, when the A-IoT device 3-1 has insufficient energy for performing a D2R transmission. For example, the indication on remaining energy status may, by way of example only, comprise a one-bit indication that can indicate to the A-IoT device reader whether or not the A-IoT device 3-1 is able to perform further D2R transmissions after the current R2D message.

[0157] Additionally, in the case where the indication indicates that the A-IoT device 3-1 is not able to perform D2R transmissions, the indication may also indicate to the A-IoT device reader that the A-IoT device 3-1 will switch off after the current D2R transmission.

[0158] The A-IoT device 3-1 may also be able to inform the A-IoT device reader, via the indication on remaining energy status, how much data (or how many data transmissions) that the A-IoT device 3-1 can perform after the current D2R transmission based on its current energy level. The A-IoT device 3-1 may also be able to inform the A-IoT device reader, via the indication on remaining energy status, how long (e.g., in ms) the A-IoT device 3-1 can continue to monitor the R2D link (e.g., the PRDCH) and / or how long the A-IoT device 3-1 can perform subsequent D2R transmissions after the current D2R transmission based on its current energy level.

[0159] Additionally (or alternatively), the control information MAC CE of D2R Msg#1 may also include an indication of a time (or a timing window) when the A-IoT device 3-1 can expect to receive a next R2D message after the current D2R transmission.

[0160] Additionally (or alternatively), the control information MAC CE of D2R Msg#1 may also include an indication of energy harvesting requirements of the A-IoT device 3-1 and may include an indication of a time at which the A-IoT device 3-1 can perform energy harvesting before the next D2R transmission (e.g., D2R Msg#2). For example, the control information MAC CE of D2R Msg#1 may include a 1-bit indication to indicate to the A-IoT device reader that there is a requirement for the A-IoT device 3-1 to perform energy harvesting procedures.

[0161] Additionally (or alternatively), the control information MAC CE of D2R Msg#1 may also include an indication of a duration in which the A-IoT device 3-1 will perform an energy harvesting procedure. In this way the A-IoT device 3-1 is able to indicate to the A-IoT device reader a time period (which may be expressed using a configured timer) within which the A-IoT device 3-1 does not expect (and / or does not want) the A-IoT device reader to schedule a subsequent D2R transmission - i.e., the A-IoT device reader should not schedule a subsequent D2R transmission for that A-IoT device until expiry of the configured timer. It will be appreciated that the A-IoT device 3-1 may not be able generate the next D2R transmission and / or monitor for R2D messages until expiry of that configured timer.

[0162] Additionally (or alternatively), the control information MAC CE of D2R Msg#1 may also include an indication of time at, or a timing window within which, the A-IoT device 3-1 is able to generate a next D2R transmission.

[0163] Examples energy harvesting based scheduling that may be implemented by the A-IoT device 3-1 is described in further detail below.

[0164] An example control information MAC PDU for D2R scheduled transmissions is shown in Fig. 7. That figure shows that a MAC PDU transmitted over a D2R link may comprise, by way of example only, two (or more) MAC subPDUs (e.g., MAC subPDU #X and #Y). One MAC subPDU (e.g., MAC subPDU #X) may include an appropriate MAC subheader and a MAC SDU includes part of (or all of) the data available at the A-IoT device 3-1 that it wants to send to the A-IoT device reader. Another MAC subPDU (e.g., MAC subPDU #Y) may include an appropriate MAC subheader and a MAC CE that includes control information such as that already described above.

[0165] Step S506 　　It will be appreciated that following the D2R transmission at step S504 (e.g., transmission of D2R Msg#1), a further R2D message (R2D Msg#2) may be sent by the A-IoT device reader to the A-IoT device 3-1 at step S506. For example, the A-IoT device reader may send a further (second) R2D message to the A-IoT device 3-1 when the A-IoT device reader wishes to schedule the A-IoT device 3-1 for further D2R transmissions (e.g., for D2R Msg#2 sent at S508). The content of this further R2D message (R2D Msg#2) may, for example, be based on control information received by the A-IoT device reader at step S504 (e.g., in D2R Msg#1).

[0166] That further (second) R2D message (e.g., R2D Msg#2) sent to the A-IoT device 3-1 may, for example, carry the same type of information and / or fields as was included in the first R2D message (e.g., R2D Msg#1) that the A-IoT device reader sent to the A-IoT device 3-1 at step S502. Furthermore, that further (second) R2D message (e.g., R2D Msg#2) sent to the A-IoT device 3-1 may also carry an appropriate scheduling information MAC CE to schedule a further D2R transmission, or multiple further D2R transmissions.

[0167] In response to the further (second) R2D message (e.g., R2D Msg#2) sent to the A-IoT device 3-1 sent at step S506, the A-IoT device 3-1 may generate a further D2R transmission (e.g., D2R Msg#2), or multiple further D2R transmissions (e.g., D2R Msg#2 and further similar messages) in accordance with the information indicated to the A-IoT device 3-1 in the scheduling information MAC CE it received in the further (second) R2D message (e.g., R2D Msg#2). Alternatively, the A-IoT device 3-1 may generate a further D2R transmission, or multiple further D2R transmissions in accordance with information indicated to the A-IoT device 3-1 in a scheduling information MAC CE it received in an earlier R2D message (e.g., R2D Msg#1).

[0168] That further (second) D2R transmission (e.g., D2R Msg#2) may, for example, carry the same type of information and / or fields as was included in the first D2R transmission (e.g., D2R Msg#1) that the A-IoT device 3-1 sent to the A-IoT device reader at step S504. For example, the further (second) D2R transmission (e.g., D2R Msg#2) may carry an appropriate control information MAC CE (or other higher layer messaging) as already described with reference to the first D2R transmission (e.g., D2R Msg#1) that the A-IoT device 3-1 sent to the A-IoT device reader at step S504. That appropriate control information MAC CE (or other higher layer messaging) may, for example, help the A-IoT device reader to correctly decode the D2R transmission, and / or help the A-IoT device reader to determine if there is a need to schedule further D2R transmissions.

[0169] Scheduling Examples 　　To help illustrate how the procedure of Fig. 5 may be used in the context of scheduling a number of scheduling examples will now be described, by way of example only.

[0170] Energy Harvesting-based Scheduling Example:

[0171] Fig. 8 illustrates a scheduling example that may take place in the communication system of Fig. 1 when the A-IoT device 3-1 wishes to perform an energy harvesting procedure.

[0172] As shown in Fig. 8, when the A-IoT device reader receives a D2R transmission (e.g., D2R Msg#1 at step S504) at time T2from the A-IoT device 3-1, which includes a control information MAC CE that indicates a requirement for the A-IoT device 3-1 to perform energy harvesting procedures (e.g., an indication of an appropriate timer T, or the like), the A-IoT device reader may start that timer T, and may delay the transmission of R2D messages (e.g., R2D Msg#2) until expiry of the timer T - i.e., until the A-IoT device 3-1 is properly charged and capable of receiving and transmitting messages at time T3.

[0173] The A-IoT device 3-1 may also start a timer based on the time required for energy harvesting and may not monitor R2D messages (and / or generate any D2R transmissions) over this period until the expiry of the timer T at time T3(i.e., The A-IoT device 3-1 will only re-start monitoring for R2D messages when the timer T expires).

[0174] At time T2when the A-IoT device 3-1 sends a D2R transmission (e.g., D2R Msg#1) to the A-IoT device reader, and that D2R transmission indicates that the A-IoT device 3-1 needs to perform energy harvesting procedures, the time period indicated for performing those energy harvesting procedures may be over-estimated. In this case, the A-IoT device 3-1 may be able to generate a specific transmission for sending to the A-IoT device reader to notify the A-IoT device reader when the A-IoT device 3-1 has completed those energy harvesting procedures. For example, the IoT device 3-1 may be able to generate a specific transmission for sending to the A-IoT device reader to notify the A-IoT device reader when the A-IoT device 3-1 has completed those energy harvesting procedures earlier than the indicated over-estimated time period.

[0175] When the A-IoT device 3-1 sends that specific transmission to notify the A-IoT device reader that it has completed those energy harvesting procedures, the A-IoT device 3-1 may begin monitoring for R2D messages from the A-IoT device reader straight away if the specific transmission sent to notify the A-IoT device reader that the A-IoT device 3-1 has completed its energy harvesting procedures is sent on a pre-configured or pre-defined radio resource (e.g., in a special frequency domain to avoid transmission collisions). It will be appreciated that the A-IoT device reader may be expected to monitor for such special transmissions without needing to meet strict timing alignment requirements.

[0176] Alternatively, when the A-IoT device 3-1 sends that specific transmission to notify the A-IoT device reader that it has completed those energy harvesting procedures it may nevertheless wait until the expiry of the indicated over-estimated timer T before beginning to monitor for R2D messages from the A-IoT device reader. It will once again be appreciated that the A-IoT device reader may be expected to monitor for such special transmissions without needing to meet strict timing alignment requirements.

[0177] It will also be appreciated that nevertheless the A-IoT device 3-1 may also be able to resume monitoring for R2D message even though it is not fully charged. For example, the A-IoT device 3-1 may be able to being monitoring for R2D messages (but not generate D2R transmissions) when it is partially charged and / or charging (e.g., when in a limited energy state). In this case, the A-IoT device 3-1 may indicate two different timers, T1 and T2. Timer T1 may be associated with monitoring R2D messages and timer T2 may be associated with generating D2R transmissions. For example, with reference to Fig. 8, timer T1 may be a timer that expires at T3, while timer T2 may be a timer that expires at T4.

[0178] It will also be appreciated that in order to maximise resource efficiencies, transmission occasions and / or resources that have been allocated during an indicated time period that is used by the A-IoT device 3-1 to perform energy harvesting procedures may be skipped by the A-IoT device 3-1 (i.e., not used) and / or retrieved by the A-IoT device reader (i.e., deallocated and / or reallocated as appropriated).

[0179] Alternatively, when the A-IoT device 3-1 indicates to the A-IoT device reader that it needs to perform an energy harvesting procedure, the A-IoT device reader may control the charge (energy) of the A-IoT device 3-1 via an appropriate continuous wave (CW) signal, which in turn may enable the A-IoT device reader to know (or determine) how long may be needed for the A-IoT device 3-1 to fully re-charge. In this scenario, there may be no need to define appropriate timers associated with the energy harvesting procedures; rather the A-IoT device reader can determine a time it will take for the A-IoT device 3-1 to charge. In this case, the A-IoT device reader may be able to send R2D messages to the A-IoT device 3-1 once the A-IoT device reader is sure that the A-IoT device 3-1 has sufficient energy.

[0180] It will be appreciated that when the A-IoT device 3-1 initiates an energy harvesting procedure and begins to charge, the A-IoT device 3-1 will take time to fully charge, and thus appropriate mechanisms may be needed to facilitate recovery of the A-IoT device's ability to re-start monitoring for R2D messages and / or generating D2R transmissions.

[0181] With respect to monitoring R2D messages, the A-IoT device 3-1 may be expected to monitor for R2D messages when a status of the battery of the A-IoT device 3-1 allows. For example, the A-IoT device 3-1 may be expected to monitor for R2D messages when the battery of the A-IoT device 3-1 has a partial charged status i.e., the A-IoT device 3-1 may be able to begin monitoring for R2D message even when it is not fully charged. Alternatively, the A-IoT device 3-1 may be configured such that it cannot begin monitoring for R2D messages until the battery is fully re-charged.

[0182] It will be appreciated that when the A-IoT device 3-1 begins an energy harvesting procedure and stops monitoring for R2D messages, the A-IoT device 3-1 may lose its connection and / or timing alignment with the A-IoT device reader. However, the A-IoT device 3-1 once fully re-charged (or in a partial charge status) may nevertheless be configured to be able to monitor for initial triggering messages over the PRDCH for the purposes of triggering a random access-procedure.

[0183] Alternatively, the A-IoT device 3-1, once fully re-charged (or in a partial charge status), may be able to monitor for R2D messages using a pre-allocated R2D specific resource, or a common resource allocation. In this case, it will be appreciated that the A-IoT device 3-1 may not need to perform a random-access procedure to re-access the A-IoT device reader.

[0184] With respect to generating D2D transmissions, the A-IoT device reader may assume that continuous communication with the A-IoT device 3-1 is not possible because of non-alignment of transmission timings after battery charging. In this case, the A-IoT device 3-1 may have to obtain newly scheduled resources from the A-IoT device reader to allow it to generate and send further D2R transmissions. In the case where resources for D2R transmissions have already been pre-allocated to the A-IoT device 3-1 prior to it beginning an energy harvesting procedure, those resources (e.g., transmission occasions) may be dropped by the A-IoT device 3-1 and retrieved by the A-IoT device reader.

[0185] For example, after completion of an energy harvesting procedure, the A-IoT device 3-1 may initiate a new RACH procedure using appropriate resources indicated to the A-IoT device 3-1 by the A-IoT device reader in a normal initial triggering message (e.g., an R2D message), or the like. Thus, after completion of an energy harvesting procedure, the A-IoT device 3-1 may trigger an appropriate RACH procedure (meaning that the A-IoT device reader does not have to make a specific access request to the A-IoT device 3-1), before the A-IoT device 3-1 generates and sends D2R transmissions.

[0186] In another example, the A-IoT device 3-1 may initiate a new RACH procedure in response to the A-IoT device 3-1 receiving an initial triggering message (e.g., an R2D message) from the A-IoT device reader. Thus, the A-IoT device 3-1 may not access the A-IoT device reader until the A-IoT device reader specifically requests the A-IoT device 3-1 to do so. Once the A-IoT device 3-1 has successfully accessed the A-IoT device reader it may continue D2R transmissions to the A-IoT device reader.

[0187] Alternatively, the A-IoT device reader may assume that continuous communication with the A-IoT device 3-1 is feasible and may assume that the A-IoT device 3-1 can send D2R transmission in a pre-allocated D2R transmission occasion. Thus, a pre-allocated D2R transmission occasion assigned by the A-IoT device reader may take effect after charging is complete.

[0188] Remaining data based scheduling example: 　　In another example, the network / reader may use a procedure based on that of Fig. 5 to perform scheduling based on a remaining data status reported by the A-IoT device 3-1. 　　Specifically, the A-IoT device 3-1 may provide an indication (e.g., in D2R Msg#1 at S504) that there is still remaining data (e.g., via control information MAC CE as described above) when it transmits data via the PDRCH channel to the network / A-IoT device reader. It will be appreciated that this indication may be a simple indication that remaining data is at the A-IoT device 3-1, and / or an indication of an amount of remaining data still to be transmitted.

[0189] Having received the indication that there is still remaining data the A-IoT device 3-1 has remaining data that it wishes to send to the A-IoT device reader, the A-IoT device reader may indicate a new transmission occasion, or set of transmission occasions (e.g., a time resource and / or frequency resource indication) to the A-IoT device 3-1. The indication of a new transmission occasion or set of transmission occasions may, for example, be provided to the A-IoT device 3-1 via a scheduling information MAC CE (e.g. in R2D Msg #2 at S506) to allow the A-IoT device 3-1 to perform the data transmission over the PDRCH.

[0190] The indicated new transmission occasion, or set of transmission occasions, may then be used by the A-IoT device 3-1 to perform transmissions of remaining data stored at in its buffer (e.g. in D2R Msg #2 at S508 and possibly subsequent similar messages) in accordance with the scheduling information it received over the PRDCH.

[0191] Transmission occasions based scheduling example: 　　In another example, the network / reader may use a procedure based on that of Fig. 5 to perform scheduling based on the number of transmission occasions required to transmit available (possibly remaining) data, suggested by the A-IoT device 3-1.

[0192] Specifically, as described above, the control information provided by the A-IoT device 3-1 (e.g. in D2R Msg#1 at S504) may include an appropriate indication of a number of transmission occasions that it may take for the A-IoT device 3-1 to transmit its available (or remaining) data to the A-IoT device reader. As mentioned above, the number of transmission occasions that it may take for the A-IoT device 3-1 to transmit its available (or remaining) data to the A-IoT device reader may, for example, be calculated based on how much data can be hosted within a single transmission occasion with a preconfigured set of transmission parameters. For example, the calculation may be based on how much data can be hosted within a single transmission occasion with a specific modulation scheme, coding scheme, chip level, repetition level, etc.

[0193] Based on the number of transmission occasions indicated in the control information, the A-IoT device reader instructs the A-IoT device 3-1 to perform data transmissions using that number of transmission occasions (e.g., in R2D Msg2 sent at S506 and possibly subsequent similar messages). For example, the A-IoT device reader may send, to the A-IoT device 3-1 via the PRDCH, one or more indications of appropriate transmission occasions that may be used by the A-IoT device 3-1 for the data transmission. That appropriate indication may, by way of example only, comprise a one-off indication of a set of transmission occasions, or it may comprise a set of consecutive indications (e.g., an indication per occasion).

[0194] Having received the indication of an appropriate set of transmission occasions that may be used by the A-IoT device 3-1 for the data transmission, the A-IoT device 3-1 may perform continuous data transmission using the set of transmission occasions until all the data in its buffer is transmitted.

[0195] It will be appreciated that both the remaining data-based scheduling of the previous example, and the transmission occasion-based scheduling of the current example, may also consider the device's requirement for energy harvesting with a required time (e.g., a timer T).

[0196] Devices in the Communication System 　　User Equipment 　　Fig. 9 is a simplified block schematic illustrating the main components of a UE 3-2; 3-3 for implementation in the communication system 1 of Fig. 1. By way of example only UE 3-2 may correspond to the intermediate node 5-2 referred to above.

[0197] As shown, the UE 3-2; 3-3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a base station 5-1 via one or more antenna 33 (e.g., comprising one or more antenna elements). The UE 3-2, 3-3 has a controller 37 to control the operation of the UE 3-2, 3-3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily required for its operation, the UE 3-2; 3-3 might, of course, have all the usual functionality of a conventional UE (e.g., a user interface 35, such as a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 39 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

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

[0199] The communication control module 43 is operable to control the communication between the UE 3-2; 3-3 and its serving RAN node or RAN nodes 5-1 (and other communication devices connected to the RAN node 5-1, such as further UEs 3 and / or core network nodes). The communication control module 43 is configured for the overall handling of uplink communication via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 43 is also configured for the overall handling of receipt of downlink communication via associated downlink channels (e.g., of DCI via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-persistent scheduling (e.g., SPS). The communication control module 43 is responsible, for example: for determining where to monitor for downlink control information; for determining the resources to be used by the UE 3-2, 3-3 for transmission / reception of UL / DL communication (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the UE side; for determining how slots / symbols are configured (e.g., for UL, DL or full duplex communication, or the like); for determining which bandwidth parts are configured for the UE 3-2; 3-3; for determining how uplink transmissions should be encoded and the like.

[0200] It will be appreciated that the communication control module 43 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 43 may include the intermediate node protocol stack layers and corresponding entities to control functions at those layers as described above with reference to Figs. 5 and 6 when the intermediate node 5-2 is a UE 3-2. 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.

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

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

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

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

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

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

[0207] In this example, the A-IoT device 3-1 also has a controller 337 to control the overall operation of the A-IoT device 3-1. The controller 337 is associated with a memory 339 and is coupled to the transceiver circuit 331. Although not necessarily required for its operation, the A-IoT device 3-1 might, of course, have all the usual functionality of a more conventional UE (e.g., a user interface 335, such as a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 339 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

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

[0209] The controller 337 also comprises any suitable form of processing circuitry 338 to process, for examples, signals received and transmitted by the A-IoT device 3-1. For example, the processing circuitry 338 may be configured to process (H)ARQ ACK / NACK messages received from other devices and respond according to those (H)ARQ ACK / NACK messages. The processing circuitry 338 may include (but is 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.

[0210] 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 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 343 may also be 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).

[0211] A data buffer 345 provided as part of the memory 339 (although it could be provided separately) and is configured to store data from the data source 332. By way of example only, where the data source 332 is a sensor (e.g., an optical, temperature, position sensor or the like), the data buffer 245 may store measurement data from the one or more sensors. The storage of data from the data source 332 in the data buffer 345 is controlled by the controller 337. The data buffer may be configured to store the last set of data (e.g., TB) generated by the data source 332, or alternatively it may be configured to store multiple sets of data (e.g., TBs) generated by the data source. For example, the data buffer may store a specific number of sets of data (e.g., TBs) generated by the data sources that are overwritten incrementally as new sets of data are generated. The number (amount) of sets of data (e.g., TBs) to be stored by the data buffer may be preconfigured at the controller 337. Alternatively, the number (amount) of sets of data (e.g., TBs) to be stored by the data buffer may be adjustable by the controller 337. The controller 337 is also configured to allow data from the data buffer 345 to be transmitted by the A-IoT device 3-1 when triggered to do so.

[0212] 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 the ambient IoT device protocol stack layers and corresponding entities to control functions at those layers as described above with reference to Figs. 5 and 6.

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

[0214] There now follows more detailed examples of a UE 3 comprising an ambient IoT device 3-1 for possible implementation in the communication system 1 of Fig. 1.

[0215] RAN node 　　Fig. 11 is a simplified block schematic illustrating the main components of a RAN node 5-1 (e.g., a base station 5-1) for implementation in the communication system 1 of Fig. 1. The RAN node 5-1 is an example of an ambient IoT device reader.

[0216] 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 5-1 via an appropriate interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR). The RAN node 5-1 has a controller 57 to control the operation of the RAN node 5-1. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the RAN node 5-1 by, in this example, program instructions or software instructions stored within memory 59.

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

[0218] 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 RAN node 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.

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

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

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

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

[0223] The assisting node 5-2 has a controller 157 to control the operation of the assisting node 5-2. The controller 157 is associated with a memory 159 and is coupled to the transceiver circuit 151. Although not necessarily required for its operation, the assisting node 5-2 might, of course, have other functionality (e.g., a user interface, such as a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 159 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

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

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

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

[0227] It will be appreciated that the communication control module 163 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 163 may include the intermediate node protocol stack layers and corresponding entities to control functions at those layers as described above with reference to Figs. 5 and 6. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0246]

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

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

[0249] Furhter, each example embodiment can be appropriately combined with at least one of example embodiments.

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

[0251] Furhter, the whole or part of the example 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 via a Medium Access Control (MAC) layer, a first message for scheduling a transmission from the mobile device to the reader device; 　　transmitting, to the reader device via the MAC layer, a second message including a part of uplink data in a buffer and first information indicating that the mobile device has remaining of the uplink data transmitted via the MAC layer, based on the first message; 　　receiving, from the reader device via the MAC layer, a further first message for scheduling the transmission of the remaining of the uplink data in the buffer via the MAC layer, upon transmitting the first information; and 　　transmitting, to the reader device via the MAC layer, a further second message including at least a part of the remaining of the uplink data. 　　(Supplementary Note 2) 　　The method according to supplementary note 1, wherein 　　the first information includes at least one of: 　　　　information indicating at least one transmission occasion for the transmission of the remaining of the uplink data, 　　　　information indicating data size of the remaining of the uplink data, 　　　　information indicating a number of segmentations of the remaining of the uplink data, 　　　　information indicating an energy status at the mobile device, 　　　　information indicating charging time which the mobile device charges for gaining energy for monitoring the further first message, or 　　　　information indicating when a next first message is expected to be transmitted. 　　(Supplementary Note 3) 　　The method according to supplementary note 1 or 2, wherein 　　the first information includes at least one of: 　　　　information indicating the mobile device, 　　　　information indicating modulation and coding scheme for the transmission of the remaining of the uplink data, 　　　　information indicating a length of a chip for the transmission of the remaining of the uplink data, 　　　　information indicating a transport block size (TBS) for the transmission of the remaining of the uplink data, 　　　　information indicating time domain resource allocation for the transmission of the remaining of the uplink data, 　　　　information indicating frequency domain resource allocation for the transmission of the remaining of the uplink data, or 　　　　information indicating a repetition for the transmission of the remaining of the uplink data. 　　(Supplementary Note 4) 　　The method according to any one of supplementary notes 1 to 3, wherein 　　the first information is multiplexed in at least one of: 　　　　a MAC control element (CE), or 　　　　a MAC protocol data unit (PDU). 　　(Supplementary Note 5) 　　The method according to any one of supplementary notes 1 to 4, wherein 　　the second message includes a MAC service data unit (SDU). 　　(Supplementary Note 6) 　　The method according to any one of supplementary notes 1 to 5, wherein 　　the first message includes scheduling information including at least one of: 　　　　information indicating the mobile device, 　　　　information indicating modulation and coding scheme for the transmission of the remaining of the uplink data, 　　　　information indicating a length of a chip for the transmission of the remaining of the uplink data, 　　　　information indicating a transport block size (TBS) for the transmission of the remaining of the uplink data, 　　　　information indicating time domain resource allocation for the transmission of the remaining of the uplink data, 　　　　information indicating frequency domain resource allocation for the transmission of the remaining of the uplink data, or 　　　　information indicating a repetition for the transmission of the remaining of the uplink data. 　　(Supplementary Note 7) 　　The method according to supplementary note 6, wherein 　　the scheduling information is multiplexed in at least one of: 　　　　a MAC control element (CE), or 　　　　a MAC protocol data unit (PDU). 　　(Supplementary Note 8) 　　The method according to any one of supplementary notes 1 to 7, wherein 　　the first message is received after obtaining a clock signal and before receiving a data part. 　　(Supplementary Note 9) 　　The method according to any one of supplementary notes 1 to 8, wherein 　　the transmitting the second message is performed in a case where the mobile device determines that the first message is an initial triggering message. 　　(Supplementary Note 10) 　　The method according to any one of supplementary notes 1 to 9, wherein 　　the transmitting the second message is performed based on at least one of: 　　　　a type of the second message which the first message corresponds to, or 　　　　a type of the mobile device. 　　(Supplementary Note 11) 　　The method according to any one of supplementary notes 1 to 10, further comprising: 　　determining a type of the first message based on at least one of: 　　　　a sequence of the first message, 　　　　a waveform of the first message, 　　　　time-space for the first message, 　　　　a powel level for the first message, or 　　　　resources for the first message; and 　　determining whether to transmit the second message based on the type of the first message. 　　(Supplementary Note 12) 　　The method according to any one of supplementary notes 1 to 11, wherein 　　the first message includes information indicating at least one of: 　　　　a format of the first information, or 　　　　a size of the first information. 　　(Supplementary Note 13) 　　The method according to any onr of supplementary notes 1 to 12, wherein 　　the first message includes information indicating a content of the uplink data. 　　(Supplementary Note 14) 　　The method according to any one of supplementary notes 1 to 13, wherein 　　the first information includes indicating charging time which the mobile device charges for gaining energy for monitoring the further first message, and 　　the receiving the further first message is performed after the charging time has passed. 　　(Supplementary Note 15) 　　The method according to supplementary note 14, further comprising: 　　transmitting, to the reader device, information indicating that charging at the mobile device has completed before the charging time passed; and 　　monitoring the further first message after transmitting the information indicating the charging has completed. 　　(Supplementary Note 16) 　　The method according to supplementary note 14, further comprising: 　　monitoring the further first message before the charging time has passed in a limited energy status, and 　　wherein the transmitting the further second message is performed after the charging time has passed. 　　(Supplementary Note 17) 　　The method according to supplementary note 16, further comprising: 　　transmitting, to the reader device, information indicating a time when the mobile device is able to monitor the further first message and information indicating a time when the mobile device is able to transmit the further second message. 　　(Supplementary Note 18) 　　The method according to supplementary note 17, wherein 　　the transmitting the information indicating the time when the mobile device is able to monitor the further first message and the information indicating the time when the mobile device is able to transmit the further second message is performed using a preconfigured resource. 　　(Supplementary Note 19) 　　The method according to any one of supplementary notes 1 to 13, further comprising: 　　receiving, from the reader device, a continuous wave signal for the reader device to control charging of the mobile device, and 　　the receiving the further first message is performed based on a result of controlling using the continuous wave signal. 　　(Supplementary Note 20) 　　The method according to any one of supplementary notes 1 to 19, wherein 　　the transmitting the further second message is performed without a random access procedure. 　　(Supplementary Note 21) 　　The method according to any one of supplementary notes 1 to 19, wherein 　　the transmitting the further second message is performed by a random access procedure. 　　(Supplementary Note 22) 　　The method according to any one of supplementary notes 1 to 19, wherein 　　the transmitting the further second message is performed in a preconfigured transmission occasion. 　　(Supplementary Note 23) 　　A method performed by a reader device, the method comprising: 　　transmitting, to a mobile device via a Medium Access Control (MAC) layer, a first message for scheduling a transmission from the mobile device to the reader device; 　　receiving, from the mobile device via the MAC layer, a second message including a part of uplink data in a buffer and first information indicating that the mobile device has remaining of the uplink data transmitted via the MAC layer, based on the first message; 　　transmitting, to the mobile device via the MAC layer, a further first message for scheduling the transmission of the remaining of the uplink data in the buffer via the MAC layer, upon transmitting the first information; and 　　receiving, from the mobile device via the MAC layer, a further second message including at least a part of the remaining of the uplink data. 　　(Supplementary Note 24) 　　A mobile device comprising: 　　means for receiving, from a reader device via a Medium Access Control (MAC) layer, a first message for scheduling a transmission from the mobile device to the reader device; 　　means for transmitting, to the reader device via the MAC layer, a second message including a part of uplink data in a buffer and first information indicating that the mobile device has remaining of the uplink data transmitted via the MAC layer, based on the first message; 　　means for receiving, from the reader device via the MAC layer, a further first message for scheduling the transmission of the remaining of the uplink data in the buffer via the MAC layer, upon transmitting the first information; and 　　means for transmitting, to the reader device via the MAC layer, a further second message including at least a part of the remaining of the uplink data. 　　(Supplementary Note 25) 　　A reader device comprising: 　　means for transmitting, to a mobile device via a Medium Access Control (MAC) layer, a first message for scheduling a transmission from the mobile device to the reader device; 　　means for receiving, from the mobile device via the MAC layer, a second message including a part of uplink data in a buffer and first information indicating that the mobile device has remaining of the uplink data transmitted via the MAC layer, based on the first message; 　　means for transmitting, to the mobile device via the MAC layer, a further first message for scheduling the transmission of the remaining of the uplink data in the buffer via the MAC layer, upon transmitting the first information; and 　　means for receiving, from the mobile device via the MAC layer, a further second message including at least a part of the remaining of the uplink data.

[0252] Furhter, Some or all of elements specified in Supplementary Notes 2 to 22 dependent on Supplementary Note 1 may also be dependent on Supplementary Notes 23, 24 and 25 in dependency similar to that of Supplementary Notes 2 to 22 on Supplementary Note 1. Some or all of elements specified in any of Supplementary Notes may be applied to various types of hardware, software, and recording means for recording software, systems, and methods.

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

[0254] 1　　COMMUNICATION SYSTEM 3-1　　AMBIENT INTERNET OF THINGS (IoT) DEVICE 3-2, 3-3　　NON-INTERNET OF THINGS (IoT) USER EQUIPMENT (UE) 5-1　　RADIO ACCESS NETWORK (RAN) NODE 5-2　　INTERMEDIATE OR ASSISTING NODE 7　　CORE NETWORK 9　　CELL 10　　CONTROL PLANE FUNCTION (CPF) 10-1　　ACCESS AND MOBILITY MANAGEMENT FUNCTION (AMF) 10-2　　SESSION MANAGEMENT FUNCTION (SMF) 10-N　　OTHER FUNCTIONS 11　　USER PLANE FUNCTION (UPF) 20, 20-1, 20-2, 20-3　　COMMUNICATION 21　　EXTERNAL DATA NETWORK 31　　TRANSCEIVER CIRCUIT 33　　ANTENNA 35　　USER INTERFACE 37　　CONTROLLER 39　　MEMORY 41　　OPERATING SYSTEM 43　　COMMUNICATION CONTROL MODULE 51　　TRANSCEIVER CIRCUIT 53　　ANTENNA 55　　CORE NETWORK INTERFACE 57　　CONTROLLER 59　　MEMORY 61　　OPERATING SYSTEM 63　　COMMUNICATION CONTROL MODULE 151　　TRANSCEIVER CIRCUIT 153　　ANTENNA 155　　RAN INTERFACE 157　　CONTROLLER 159　　MEMORY 161　　OPERATING SYSTEM 163　　COMMUNICATION CONTROL MODULE 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　　COMMUNICATION CONTROL MODULE 345　　DATA BUFFER

Claims

1. A method performed by a mobile device, the method comprising: 　　receiving, from a reader device via a Medium Access Control (MAC) layer, a first message for scheduling a transmission from the mobile device to the reader device; 　　transmitting, to the reader device via the MAC layer, a second message including a part of uplink data in a buffer and first information indicating that the mobile device has remaining of the uplink data transmitted via the MAC layer, based on the first message; 　　receiving, from the reader device via the MAC layer, a further first message for scheduling the transmission of the remaining of the uplink data in the buffer via the MAC layer, upon transmitting the first information; and 　　transmitting, to the reader device via the MAC layer, a further second message including at least a part of the remaining of the uplink data.

2. The method according to claim 1, wherein 　　the first information includes at least one of: 　　　　information indicating at least one transmission occasion for the transmission of the remaining of the uplink data, 　　　　information indicating data size of the remaining of the uplink data, 　　　　information indicating a number of segmentations of the remaining of the uplink data, 　　　　information indicating an energy status at the mobile device, 　　　　information indicating charging time which the mobile device charges for gaining energy for monitoring the further first message, or 　　　　information indicating when a next first message is expected to be transmitted.

3. The method according to claim 1 or 2, wherein 　　the first information includes at least one of: 　　　　information indicating the mobile device, 　　　　information indicating modulation and coding scheme for the transmission of the remaining of the uplink data, 　　　　information indicating a length of a chip for the transmission of the remaining of the uplink data, 　　　　information indicating a transport block size (TBS) for the transmission of the remaining of the uplink data, 　　　　information indicating time domain resource allocation for the transmission of the remaining of the uplink data, 　　　　information indicating frequency domain resource allocation for the transmission of the remaining of the uplink data, or 　　　　information indicating a repetition for the transmission of the remaining of the uplink data.

4. The method according to any one of claims 1 to 3, wherein 　　the first information is multiplexed in at least one of: 　　　　a MAC control element (CE), or 　　　　a MAC protocol data unit (PDU).

5. The method according to any one of claims 1 to 4, wherein 　　the second message includes a MAC service data unit (SDU).

6. The method according to any one of claims 1 to 5, wherein 　　the first message includes scheduling information including at least one of: 　　　　information indicating the mobile device, 　　　　information indicating modulation and coding scheme for the transmission of the remaining of the uplink data, 　　　　information indicating a length of a chip for the transmission of the remaining of the uplink data, 　　　　information indicating a transport block size (TBS) for the transmission of the remaining of the uplink data, 　　　　information indicating time domain resource allocation for the transmission of the remaining of the uplink data, 　　　　information indicating frequency domain resource allocation for the transmission of the remaining of the uplink data, or 　　　　information indicating a repetition for the transmission of the remaining of the uplink data.

7. The method according to claim 6, wherein 　　the scheduling information is multiplexed in at least one of: 　　　　a MAC control element (CE), or 　　　　a MAC protocol data unit (PDU).

8. The method according to any one of claims 1 to 7, wherein 　　the first message is received after obtaining a clock signal and before receiving a data part.

9. The method according to any one of claims 1 to 8, wherein 　　the transmitting the second message is performed in a case where the mobile device determines that the first message is an initial triggering message.

10. The method according to any one of claims 1 to 9, wherein 　　the transmitting the second message is performed based on at least one of: 　　　　a type of the second message which the first message corresponds to, or 　　　　a type of the mobile device.

11. The method according to any one of claims 1 to 10, further comprising: 　　determining a type of the first message based on at least one of: 　　　　a sequence of the first message, 　　　　a waveform of the first message, 　　　　time-space for the first message, 　　　　a powel level for the first message, or 　　　　resources for the first message; and 　　determining whether to transmit the second message based on the type of the first message.

12. The method according to any one of claims 1 to 11, wherein 　　the first message includes information indicating at least one of: 　　　　a format of the first information, or 　　　　a size of the first information.

13. The method according to any onr of claims 1 to 12, wherein 　　the first message includes information indicating a content of the uplink data.

14. The method according to any one of claims 1 to 13, wherein 　　the first information includes indicating charging time which the mobile device charges for gaining energy for monitoring the further first message, and 　　the receiving the further first message is performed after the charging time has passed.

15. The method according to claim 14, further comprising: 　　transmitting, to the reader device, information indicating that charging at the mobile device has completed before the charging time passed; and 　　monitoring the further first message after transmitting the information indicating the charging has completed.

16. The method according to claim 14, further comprising: 　　monitoring the further first message before the charging time has passed in a limited energy status, and 　　wherein the transmitting the further second message is performed after the charging time has passed.

17. The method according to claim 16, further comprising: 　　transmitting, to the reader device, information indicating a time when the mobile device is able to monitor the further first message and information indicating a time when the mobile device is able to transmit the further second message.

18. The method according to claim 17, wherein 　　the transmitting the information indicating the time when the mobile device is able to monitor the further first message and the information indicating the time when the mobile device is able to transmit the further second message is performed using a preconfigured resource.

19. The method according to any one of claims 1 to 13, further comprising: 　　receiving, from the reader device, a continuous wave signal for the reader device to control charging of the mobile device, and 　　the receiving the further first message is performed based on a result of controlling using the continuous wave signal.

20. The method according to any one of claims 1 to 19, wherein 　　the transmitting the further second message is performed without a random access procedure.

21. The method according to any one of claims 1 to 19, wherein 　　the transmitting the further second message is performed by a random access procedure.

22. The method according to any one of claims 1 to 19, wherein 　　the transmitting the further second message is performed in a preconfigured transmission occasion.

23. A method performed by a reader device, the method comprising: 　　transmitting, to a mobile device via a Medium Access Control (MAC) layer, a first message for scheduling a transmission from the mobile device to the reader device; 　　receiving, from the mobile device via the MAC layer, a second message including a part of uplink data in a buffer and first information indicating that the mobile device has remaining of the uplink data transmitted via the MAC layer, based on the first message; 　　transmitting, to the mobile device via the MAC layer, a further first message for scheduling the transmission of the remaining of the uplink data in the buffer via the MAC layer, upon transmitting the first information; and 　　receiving, from the mobile device via the MAC layer, a further second message including at least a part of the remaining of the uplink data.

24. A mobile device comprising: 　　means for receiving, from a reader device via a Medium Access Control (MAC) layer, a first message for scheduling a transmission from the mobile device to the reader device; 　　means for transmitting, to the reader device via the MAC layer, a second message including a part of uplink data in a buffer and first information indicating that the mobile device has remaining of the uplink data transmitted via the MAC layer, based on the first message; 　　means for receiving, from the reader device via the MAC layer, a further first message for scheduling the transmission of the remaining of the uplink data in the buffer via the MAC layer, upon transmitting the first information; and 　　means for transmitting, to the reader device via the MAC layer, a further second message including at least a part of the remaining of the uplink data.

25. A reader device comprising: 　　means for transmitting, to a mobile device via a Medium Access Control (MAC) layer, a first message for scheduling a transmission from the mobile device to the reader device; 　　means for receiving, from the mobile device via the MAC layer, a second message including a part of uplink data in a buffer and first information indicating that the mobile device has remaining of the uplink data transmitted via the MAC layer, based on the first message; 　　means for transmitting, to the mobile device via the MAC layer, a further first message for scheduling the transmission of the remaining of the uplink data in the buffer via the MAC layer, upon transmitting the first information; and 　　means for receiving, from the mobile device via the MAC layer, a further second message including at least a part of the remaining of the uplink data.

Images