Method performed by first device, method performed by first reader and first device

Abstract

A method performed by a first device is disclosed. The method includes receiving, from a first reader, first information indicating a first length of a first sequence for a midamble of a device-to-reader, D2R, signal, wherein the first reader is connected to the device via an Ambient Internet of Things, A-IoT, radio interface, and generating a transmission of the D2R signal using the first information.

Description

METHOD PERFORMED BY FIRST DEVICE, METHOD PERFORMED BY FIRST READER AND FIRST DEVICE

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

[0002] The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards, equivalents, or derivatives thereof (including Long-Term Evolution (LTE)-Advanced, Next Generation or 5G networks, future generations, and beyond). The present disclosure relates, in particular but not exclusively, ambient Internet-of-Things (A-IoT) systems and the implementation of midambles for specific purposes in device-to-reader (D2R) transmissions from an A-IoT device to an A-IoT device reader.

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

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

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

[0006] In the current 5G architecture, the base station structure may be split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by a CU-DU interface (e.g., 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 CU-DU interface. Thus, for example, the higher layer CU functionality for a number of base stations may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each base station.

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

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

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

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

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

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

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

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

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

[0016] Such backscattered signals are typically transmitted on the same frequency as the unmodulated carrier signal from which it originated, but alternatively, the backscattered signals may undergo additional processing such that the backscattered signals have an offset from the frequency of the unmodulated carrier signal.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0030] The current view is that R2D transmission will typically comprise an R2D preamble to indicate a start time of the following PRDCH and possibly chip length (duration) information. This R2D preamble is followed immediately by the PRDCH transmission (carrying any R2D traffic data and / or any control information). An R2D postamble may be transmitted immediately after the PRDCH transmission to indicate an end of the PRDCH transmission. Thus, as the R2D preamble is used to indicate the start of each R2D transmission, the R2D postamble implicitly indicates the transport block size (TBS) of the PDRCH transmission by indicating the end of each R2D transmission. Accordingly, there is no need to restrict the timing of the R2D transmission to align with a conventional OFDM slot (e.g., an NR slot in a 5G system). Moreover, given the potential for a large number of small packets to be transmitted via A-IoT communication, flexible and efficient scheduling can be facilitated by not imposing a constraint that the boundary of the R2D transmission should align with that of the OFDM (e.g. NR) slots. Nevertheless, since the R2D transmission waveform is an OFDM-based waveform, the start of an R2D transmission may be aligned with the boundary of an OFDM (e.g., NR) symbol (including any cyclic prefix) when the R2D transmission co-exists with such transmissions) for in-band and guard-band operations.

[0031] Similarly, for D2R transmissions, it is envisaged that a D2R preamble will be transmitted at the beginning of each D2R transmission, immediately before the PDRCH transmission, to indicate a start time of the PDRCH transmission. A D2R postamble may also be transmitted following the PDRCH transmission to indicate the end of the PDRCH transmission (and possibly provide a final timing correction to the A-IoT device reader). In the context of D2R communication, however, one or more D2R 'midambles' may be inserted into (sent during) the PDRCH transmission. Such midambles may be supported in the PDRCH transmission, for example, for the purposes of performing timing / frequency tracking, channel estimation (e.g., depending on the length of that PDRCH transmission), and / or interference estimation. Additionally, such midambles may also be supported in the PDRCH transmission for the purposes of performing (and / or improving) SFO estimation, SFO tracking for a PDRCH transmission with a long transmission duration, and / or timing correction procedures. For example, in the case of timing correction procedures, after SFO estimation based on the D2R preamble, a D2R midamble may be used for improving the SFO estimation.

[0032] For the purposes of D2R scheduling, for example, the following information potentially can be indicated (explicitly or implicitly) by the A-IoT device reader, to the A-IoT device, via the corresponding PRDCH: time domain resources; frequency domain resources; modulation and coding scheme (MCS) like information; chip duration; one or more identifiers (IDs) associated with one or more A-IoT devices; an indication of a number of repetitions; and / or midamble related information (if such midambles are supported).

[0033] There have been a number of different proposals as to what the midamble related information might indicate including, for example, the presence / absence of a midamble in the D2R transmission, the location of a midamble in the D2R transmission, and / or the number of D2R midambles to be included. However, there is still a need to develop an efficient mechanism for indicating this and / or any other midamble related information (either implicitly or explicitly). Moreover, the fact that the midamble may be used for multiple different purposes complicates the use of such preambles, and current proposals do not address how this additional complexity might be handled efficiently.

[0034] It will also be appreciated that such midambles, when included in a PDRCH transmission, can cause additional overhead, and thus 'always-on' midambles in PDRCH transmissions may not be optimal. Furthermore, whether midambles can be included in PDRCH transmissions may also depend on any limit on the size of those PDRCH transmissions.

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

[0036] The disclosure has a method performed by a first device, the method comprising receiving, from a first reader, first information indicating a first length of a first sequence for a midamble of a device-to-reader, D2R, signal, wherein the first reader is connected to the device via an Ambient Internet of Things, A-IoT, radio interface, and generating a transmission of the D2R signal using the first information.

[0037] The disclosure has a method performed by a first reader, the method comprising transmitting, to a first device, first information indicating a first length of a first sequence for a midamble of a device-to-reader, D2R, signal, wherein the first reader is connected to the device via an Ambient Internet of Things, A-IoT, radio interface, and receiving a transmission of the D2R signal using the first information.

[0038] The disclosure has a first device comprising means for receiving, from a first reader, first information indicating a first length of a first sequence for a midamble of a device-to-reader, D2R, signal, wherein the first reader is connected to the device via an Ambient Internet of Things, A-IoT, radio interface, and means for generating a transmission of the D2R signal using the first information.

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

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

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

[0042] Fig. 1 illustrates schematically a mobile (cellular or wireless) communication system to which example embodiments of the disclosure may be applied;Fig. 2A illustrates schematically a first possible arrangement of a first connectivity topology (topology 1) that may be used in the communication system of Fig. 1;Fig. 2B illustrates schematically another possible arrangement of a first connectivity topology (topology 1) that may be used in the communication system of Fig. 1;Fig. 3A illustrates schematically a first possible arrangement second connectivity topology (topology 2) that may be used in the communication system of Fig. 1;Fig. 3B illustrates schematically another possible arrangement second connectivity topology (topology 2) that may be used in the communication system of Fig. 1;Fig. 4A illustrates schematically a first possible arrangement of a third connectivity topology (topology 3) that may be used in the communication system of Fig. 1;Fig. 4B illustrates schematically another possible arrangement of the third connectivity topology (topology 3) of Fig. 4A;Fig. 5 illustrates a simplified sequence diagram of an example procedure for indicating the inclusion of midambles in D2R transmissions that may be implemented in the communication system of Fig. 1;Fig. 6 illustrates an example table including mappings of specific midamble sequences that may be included in D2R transmissions for specific purposes that may be (pre)configured and indicated in the procedure of Fig. 5;Fig. 7 illustrates another example table including mappings of specific midamble sequences that may be included in D2R transmissions for specific purposes that may be (pre)configured and indicated in the procedure of Fig. 5;Fig. 8 illustrates a simplified sequence diagram of an example use case of the (pre)configured mappings of the specific midamble sequences of Figs. 6 and 7 when indicating the inclusion of midambles in D2R transmissions;Fig. 9A illustrates an example of how midambles for specific purposes may be inserted into a D2R transmission when using the procedure of Fig. 8;Fig. 9B illustrates another example of how midambles for specific purposes may be inserted into a D2R transmission when using the procedure of Fig. 8;Fig. 10 illustrates another example of a bundling (mapping) of an indication of one or more specific midamble sequences with repetition D2R scheduling information;Fig. 11 illustrates an example of a bundling (mapping) of an indication of one or more specific midamble sequences with line coding scheme D2R scheduling information;Fig. 12 illustrates an example of a bundling (mapping) of an indication of one or more specific midamble sequences with the scheduled time domain resource to be used for D2R transmission;Fig. 13 illustrates an example of a bundling (mapping) of an indication of one or more specific midamble sequences with the scheduled frequency domain resource to be used for D2R transmission;Fig. 14 illustrates an example of a bundling (mapping) of an indication of one or more specific midamble sequences with modulation and coding scheme (MCS) D2R scheduling information;Fig. 15 illustrates an example of a bundling (mapping) of an indication of one or more specific midamble sequences with TBS D2R scheduling information;Fig. 16 illustrates an example of a bundling (mapping) of an indication of one or more specific midamble sequences with both repetition and TBS D2R scheduling information;Fig. 17 illustrates an example of a bundling (mapping) of an indication of one or more specific midamble sequences with both the scheduled time domain resource and the frequency domain resource to be used for D2R transmission;Fig. 18 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. 19 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. 20 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. 21 is a simplified block schematic illustrating the main components of an intermediate or assisting node that may be used in the communication system of Fig. 1.

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

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

[0045] In the communication system 1 user equipments (UEs) 3 (3-1, 3-2, 3-3) (e.g., mobile telephones and / or other mobile devices including (ambient) IoT devices) can communicate with each other via a corresponding radio access network (RAN) node 5-1 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN node 5-1 comprises a base station operating one or more associated cells. 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).

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

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

[0048] The A-IoT device 3-1 may, for example, be a Type 1, Type 2a, or Type 2b device as described in the introduction. As described in more detail later, depending on the connectivity topology employed, the A-IoT device 3-1 may be configured for uplink (backscatter) communication and / or downlink communication directly with the RAN node 5-1 and / or may be configured for uplink (backscatter) communication and / or downlink communication indirectly via communication (e.g., 'sidelink' or similar communication) with intermediate, or assisting, node 5-2. It will be appreciated that the intermediate, or assisting, node 5-2 may, in effect, be another node of the RAN, a separate RAN or other type of communication node, or another UE 3 that communicates with the A-IoT device 3-1 via an appropriate device-to-device (D2D) interface (e.g., 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0066] For example, each A-IoT device reader (e.g., RAN node 5-1 or intermediate node 5-2) is also configured for transmission of, and the A-IoT devices 3-1 are configured for the reception of, control information and data via a physical R2D channel (PRDCH) for R2D communication that will typically carry any higher-layer payload, and any L1 R2D control information (if defined). For example, each R2D transmission may typically comprise an R2D preamble to indicate a start time of the following PRDCH and possibly and chip length (duration) information. This R2D preamble is followed immediately by the PRDCH transmission, which may, for example, be carrying R2D traffic data and / or control information such as indications of time domain resources and / or frequency domain resources scheduled for D2R transmissions. An R2D postamble may be transmitted immediately after the PRDCH transmission to indicate an end of the PRDCH transmission.

[0067] Similarly, each A-IoT device reader is also configured for reception of, and the A-IoT devices 3-1 are configured for the transmission of, control information and data via a physical D2R channel (PDRCH) for D2R communication that will typically carry any higher-layer payload, and any L1 D2R control information (if defined). For example, each D2R transmission may typically comprise a D2R preamble that is transmitted at the beginning of each D2R transmission, immediately before the PDRCH transmission, to indicate a start time of the PDRCH transmission. A D2R postamble may also be transmitted following the PDRCH transmission to indicate the end of the PDRCH transmission (and possibly provide a final timing correction to the A-IoT device reader).

[0068] Additionally, the PDRCH transmission may include one or more midambles. Such midambles may be embedded within a D2R transmission (e.g., between adjacent data segments of the D2R transmission), and may be provided in the PDRCH transmission for the purposes of performing timing / frequency tracking, channel estimation (e.g., depending on the length of that PDRCH transmission), and / or interference estimation. Additionally, such midambles may also be supported in the PDRCH transmission for the purposes of performing SFO estimation, SFO tracking for a PDRCH transmission with a long transmission duration, and / or timing correction procedures. For example, in the case of timing correction procedures, after SFO estimation based on the D2R preamble, a D2R midamble may be used for improving the SFO estimation.

[0069] The R2D control information may include any appropriate information. For the purposes of D2R scheduling, for example, the R2D control information may include: time domain resources; frequency domain resources; modulation and coding scheme (MCS) like information; chip duration; one or more identifiers (IDs) associated with one or more A-IoT devices; an indication of a number of repetitions; and / or midamble related information.

[0070] The midamble related information may be provided explicitly and / or implicitly and may include, for example, information such as: an indication of the required / requested presence (or absence of) one or more midambles in a D2R transmission; an indication of the number of midambles that are to be included per D2R transmission; an indication of the position / location of the midamble / midambles (e.g., with respect to the preamble, data, and / or postamble in the D2R transmission); an indication of the length of the midamble / midambles; and / or the like. Nevertheless, it will be appreciated that the number of midambles that are to be included per D2R transmission, and the position / location and / or length of those midambles may alternatively be predefined by a preconfigured rule (e.g., the number and position of the midambles may be fixed and the same for every D2R transmission).

[0071] It will be appreciated that, as one or more midambles may be used to perform a number of different procedures such as those highlighted above, the design / format / length of such midambles may need to vary depending on their specific purpose. Accordingly, the midamble related information may also (or alternatively), beneficially include an explicit and / or implicit indication of one or more specific purposes for which the midamble (or plurality of midambles) is intended.

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

[0073] <Topology 1: RAN node <= => IoT device> 　　Fig. 2A illustrates schematically a first possible arrangement of a first connectivity topology (topology 1) that may be used in the communication system 1.

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

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

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

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

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

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

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

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

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

[0083] <Topology 2: RAN node <= => Intermediate node <= => IoT device> 　　Fig. 3A illustrates schematically a first possible arrangement of a second connectivity topology (topology 2) that may be used in the communication system 1.

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

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

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

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

[0088] That is to say, 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 (D2R) signal 20-3 from A-IoT device 3-1 (e.g., on a 'sidelink' or similar interface where the intermediate node 5-2 is a UE 3). Specifically, the uplink communication may comprise a modulated backscattered signal 20-3 from the A-IoT device 3-1 to the intermediate node 5-2 that is transmitted (e.g., on a 'sidelink' or similar interface where the intermediate node 5-2 is a UE 3) in using the unmodulated carrier signal 20-1 from the intermediate node 5-2. This modulated backscattered D2R signal 20-3 (or at least the information encoded in it), once received by the intermediate node 5-2, may be relayed / forwarded (transmitted) to the RAN node 5-1 in an uplink signal as part of the communication 20-4 between the intermediate node 5-2 and the RAN node 5-1. The modulated backscattered D2R signal 20-3 may be processed before being relayed by the intermediate node 5-2 to the RAN node 5-1. For example, the modulated D2R backscattered D2R signal 20-3 may be processed by the intermediate node 5-2 to extract information encoded in the modulated D2R backscattered signal, and to encapsulate the extracted information into an appropriate message format (e.g., in accordance with a corresponding application protocol) for communication with the RAN node 5-1. Alternatively, the modulated backscattered D2R signal may itself be processed by the intermediate node 5-2 (without extracting any data encoded in it) to encapsulate it into an appropriate message format (e.g., in accordance with a corresponding application protocol) for communication with the RAN node 5-1.

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

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

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

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

[0093] Similarly to in Fig. 3a, the intermediate node 5-2 may then send / relay the modulated backscattered D2R signal 20-3 it receives from the A-IoT device 3-1 (or at least the information encoded in it), to the RAN node 5-1 in an uplink signal as part of the communication 20-4 between the intermediate node 5-2 and the RAN node 5-1. The modulated backscattered D2R signal 20-3 may be processed before being relayed by the intermediate node 5-2 to the RAN node 5-1. For example, the modulated backscattered D2R signal 20-3 may be processed by the intermediate node 5-2 to extract information encoded in the modulated backscattered D2R signal, and to encapsulate the extracted information into an appropriate message format (e.g., in accordance with a corresponding application protocol) for communication with the RAN node 5-1. Alternatively, the modulated backscattered D2R signal may itself be processed by the intermediate node 5-2 (without extracting any data encoded in it) to encapsulate it into an appropriate message format (e.g., in accordance with a corresponding application protocol) for communication with the RAN node 5-1.

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

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

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

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

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

[0099] <Topology 3: RAN node <= => Assisting node <= => A-IoT device <= => RAN node> 　　Figs. 4A and 4B illustrate schematically a third connectivity topology (topology 3) of a mobile (cellular or wireless) communication system.

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

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

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

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

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

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

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

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

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

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

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

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

[0112] As described above, D2R transmissions may include one or more specific midambles for one or more specific purposes. Moreover, the downlink transmissions (R2D signals via the PRDCH) may include control information (e.g., for the purposes of D2R scheduling) comprising midamble related information such as indications (explicit or implicit) of: the required / requested presence / absence of the midamble / midambles; the number of midambles that are to be included in a D2R transmission; and the position / location and / or length of such midambles; indication of one or more midamble sequences associated with specific purposes for which the midamble / midambles is intended. It will be appreciated that the specific purposes may not themselves need to be indicated.

[0113] It will also be appreciated that whilst it is described above that information for D2R scheduling may be included in control information sent via R2D signal, it could alternatively be provided by appropriate higher-layer signalling.

[0114] To facilitate this, the communication system 1 is beneficially configured to implement one or more appropriate mechanisms and / or procedures for supporting the flexible and efficient provision of the necessary midamble related information.

[0115] For example, the A-IoT device reader and A-IoT devices 3-1 of the communication system 1 may be mutually configured to support one or more appropriate mechanisms / procedures for the efficient configuration of the A-IoT devices 3-1 to include one or more midambles in their D2R transmissions to the A-IoT device reader.

[0116] Moreover, the A-IoT device reader and A-IoT devices 3-1 of the communication system 1 may be mutually configured to support one or more appropriate mechanisms / procedures specifically for the efficient configuration of the A-IoT devices 3-1 to include one or more specific midambles for one or more different specific purposes (e.g., timing / frequency tracking, channel estimation, and / or interference estimation, and the like) in their D2R transmissions to the A-IoT device reader.

[0117] Moreover, the A-IoT device reader and A-IoT devices 3-1 of the communication system 1 may be mutually configured to support one or more mechanisms / procedures specifically for the efficient configuration of the location / position of one or more midambles in D2R transmissions of the A-IoT device 3-1 when such midambles are to be included in D2R transmissions.

[0118] Moreover, the A-IoT device reader and A-IoT devices 3-1 of the communication system 1 may be mutually configured to support one or more mechanisms / procedures specifically for the efficient configuration of the size / length of one or more midambles in D2R transmissions of the A-IoT device 3-1 when such midambles are to be included in D2R transmissions.

[0119] Various procedures and techniques for implementing the above described mechanisms will now be described, by way of example only, with reference to Figs. 5 to 17.

[0120] <Indicating Inclusion of Specific Midambles for a Specific Purpose> 　　As mentioned above, the A-IoT device reader and A-IoT devices 3-1 of the communication system 1 may be mutually configured to support one or more appropriate mechanisms / procedures for the efficient configuration of the A-IoT devices 3-1 to include one or more specific midambles for one or more different specific purposes (e.g., timing / frequency tracking, channel estimation, and / or interference estimation, and the like) in their D2R transmissions to the A-IoT device reader.

[0121] A number of possible mechanisms / procedures for supporting inclusion of one or more specific midambles for one or more different specific purposes will now be described, by way of example only, with reference to Figs. 5 to 17.

[0122] <Indicating Specific Midamble Sequences Based on Explicit Identifiers> 　　Fig. 5 illustrates a simplified sequence diagram of an example procedure, for indicating the inclusion of at least one midamble for at least one specific purpose in D2R transmissions, that may be implemented in the communication system 1.

[0123] As shown in Fig. 5, the A-IoT device 3-1 is in communication with the A-IoT device reader, which in the example of Fig. 5 is a RAN node 5-1. Nevertheless, it will be appreciated that the A-IoT device reader may be any appropriate device that can transmit to, and receive from, an A-IoT device 3-1 e.g., an intermediate node 5-2.

[0124] (Option A) 　　As shown in option A, both the A-IoT device 3-1 and the A-IoT device reader are preconfigured with a plurality of different possible midamble sequences that may be used. Each midamble sequence of the plurality of midamble sequences may be used for the same, or a different respective specific purpose (it will be appreciated that one or multiple midamble sequences may be used for each specific purpose). For example, both the A-IoT device 3-1 and the A-IoT device reader may be preconfigured with information defining mappings of specific midamble sequences for specific purposes (described later with reference to Figs. 6 and 7). Each specific midamble sequence may be associated with its own unique midamble sequence index, or some other appropriate unique identifier.

[0125] By way of example only, the purposes (whether the same or different) that each midamble sequence may be used for may include: the purpose of performing timing / frequency tracking; the purpose of channel estimation and / or interference estimation; the purpose of SFO estimation; the purpose of SFO tracking for a PDRCH transmission with a long transmission duration; the purpose of timing correction; and / or the like.

[0126] At step S502a, having been preconfigured with the mappings of the specific midamble sequences to specific purposes, the A-IoT device reader may send an R2D transmission to the A-IoT device 3-1. For example, the A-IoT device reader may send an R2D transmission that includes an UL grant, or the like, to provide a resource allocation to the A-IoT device 3-1 for use in a subsequent D2R transmission.

[0127] That R2D transmission may also include an appropriate command message, or the like, to request the A-IoT device 3-1 to send specific information and / or data in a corresponding D2R transmission. For example, the R2D transmission may request the transmission of data to the A-IoT device reader. Alternatively (or additionally), the R2D transmission may request the A-IoT device 3-1 to send an appropriate D2R transmission that may be used by the A-IoT device reader for one or more specific purposes, e.g., to support performance at the A-IoT reader of timing / frequency tracking, channel estimation and / or interference estimation, SFO estimation, SFO tracking for a PDRCH transmission with a long transmission duration, timing correction procedures, and / or the like.

[0128] If the R2D transmission requests the A-IoT device 3-1 to send an appropriate D2R transmission that may be used by the A-IoT device reader to perform one or more specific purposes (or simply for D2R scheduling without a specific purpose), then that R2D transmission may also include appropriate midamble related information. For example, the R2D transmission may include an explicit indication of one or more midamble sequence indices (or other midamble identifiers) to indicate to the A-IoT device 3-1 that the A-IoT device 3-1 is to include the specific midamble / midambles indicated in its D2R transmissions to the A-IoT device reader (e.g., using the resources allocated by the R2D transmission sent at step S502a).

[0129] Alternatively, where only a single midamble sequence is supported regardless of specific purpose the R2D transmission, the R2D transmission may not include one or more midamble sequence indices (or other midamble identifiers). Instead, the A-IoT device reader can indicate the required presence of a midamble sequence and the A-IoT device 3-1 may include the single midamble sequence in response to the R2D transmission sent at step S502a.

[0130] At step S504a, the A-IoT device 3-1 sends, in response to the R2D transmission at step S502a, an appropriate D2R transmission to the A-IoT device reader (e.g., using resources indicated in the R2D transmission) including one or more midambles based on the midamble related information provided by the R2D transmission.

[0131] (Option B) 　　Alternatively, as shown in option B, at step S502b, the A-IoT device reader may configure a plurality of different possible midamble sequences that may be used. Each midamble sequence of the plurality of midamble sequences may be configure for the same, or a different respective specific purpose. For example, A-IoT device reader may send a higher layer configuration message to the A-IoT device 3-1 to configure, at the A-IoT device 3-1, information defining mappings of specific midamble sequences to specific purposes (described later with reference to Figs. 6 and 7). Each specific midamble sequence may be associated with its own unique midamble sequence index, or some other appropriate unique identifier.

[0132] At step S504b, having configured the A-IoT device 3-1 with the mappings of the specific midamble sequences to specific purposes, the A-IoT device reader may send an R2D transmission to the A-IoT device 3-1. For example, the A-IoT device reader may send an R2D transmission that includes an UL grant, or the like, to provide a resource allocation to the A-IoT device 3-1 for use in a subsequent D2R transmission.

[0133] Additionally, where midambles are supported if the R2D transmission requests the A-IoT device 3-1 to send an appropriate D2R transmission that may be used by the A-IoT device reader for one or more specific purposes, e.g., to support performance at the A-IoT reader of timing / frequency tracking, channel estimation, and / or interference estimation, SFO estimation, SFO tracking for a PDRCH transmission with a long transmission duration, timing correction procedures, or the like, that R2D transmission may also include appropriate midamble related information.

[0134] For example, the R2D transmission may include an explicit indication of one or more midamble sequence indices (or other midamble identifiers) to indicate to the A-IoT device 3-1 that the A-IoT device 3-1 is to include the specific midamble / midambles indicated in its D2R transmissions to the A-IoT device reader (e.g., using the resources allocated by the R2D transmission sent at step S504b).

[0135] Alternatively, if the R2D transmission requests the A-IoT device 3-1 to send an appropriate D2R transmission that may be used by the A-IoT device reader to perform one or more specific purposes, then that R2D transmission may not include one or more midamble sequence indices. Instead, the A-IoT device 3-1 may be able to determine an appropriate midamble sequence to include in the D2R transmissions it sends in response to the R2D transmission sent at step S502a based on the configured mapping and the type of command message included in the R2D transmission (i.e., the type of command message effectively conveys the necessary midamble related information).

[0136] At step S506b, the A-IoT device 3-1 sends, in response to the R2D transmission at step S504b, an appropriate D2R transmission to the A-IoT device reader (e.g., using the resources indicated in the R2D transmission) including one or more midambles based on the midamble related information provided by the R2D transmission.

[0137] <Examples of Possible Midamble Mappings> 　　Fig. 6 illustrates an example mapping table including mappings of specific midamble sequences that may be included in D2R transmissions for specific purposes that may be (pre)configured and indicated in the procedure of Fig. 5.

[0138] As shown in the table of Fig. 6, a plurality of midamble sequences #1…#N may each be respectively associated with its own unique midamble sequence index #1…#N. It will be appreciated that each midamble sequence may be respectively associated with one or more specific purposes (e.g., in a one-to-one or one-to-many type relationship), and each specific purpose may be respectively associated with one or more midamble sequences (e.g., in a one-to-one or one-to-many type relationship). More specifically, by way of example only: -　　Midamble sequence index #1 may correspond to a midamble with a midamble sequence #1 that may be used for a first specific purpose (purpose #1). -　　Midamble sequence index #2 may correspond to a midamble with a midamble sequence #2 that may also be used for the first specific purpose (purpose #1). -　　Midamble sequence index #3 may correspond to a midamble with a midamble sequence #3 that may be used for a second specific purpose (purpose #2). -　　Midamble sequence index #4 may correspond to a midamble with a midamble sequence #4 that may also be used for the second specific purpose (purpose #2 - e.g., channel estimation). -　　Midamble sequence index #5 may correspond to a midamble with a midamble sequence #5 that may be used for a combined / joint purpose (purpose #1 and #2). -　　Etc.

[0139] It will be appreciated that the absence of any midamble indication, or a midamble indication indicating midamble sequence index #0, may be used to indicate that no midamble is to be sent.

[0140] It will be appreciated that the mapping shown in Fig. 6 is by way of example only and that the example purposes outlined above are for illustrative purposes only.

[0141] Furthermore, it will be appreciated that the specific purpose associated with each respective midamble sequence may not be explicitly represented in the mapping table configured / provided to the A-IoT device 3-1. For example, the mapping table may typically be configured with multiple midamble sequences and indices only (i.e., the A-IoT device 3-1 may not know the specific purposes for which each midamble sequence can be used). Specifically, the A-IoT device reader may simply indicate the index associated with a specific midamble sequence (or set of midamble sequences) regardless of whether any specific purpose in a mapping table (or the like) configured at the A-IoT device 3-1.

[0142] Similarly, it will be appreciated that the specific purpose (or specific purposes) need not be explicitly provided in any of the other mapping examples described hereafter.

[0143] Fig. 7 illustrates another example mapping table including mappings of specific midamble sequences that may be included in D2R transmissions and used for specific purposes that may be (pre)configured in the procedure of Fig. 5.

[0144] As shown in the table of Fig. 7, a plurality of midamble sets, each set including one or more midamble sequences #1…#N, may be configured. Each midamble set may be associated with its own unique midamble set index #1…#N. It will be appreciated that each midamble sequence may each be respectively associated with one or more specific purposes (e.g., in a one-to-one or one-to-many type relationship), and each specific purpose may be respectively associated with one or more midamble sequences (e.g., in a one-to-one or one-to-many type relationship). Each unique midamble set index #1…#N may also be associated with a number (quantity) of different midambles in that midamble set. More specifically, by way of example only: -　　Midamble set index #1 may correspond to one midamble (number of midambles = 1). That midamble is a midamble with a midamble sequence #1 which may be used for a first specific purpose (purpose #1). -　　Midamble set index #2 may correspond to one midamble (number of midambles = 1). That midamble is a midamble with the midamble sequence #2 which may also be used for the first specific purpose (purpose #1). -　　Midamble set index #3 may correspond to a combination of two midambles (number of midambles = 2). The first midamble is the midamble with the midamble sequence #1 which may be used for a first purpose (purpose #1). The second midamble is a midamble with a midamble sequence #3 which may be used for a second purpose (purpose #2). -　　Midamble set index #4 may correspond to a combination of two midambles (number of midambles = 2). The first midamble is the midamble with the midamble sequence #3 which may be used for the second purpose (purpose #2). The second midamble is a midamble with a midamble sequence #4 which may also be used for the second purpose (purpose #2). -　　Midamble set index #5 may correspond to one midamble (number of midambles = 1). That midamble is a midamble with a midamble sequence #5 which may be used for a third purpose (purpose #3). -　　Etc.

[0145] It will be appreciated that the absence of any midamble indication, or a midamble indication indicating midamble sequence index #0, may be used to indicate that no midamble is to be sent.

[0146] It will be appreciated that the mapping shown in Fig. 7 is by way of example only and that the example purposes outlined above are for illustrative purposes only.

[0147] For example, the 'Number of Midambles' column of the mapping shown in Fig. 7 may be substituted with any other appropriate column to provide any other appropriate information that may be relevant to the provision of midambles in D2R transmissions. It will also be appreciated that the number of midambles may not be included explicitly in the table but may be derivable from other information in the table (e.g., the number of midamble sequences represented in the midamble format column).

[0148] Furthermore, additional columns may be added to the mapping shown in Fig. 7 to provide any other appropriate information that may be relevant to the provision of midambles in D2R transmissions and / or the provision of D2R transmissions in general. For example, columns may be included to provide other forms of control information to e.g., the location of midambles, the length of midambles, time domain resources, frequency domain resources, MCS-like information, chip duration, IDs associated with A-IoT devices 3-1, repetitions, or the like, to allow joint indication of a requirement for midambles with other control information in the R2D transmissions for corresponding D2R transmissions.

[0149] It will be appreciated that in the examples shown in the mappings of Figs. 6 and 7, the midamble sequences may each be of the same length, or alternatively the length between different midamble sequences may vary (or may be adapted by an appropriate indication - described later on).

[0150] It will also be appreciated in the examples shown in the mappings of Figs. 6 and 7, that by providing multiple midamble sequences that can be used for a same purpose greater diversity of midamble implementation is provided in the communication system 1.

[0151] <Indicating Specific Midambles for a Plurality of Different Specific Purposes> 　　Fig. 8 illustrates a simplified sequence diagram of an example use case of the (pre)configured mappings of the specific midamble sequences of Figs. 6 and 7 when indicating the inclusion of midambles in D2R transmissions.

[0152] As shown in Fig. 8, the A-IoT device 3-1 is in communication with the A-IoT device reader, which in the example of Fig. 8 is a RAN node 5-1. Nevertheless, it will be appreciated that the A-IoT device reader may be any appropriate device that can transmit to, and receive from, an A-IoT device 3-1 e.g., an intermediate node 5-2.

[0153] As shown in Fig. 8 at some prior time a (pre)configuration of multiple midamble sequences for different / same purposes may occur between the A-IoT device reader and the A-IoT device 3-1. For example, as described above with reference to Fig. 5, multiple midamble sequences for different / same purposes may be preconfigured at both the A-IoT device reader and A-IoT device 3-1, or alternatively, an upper-layer configuration message (e.g., RRC configuration message, or the like) may be sent by the A-IoT device reader to the A-IoT device 3-1 to configure the A-IoT device 3-1 with the multiple midamble sequences for different / same purposes.

[0154] At step S802, the A-IoT device reader may (optionally) determine that it needs to perform a specific type of procedure that requires specific information from the A-IoT device 3-1. For example, the A-IoT device reader may determine that it needs to perform one or more procedures for a plurality of different specific purposes - for example, a first specific purpose (e.g., purpose #1) and for a second specific purpose (e.g., purpose #2).

[0155] For example, based on a real / actual current situation of the A-IoT device 3-1 (e.g., D2R data size, channel status, SFO, carrier frequency offset (CFO), timing, etc), the A-IoT device reader may require D2R transmissions that can be used by the A-IoT device reader for a combination of different purposes to improve D2R scheduling (e.g., timing / frequency tracking, channel estimation, and / or interference estimation, and the like).

[0156] Examples of purpose #1 and purpose #2 may, for example, include: the purpose of timing / frequency tracking, the purpose of channel estimation and / or interference estimation, the purpose of SFO estimation, the purpose of SFO tracking for a PDRCH transmission with a long transmission duration, the purpose of timing correction procedures, and / or the like. By way of example only, and for the purposes of illustration, timing / frequency tracking may be purpose #1, and channel estimation may be purpose #2. Nevertheless, it will be appreciated that purpose #1 and purpose #2 may be any appropriate purpose for which the A-IoT device reader needs to receive one or more specific midambles from the A-IoT device 3-1.

[0157] Nevertheless, the A-IoT device reader may decide to perform an R2D transmission for some other requirement (e.g., D2R scheduling) that will include an indication of one or more midamble sequences (e.g., which may be associated with a plurality of different purposes) to be included in the D2R transmission.

[0158] At step S804, the A-IoT device reader sends, to the A-IoT device 3-1, an R2D transmission. That R2D transmission may include, by way of example only, an appropriate command message, or the like, to request the A-IoT device 3-1 to send an appropriate D2R transmission for facilitating one or more procedures for a plurality of different specific purposes - for example purpose #1 (e.g., timing / frequency tracking) and purpose #2 (e.g., channel estimation). Nevertheless, the R2D transmission may alternatively be for some other requirement (e.g., D2R scheduling). Additionally, the R2D transmission may include an indication of appropriate resources (e.g., in an UL grant) for use by the A-IoT device 3-1 to send that D2R transmission to the A-IoT device reader. Furthermore, the R2D transmission may also include any other appropriate control information necessary for the A-IoT device 3-1 to send that D2R transmission (e.g., A-IoT device ID, MCS-like information, chip duration, repetition information, and the like).

[0159] The R2D transmission may include one or more midamble sequence indices to indicate to the A-IoT device 3-1 that the A-IoT device reader wishes the A-IoT device 3-1 to include one or more specific midambles (e.g., one or more specific midambles for a plurality of different specific purposes (e.g., purposes #1 and #2)) in its D2R transmissions to the A-IoT device reader (e.g., using the resources allocated by the R2D transmission sent at step S804).

[0160] For example, in the case where the mapping of Fig. 6 is (pre)configured at the A-IoT device 3-1, the R2D transmission may include a first midamble sequence index (e.g., index #1 or index #2) corresponding to a first specific sequence (e.g., specific sequence #1 or specific sequence #2) associated with the first purpose (purpose #1) and a second midamble sequence index (e.g., index #3 or index#4) corresponding to a second specific sequence (e.g., specific sequence #3 or specific sequence #4) associated with the second purpose (purpose #2). Nevertheless, the R2D transmission may include a single midamble sequence index (e.g., index #5) corresponding to a single specific sequence (e.g., specific sequence #5) associated with both purposes (e.g., purposes #1 and #2).

[0161] In the case where the mapping of Fig. 7 is (pre)configured at the A-IoT device 3-1, the R2D transmission may include a single midamble sequence index (e.g., index #3) corresponding to a plurality of specific sequences (e.g., specific sequence #1 and specific sequence #3) associated with the different purposes (e.g., purposes #1 and #2).

[0162] At step S806, the A-IoT device 3-1 sends, in response to the R2D transmission at step S804, an appropriate D2R transmission to the A-IoT device reader (e.g., using resources indicated in the R2D transmission) including one or more midambles, based on the midamble related information provided by the R2D transmission, associated with the plurality of different purposes (e.g., purposes #1 and #2).

[0163] It will be appreciated that where multiple midambles are required because the A-IoT device reader requires a D2R transmission of one or more midamble sequences associated with a plurality purposes, the mapping of Fig. 7 is particularly beneficial as it allows multiple midamble sequences associated with multiple purposes to be indicated in an R2D transmission to the A-IoT device 3-1 via a single index.

[0164] < Plural Midambles for a Single Specific Purpose> 　　In the case where the mapping of Fig. 6 is (pre)configured at the A-IoT device 3-1 and the A-IoT device 3-1 is configured to allow the inclusion of two midambles in its D2R transmissions upon request, in response to receiving an R2D transmission from the A-IoT device reader at step S804 with an appropriate command / information to request a D2R transmission for a single specific purpose (e.g., purpose #1) only (e.g., in a case where the A-IoT device reader is in urgent / severe need of performing a procedure for that specific purpose (e.g., purpose #1)), the D2R transmission sent at step S806 may include two midambles, where both midambles are for that specific purpose (e.g., purpose #1).

[0165] For example, as shown in Fig. 9A, the D2R transmission sent at step S806 may include two midambles adjacent to data (e.g., Midamble #1 and Midamble #2), and both of those midambles may include the same midamble sequence (e.g., midamble sequence #1) which is for the specific purpose (e.g., purpose #1).

[0166] It will be appreciated that the example of Fig. 9A beneficially improves the chances of the A-IoT device reader correctly receiving (and decoding) the midamble for the specific purpose (e.g., purpose #1) in a case where the A-IoT device reader urgently needs a D2R transmission for the specific purpose (e.g., purpose #1).

[0167] In another example, as shown in Fig. 9B, the D2R transmission sent at step S806 may include two midambles adjacent to data (e.g., Midamble #1 and Midamble #2), and each of those midambles may include a different midamble sequence (e.g., midamble sequence #1 and midamble sequence 2) which are for the same specific purpose (e.g., purpose #1).

[0168] It will be appreciated that the example of Fig. 9B beneficially improves diversity as the D2R transmission includes two different midamble sequences, both of which can be used for the same specific purpose (e.g., purpose #1). That in turn may beneficially improve the chances of the A-IoT device reader correctly receiving (and decoding) the midamble for the specific purpose (e.g., purpose #1) in a case where the A-IoT device reader urgently needs a D2R transmission for the specific purpose (e.g., purpose #1).

[0169] <Indicating Midamble Related Information Implicitly Based on Other D2R Information> 　　In the example procedures above of Figs. 5 to 9, both the A-IoT device 3-1 and the A-IoT device reader may be (pre)configured with a mapping of specific midamble sequences (e.g., for specific purposes). Each specific midamble sequence, or set of one or more midamble sequences, may be associated with its own unique identifier (e.g., midamble sequence index / midamble set index).

[0170] Nevertheless, it will be appreciated that other mappings are possible. For example, rather than providing an explicit identifier for each midamble sequence or set of one or more midamble sequences, the indication of the midamble sequences and / or any other midamble related information may, in effect, be bundled with (e.g., implicitly indicated by) other D2R scheduling information.

[0171] For example, in the procedure of Fig. 8, at step S804, the A-IoT device reader may send, to the A-IoT device 3-1, an R2D transmission. That R2D transmission may include, by way of example only, appropriate D2R transmission scheduling information (e.g., time / frequency domain indications, repetition information, MCS-like information, TBS information etc.) which may implicitly indicate to the A-IoT device 3-1 that one or more appropriate midamble sequences need to be included in the D2R transmission (e.g., for the A-IoT device reader to perform one or more specific purposes). At step S806 of Fig. 8, the A-IoT device 3-1 may then send an appropriate D2R transmission to the A-IoT device reader that contains the one or more specific midamble sequences.

[0172] It will be appreciated that where a midamble sequence is implicitly indicated via other D2R scheduling information with which the indication of that midamble sequence is bundled, the bundling of the indication of the midamble sequence with the other D2R transmission scheduling information may be (pre)configured (or predefined) at the A-IoT device reader and A-IoT device 3-1 (e.g., in a manner similar to the (pre)configuration described above with reference to Fig. 5).

[0173] Examples of bundling of the indication of the midamble sequences with D2R transmission scheduling information will now be described with reference to Figs. 10 to 17.

[0174] < Bundling with Repetition Information> 　　Fig. 10 illustrates an example of a bundling (mapping) of an indication of one or more specific midamble sequences with repetition D2R scheduling information.

[0175] As shown in the table of Fig. 10, a plurality of midamble sequences #1…#N may each be configured, and each midamble sequence (or each set of a plurality of sets of midamble sequences) may be respectively mapped to a specific repetition number #1…#N (e.g., the number of repetitions of the data that should be included in the D2R transmission). Each of those midamble sequences (or sets of midamble sequences) may be respectively associated with a specific purpose as described previously. Each repetition number #1…#N may also be associated with a number (quantity) of midambles to be included in the D2R transmissions. More specifically, by way of example only: -　　Repetition number #0 indicated in the R2D transmission (e.g., the data is to be included in the D2R transmission once only) may correspond to no midambles being included. -　　Repetition number #1 indicated in the R2D transmission (e.g., one repetition of the data to be included in the D2R transmission) may correspond to one midamble (number of midambles = 1), where that midamble has a first midamble sequence (e.g., midamble sequence #1) which may be used for a first purpose (e.g., purpose #1). -　　Repetition number #2 indicated in the R2D transmission (e.g., two repetitions of the data to be included in the D2R transmission) may correspond to a combination of two midambles (number of midambles = 2), where the first midamble has a first midamble sequence (e.g., midamble sequence #1) which may be used for a first purpose (e.g., purpose #1) and the second midamble has a second midamble sequence (e.g., midamble sequence #3) which may be used for a second purpose (purpose #2). -　　Etc.

[0176] It will be appreciated that the bundling (mapping) shown in Fig. 10 is by way of example only and that the example purposes outlined above are for illustrative purposes only.

[0177] < Bundling with Line Code Scheme Information> 　　Fig. 11 illustrates an example of a bundling (mapping) of an indication of one or more specific midamble sequences to the line coding scheme D2R scheduling information.

[0178] As shown in the table of Fig. 11, a plurality of midamble sequences #1…#N may each be configured, and each midamble sequence (or each set of a plurality of sets of midamble sequences) may be respectively mapped to a specific line coding scheme to be used for encoding the D2R transmission. Each of those midamble sequences(or each set of a plurality of sets of midamble sequences) may be respectively associated with a specific purpose as described previously. Each line coding scheme may also be associated with a number (quantity) of midambles to be included in the D2R transmissions. More specifically, by way of example only: -　　The absence of any line coding scheme indicated in the R2D transmission may correspond to no midambles being included. -　　Manchester coding scheme indicated in the R2D transmission may likewise correspond to no midambles being included. -　　Miller coding scheme indicated in the R2D transmission may correspond to one midamble (number of midambles = 1) where the midamble has a first midamble sequence (e.g., midamble sequence #1) which may be used for a first purpose (e.g., purpose #1). -　　Flexible Macro-block Ordering (FMO) scheme indicated in the R2D transmission may correspond to one midamble (number of midambles = 1) where the midamble has the first midamble sequence (e.g., midamble sequence #1) which may be used for the first purpose (e.g., purpose #1). -　　Etc.

[0179] It will be appreciated that the bundling (mapping) shown in Fig. 11 is by way of example only and that the example purposes outlined above are for illustrative purposes only. For example, whilst in the table of Fig. 11 the Miller and FMO coding scheme are jointly bundled in a single entry, each coding scheme may alternatively be given their own entry in the bundling (mapping) table.

[0180] <Bundling with a Time Domain Resource Indication> 　　Fig. 12 illustrates an example of a bundling (mapping) of an indication of one or more specific midamble sequences with the scheduled time domain resource to be used for D2R transmission.

[0181] As shown in the table of Fig. 12, a plurality of midamble sequences #1…#N may each be configured, and each midamble sequence (or each set of a plurality of sets of midamble sequences) may be respectively mapped to a specific time domain resource group to be used for transmission of the D2R transmission. The time domain resource groups may be defined in terms of chips, symbols, slot, minimum time unit for resource allocation, or some other appropriate granularity.

[0182] Each of those midamble sequences (or each set of a plurality of sets of midamble sequences) may be respectively associated with a specific purpose. Each time domain resource may also be associated with a number (quantity) of midambles to be included in the D2R transmissions. More specifically, by way of example only: -　　A continuous set of time domain resource within a time domain resource group T1 may correspond to no midambles being included. -　　A continuous set of time domain resources comprising a time domain resource group T1 and a time domain resource group T2 may correspond to one midamble (number of midambles = 1), where that midamble has a first midamble sequence (e.g., midamble sequence #1) which may be used for a first purpose (e.g., purpose #1). In this case, by way of example only, the midamble may be sent at the end of the time domain resource group T1 as shown in Fig. 12. -　　A discontinuous set of time domain resources comprising a first set of time domain resources and a second set of time domain resources, and the two sets of time domain resources are not contiguous with each other may correspond to one midamble (number of midambles = 1). Both the first set of time domain resources and the second set of time domain resource may however both be contained within a single time domain resource group T1. That midamble has a third midamble sequence (e.g., midamble sequence #3) which may be used for a second purpose (e.g., purpose #2). In this case, by way of example only, the midamble may be sent at the start of the second set of time domain resources in the time domain resource group T1 as shown in Fig. 12. -　　A discontinuous set of time domain resources comprising a first set of time domain resources and a second set of time domain resources, and the two sets of time domain resources are not contiguous with each other may correspond to two midambles (number of midambles = 2). Both the first set of time domain resources and the second set of time domain resource may however both be contained within a single time domain resource group T1. Each of those midambles have a third midamble sequence (e.g., midamble sequence #3) which may be used for a second purpose (e.g., purpose #2 -) and a fourth midamble sequence (midamble sequence #4) which may be used for the second purpose, respectively. -　　Etc.

[0183] It will be appreciated in the above example with reference to Fig. 12 that while the first and second sets of time domain resources may not be contiguous with one another, the resources within the first and second sets of time domain resources respectively may be contiguous.

[0184] It will be appreciated that the bundling (mapping) shown in Fig. 12 is by way of example only and that the example purposes outlined above are for illustrative purposes only.

[0185] < Bundling with a Frequency Domain Resource Indication> 　　Fig. 13 illustrates an example of a bundling (mapping) of an indication of one or more specific midamble sequences with the scheduled frequency domain resource to be used for D2R transmission.

[0186] As shown in the table of Fig. 13, a plurality of midamble sequences #1…#N may each be configured, and each midamble sequence (or each set of a plurality of sets of midamble sequences)may be respectively mapped to a specific frequency domain resource group to be used for transmission of the D2R transmission. The frequency domain resource groups may be defined in terms of physical resource blocks (PRBs), a range of frequencies in Hz, or a minimum frequency unit for resource allocation.

[0187] Each of those midamble sequences (or each set of a plurality of sets of midamble sequences) may be respectively associated with a specific purpose as described previously. Each frequency domain resource may also be associated with a number (quantity) of midambles to be included in the D2R transmissions. More specifically, by way of example only: -　　A continuous set of frequency domain resources within a frequency domain resource group F1 may correspond to no midambles being included. -　　A continuous set of frequency domain resources within a frequency domain resource group F2 may correspond to one midamble (number of midambles = 1). That midamble has a first midamble sequence (e.g., midamble sequence #1) which may be used for a first purpose (e.g., purpose #1). In this case, by way of example only, the midamble may be sent at the end of the frequency domain resource group F1 as shown in Fig. 13. -　　A discontinuous set of frequency domain resources comprising a first set of frequency domain resources and a second set of frequency domain resources, and the two sets of frequency domain resources are not contiguous with each other may correspond to one midamble (number of midambles = 1). Both the first set of time domain resources and the second set of time domain resource may however both be contained within a single frequency domain resource group F1. That midamble has a third midamble sequence (midamble sequence #3) which may be used for a second purpose (e.g., purpose #2). In this case, by way of example only, the midamble may be sent on a frequency in between the first and second set of frequency domain resources in the time domain resource group F1 as shown in Fig. 13. -　　Etc.

[0188] It will be appreciated in the above example with reference to Fig. 13 that while the first and second sets of frequency domain resources may not be contiguous with one another, the resources within the first and second sets of frequency domain resources respectively may be contiguous.

[0189] It will be appreciated that the bundling (mapping) shown in Fig. 13 is by way of example only and that the example purposes outlined above are for illustrative purposes only.

[0190] < Bundling with an MCS-like Information> 　　Fig. 14 illustrates an example of a bundling (mapping) of an indication of one or more specific midamble sequences with the modulation and coding scheme (MCS) to be used for D2R transmission.

[0191] As shown in the table of Fig. 14, a plurality of midamble sequences #1…#N may each be configured, and each midamble sequence (or each set of a plurality of sets of midamble sequences) may be mapped to a specific MCS to be used for transmission of the D2R transmission.

[0192] Each of those midamble sequences (or each set of a plurality of sets of midamble sequences) may be respectively associated with a specific purpose previously described. Each frequency domain resource may also be associated with a number (quantity) of midambles to be included. More specifically, by way of example only: -　　A first MCS where MCS ID = 0 (e.g., Binary Phase Shift Keying (BPSK)) may correspond to no midambles being included. -　　A second MCS where MCS ID = 1 (e.g., On-Off Keying (OOK)) may correspond to one midamble (number of midambles = 1). That midamble is has a first midamble sequence (e.g., midamble sequence #1) which may be used for a first purpose (e.g., purpose #1). -　　A third MCS where MCS ID = 2 (e.g., Minimum Shift Keying (MSK)) may correspond to two midambles (number of midambles = 2). Those midambles respectively a first midamble sequence (e.g., midamble sequence #1) which may be used for a first purpose (e.g., purpose #1) and a second midamble sequence (e.g., midamble sequence #2) which may also be used for the first purpose (e.g., purpose #1). -　　Etc.

[0193] It will be appreciated that the bundling (mapping) shown in Fig. 14 is by way of example only and that the example purposes outlined above are for illustrative purposes only.

[0194] <Bundling with a TBS Indication> 　　Fig. 15 illustrates an example of a bundling (mapping) of an indication of one or more specific midamble sequences with the TBS to be used for D2R transmission.

[0195] As shown in the table of Fig. 15, a plurality of midamble sequences #1…#N may each be configured, and each midamble sequence (or each set of a plurality of sets of midamble sequences)may be mapped to a specific TBS to be used for transmission of the D2R transmission.

[0196] Each of those midamble sequences may be respectively associated with a specific purpose as previously described. Each frequency domain resource may also be associated with a number (quantity) of midambles. More specifically, by way of example only: -　　A TBS which has a size less than a specific TBS (e.g., TBS1) may correspond to no midambles being included. -　　A TBS with a size TBS1 and a TBS with a size TBS2 may correspond to one midamble (number of midambles = 1). That midamble has a first midamble sequence (midamble sequence #1) which may be used for a first purpose (e.g., purpose #1). -　　A TBS with a size TBS2 and a TBS with a size TBS3 may correspond to two midambles (number of midambles = 2). Those midambles respectively have a first midamble sequence (e.g., midamble sequence #1) which may be used for a first purpose (e.g., purpose #1) and a second midamble sequence (e.g., midamble sequence #2) which may also be used for the first purpose (e.g., purpose #1). -　　Etc.

[0197] It will be appreciated that the bundling (mapping) shown in Fig. 15 is by way of example only and that the example purposes outlined above are for illustrative purposes only.

[0198] <Bundling Based on a Combination of Information (Repetition and TBS Information)> 　　Fig. 16 illustrates an example of a bundling (mapping) of one or more specific midamble sequences with both a repetition and a TBS to be used for D2R transmission.

[0199] As shown in the table of Fig. 16, a plurality of midamble sequences #1…#N may each be configured, and each midamble sequence (or each set of a plurality of sets of midamble sequences)may be respectively mapped to a specific repetition and TBS to be used for transmission of the D2R transmission.

[0200] Each of those midamble sequences (or each set of a plurality of sets of midamble sequences) may be respectively associated with a specific purpose as previously described. Each combination of repetitions and TBS may also be associated with a number (quantity) of midambles to be included. More specifically, by way of example only: -　　A combination of a TBS which has a size less than a specific TBS (e.g., TBS1) and a repetition number #0 indicated in the R2D transmission (e.g., the data is to be included in the D2R transmission once only) may correspond to no midambles being included. -　　A combination of a TBS with a size TBS1 (or a size TBS2) and a repetition number #1 indicated in the R2D transmission (e.g., a repetition of data is to be included in the D2R transmission) may correspond to one midamble (number of midambles = 1). That midamble has a first midamble sequence (e.g., midamble sequence #1) which may be used for a first purpose (e.g., purpose #1). -　　A combination of a TBS with a size TB1 (or a size TB2) and a repetition number #1 indicated in the R2D transmission (e.g., a repetition of data is to be included in the D2R transmission) may correspond to three midambles (number of midambles = 3). The first midamble has a first midamble sequence (midamble sequence #1) which may be used for a first purpose (e.g., purpose #1), the second midamble has a second midamble sequence (midamble sequence #2) which may also be used for the first purpose (e.g., purpose #1), and the third midamble has a third midamble sequence (e.g., midamble sequence #3) which may be used for a second purpose (e.g., purpose #2). As shown in Fig. 16, by way of example only, in the case a TBS size TSB1 and a repetition number = 3, the first midamble may be located at the end of the TBS of size TBS1 and the second and third midambles may be located as appropriate repetition points (option #1). Alternatively, as also shown in Fig. 16, by way of example only, in the case a TBS size TSB1 and a repetition number = 3, the first midamble may be located the first midamble may be located at the middle of the TBS and the second and third midambles may be located as appropriate repetition points (option #2). -　　A combination of a TBS with a size TB1 (or a size TB2) and a repetition number #2 indicated in the R2D transmission (e.g., a repetition of data is to be included in the D2R transmission) may correspond to five midambles (number of midambles = 5). The first midamble has a first midamble sequence (midamble sequence #1) which may be used for a first purpose (e.g., purpose #1), the second midamble has a second midamble sequence (e.g., midamble sequence #2) which may also be used for the first purpose (e.g., purpose #1), the third midamble has a the midamble sequence (e.g., midamble sequence #1) which may also be used for the first purpose (e.g., purpose #1), the fourth midamble has a third midamble sequence (e.g., midamble sequence #3) which may be used for a second purpose (e.g., purpose #2), and the fifth midamble has the first midamble sequence (e.g., midamble sequence #1) which may also be used for the first purpose (e.g., purpose #1). -　　Etc.

[0201] It will be appreciated that the bundling (mapping) shown in Fig. 16 is by way of example only and that the example purposes outlined above are for illustrative purposes only.

[0202] <Bundling Based on a Combination of Information (Time Domain Resource and Frequency Domain Resource Information)> 　　Fig. 17 illustrates an example of a bundling (mapping) of an indication of one or more specific midamble sequences with both the scheduled time domain resource and the frequency domain resource to be used for D2R transmission.

[0203] As shown in the table of Fig. 17, a plurality of midamble sequences #1…#N may each be configured, and each midamble sequence (or each set of a plurality of sets of midamble sequences)may be respectively mapped to a combination of a specific time domain resource group and a frequency domain group to be used for transmission of the D2R transmission. The time domain resource groups may be defined in terms of chips, symbols, slot, minimum time unit for resource allocation, or some other appropriate granularity. Furthermore, the frequency domain resource groups may be defined in terms of physical resource blocks (PRBs), a range of frequencies in Hz, or a minimum frequency unit for resource allocation.

[0204] Each of those midamble sequences(or each set of a plurality of sets of midamble sequences) may be respectively associated with a specific purpose described previously. Each combination of a specific time domain resource group and a frequency domain group may also be associated with a number (quantity) of midambles to be included. More specifically, by way of example only: -　　A continuous set of time and frequency domain resources that have a time smaller than the times within time domain resource group T1 and that have a frequency smaller than the frequencies within frequency domain resource group F1 may correspond to no midambles being included. -　　A continuous set of time domain resources that have a time smaller than the times within time domain resource group T1 and which have a frequency that is within with frequency domain group F1 and / or F2 may correspond to one midamble (number of midambles = 1). That midamble is a first midamble sequence (e.g., midamble sequence #1) which may be used for a first purpose (e.g., purpose #1). -　　A continuous set of frequency domain resources that have a frequency smaller than the frequencies within frequency domain resource group F1 and which have a time that is within with time domain group T1 and / or T2 may correspond to one midamble (number of midambles = 1). That midamble has a second midamble sequence (e.g., midamble sequence #2) which may be used for the first purpose (e.g., purpose #1). As shown in Fig. 17, by way of example only, the location of the midamble in this case may be at a resource with a time point T1, or at the middle of the resource with the time point T1. -　　A continuous set of time domain resources that have a time that is within with time domain group T1 and / or T2 and which have a frequency that is within with frequency domain group F1 and / or F2 may correspond to two midambles (number of midambles = 2). The first midamble has a first midamble sequence (midamble sequence #1) which may be used for a first purpose (e.g., purpose #1) and the second midamble has a second midamble sequence (midamble sequence #2) which may also be used for the first purpose (e.g., purpose #1). As shown in Fig. 17, by way of example only, the location of the midamble in this case may be at a resource with a time point T2 and a frequency point F1, or at the middle of the resource with the time point T2 and frequency point F1. -　　A discontinuous set of resources with N pieces of time domain and / or frequency domain resources may correspond to N midambles (e.g., one midamble per piece of time and / or frequency resource). In this scenario each midamble associated with each piece of time domain and / or frequency domain resource may have its own respective midamble sequence (e.g., midamble sequence #1….#N), and each different midamble sequence may be used for a specific purpose as previously described. As shown in Fig. 17, by way of example only, the location of each midamble in this case may be within the piece of time and / or frequence domain resource for which the that respective midamble is associated. -　　Etc.

[0205] It will be appreciated that the bundling (mapping) shown in Fig. 17 is by way of example only and that the example purposes outlined above are for illustrative purposes only.

[0206] <Other Bundling Possibilities> 　　It will be appreciated that the single bundling and multi-bundling examples of midambles with one or more other pieces of D2R scheduling information is by way of example only. An ordinary person skilled in the art will appreciate that the examples described above can be adapted and / or extended to provide different bundling than the ones explicitly described. For example, other multi-bundling examples of midambles with one or more other pieces of D2R scheduling information could include: -　　The bundling of midambles with a combination of MCS-like information and repetitions. -　　The bundling of midambles with a combination of TBS information and MCS-like information. -　　The bundling of midambles with a combination of TBS information and chip duration. -　　Etc.

[0207] Additionally, whilst the multi-bundling examples described herein involve the combination of two different pieces of D2R scheduling information, it will be appreciated that the multi-bundling may involve the combination with any number of different pieces of D2R scheduling information. For example, midambles may be bundled with a combination of three or more pieces of D2R scheduling information (e.g., a combination of TBS information, resource allocation information, and repetition information).

[0208] It will be appreciated that in all of the example mappings involving bundling described above if only a single fixed midamble sequence (e.g., midamble sequence #1) is supported, then the column 'Midamble Format' in the mapping tables can be omitted.

[0209] <Indicating the Location of Midambles in D2R Transmissions in A-IoT> 　　In the procedures for indicating the inclusion of midambles in D2R Transmissions as described above with reference to Figs. 5 to 17, it will be appreciated that as well as an A-IoT device reader being able to indicate to the A-IoT device 3-1 that it should include one or more midambles in its D2R transmissions, it may also be beneficial for the A-IoT device reader to be able to indicate the location at which those midambles should be included in the D2R transmissions; for example, to enable the A-IoT device reader to identify the midambles in the D2R transmission reliably.

[0210] There now follows some possible examples of how the locations of such midambles may be indicated by the A-IoT device reader to the A-IoT device 3-1.

[0211] (Case #1) 　　In one example, which is applicable to the procedures of Figs. 5 to 17, the location (or locations) in D2R transmissions at which the A-IoT device 3-1 includes midambles may be (pre)configured or predefined based on a fixed rule.

[0212] For example, the location (or locations) in D2R transmissions at which the A-IoT device 3-1 includes midambles may be based on an appropriate predefined boundary - for example, at a predefined threshold location in the D2R transmission (e.g., at the end of a given transport block (TB) / chip, or at a boundary between TBs / chips - which may be represented by a corresponding TBS (TBS1, TBS2, or the like) / chip length (chip length #1, chip length #2, or the like).

[0213] In another example, which is applicable to the procedures of Figs. 5 to 17, the location (or locations) in D2R transmissions at which the A-IoT device 3-1 includes midambles may be based on a ratio / fraction of a TBS or number of chips. By way of example only, the midambles may always be inserted at a position at half, a third, or other fraction of the TBS of scheduled D2R transmission within each repetition or number of chips.

[0214] It will be appreciated that different rules may be applied at different times and the specific rule to be applied may, itself, be indicated to the A-IoT device (e.g., as a one-bit indication for indicating which of the above options is applicable).

[0215] (Case #2) 　　In another example, which is applicable to the procedures of Figs. 5 to 17, the location (or locations) in D2R transmissions at which the A-IoT device 3-1 includes midambles may be dynamic i.e., it can change / vary from D2R transmission to D2R transmission. In this scenario the time and frequency domain resources that the A-IoT device 3-1 is scheduled to use for the midamble in the D2R transmission may be indicated to the A-IoT device 3-1 by the A-IoT device reader in an R2D transmission.

[0216] It will be appreciated that in both Case #1 and Case #2 the indications (e.g., one-bit indication in Case #1 and / or indication of time and frequency resources in Case #2) may be combined with other midamble related information that may be provided to the A-IoT device 3-1 as described above.

[0217] <Indicating the Length of Midambles in D2R Transmissions in A-IoT> 　　In the procedures for indicating the inclusion of midambles in D2R Transmissions as described above with reference to Figs. 5 to 17, as well as the procedure described above for indicating the location of midambles in D2R transmissions, it will be appreciated it may also be beneficially for the A-IoT device reader to be able to indicate a length of those midambles that are to be included in the D2R transmissions. For example, whilst the length of midamble sequences may typically be predefined and have a fixed length, it may be beneficial, in some cases, to allow for an extension / reduction of predefined midamble sequence length to take account of a D2R transmission status. The ability to indicate an additional midamble length therefore would provide flexibility to the midamble sequences that can be achieved based on limited predefined midamble sequences.

[0218] There now follows some possible examples of how the length of such midambles may be extended / reduced which are applicable to the procedures of Figs. 5 to 17.

[0219] (Option #1 - Multi-Bit Index-based Indication) 　　One option to extend / reduce the length of the predefined midamble sequence (e.g., a midamble sequence from the mappings discussed above) may be to provide a list of potential / candidate lengths of midamble sequences e.g. {6, 8, 10, 15, 20, 24} to the A-IoT device 3-1 which may be applied to predefined midamble sequences to extend / reduce the length of those midamble sequences.

[0220] For example, the A-IoT device reader may include an appropriate indication (e.g., the index {1, 2, 3, 4, 5, 6} respectively corresponding to one of the potential / candidate lengths {6, 8, 10, 15, 20, 24} of midamble sequences) in an R2D transmission to the A-IoT device 3-1, and upon receipt, the A-IoT device 3-1 may apply that length of midamble sequence to a preconfigured midamble sequence. By way of example only, the A-IoT device reader may send an indication of index = 5 to the A-IoT device 3-1 and the A-IoT device may apply the fifth midamble sequence length in the list (e.g., length = 20) to a preconfigured midamble sequence. It will be appreciated that in this scenario an indication of an index = 0 does not correspond to a specific extended / reduced length. Hence, an index = 0 may be sent to the A-IoT device 3-1 when no change of midamble length is to be applied in respect of a preconfigured midamble sequence (e.g., index = 0 may be the default indication in R2D transmissions).

[0221] Alternatively, by way of example only, the index {0, 1, 2, 3, 4, 5} may respectively correspond to one of the potential / candidate lengths {6, 8, 10, 15, 20, 24} of midamble sequences. Thus, in this case the A-IoT device reader may send an indication of index = 4 to the A-IoT device 3-1 and the A-IoT device may apply the fifth midamble sequence length in the list (e.g., length = 20) to a preconfigured midamble sequence. It will be appreciated that in this scenario an indication of an index = 0 corresponds to the first midamble sequence length in the list (e.g., length = 6). Hence, in this scenario, when no additional midamble length is to be added to a preconfigured midamble sequence the index may simply be omitted from the R2D transmissions (e.g., the field is left blank).

[0222] It will be appreciated that in the case where more than one midamble sequence is to be included in a D2R transmission, an appropriate indication (e.g., an index corresponding to one of the potential / candidate lengths of midamble sequences) in an R2D transmission to the A-IoT device 3-1 may be included for each separate midamble sequence to be included in the D2R transmission.

[0223] It will be appreciated that for more than one midamble sequence in a D2R transmission, a common index corresponding to one of the potential / candidate lengths of midamble sequences may be applied to all midamble sequences to be included in the D2R transmission. For example, a single common index (e.g., length#0) may be used to represent a common length to be applied in respect of all the midamble sequences to be sent in the D2R transmission (e.g., a single length #0 may be indicated which is applicable to each of a plurality (e.g. three) of midamble sequences).

[0224] Alternatively, for more than one midamble sequence in a D2R transmission, a respective index corresponding to each of a plurality of potential / candidate lengths of midamble sequences may be provided and an appropriate one of the lengths may be applied to each respective midamble sequence based on a specified / predefined rule. For example, assuming that there are three midambles with midamble sequences #1 to #3 to be included in a D2R transmission a respective index may be provided corresponding to each of the three candidate lengths #1 to #3, then the first candidate length #1 may be applied for the midamble sequence #1 of the first midamble, the second candidate length #2 may be applied for the midamble sequence #2 of the second midamble, and the third candidate length #3 may be applied for the midamble sequence #3.

[0225] In another example, the number of candidate lengths indicated may be equal to the total number of different midamble sequences of midambles to be included in the D2R transmission, rather than being equal to the number of midamble sequences as in the example above. In this case, assuming there are three midambles the first two having midamble sequence #1, and the last having midamble sequence #2, then two candidate lengths with length #1 and #2 can be indicated, and length #1 can be applied to the first two midambles having midamble sequence #1, and length #2 can be applied to the third midamble having midamble sequence #2.

[0226] Irrespective of the manner in which an index corresponding to one (or more) potential / candidate lengths of midamble sequences are indicated to the A-IoT device 3-1 (e.g., as described above), upon receipt of such an index, if the predefined midamble sequence length of a midamble to be included in a D2R transmission is smaller than the indicated candidate length then the predefined midamble sequence may be extended by use of repetition or padding (e.g., with 0s, 1s or a specific pattern of 0s and 1s) at the start and / or middle, and / or end of the predefined midamble sequence. Alternatively, if the predefined midamble sequence length of a midamble to be included in a D2R transmission is larger than the indicated candidate length then the predefined midamble sequence may be reduced by deleting / removing some of the start and / or middle, and / or end of the predefined midamble sequence.

[0227] For example, if the inclusion of three midambles with midamble sequences #1 to #3 respectively is indicated to the A-IoT device 3-1 via an R2D transmission, and the sequence length of midamble sequences #1 to #3 are 5, 6, and 7 respectively, but the indicated index (or indices) corresponding to candidate lengths for those midambles are 8, 9, and 10 respectively, then midamble sequence #1 for the first midamble will be extended to a length 8 by use of appropriate repetitions / padding, midamble sequence #2 for the second midamble will be extended to a length 9 by use of appropriate repetitions / padding, and the third midamble sequence #3 for the third midamble will be extended to a length 10 by use of appropriate repetitions / padding.

[0228] In another example, if the inclusion of three midambles with midamble sequences #1 to #3 respectively is indicated to the A-IoT device 3-1 via an R2D transmission, and the sequence length of midamble sequences #1 to #3 are 8, 9, and 10 respectively, but the indicated index (or indices) corresponding to candidate lengths for those midambles are 5, 6, and 7 respectively, then a portion of the midamble sequence #1 will be deleted to reduce it to a length 5, a portion of the midamble sequence #2 for the second midamble will be deleted to reduce it to a length 9, and a portion of the third midamble sequence #3 for the third midamble will be deleted to reduce it to a length 10.

[0229] (Option #1 -One-Bit Index-based Indication) 　　It will be appreciated that the multi-bit index-based indication described above may be adapted to a one-bit index-based indication in a case where the list of potential / candidate lengths of midamble sequences comprises only two potential / candidate lengths e.g. {6, 20} that can be applied to predefined midamble sequences to extend / reduce those midamble sequences.

[0230] For example, if the inclusion of three midambles with midamble sequences #1 to #3 respectively is indicated to the A-IoT device 3-1 via an R2D transmission, and the sequence length of midamble sequences #1 to #3 are 5, 6, and 7 respectively, then to apply a first one of the two potential / candidate lengths (e.g. length 6) to the predefined midamble sequences #1 to #3, an index (or indices) with a value '0' may be indicated to the A-IoT device 3-1, while to apply a second one of the two potential / candidate lengths (e.g. length 20) to the predefined midamble sequences #1 to #3 an index (or indices) with a value '1' may be indicated to the A-IoT device 3-1. It will be appreciated that in this case, where no candidate midamble length is to be applied to an indicated predefined midamble sequence (e.g., midamble sequence #1, #2, #3) the index (or indices) used to indicate the candidate midamble lengths for those midamble sequences may be omitted from the R2D transmission.

[0231] It will also be appreciated that the one-bit index-based indication described above may also cover a case where the list of potential / candidate lengths of midamble sequences comprises only one potential / candidate length e.g. {20} that can be applied to predefined midamble sequences to extend / reduce those midamble sequences. In this case, if the inclusion of three midambles with midamble sequences #1 to #3 respectively is indicated to the A-IoT device 3-1 via an R2D transmission, and the sequence length of midamble sequences #1 to #3 are 5, 6, and 7 respectively, then to apply the potential / candidate length (e.g. length 20) to the predefined midamble sequences #1 to #3, an index (or indices) with a value '1' may be indicated to the A-IoT device 3-1. It will be appreciated that in this case, where no candidate midamble length is to be applied to an indicated predefined midamble sequence (e.g., midamble sequence #1, #2, #3) the index (or indices) used to indicate the candidate midamble lengths for those midamble sequences may be set to '0'. Which may be the default setting for that index (indices) in the R2D transmission.

[0232] It will be appreciated that the manner in which the indices for the potential / candidate lengths of midamble sequences indicated (e.g., as individual indices per midamble sequence, as a common index for all midamble sequences, as individual indices per different midamble sequence) as described above for the multi-bit index-based indication case, apply equally to the one-bit index-based Indication case.

[0233] It will also be appreciated that the manner in which the potential / candidate lengths of midamble sequences are applied to predefined midamble sequences to extend or reduce the length of those predefined midamble as described above for the multi-bit index-based indication case, apply equally to the one-bit index-based indication case.

[0234] < Option #2 - Absolute Indication> 　　Another option to indicate the length of the predefined midamble sequence (e.g., a midamble sequence such as those discussed above) may be to provide an additional appropriate indication in the R2D transmission for each midamble to indicate an exact / real length that should be applied to a predefined length of the midamble sequence to be used for each respective midamble. Thus, when indicating to the A-IoT device 3-1 that it should include one or more midambles in its D2R transmissions, the A-IoT device reader may also, for each midamble, explicitly indicate an additional length for application to the one or more midambles with the indication to include the one or more midamble.

[0235] By way of example only, in the case where an A-IoT device reader indicates, via an R2D transmission, to an A-IoT device 3-1 that it should include a midamble in its D2R transmissions with a specific midamble sequence, the A-IoT device reader may additionally include a 4-bit indication that indicates a specific length that should be applied to the midambles that the A-IoT device reader has indicated that the A-IoT device should include in its D2R transmissions. For example, indications of '0001' to '1111' may represent lengths of '1' to '15', where an indication of '0000' may represent no change to the midamble length. Alternatively, indications of '0000' to '1111' may represent lengths of '1' to '16', with the 4-bit indication being omitted from the R2D transmission if there is to be no change to the midamble length.

[0236] It will be appreciated that the manner in which the absolute values for the potential / candidate lengths of midamble sequences are indicated may be similar to that described above for the multi-bit index-based indication case. For example, a respective individual absolute value per midamble sequence, or common absolute value for all midamble sequences, may be indicated.

[0237] It will also be appreciated that the manner in which the potential / candidate lengths of midamble sequences are applied to predefined midamble sequences to extend or reduce the length of those predefined midamble as described above for the multi-bit index-based indication case, apply equally to the absolute indication case.

[0238] (Option #3 - Incremental Increase / Reduction Indication) 　　Yet another option to extend / reduce the length of the predefined midamble sequence (e.g., a midamble sequence from the mappings discussed above) may be to provide an appropriate incremental increase / reduction indication in the R2D transmission for each midamble to indicate a length adjustment compared to a predefined length of the midamble sequence to be used for each respective midamble. Thus, when indicating to the A-IoT device 3-1 that it should include one or more midambles in its D2R transmissions, the A-IoT device reader may also, for each midamble, explicitly indicate a length adjustment for application to the one or more midambles with the indication to include the one or more midamble.

[0239] By way of example only, in the case where an A-IoT device reader indicates, via an R2D transmission, to an A-IoT device 3-1 that it should include a midamble in its D2R transmissions with a specific predefined midamble sequence (e.g., a predefined midamble sequence #1 with a length of 8), the A-IoT device reader may also include an incremental increase / reduction indication to indicate a specific incremental increase (or incremental reduction) in length (e.g. incremental increase of 4) that should be applied to the midambles that the A-IoT device reader has indicated that the A-IoT device should include in its D2R transmissions. The resultant midamble sequence length may then be increased by 4 (e.g., to 12 => 8 + 4 = 12) or decreased by 4 (e.g., to 4 => 8 - 4 = 4).

[0240] It will be appreciated that in this scenario where a length adjustment for application to one or more midambles is provided as described above, an additional one-bit indication may be required to indicate whether the length adjustment is to added to a predefined midamble sequence or subtracted from a predefined midamble sequence. For example, an additional one-bit indication may be provided in the R2D transmission along with the incremental increase / reduction indication, and when that one-bit indicate equals '1' the length adjustment is added to the predefined midamble sequence length, and when that one-bit indication equals '0' the length adjustment is subtracted from the predefined midamble sequence length (or vice versa).

[0241] It will be appreciated that the manner in which the indices for the potential / candidate lengths of midamble sequences indicated (e.g., as individual indices per midamble sequence, as a common index for all midamble sequences, as individual indices per different midamble sequence) as described above for the multi-bit index-based indication case, apply equally to the incremental increase / reduction indication case.

[0242] It will also be appreciated that the incremental increase / reduction technique described above can also be adapted to extend or reduce the length of the predefined midamble / midambles based on the multi-bit / single bit index-based indication case, or the absolute indication case, described above. For example, if the A-IoT device reader sends an indication of a specific index (e.g., index = 4) to the A-IoT device 3-1 representing a particular length (e.g., length = 15) then the final length of a midamble sequence of a predefined length (e.g. length=8) - possibly with a single-bit 'increase' indication if necessary - would be the sum of those lengths (e.g., 8+15=23). Similarly, if the A-IoT device reader sends a 4-bit indication of an absolute value (e.g., '1111') to the A-IoT device 3-1 representing a particular absolute value of length (e.g., length = 15) - possibly with a single-bit 'increase' indication if necessary - then the final length of a midamble sequence of a predefined length (e.g. length=8) would be the sum of those lengths (e.g., 8+15=23).

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

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

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

[0246] The communication control module 43 is operable to control the communication between the UE 3-2; 3-3 and its serving RAN node or RAN nodes 5-1 (and other communication devices connected to the RAN node 5-1, such as further UEs and / or core network nodes). The communication control module 43 is configured for the overall handling of uplink communication via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 43 is also configured for the overall handling of receipt of downlink communication via associated downlink channels (e.g., of DCI via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-persistent scheduling (e.g., SPS). The communication control module 43 is responsible, for example: for determining where to monitor for downlink control information; for determining the resources to be used by the UE 3 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.

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

[0248] It will be appreciated that the communication control module 43 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the UE 3-2, 3-3 may include sub-modules corresponding to the layers of a conventional protocol stack (PHY, MAC, RRC, RLC, PDCP etc.). Moreover, where the UE 3-2, 3-3 is configured to operate as an intermediate / assisting node 5-2, communication control module 43 may include sub-modules corresponding to the layers of a dedicated ambient IoT device protocol stack for controlling functions associated with those layers.

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

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

[0251] As shown, the ambient IoT device 3-1 (also referred to simply as an 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).

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

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

[0254] The transceiver circuit 331 also has modulation circuitry 331-2 which modulates an incoming unmodulated carrier signal to the IoT device 3-1 to produce the modulated backscatter signal to be reflected from the 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 IoT device 3-1 by altering the impedance or reflectivity of the IoT device 3-1 in response to receiving that incoming RF signal. The modulation circuitry 331-2 may be configured to modulate the incoming signal to encode data provided from one or more data sources 332. Typically, for example, the 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.

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

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

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

[0258] The communication control module 343 is operable to control the communication between the IoT device 3-1, the RAN node 5-1, and / or the assisting node 5-2. The communication control module 343 may, for example, be configured for the overall handling of communication via associated physical channels (e.g., via a physical D2R channel (PDRCH), random access channel (RACH), and / or a physical R2D channel (PRDCH)).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0298] For example, the whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes. 　　(Supplementary note 1) 　　　　A method performed by a first device, the method comprising: 　　receiving, from a first reader, first information indicating a first length of a first sequence for a midamble of a device-to-reader, D2R, signal, wherein the first reader is connected to the device via an Ambient Internet of Things, A-IoT, radio interface, and 　　generating a transmission of the D2R signal using the first information. 　　(Supplementary note 2) 　　The method of supplementary note 1, wherein the first information is provided by higher layers. 　　(Supplementary note 3) 　　The method of supplementary note 1, wherein the first information is provided by Layer 1 control information. 　　(Supplementary note 4) 　　The method of any one of supplementary notes 1-3, wherein, 　　the first sequence is one of a plurality of predefined sequences for D2R, 　　each of the plurality of predefined sequences has a predefined length, and 　　the first information is mapped to the first length from among a plurality of predefined lengths for each of the plurality of predefined sequences for D2R. 　　(Supplementary note 5) 　　The method of any one of supplementary notes 1-4, wherein, 　　the first sequence corresponds to a plurality of sequences from among a plurality of predefined sequences for D2R. 　　(Supplementary note 6) 　　The method of any one of supplementary notes 1-5, further comprising: 　　receiving from the first reader, second information indicating a location of the midamble, wherein the location is based on data size of a physical D2R channel, PDRCH. 　　(Supplementary note 7) 　　A method performed by a first reader, the method comprising: 　　transmitting, to a first device, first information indicating a first length of a first sequence for a midamble of a device-to-reader, D2R, signal, wherein the first reader is connected to the device via an Ambient Internet of Things, A-IoT, radio interface, and 　　receiving a transmission of the D2R signal using the first information. 　　(Supplementary note 8) 　　The method of supplementary note 7, wherein the first information is provided by higher layers. 　　(Supplementary note 9) 　　The method of supplementary note 7, wherein the first information is provided by Layer 1 control information. 　　(Supplementary note 10) 　　The method of any one of supplementary notes 7-9, wherein, 　　the first sequence is one of a plurality of predefined sequences for D2R, 　　each of the plurality of predefined sequences has a predefined length, and 　　the first information is mapped to the first length from among a plurality of predefined lengths for each of the plurality of predefined sequences for D2R. 　　(Supplementary note 11) 　　The method of any one of supplementary notes 7-10, wherein, the first sequence corresponds to a plurality of sequences from among a plurality of predefined sequences for D2R. 　　(Supplementary note 12) 　　The method of any one of supplementary notes 7-11, further comprising: 　　transmitting to the first device, second information indicating a location of the midamble, wherein the location is based on data size of a physical D2R channel, PDRCH. 　　(Supplementary note 13) 　　A first device comprising: 　　means for receiving, from a first reader, first information indicating a first length of a first sequence for a midamble of a device-to-reader, D2R, signal, wherein the first reader is connected to the device via an Ambient Internet of Things, A-IoT, radio interface, and 　　means for generating a transmission of the D2R signal using the first information. 　　(Supplementary note 14) 　　The first device of supplementary note 13, wherein the first information is provided by higher layers. 　　(Supplementary note 15) 　　The first device of supplementary note 13, wherein the first information is provided by Layer 1 control information. 　　(Supplementary note 16) 　　The first device of any one of supplementary notes 13-15, wherein, the first sequence is one of a plurality of predefined sequences for D2R, each of the plurality of predefined sequences has a predefined length, and the first information is mapped to the first length from among a plurality of predefined lengths for each of the plurality of predefined sequences for D2R. 　　(Supplementary note 17) 　　The first device of any one of supplementary notes 13-16, wherein, the first sequence corresponds to a plurality of sequences from among a plurality of predefined sequences for D2R. 　　(Supplementary note 18) 　　The first device of any one of supplementary notes 13-17, further comprising: 　　means for receiving from the first reader, second information indicating a location of the midamble, wherein the location is based on data size of a physical D2R channel, PDRCH.

[0299] This application is based upon and claims the benefit of priority from Great Britain Patent Application No. 2500353.4, filed on January 10, 2025, the disclosure of which is incorporated herein in its entirety by reference.

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

Claims

A method performed by a first device, the method comprising:　　receiving, from a first reader, first information indicating a first length of a first sequence for a midamble of a device-to-reader, D2R, signal,wherein the first reader is connected to the device via an Ambient Internet of Things, A-IoT, radio interface, and　　generating a transmission of the D2R signal using the first information.　　The method of claim 1, wherein the first information is provided by higher layers.　　The method of claim 1, wherein the first information is provided by Layer 1 control information.　　The method of any one of claims 1-3, wherein,　　the first sequence is one of a plurality of predefined sequences for D2R,　　each of the plurality of predefined sequences has a predefined length, and　　the first information is mapped to the first length from among a plurality of predefined lengths for each of the plurality of predefined sequences for D2R.　　The method of any one of claims 1-4, wherein,　　the first sequence corresponds to a plurality of sequences from among a plurality of predefined sequences for D2R.　　The method of any one of claims 1-5, further comprising:　　receiving from the first reader, second information indicating a location of the midamble, wherein the location is based on data size of a physical D2R channel, PDRCH.　　A method performed by a first reader, the method comprising:　　transmitting, to a first device, first information indicating a first length of a first sequence for a midamble of a device-to-reader, D2R, signal,wherein the first reader is connected to the device via an Ambient Internet of Things, A-IoT, radio interface, and　　receiving a transmission of the D2R signal using the first information.　　The method of claim 7, wherein the first information is provided by higher layers.　　The method of claim 7, wherein the first information is provided by Layer 1 control information.　　The method of any one of claims 7-9, wherein,　　the first sequence is one of a plurality of predefined sequences for D2R,　　each of the plurality of predefined sequences has a predefined length, and　　the first information is mapped to the first length from among a plurality of predefined lengths for each of the plurality of predefined sequences for D2R.　　The method of any one of claims 7-10, wherein,the first sequence corresponds to a plurality of sequences from among a plurality of predefined sequences for D2R.　　The method of any one of claims 7-11, further comprising:　　transmitting to the first device, second information indicating a location of the midamble, wherein the location is based on data size of a physical D2R channel, PDRCH.　　A first device comprising:　　means for receiving, from a first reader, first information indicating a first length of a first sequence for a midamble of a device-to-reader, D2R, signal,wherein the first reader is connected to the device via an Ambient Internet of Things, A-IoT, radio interface, and　　means for generating a transmission of the D2R signal using the first information.　　The first device of claim 13, wherein the first information is provided by higher layers.　　The first device of claim 13, wherein the first information is provided by Layer 1 control information.　　The first device of any one of claims 13-15, wherein,the first sequence is one of a plurality of predefined sequences for D2R,each of the plurality of predefined sequences has a predefined length, andthe first information is mapped to the first length from among a plurality of predefined lengths for each of the plurality of predefined sequences for D2R.　　The first device of any one of claims 13-16, wherein,the first sequence corresponds to a plurality of sequences from among a plurality of predefined sequences for D2R.　　The first device of any one of claims 13-17, further comprising:　　means for receiving from the first reader, second information indicating a location of the midamble, wherein the location is based on data size of a physical D2R channel, PDRCH.

Images