Method of mobile device, method of access network node, mobile device and access network node

Abstract

A method performed by a mobile device is described, comprising transmitting, to an access network node, first data and information indicating that the mobile device has remaining data to be transmitted in a case where the mobile device has data to be transmitted whose transport block size is larger than the transport block size of the first data.

Description

METHOD OF MOBILE DEVICE, METHOD OF ACCESS NETWORK NODE, MOBILE DEVICE AND ACCESS NETWORK NODE

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

[0002] The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards, equivalents, or derivatives thereof (including Long Term Evolution (LTE)-Advanced, Next Generation or 5G networks, future generations, and beyond). The present disclosure in particular relates to scheduling considerations within an 'Ambient' Internet-of-Things (IoT) system, for example in the event that an A-IoT device (also sometimes referred to simply as an IoT device) has more data to send than a transport block size (TBS) indicated by a by an A-IoT device reader.

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

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

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

[0006] In the current 5G architecture, the base station structure may be split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by an F1 interface. This enables the use of a 'split' architecture in which the typically 'higher' CU layers (for example, but not necessarily or exclusively, Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) layers) and the, 'lower' DU layers (for example, but not necessarily or exclusively, Radio Link Control (RLC), Media (sometimes referred to as 'Medium') Access Control (MAC), and Physical (PHY) layers) are separated between a particular CU, and one or more Dus that are connected to and controlled by that CU via the F1 interface. Thus, for example, the higher layer CU functionality for a number of base stations may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each base station.

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

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

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

[0010] As the payload data from UEs, and especially IoT devices, can be relatively small compared to the control signalling required to form an RRC connection to send that small data over the radio interface, making an RRC connection for such a small data transmission is relatively inefficient (both for the RAN and the UE) due to the control signalling overhead. The number of IoT devices may be extremely large (especially for NR deployments which, by definition, support a potentially massive number of IoT devices,) and, consequently, the control signalling overhead, even where the total amount of data is relatively small, can become a significant limiting factor. This is compounded, for IoT devices in particular, by the fact that the control signalling consumes energy and thus impacts the limited energy storage capability typical of such IoT devices.

[0011] To help alleviate such issues, the concept of small data transmission (SDT) has been developed via which it is possible for a UE to send small amounts of data without requiring an RRC connection to first be completed. Specifically, SDT is a procedure which allows data and / or signalling transmission while the device remains in an idle or inactive state without transitioning to connected state. SDT may be initiated by the UE on condition that less than a configured amount of UL data awaits transmission across all radio bearers for which SDT is enabled. Otherwise the normal data transmission scheme, requiring an RRC connection to be completed, is typically used.

[0012] One of the ways in which SDT may be implemented is for the UE (e.g., an IoT device) to transmit the small data as part of a contention based random access procedure (e.g., as described above). For this type of SDT, therefore, the UE does not have a dedicated radio resource allocated for transmission of the small data (and hence contention is possible). The UE typically determines resources to use for attempting the random access based SDT from system information messages, in a similar way to a conventional CBRA procedure. However, the resources for SDT UEs, and for non-SDT UEs, are different so that a UEs performing random access based SDT do not interfere with UEs performing other types of random access.

[0013] The random access based SDT may be performed as part of a two-step random access procedure, or as part of a four-step random access procedure. In the case of two-step random access the small data payload is sent in the first step (e.g., with the initial random access message, 'MsgA'). Contrastingly, in the four-step procedure the contention resolution may be performed (e.g., based on Msg1 and Msg2) before the UE sends the small data payload with Msg3 (e.g., with an RRC Resume Request). Msg4 may then release the connection (possibly with a suspend indication to move the UE back into an inactive state) although the procedure may continue with further small data transmissions before the connection is released.

[0014] In another form of SDT resources for the SDT are allocated periodically (e.g., based on estimated traffic requirements) - this may be referred to as Configured Grant (CG) SDT. With CG SDT there will be no contention as the allocated resources are dedicated for each device. The CG is typically signalled to the UE, by a RAN node, when the UE leaves the connected state.

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

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

[0017] It will be appreciated that types 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.

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

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

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

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

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

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

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

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

[0026] Generally, for A-IoT communication, it is envisaged that multiple A-IoT logical channels for communication of upper layer data need not be supported. It is yet to be determined whether the concept of A-IoT logical channels is used (e.g., depending on final modelling issues). It is also envisaged that access stratum (AS) layer (above the PHY layer) RLC-like retransmission / repetition will not be supported for A-IoT. Nevertheless, this does not preclude the reader and device resending the payload again as new transmission from the perspective of the MAC layer. It is yet to be determined how segmentation is to be handled (if needed).

[0027] The various constraints imposed on A-IoT type communication raises a number of issues that need to be resolved. For example, the A-IoT device may need to transmit a particularly long data packet, in which case the A-IoT device may not be able to include the full data packet within a single transport block (TB). Specifically, the size (amount) of data to be transmitted by the A-IoT device may be larger than a TBS indicated, via the PRDCH. Hence, following data transmission by the A-IoT device untransmitted data remains at (e.g., in a transmission buffer of) the A-IoT device.

[0028] Historically, in new radio (NR), an initial amount of data available to transmit by a UE could be indicated via a scheduling request (SR), in response to which the RAN node could respond with an uplink grant that scheduled resources for an initial transmission by that UE 3. In the event that the scheduled resources did not allow all the available data to be transmitted in that initial transmission then the UE could include a buffer status report (BSR) with the data transmission that indicated an amount of remaining data still to be transmitted at that UE. The RAN node could then respond with a grant that scheduled further uplink resources for a further transmission by that UE 3. This process of transmitting a BSR with a data transmission could then be repeated for each subsequent transmission until there is no more remaining data to transmit.

[0029] To minimize the size of a conventional BSR, the BSR might comprise an 'absolute data size indication' having a limited number of bits that points to single entry of a corresponding entry a corresponding BSR table, each entry representing a range of possible data sizes. By way of example only, a hypothetical two-bit TBS indication might indicate one of four different possible buffer statuses (remaining data size / amount), as follows:

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

[0031] However, such an indication method is not particularly flexible, and can result in the transmission of a TB with a relatively large number of padding bits, which is inefficient - especially in the context of A-IoT type communication. Whilst, for conventional UEs, an indication with a larger number of bits could be used to increase the granularity of buffer statuses that can be reported, the use of a larger number of bits involves a larger bit overhead, which can be undesirable - especially in the context of A-IoT.

[0032] In any case, it is envisaged that the use of legacy NR type SR / BSR such as this for indicating the available / remaining data within a device will not be required for A-IoT communication.

[0033] Accordingly, there is a need for one or more enhanced mechanisms could be developed that support the provision, by an A-IoT device (and / or other UE) of an indication of an amount of data (e.g., remaining data) to be transmitted in a more efficient manner. It would be particularly beneficial for any such enhanced mechanism to provide one or more of the following benefits: minimisation of the number of padding bits required (hence reducing wasted resources); minimisation of the number of control bits required to provide the indication; efficient scheduling for each A-IoT device (and / or other UE); and / or minimisation of the number of scheduling rounds (hence minimising latency).

[0034] It will be appreciated that whilst any such mechanism will be of particular benefit in the context of A-IoT, the benefits provided by such a mechanism will, nevertheless, be more widely applicable in conventional cellular communication involving non-ambient IoT (e.g., conventional) UEs.

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

[0036] The disclosure has a method performed by a mobile device, the method comprising transmitting, to an access network node, first data and information indicating that the mobile device has remaining data to be transmitted in a case where the mobile device has data to be transmitted whose transport block size is larger than the transport block size of the first data.

[0037] The disclosure has a method performed by an access network node, the method comprising receiving, from a mobile device, first data and information indicating that the mobile device has remaining data to be transmitted in a case where the mobile device has data to be transmitted whose transport block size is larger than the transport block size of the first data.

[0038] The disclosure has a mobile device comprising means for transmitting, to an access network node, first data and information indicating that the mobile device has remaining data to be transmitted in a case where the mobile device has data to be transmitted whose transport block size is larger than the transport block size of the first data.

[0039] The disclosure has an access network node, the method comprising receiving, from a mobile device, first data and information indicating that the mobile device has remaining data to be transmitted in a case where the mobile device has data to be transmitted whose transport block size is larger than the transport block size of the first data.

[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 the 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. 2 illustrates schematically a first connectivity topology (topology 1) that may be used in the communication system of Fig. 1;Fig. 3 illustrates schematically a second connectivity topology (topology 2) that may be used in the communication system of Fig. 1;Fig. 4A illustrates schematically a third connectivity topology (topology 3) that may be used in the communication system of Fig. 1;Fig. 4B illustrates schematically another arrangement of the third connectivity topology (topology 3) of Fig. 4A;Fig. 5 illustrates a simplified sequence diagram of an example data scheduling and transmission procedure that may be implemented in the communication system of Fig. 1.Fig. 6 illustrates an example signalling container for carrying D2R control information for assisting scheduling that may be implemented in the communication system of Fig. 1;Fig. 7 illustrates a simplified sequence diagram of another example data scheduling and transmission procedure that may be implemented in the communication system of Fig. 1;Fig. 8 illustrates a simplified sequence diagram of an example RA based SDT procedure that may be implemented in the communication system of Fig. 1;Fig. 9 illustrates a simplified sequence diagram of another example RA based SDT procedure that may be implemented in the communication system of Fig. 1;Fig. 10 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. 11 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. 12 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. 13 is simplified block schematic illustrating the main components of an intermediate or assisting node that may be used in the communication system of Fig. 1.

[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 9. Communication via the RAN node 5-1 is typically routed through a core network 7 (e.g., a 5G / 6G or later generations core network or evolved packet core network (EPC)). As those skilled in the art will appreciate however, a base station 5-1 or 'gNB' 5-1 is an example of a RAN node 5-1 only and that the RAN node 5-1 may be any appropriate RAN node 5-1 (e.g., where appropriate the RAN node 5-1 may be a RAN node that operates using a different RAT than NR / 5G).

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

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

[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 authorization, user registration, and data network profiles); a Policy Control Function (PCF); an Application Function (AF); a Security Anchor Function (SEAF) which is in a serving network and acts as a "middleman" during an authentication process between a UE 3 and its home network; an Authentication credential Repository and Processing Function (ARPF) which maintains the authentication credentials; and / or the like. It will be appreciated that the nodes or functions may have different names in different systems.

[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-2, 3-3 are each connected to the AMF 10-1 via a non-access stratum (NAS) connection over an appropriate reference point (e.g., N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated, that N1 communication is routed transparently via the RAN node 5-1.

[0054] One or more UPFs 11 are connected to an external data network 21 (e.g., an IP network such as the internet) via an appropriate reference point (e.g., an N6 reference point) for communication of the user data. 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.

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

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

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

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

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

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

[0061] 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 synchronization 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 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.

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

[0063] While contention-based RACH procedures are described it will be appreciated that the UE 3-2, 3-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-2, 3-3. Moreover, the UE 3-2, 3-3 and the RAN node 5-1 may perform a two-step RACH procedure.

[0064] At least the non-ambient IoT UEs 3-2, 3-3, and the RAN node 5-1 are mutually configured for performing random access (RA) based small data transmissions (SDTs) as part of a contention based random access (CBRA) procedure (e.g., as described above). Specifically, resources for attempting the RA based SDT may be configured by the RAN node 5-1 to the UE 3-2, 3-3, in a system information message or the like. The UEs 3-2, 3-3, and the RAN node 5-1 may then send the SDT in one of the messages sent from the UE 3-2, 3-3 to the RAN node 5-1 as part of the RA procedure. The RA based SDT may be performed as part of a two-step RACH procedure, or as part of a four-step RACH procedure. In the case of two-step RA the small data payload may be sent in the first step (e.g., with the initial random access message, 'MsgA'). Contrastingly, in the four-step procedure contention resolution may be performed (e.g., based on Msg1 and Msg2) before the small data payload is transmitted with Msg3 (e.g., with an RRC Resume Request or the like). Msg4 may then release the connection (possibly with a suspend indication to move the UE 3-2, 3-3 back into an inactive state) although the procedure may continue with further small data transmissions before the connection is released.

[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 3-1 as described above. For example, the A-IoT device 3-1 and RAN node 5-1 and / or intermediate / assisting node 5-2 may be configured for performing a two-step and / or four-step RACH procedure the same as (or similar to) that described above, and may be configured for performing SDT as part of the two-step and / or four-step RACH procedure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0081] In a first (downlink) direction 　　(RAN node 5-1 ? intermediate node 5-2 ? A-IoT device 3-1) 　　, a downlink signal may be transmitted from the RAN node 5-1 to the intermediate node 5-2 as part of communication 20-3 between the RAN node 5-1 and the intermediate node 5-2. The downlink signal, once received by the intermediate node 5-2, may trigger transmission of an unmodulated carrier signal 20-1 to the A-IoT device 3-1 (e.g., on a 'sidelink' or similar). The downlink signal may be (or may carry) the unmodulated carrier signal 20-1 that is to be transmitted (e.g. relayed) by the intermediate node 5-2 to the A-IoT device 3-1 or may be a trigger signal for triggering transmission of the unmodulated carrier signal 20-1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0096] <Indication of Remaining Data> 　　Beneficially, the A-IoT device reader (e.g., RAN node 5-1 or assisting / intermediate node 5-2) and the A-IoT device 3-1 of the communication system 1 are mutually configured for implementing one or more enhanced procedures for providing an indication of an amount of data (e.g., remaining data) to be transmitted from the A-IoT device 3-1. A number of such enhanced procedures will now be briefly introduced, by way of example only, before a more detailed description of the various enhanced procedures is provided.

[0097] It will be appreciated that whilst the enhanced procedures introduced below are described in the specific context of an A-IoT device reader and A-IoT device 3-1, the principles encompassed by the enhanced procedures can be extended to non-ambient IoT UEs (e.g., such as UEs 3-2, 3-3) and RAN nodes 5-1. It will also be appreciated that whilst the enhanced procedures introduced below are described, primarily, in the context of indicating an amount of data remaining following an earlier D2R data transmission, the principles encompassed by the enhanced procedures may be applied for indicating an amount / size of data to be transmitted before any data transmission.

[0098] As described in more detail later, the communication system 1 may support a first enhanced data scheduling / transmission procedure in which, rather than provide an absolute size indication (i.e., representing a fixed range of data size / amount), the A-IoT device 3-1 is able to provide a relative indication that indicates a (remaining) data amount / size relative to a reference data amount / size that may be predefined at the A-IoT device 3-1, or configured by the network. Specifically, the relative indication indicates a ratio of the (remaining) data amount / size to the reference data amount / size. Hence, the A-IoT device reader can determine an appropriate new TBS for a subsequent D2R transmission of at least some of the (remaining) data in a transmission buffer of the A-IoT device 3-1, and schedule the D2R transmission based on that determined TBS (e.g., via a subsequent R2D transmission).

[0099] The reference data amount / size may, for example, be: a previously scheduled (e.g., a current transport block size (TBS)); or some other predefined, or network configured, data amount / size (e.g., a maximum TBS (e.g., 1000 bits for A-IoT) or particular proportion (e.g., half) of a maximum TBS (e.g., 500 bits for A-IoT)). Here it will be appreciated that the size values given are purely for illustrative purposes.

[0100] As will be apparent to those skilled in the art, the use of a relative indication as described above has the potential to provide improvements in scheduling flexibility and efficiency. For example, unlike an indication of an absolute data amount / size (BSR), which can be inflexible because it cannot be adapted to the specific circumstances of an individual device (i.e., due to the potential high data variability between the A-IoT devices 3-1), the use of a relative indication has the flexibility to indicate data amount / size in a device-specific manner. Specifically, the reference data amount / size (e.g., current TBS or other configured value) can be different for different device types (e.g., based on device type, the dynamic data related situation prevailing at the A-IoT device 3-1 at a particular time, and / or other device specific factors).

[0101] Moreover, the use of a relative indication has the potential to use fewer control bits compared to an indication of an absolute data amount / size (BSR). Whilst a single bit could, hypothetically, be used simply to indicate that there is data remaining that needs to be scheduled, such an approach can lead to blind scheduling which is relatively inefficient - for example resulting in scheduling based on a TBS that is too small and hence increased latency (associated with repetitive scheduling rounds), or scheduling based on a TBS that is too large (and hence a high number of padding bits which is wasteful). Contrastingly, indicating a relative amount / size of (remaining) data can reduce, if not eliminate, the need for blind scheduling. As described in more detail later, there are a number of different ways in which a relative amount / size may be indicated.

[0102] For example, an absolute value for the relative amount / size (e.g., the ratio) of the (remaining) data may be determined within a quantised range of possible values, and the relative indication may represent that determined absolute value. One or more (e.g., two) bits may, for example, indicate an integer part of the quantised ratio value and one or more (e.g., three) bits may indicate a decimal part of the quantised ratio value (e.g., an integer part of '01' with a decimal part of '001' might indicate a ratio of 1.125). The use of this type of indication has the potential to provide a particularly precise data size and thus helps to minimise the number of padding bits typically required. It will also be appreciated that this approach has the potential to reduce the number of control bits required compared to an indication of an absolute data amount / size (BSR) albeit that there is a trade-off between the total number of control bits required and the quantisation granularity. The use of this type of indication also has the benefit that it can be implemented in a relatively straightforward manner (e.g., without requiring a table of different possible ranges of relative amount / size of the (remaining) data to be predefined or configured at the A-IoT device 3-1).

[0103] Nevertheless, the relative amount / size of (e.g., the ratio of) the (remaining) data may be determined to be within one of a plurality of different possible predefined (or configured) ranges of relative amount / size of the (remaining) data, and the indication may provide an indication of the range within which the relative amount / size of the (remaining) data falls. The ranges may, for example, be predefined, or configured by the network, as part of a table of different possible relative amount / size ranges (e.g., a table of different ranges of ratios). Whilst indicating a range in this way may provide a less precise indication of the relative amount / size of (remaining) data than indication of an absolute value of the relative amount / size, indicating a range has the benefit that it can potentially be achieved using fewer additional control bits (i.e., with a smaller control bit overhead). Moreover, indicating a range (e.g., from a (pre)configured table or the like) within which the relative amount / size of the (remaining) data falls also has the potential to significantly reduce the number of padding bits typically required (albeit not necessarily to the same extent as indicating an absolute value of the relative amount / size).

[0104] Where the indication indicates a range from a plurality of different possible ranges of relative amount / size of the (remaining) data, the ranges may, for example, be partitioned uniformly between zero and one (i.e., the amount / size of the (remaining) data equals the reference value). The ranges may, nevertheless, be partitioned non-uniformly between zero and one, for example, with larger partitions for a (remaining) data amount / size closer to zero and with smaller partitions closer to (but lower than) one. It will be appreciated that for both uniform and non-unform partitioning, for data amounts / sizes above one (i.e., for cases where the amount / size of the (remaining) data is greater than the reference value), the ranges may be significantly larger, or even indefinite (e.g., encompassing all values greater than one, or some other value greater than one).

[0105] The indication itself may comprise a variable number of bits or a fixed number of bits. It will be appreciated that the use of a variable number of bits allows indication of a larger number of possibilities with fewer bits, and hence a finer granularity (for a given maximum number of control bits) to assist efficient data scheduling. For example, a single bit indication (e.g., '0' or '1') may represent a different relative amount / size (e.g., ratio) of the (remaining) data than the corresponding two-bit indication (e.g., '00' or '01'). Nevertheless, a fixed number of bits (e.g., three bits to represent eight different possibilities) may be helpful for identification of the relevant bits / bit field from among all the D2R control data in a given message.

[0106] In a variation of the above, as described in more detail later, the communication system 1 may support a second enhanced data scheduling / transmission procedure in which a hybrid approach is taken. Specifically, depending on the relative amount / size of (remaining) data at the A-IoT device 3-1, either an absolute amount / size indication (i.e., representing a fixed range of data size / amount) similar to a conventional BSR is provided, or a relative indication of the (remaining) data amount / size is provided (e.g., essentially as introduced above in respect of the first enhanced data scheduling / transmission procedure). Specifically, when the relative amount / size of (remaining) data is above (or possibly equal to) a particular threshold, then an absolute amount / size (BSR like) indication based on a (pre)configured an absolute amount / size (BSR like) table is provided. On the other hand, when the relative amount / size of (remaining) data is below (or possibly equal to) a particular threshold then a relative indication (e.g. of a ratio) is provided based on a (pre)configured relative amount / size (e.g., ratio) based table. Hence, the A-IoT device reader can determine an appropriate new TBS for a subsequent D2R transmission of at least some of the (remaining) data in a transmission buffer of the A-IoT device 3-1, and schedule the D2R transmission based on that determined TBS (e.g., via a subsequent R2D transmission).

[0107] It will be appreciated that whilst the use of the hybrid approach introduces additional complexity, it advantageously allows the A-IoT device 3-1 and A-IoT device reader to benefit from the use of a relative indication when most advantageous, whilst avoiding specific (occasional) scenarios in which the use of a relative indication might result in more scheduling rounds than might otherwise be the case. For example, when the ratio of the amount / size of (remaining) data to the reference data amount / size (e.g., current TBS) is particularly high (e.g., greater than 1.5 or 2.5), a scenario may arise in which a TBS determined for subsequent scheduling, based on an indication of a relative amount / size of data, is both smaller than a maximum TBS and insufficient for transmission of all the remaining data. Hence, an additional scheduling round may be required unnecessarily. For scenarios where it is particularly desirable to minimise the need for additional scheduling rounds, therefore, the hybrid approach may be used to allow the A-IoT device 3-1 to switch to informing the A-IoT device reader of an absolute amount / size of (remaining) data using an indication of a range within which the absolute amount / size of (remaining) data falls. Hence, the A-IoT device reader can determine the correct TBS for subsequent scheduling.

[0108] It will be appreciated that the communication system 1 may support both the second enhanced data scheduling / transmission procedure that uses the hybrid approach and the first enhanced data scheduling / transmission procedure based on the approach using only a relative indication of the (remaining) data amount / size (e.g., different A-IoT devices 3-1 may be configured to follow different approaches, or to switch between different approaches, dependent on their type and / or data transmission requirements). Nevertheless, the communication system 1 may support only one of the first and the second enhanced data scheduling / transmission procedure.

[0109] Beneficially the communication system 1 may alternatively (or additionally) support the use of a relative indication of the (remaining) data amount / size in other procedures in which the A-IoT device 3-1 sends data to the network.

[0110] For example, the A-IoT device 3-1 and A-IoT device reader of the communication system 1 may support one or more enhanced RA based SDT procedures in which the A-IoT device 3-1 can provide a small data payload together with an indication of a relative amount / size of data remaining after the SDT, as part of a contention based RACH procedure.

[0111] One such enhanced RA based SDT procedure described in more detail later is based on a two-step RACH procedure in which the small data payload is provided, together with an indication of a relative amount / size of data remaining, in MsgA. Another such enhanced RA based SDT procedure described in more detail later is based on a four-step RACH procedure in which the small data payload is provided, together with an indication of a relative amount / size of data remaining, in Msg3. It will be appreciated that in either of these RA based SDT procedures the indication of a relative amount / size of data remaining may be as described for the first and the second enhanced data scheduling / transmission procedures introduced above.

[0112] Moreover, in either of these enhanced RA based SDT procedures, an indication of a relative amount / size of data remaining may be sent in MsgA / Msg3 conditionally on the relative amount / size of data being below a threshold, in similar manner to the hybrid approach used the second enhanced data scheduling / transmission procedure introduced above. In this case when the relative amount / size of data is above the threshold an indication of an absolute amount / size of data remaining (e.g., a BSR like indication) may be sent in MsgA / Msg3, in similar manner to the hybrid approach used the second enhanced data scheduling / transmission procedure introduced above.

[0113] Beneficially, in any of the enhanced procedures introduced above, the A-IoT device 3-1 may (optionally) include, with an indication of a relative amount / size of (remaining) data (or with an absolute amount / size when a hybrid approach is used), an indication of a suggested / recommended MCS (e.g., in an 'I_mcs' field) that the A-IoT device reader may take into account when deciding an MCS that should be used by the A-IoT device 3-1 for a subsequent data transmission. Providing such an indication of a suggested / recommended MCS beneficially allows the A-IoT device reader to derive implicitly additional information about the communication status (e.g., the PRDCH status) at the A-IoT device 3-1 that may contribute to efficient scheduling. For example, such an indication may be used, in a similar manner to a channel quality indicator (CQI) that is typically provided as part of a channel state information (CSI) report, both to help identify an MCS and the way in which resources should be scheduled. Effectively, since CSI may not be used in the context of A-IoT, the provision of an indication of a suggested / recommended MCS can act as a partial substitute. The A-IoT device 3-1 device may, for example, derive the suggested / recommend MCS based on a bit error rate (BER) (and / or possibly some other metric such as signal to interference plus noise ratio (SINR), signal to noise ratio (SNR), reference signal received power (RSRP), and / or the like) calculated for the PRDCH, and thus is indicative of the channel / communication link status.

[0114] It will be appreciated that the communication system 1 may support one or both of the RA based SDT procedures in addition to (or as an alternative to) the first enhanced data scheduling / transmission procedure and / or second enhanced data scheduling / transmission procedure introduced above.

[0115] The various data scheduling / transmission procedures and introduced above, and associated techniques, will now be described in more detail, by way of example only, with reference to Figs. 5 to 9.

[0116] <D2R Data Scheduling and Transmission Procedure (Relative Data Amount / Size Indication)> 　　As mentioned above, the communication system 1 may support an enhanced data scheduling / transmission procedure in which, rather than provide an absolute amount / size indication (i.e., representing a fixed range of data size / amount), the A-IoT device 3-1 provides a relative indication that indicates a (remaining) data amount / size relative to a reference data amount / size that may be predefined at the A-IoT device 3-1, or configured by the network.

[0117] One such method will be described, by way of example only, with reference to Fig. 5, which illustrates a simplified sequence diagram of an example data scheduling and transmission procedure that may be implemented in the communication system 1.

[0118] It will be appreciated that whilst the enhanced procedure of Fig. 5 is described in the specific context of an A-IoT device reader and A-IoT device 3-1, the principles encompassed by the enhanced procedure can be extended to a non-ambient IoT UE 3-2, 3-3 and an associated RAN node 5-1.

[0119] As seen in Fig. 5, in this example, before data scheduling, the A-IoT device reader may provide, to the A-IoT device 3-1, information for configuring a ratio based table, based on which the A-IoT device 3-1 may determine the relative indication to be used at a given time (e.g., as seen at S502). The information for configuring a ratio based table may be provided in any suitable manner (e.g., as an R2D message, as part of a random access procedure, on the PRDCH, and / or the like). Effectively, a ratio based table configured by the information defines a mapping between each possible bit pattern that may be used as a relative indication, and a respective range of ratios. It will be appreciated that the provision of information for configuring a ratio based table may not be necessary. For example, provision of information for configuring a ratio based table may not be necessary if a ratio based table is predefined at the A-IoT device 3-1, or if the relative indication used indicates a calculated absolute value of the relative amount / size (e.g., the ratio) of the (remaining) data (e.g., from within a quantised range of possible absolute values).

[0120] It will be appreciated that whilst this example is described in the context of a relative data amount / size defined as a ratio of a (remaining) data amount / size to a current TBS ('TBS1'), the relative data amount / size may be defined differently. For example, the relative data amount / size may be defined as a ratio of a (remaining) data amount / size to a pre-defined fixed data amount / size - for example the maximum TBS (e.g., 1000 bits for A-IoT), half the maximum TBS (e.g., 500 bits for A-IoT), and / or the like.

[0121] The data scheduling commences, at S504, with the A-IoT device reader sending, on the PRDCH, a message for scheduling (allocating resources for) a subsequent D2R data transmission. The scheduling message may indicate a first TBS ('TBS1') based upon which the resources allocated for the D2R data have been determined.

[0122] If the data available at the A-IoT device 3-1 for a D2R transmission is greater than TBS1 (as seen at S506a), then the A-IoT device 3-1 determines a remaining data ratio and, based on the remaining data ratio, a bit pattern (of one or more bits) that should be used for an associated relative indication to be sent to the A-IoT device reader.

[0123] The A-IoT device 3-1 may also determine, at this stage, a recommended / suggested MCS (e.g., based on a BER for the PRDCH and / or some other suitable metric) or simply whether or not a different MCS might be beneficial. The A-IoT device 3-1 may also determine an associated MCS indication (e.g. 'I_mcs') to be sent to the A-IoT device reader to indicate the recommended / suggested MCS (or that the use of a different (or the same) MCS is suggested / recommended). For example, a multi-bit indication may be used to indicate a specific one of a set of (more than two) supported MCSs. Alternatively, a single bit indication may be used to indicate that the use of a different (or the same) MCS is suggested / recommended. For example, a bit set to '1' (or '0') may indicate a different MCS is suggested / recommended, whereas a bit set to '0' (or '1') - or the omission of the bit entirely - may indicate that use of the same MCS is suggested / recommended.

[0124] If the data available at the A-IoT device 3-1 for a D2R transmission is not greater than TBS1 (as seen at S506b), then the A-IoT device 3-1 determines the number of padding bits (if any) that need to be added to the D2R data to reach the TBS1.

[0125] At S508, the A-IoT device 3-1 transmits, to the A-IoT device reader, on the PDRCH, a transport block (TB) of size equal to TBS1 comprising at least some of the data stored in the transmission buffer of the A-IoT device 3-1. In a case where the data available at the A-IoT device 3-1 for a D2R transmission is greater than TBS1, the A-IoT device 3-1 includes, with this transmission, the relative indication and any MCS indication (e.g., I_mcs). In a case where the data available at the A-IoT device 3-1 for a D2R transmission is not greater than TBS1 no such indications need be provided (although it will be appreciated that an explicit 'relative' indication may be provided indicating that there is no remaining data) and the TB will include all the D2R data together with any padding bits that may be needed - thus no further scheduling is required.

[0126] In a case where there is remaining data available at the A-IoT device 3-1, however, the A-IoT device reader determines, at S510, an appropriate new TBS ('TBS2') to use for subsequent scheduling and, if needed, an appropriate MCS to be used. If an MCS indication is provided with the D2R transmission sent at S508 any determination of an MCS may take the MCS indication into account. The A-IoT device reader also determines appropriate resources to allocate for a subsequent D2R remaining data transmission

[0127] The A-IoT device reader then sends, at S512, on the PRDCH, a message for scheduling (allocating resources for) the subsequent D2R remaining data transmission. The scheduling message sent at S512 may indicate the new TBS ('TBS2'), based upon which the resources allocated for the D2R remaining data have been determined.

[0128] If the remaining data available at the A-IoT device 3-1 for a subsequent D2R transmission is greater than the new TBS2 (as seen at S514a), then the A-IoT device 3-1 may determine the corresponding remaining data ratio and, based on the remaining data ratio, a new bit pattern (of one or more bits) that should be used for a further relative indication to be sent to the A-IoT device reader.

[0129] As described with reference to S506a the A-IoT device 3-1 may also (optionally) determine, at S514a, a further recommended / suggested MCS, or whether or not a different MCS might be beneficial, and an associated further MCS indication (as described above).

[0130] If the data available at the A-IoT device 3-1 for a D2R transmission is not greater than TBS1 (as seen at S514b), then the A-IoT device 3-1 determines the number of padding bits (if any) that need to be added to the D2R data to reach the TBS2.

[0131] At S516, the A-IoT device 3-1 transmits, to the A-IoT device reader, on the PDRCH, a transport block (TB) of size equal to TBS2 comprising at least some of the remaining data stored in the transmission buffer of the A-IoT device 3-1. In a case where the data available at the A-IoT device 3-1 for a D2R transmission is greater than TBS2, the A-IoT device 3-1 includes, with this transmission, the further relative indication and any further MCS indication (e.g., I_mcs). In a case where the data available at the A-IoT device 3-1 for a D2R transmission is not greater than TBS2 no such indications need be provided (although it will be appreciated that an explicit 'relative' indication may be provided indicating that there is no remaining data) and the TB will include all the remaining D2R data together with any padding bits that may be needed - thus no further scheduling is required.

[0132] As indicated at S550, in a case where there is still further remaining data available at the A-IoT device 3-1, however, the A-IoT device reader and A-IoT device 3-1 may engage in one or more further rounds of scheduling (essentially corresponding to the steps described with reference to S510 to S516 but with a potentially different TBS (e.g., TBS3, …, etc.) and optionally MCS being used in each scheduling round).

[0133] As mentioned above, a relative amount / size indication may be indicate an absolute value of the relative amount / size (e.g., the ratio) of the remaining data, or may indicate one of a plurality of different possible relative amount / size (e.g., ratio) ranges, within which the relative amount / size (e.g., the ratio) of the remaining data is found, from an associated table (e.g., a ratio based table that is predefined, or configured by the A-IoT device reader as described with reference to S502, Fig. 5).

[0134] <Bitmap Used for Relative Indication (Absolute Value of Ratio)> 　　In a case where the relative indication indicates an absolute value for the relative amount / size (e.g., the ratio) of the remaining data, the absolute value may be determined from within a quantised range of possible values. For example, the range may be quantised into eighths and the indicated absolute value may be the closest quantum to the calculated relative amount / size (or the quantum that is immediately above the calculated relative amount / size). In this example, therefore, the relative indication may comprise a fixed size bitmap having a total of five bits (in this example) with two bits used to indicate an integer part of the indicated absolute value (from 0 to 3) and three bits used to indicate a decimal part of the quantised ratio value (e.g., '000' corresponds to 0, '001' corresponds to 0.125 (1 / 8), '111' corresponds to 0.875 (7 / 8), etc.).

[0135] Thus, when the A-IoT device reader determines the TBS to be used based on the Relative Indication, the selected TBS can be selected to ensure that it is either large enough for all the remaining data to be transmitted in a single message, or is the maximum TBS (e.g., if the remaining data amount / size is larger than the maximum TBS). Moreover, the TBS can be determined to be any value based on A-IoT device reader's algorithm. It will be appreciated that in some scenarios, the selected TBS2 may be smaller than the remaining data size (e.g., when available resources at the A-IoT device reader side are insufficient), even though the A-IoT device reader is aware that there is a large amount / size of remaining data at the A-IoT device, because only a relatively small TBS2 is available for assignment.

[0136] <Bitmap Used for Relative Indication (Ratio Table Based)> 　　As mentioned above, in a case where the relative indication indicates one of a plurality of different possible relative amount / size (e.g., ratio) ranges from an associated table, the bitmap used may have a fixed or a variable number of bits. Moreover, the different possible ranges may be partitioned uniformly or non-uniformly (between zero and one).

[0137] Possible relationships between a relative indication (ratio table based), ratio, and TBS used for subsequent scheduling will now be described, by way of example only, with reference to Tables 1 to 4. Tables 1 to 4 each show a different possible mapping between the bitmap used for a relative indication and the ratio (relative data amount / size) that the relative indication represents, and how the A-IoT device reader calculates the TBS (e.g., TBS2) for scheduling a subsequent D2R data transmission. It will be appreciated that whilst Tables 1 to 4 include a row showing a TBS (e.g., TBS2) for scheduling a subsequent D2R data transmission for illustrative purposes, where a ratio based table is configured by the A-IoT device reader, this information does not form part of that ratio based table.

[0138] Table 1 illustrates a first example in which a variable number of bits may be used to indicate one of a plurality of different ranges of ratios that are partitioned uniformly (between zero and one). As seen in Table 1, in this example, single bit indications '0' and '1' are respectively used to indicate a ratio of zero (i.e., no remaining data), and a ratio greater than one (i.e., more remaining data than the reference value (e.g., the previously scheduled TBS (e.g., TBS1 following the initial scheduling round))). For ratios between zero and one the ranges are partitioned into quarters with each quarter represented by a corresponding two bit relative indication.

[0139] As seen in Table 1, in this example, the subsequently scheduled TBS (e.g., TBS2) may be determined by the A-IoT device reader to be equal to the higher end of the range of possible values multiplied by the reference value (e.g., the previously scheduled TBS (e.g., TBS1 following the initial scheduling round)), thereby ensuring that the TBS is of sufficient size for transmission of all the remaining data indicated by the relative indication. For ratios greater than one, the subsequently scheduled TBS (e.g., TBS2) is determined by the A-IoT device reader to be equal to a multiplier (X1) multiplied by the reference value (e.g., the previously scheduled TBS (e.g., TBS1 following the initial scheduling round)). The multiplier (X1) may be set to any suitable value by the A-IoT device reader (e.g., X1 = 1.5).

[0140] It will be appreciated that the value of X1 may be: configured on a A-IoT device specific basis; common to a specific group of A-IoT devices 3-1 (or UEs 3 in general), for example that share a specific characteristic or capability; or may be cell specific (e.g., common to all A-IoT devices 3-1, or UEs 3 in general, in the cell). Moreover, the value of X1 may be configured dynamically (e.g., every time data is scheduled) or may be semi-persistent (e.g., only being changed relatively infrequently). It will be appreciated that there is no need to inform the specific multiplier to the A-IoT device 3-1 as it is only used at the A-IoT device reader side.

[0141] Turning to Table 2, this illustrates a second example in which a variable number of bits may be used to indicate one of a plurality of different ranges of ratios that are partitioned uniformly (between zero and one).

[0142] In this example, the single bit indications '1' and '0' are respectively used: to indicate a ratio between one and two (i.e., there is more remaining data than the reference value but less remaining data than twice the reference value); and to indicate a ratio greater than two (i.e., there is more remaining data than twice the reference value). For ratios between zero and one the ranges are partitioned into quarters with each quarter represented by a corresponding two bit relative indication. In this case no relative indication is provided in the event that there is no remaining data.

[0143] As seen in Table 2, in this example, the subsequently scheduled TBS (e.g., TBS2) may be determined by the A-IoT device reader to be equal to the higher end of the range of possible values multiplied by the reference value (e.g., the previously scheduled TBS (e.g., TBS1 following the initial scheduling round)), thereby ensuring that the TBS is of sufficient size for transmission of all the remaining data indicated by the relative indication. For ratios between one and two, the subsequently scheduled TBS (e.g., TBS2) is determined by the A-IoT device reader to be equal to a first multiplier (X1) multiplied by the reference value. For ratios greater than two, the subsequently scheduled TBS (e.g., TBS2) is determined by the A-IoT device reader to be equal to a second multiplier (X2) multiplied by the reference value. The multipliers (X1 and X2) may be set to any suitable values by the A-IoT device reader (e.g., X1 = 1.5, and X2 = 2.5). It will be appreciated that the values of X1 and X2 may be: configured on a A-IoT device specific basis; common to a specific group of A-IoT devices 3-1 (or UEs 3 in general), for example that share a specific characteristic or capability; or may be cell specific (e.g., common to all A-IoT devices 3-1, or UEs 3 in general, in the cell). Moreover, the values of X1 and X2 may be configured dynamically (e.g., every time data is scheduled) or may be semi-persistent (e.g., only being changed relatively infrequently). It will be appreciated that there is no need to inform the specific multipliers to the A-IoT device 3-1 as they are only used at the A-IoT device reader side.

[0144] It will be appreciated that the different examples illustrated in Table 1 and Table 2 may both be supported as different options by the communication system 1. The A-IoT device 3-1 may be (pre)configured to provide relative indications based on a specific one of the two examples, or may be configured to make a choice of which option to use to determine the relative indication (in which case an additional control bit may be used by the A-IoT device to allow the A-IoT device reader to identify which of the two options the A-IoT device 3-1 has used).

[0145] Turning to Table 3, this illustrates an example in which a variable number of bits may be used to indicate one of a plurality of different ranges of ratios that are partitioned non-uniformly (between zero and one).

[0146] In this example, the single bit indications '1' and '0' are respectively used: to indicate a ratio between one and 2.5 (i.e., there is more remaining data than the reference value but less remaining data than 2.5 times the reference value); and to indicate a ratio greater than 2.5 (i.e., there is more remaining data than 2.5 times the reference value). For ratios between zero and one the ranges are partitioned non-uniformly with smaller ranges for ratios closer to one (i.e., with a lowest from 0 to 1 / 3, the next range from 1 / 3 to 3 / 5, the next range from 3 / 5 to 5 / 6, and the next range from 5 / 6 to 1). It will be appreciated that these partitions are examples only, and the actual partitions may be configured flexibly (e.g., by the A-IoT device reader) for optimum scheduling.

[0147] As seen in Table 3, in this example, the subsequently scheduled TBS (e.g., TBS2) is determined by the A-IoT device reader to be equal to the higher end of the range of possible values multiplied by the reference value (e.g., the previously scheduled TBS (e.g., TBS1 following the initial scheduling round)), thereby ensuring that the TBS is of sufficient size for transmission of all the remaining data indicated by the relative indication. For ratios between one and 2.5, the subsequently scheduled TBS (e.g., TBS2) is determined by the A-IoT device reader to be equal to a first multiplier (X1) multiplied by the reference value. For ratios greater than 2.5, the subsequently scheduled TBS (e.g., TBS2) is determined by the A-IoT device reader to be equal to a second multiplier (X2) multiplied by the reference value. The multipliers (X1 and X2) may be set to any suitable values by the A-IoT device reader (e.g., X1 = 1.5, and X2 = 2.5). It will be appreciated that the values of X1 and X2 may be: configured on a A-IoT device specific basis; common to a specific group of A-IoT devices 3-1 (or UEs 3 in general), for example that share a specific characteristic or capability; or may be cell specific (e.g., common to all A-IoT devices 3-1, or UEs 3 in general, in the cell). Moreover, the values of X1 and X2 may be configured dynamically (e.g., every time data is scheduled) or may be semi-persistent (e.g., only being changed relatively infrequently). It will be appreciated that there is no need to inform the specific multipliers to the A-IoT device 3-1 as they are only used at the A-IoT device reader side.

[0148] Turning to Table 4, this illustrates an example in which a fixed number of bits may be used to indicate one of a plurality of different ranges of ratios that are partitioned uniformly (between zero and one).

[0149] In this example, a three bit relative indication is used. For example, '000' is used to indicate a ratio of zero (i.e., no remaining data). For ratios between zero and one the ranges are partitioned into quarters with each quarter represented by a corresponding three bit relative indication between '001' and '100'. For ratios greater than one: the three bit indication '101' is used to indicate a ratio between one and two (i.e., there is more remaining data than the reference value but less remaining data than twice the reference value); the three bit indication '110' is used to indicate a ratio between two and three (i.e., there is more remaining data than twice the reference value but less remaining data than three times the reference value); and the three bit indication '111' is used to indicate a ratio greater than three (i.e., there is more remaining data than three time the reference value).

[0150] As seen in Table 4, in this example, the subsequently scheduled TBS (e.g., TBS2) is determined by the A-IoT device reader to be equal to the higher end of the range of possible values multiplied by the reference value (e.g., the previously scheduled TBS (e.g., TBS1 following the initial scheduling round)), thereby ensuring that the TBS is of sufficient size for transmission of all the remaining data indicated by the relative indication. For ratios between one and two, the subsequently scheduled TBS (e.g., TBS2) is determined by the A-IoT device reader to be equal to a first multiplier (X1) multiplied by the reference value. For ratios between two and three, the subsequently scheduled TBS (e.g., TBS2) is determined by the A-IoT device reader to be equal to a second multiplier (X2) multiplied by the reference value. For ratios greater than three, the subsequently scheduled TBS (e.g., TBS2) is determined by the A-IoT device reader to be equal to a third multiplier (X3) multiplied by the reference value. The multipliers (X1, X2, and X3) may be set to any suitable values by the A-IoT device reader (e.g., X1 = 1.5, X2 = 2.5, X3 = 3.5). It will be appreciated that the values of X1, X2 and X3 may be: configured on a A-IoT device specific basis; common to a specific group of A-IoT devices 3-1 (or UEs 3 in general), for example that share a specific characteristic or capability; or may be cell specific (e.g., common to all A-IoT devices 3-1, or UEs 3 in general, in the cell). Moreover, the values of X1 and X2 may be configured dynamically (e.g., every time data is scheduled) or may be semi-persistent (e.g., only being changed relatively infrequently). It will be appreciated that there is no need to inform the specific multipliers to the A-IoT device 3-1 as they are only used at the A-IoT device reader side.

[0151] < Signalling Container> 　　There are a number of ways in which the relative indication (and any MCS indication and / or another remaining data indication) may be signalled. One way of signalling the indication (or indications) is as (layer 1 (L1)) D2R control information together with a MAC protocol data unit (PDU) carrying the D2R data in the previously scheduled TBS (e.g., TBS1). The signalling of L1 D2R control information together with a MAC PDU will now be described, by way of example only, with reference to Fig. 6.

[0152] Fig. 6 illustrates an example signalling container 600 for carrying L1 D2R control information 602 together with a MAC PDU 604 for assisting scheduling that may be implemented in the communication system 1.

[0153] As seen in Fig. 6, a relative indication (and any MCS indication) may be sent, together with other control information, as L1 D2R control information 602 forming a first (initial / start) portion of the signalling container 600. The MAC PDU 604 forms a second (end / final) portion of the signalling container 600.

[0154] It will be appreciated that, depending on configuration, as there may not always be remaining data the relative indication and the MCS indication (even when the communication system 1 supports such an indication) may not always be necessary in every PDRCH transmission carrying data (i.e., they are dynamic indications).

[0155] The L1 D2R control information 602 is configured in accordance with an appropriate (pre)configured 'L1 D2R control information format'. Specifically, the L1 D2R control information format comprises a plurality of fields 606-1, … 606-n, and 606-X (606) each configured for respectively carrying corresponding control information. One or more of the fields 606-1, … 606-n are each configured to have a corresponding fixed size (number of bits) and to carry associated standardised control information (e.g., in a similar manner to conventional uplink control information (UCI)). Another field 606-X is configured as a 'remaining data indication' (or other suitable name) field and is configured for carrying (when applicable) the relative indication (and any MCS indication and / or another remaining data indication).

[0156] The format of the remaining data indication field 606-X may be predefined to have a fixed bit size, or a variable bit size (e.g., when the relative indication has a variable bit size as indicated above). In a case where the remaining data indication field 606-X has a fixed bit size it may be located at any, predefined, location within the L1 D2R control information 602 (e.g., at the beginning, the end, or in amongst the other fields 606-1, … 606-n that carry associated standardised control information). This is because, in this case, the bit position of each bit field 606 will be fixed, and so the A-IoT device reader can determine what control information each bit field 606 represents based on the bit position of that bit field within the control information.

[0157] In a case where the remaining data indication field 606-X has a variable bit size, the remaining data indication field 606-X may be prepended at the beginning of the L1 D2R control information 602, or the remaining data indication field 606-X may be appended at the end of the L1 D2R control information 602 (e.g., the remaining data indication field 606-X may be provided before or after the other fields 606-1, … 606-n that carry associated standardised control information). In the example of Fig. 6, the remaining data indication field 606-X is shown appended at the end of the L1 D2R control information 602. In this case, the A-IoT device reader can still determine what control information each bit field 606 represents based on the bit position of that bit field within the control information (e.g., from the end or the start of the L1 D2R control information 602) and hence the bit field associated with the remaining data indication field 606-X (even though the A-IoT device reader may not know the exact size of the number of the remaining data indication field 606-X). It will be appreciated that where the remaining data indication field 606-X includes a relative indication (or an absolute 'BSR like' indication) together with an MCS indication if one of the indications has a fixed size it is relatively straightforward for the A-IoT device reader to discriminate between the bits of the relative indication (or an absolute 'BSR like' indication) and the MCS indication without requiring additional bits (e.g., an extra indication and / or padding bits) to assist identification of a start or end of the different indications.

[0158] In order for the A-IoT device reader to be able to determine the location of the L1 D2R control information 602 and the MAC PDU 604, the signalling container 600 may be provided with one or more predefined bit patterns defining a: preamble at the start of the signalling container 600 just before the L1 D2R control information 602; a midamble within the signalling container 600 just after the end the L1 D2R control information 602 / just before the start of the MAC PDU; and / or a postamble just after the end of the MAC PDU. Thus, the A-IoT device reader can determine the start of L1 D2R control information based on the preamble at the start of the L1 D2R control information 602 and / or can determine the end of L1 D2R control information based on the midamble at the end of the L1 D2R control information 602.

[0159] <Analysis> 　　The results of a simplified (idealised) analysis will now be provided to assist illustration of the benefits of using variations of the relative indication, as described with reference to Fig. 6 above, compared to the use of a conventional absolute indication (e.g., a BSR type indication). Specifically, the analysis compares use of an absolute indication (e.g., a BSR type indication) with: use of a relative indication of an absolute value of the ratio; use of a relative indication having a variable size bitmap according to the first example (of Table 1); and use of a relative indication having a variable size bitmap according to the second example (of Table 2).

[0160] It will be appreciated that the idealised analysis is based on a number of assumptions including: -　　The maxim message size =1000 bits; -　　The BSR type indication is a two bit (variable size) indication (as illustrated in the example of Table 5); -　　Uniform partitioning is used for the remaining data ranges - both for the BSR type indication (for remaining data between zero and the maximum message size), and for the relative indications (for ratios of the remaining data between 0 and 1); -　　Where applicable, the multipliers are set as follows: X1=1.5, X2=2.5.

[0161] It will be appreciated that, to help ensure a fair comparison, the BSR mapping table represented by Table 5 is enhanced, compared to a conventional BSR mapping table. Moreover, it will be appreciated that the analysis is based in an idealised resource allocation rather than a real A-IoT device reader based scheduling algorithm.

[0162] Tables 6 to 9 below show the results of the analysis for three different scenarios (Case 1, Case 2, and Case 3). Specifically, Tables 6 to 9 respectively show for each of the different indication types: the size of the subsequently scheduled TBS (e.g., TBS2), and the required padding bits, for each of the three different scenarios (Case 1, Case 2, and Case 3).

[0163] It can be seen that the use of the ratio indication has the potential to provide an efficient way to signal remaining data while minimising the need for padding bits albeit that in some scenarios an additional scheduling round may be needed (e.g., Case 3, Table 8).

[0164] < D2R Data Scheduling and Transmission Procedure (Hybrid Relative / Absolute Data Amount / Size Indication)> 　　As mentioned above (and as shown for Case 3, Table 8) specific (occasional) scenarios may occur in which the use of a relative indication might result in one more additional scheduling rounds than might otherwise be the case.

[0165] As mentioned above, to mitigate against such scenarios, the communication system 1 may support an enhanced data scheduling / transmission procedure based on a hybrid approach in which depending on the relative amount / size of (remaining) data at the A-IoT device 3-1, either an absolute amount / size indication (i.e., representing a fixed range of data size / amount) similar to a conventional BSR is provided, or a relative indication of the (remaining) data amount / size is provided.

[0166] One such method will be described, by way of example only, with reference to Fig. 7, which illustrates a simplified sequence diagram of another example data scheduling and transmission procedure that may be implemented in the communication system 1.

[0167] It will be appreciated that whilst the enhanced procedure of Fig. 7 is described in the specific context of an A-IoT device reader and A-IoT device 3-1, the principles encompassed by the enhanced procedure can be extended to a non-ambient IoT UE 3-2, 3-3 and an associated RAN node 5-1.

[0168] As seen in Fig. 7, in this example, before data scheduling the A-IoT device reader provides, at S702, the A-IoT device 3-1 with a set of information comprising: information for configuring a ratio based table; information for configuring an absolute data amount / size (BSR) based table; and information defining at least one threshold value for determining whether to use a relative indication or to use an absolute (BSR type) indication.

[0169] The set of information may be provided in any suitable manner (e.g., as an R2D message, as part of a random access procedure, on the PRDCH, and / or the like).

[0170] Effectively, the ratio based table configured by the information defines a mapping between each possible bit pattern that may be used as a relative indication, and a respective range of ratios. Effectively, the absolute data amount / size (BSR) based table configured by the information defines a mapping between each possible bit pattern that may be used as an absolute (BSR type) indication, and a respective range of data amounts / sizes. It will be appreciated that this set of information may not be needed if it is predefined at the A-IoT device 3-1. The threshold value corresponds to an appropriate ratio of remaining data to a reference value (e.g., a currently scheduled TBS (TBS1) in this example) above which the A-IoT device 3-1 will use an absolute (BSR type) indication based on the absolute data amount / size (BSR) based table in preference to a relative indication. The threshold value may be set (e.g., by the A-IoT device reader or other network node where appropriate) to any suitable value. By way of example only, the threshold may be set to be equal to multiplier X1 divided by multiplier X2, if those multipliers are configured at the A-IoT device reader (e.g., as in the example of Table 2).

[0171] The data scheduling commences, at S704, with the A-IoT device reader sending, on the PRDCH, a message for scheduling (allocating resources for) a subsequent D2R data transmission. The scheduling message may indicate a first TBS ('TBS1') based upon which the resources allocated for the D2R data have been determined.

[0172] If the data available at the A-IoT device 3-1 for a D2R transmission is greater than TBS1 (as seen at S706a), then the A-IoT device 3-1 determines a remaining data ratio and, based on the remaining data ratio, whether to use a relative indication or to use an absolute (BSR type) indication. Specifically, if the remaining data ratio is below (or possibly equal to) the threshold value then the A-IoT device 3-1 determines, based on the remaining data ratio, a bit pattern (of one or more bits) that should be used for an associated relative indication to be sent to the A-IoT device reader (e.g., based on the ratio based table). If, on the other hand, the remaining data ratio is above (or possibly equal to) the threshold value then the A-IoT device 3-1 determines, based on the amount / size of the remaining data, a bit pattern (of one or more bits) that should be used for an associated absolute (BSR type) indication to be sent to the A-IoT device reader (e.g., based on the absolute data amount / size (BSR) based table).

[0173] The A-IoT device 3-1 may also determine, at this stage, a recommended / suggested MCS (e.g., based on a BER for the PRDCH and / or some other suitable metric) or simply whether or not a different MCS might be beneficial. The A-IoT device 3-1 may also determine an associated MCS indication (e.g. 'I_mcs') to be sent to the A-IoT device reader to indicate the recommended / suggested MCS (or that the use of a different (or the same) MCS is suggested / recommended). For example, a multi-bit indication may be used to indicate a specific one of a set of (more than two) supported MCSs. Alternatively, a single bit indication may be used to indicate that the use of a different (or the same) MCS is suggested / recommended. For example, a bit set to '1' (or '0') may indicate a different MCS is suggested / recommended, whereas a bit set to '0' (or '1') - or the omission of the bit entirely - may indicate that use of the same MCS is suggested / recommended.

[0174] If the data available at the A-IoT device 3-1 for a D2R transmission is not greater than TBS1 (as seen at S706b), then the A-IoT device 3-1 determines the number of padding bits (if any) that need to be added to the D2R data to reach the TBS1.

[0175] At S708, the A-IoT device 3-1 transmits, to the A-IoT device reader, on the PDRCH, a transport block (TB) of size equal to TBS1 comprising at least some of the data stored in the transmission buffer of the A-IoT device 3-1. In a case where the data available at the A-IoT device 3-1 for a D2R transmission is greater than TBS1, the A-IoT device 3-1 includes, with this transmission, either the relative indication or the absolute (BSR type) indication (depending on which was determined at S706a), and an indication of whether a relative indication or an absolute (BSR type) indication is included (for example, an identifier of the table (e.g., a table index or the like) that was used to determine the indication included in the message). The A-IoT device 3-1 may also include, with this transmission, any MCS indication (e.g., I_mcs). In a case where the data available at the A-IoT device 3-1 for a D2R transmission is not greater than TBS1 no such indications need be provided (although it will be appreciated that an explicit indication may be provided indicating that there is no remaining data) and the TB will include all the D2R data together with any padding bits that may be needed - thus no further scheduling is required.

[0176] In a case where there is remaining data available at the A-IoT device 3-1, however, the A-IoT device reader determines, at S710, based on the relative indication, or the absolute (BSR type) indication, an appropriate new TBS ('TBS2') to use for subsequent scheduling. If needed, an appropriate MCS to be used may also be determined. If an MCS indication is provided with the D2R transmission sent at S708 any determination of the MCS may take the MCS indication into account. The A-IoT device reader also determines appropriate resources to allocate for a subsequent D2R remaining data transmission

[0177] The A-IoT device reader then sends, at S712, on the PRDCH, a message for scheduling (allocating resources for) the subsequent D2R remaining data transmission. The scheduling message sent at S712 may indicate the new TBS ('TBS2'), based upon which the resources allocated for the D2R remaining data have been determined.

[0178] If the remaining data available at the A-IoT device 3-1 for a subsequent D2R transmission is greater than the new TBS2 (as seen at S714a), then the A-IoT device 3-1 may determine a remaining data ratio and, based on the remaining data ratio, whether to use a relative indication or to use an absolute (BSR type) indication. Specifically, if the remaining data ratio is below (or possibly equal to) the threshold value then the A-IoT device 3-1 determines, based on the remaining data ratio, a bit pattern (of one or more bits) that should be used for an associated relative indication to be sent to the A-IoT device reader. If, on the other hand, the remaining data ratio is above (or possibly equal to) the threshold value then the A-IoT device 3-1 determines, based on the amount / size of the remaining data, a bit pattern (of one or more bits) that should be used for an associated absolute (BSR type) indication to be sent to the A-IoT device reader.

[0179] As described with reference to S706a the A-IoT device 3-1 may also (optionally) determine, at S714a, a further recommended / suggested MCS, or whether or not a different MCS might be beneficial, and an associated further MCS indication (as described above).

[0180] If the data available at the A-IoT device 3-1 for a D2R transmission is not greater than TBS1 (as seen at S714b), then the A-IoT device 3-1 determines the number of padding bits (if any) that need to be added to the D2R data to reach the TBS2.

[0181] At S716, the A-IoT device 3-1 transmits, to the A-IoT device reader, on the PDRCH, a transport block (TB) of size equal to TBS2 comprising at least some of the remaining data stored in the transmission buffer of the A-IoT device 3-1. In a case where the data available at the A-IoT device 3-1 for a D2R transmission is greater than TBS2, the A-IoT device 3-1 includes, with this transmission, either the relative indication or the absolute (BSR type) indication (depending on which was determined at S714a), and an indication of whether a relative indication or an absolute (BSR type) indication is included (for example, an identifier of the table (e.g., a table index or the like) that was used to determine the indication included in the message). The A-IoT device 3-1 may also include, with this transmission, any MCS indication (e.g., I_mcs). In a case where the data available at the A-IoT device 3-1 for a D2R transmission is not greater than TBS2 no such indications need be provided (although it will be appreciated that an explicit indication may be provided indicating that there is no remaining data) and the TB will include all the remaining D2R data together with any padding bits that may be needed - thus no further scheduling is required.

[0182] As indicated at S750, in a case where there is still further remaining data available at the A-IoT device 3-1, however, the A-IoT device reader and A-IoT device 3-1 may engage in one or more further rounds of scheduling (essentially corresponding to the steps described with reference to S710 to S716 but with a potentially different TBS (e.g., TBS3, …, etc.) and optionally MCS being used in each scheduling round).

[0183] It will be appreciated that the relative indication, when used, may be any relative indication as described with reference to Fig. 5 (e.g., a relative indication as described with reference to any of Tables 1 to 4). Similarly, the absolute (BSR type) indication may be , when used, may be any suitable indication (e.g., as described with reference to Table 5).

[0184] In a variation on the method described with reference to Fig. 7, as an alternative to (or in addition to) being able to switch to an absolute (BSR type) indication. The A-IoT device 3-1 may be able to switch (e.g., based on the one or more threshold values configured by the A-IoT device reader at S702) to using a different reference value for determining the ratio of the remaining data to that reference value. For example, the A-IoT device 3-1 may be able to switch from using a first ratio defined, according to a first definition, as the ratio of the remaining data to a currently scheduled TBS (e.g. TBS1) to a second ratio defined, according to a second definition, as the ratio of the remaining data to a predefined, or network configured, data amount / size (e.g., a maximum TBS (e.g., 1000 bits for A-IoT) or particular proportion (e.g., half) of a maximum TBS (e.g., 500 bits for A-IoT)).

[0185] It will be appreciated that, in this case another ratio based table may be configured (e.g., by the A-IoT device reader at S702). Effectively, this (additional) ratio based table configured by the information may define a mapping between each possible bit pattern that may be used as a relative indication, and a respective range of ratios defined according to the second definition. Nevertheless, whilst another ratio based table may be configured, it will be appreciated that an additional ratio based table does not have to be defined. For example, the same ratio based table may be used based on the different reference value used in the second definition, because the A-IoT device reader will be aware of the different reference value and can indicate that value to the A-IoT device 3-1.

[0186] Moreover, at S708 (or S716) in a case where the data available at the A-IoT device 3-1 for a D2R transmission is greater than the currently scheduled TBS (e.g., TBS1), the A-IoT device 3-1 may include, with this transmission, the relative indication based on the second definition (if the A-IoT device 3-1 has determined that such a relative indication should be used) and an indication that that specific type of relative indication is included (e.g., an identifier of a ratio based table (e.g., a table index) that is based on ratios according to the second definition). The A-IoT device 3-1 may also include, with this transmission, any MCS indication (e.g., I_mcs).

[0187] It will appreciated that there are a number of ways in which the relative indication or the absolute (BSR) indication (and any MCS indication) may be signalled. For example, one way of signalling the indication (or indications) is as L1 D2R control information together with a MAC protocol data unit (PDU) carrying the D2R data in the previously scheduled TBS (e.g., TBS1). The signalling of L1 D2R control information together with a MAC PDU may, for example, be as described above with reference to Fig. 6 except that either the absolute (BSR) indication or the absolute (BSR) indication may be signalled in the corresponding bit field of the L1 D2R control information, and that an additional fixed size indication from which the type of indication provided can be derived (e.g., a table index) may also be included.

[0188] As mentioned above the communication system 1 may alternatively (or additionally) support data transmission / scheduling as part of one or more enhanced RA based SDT procedures in which an A-IoT device 3-1 can provide a small data payload together with an indication of a relative amount / size of data remaining after the SDT, as part of a contention based RACH procedure.

[0189] The two possible enhanced RA based SDT procedures that may be supported in the communication system 1 and associated techniques will now be described in more detail, by way of example only, with reference to Figs. 8 and 9.

[0190] <Two-step RA based SDT> 　　As mentioned above, the communication system 1 may support data transmission / scheduling as part of an enhanced two-step RA based SDT procedure in which a relative indication of remaining data may be provided as part of MsgA.

[0191] One such method will be described, by way of example only, with reference to Fig. 8, which illustrates a simplified sequence diagram of an example two-step RA based SDT procedure that may be implemented in the communication system 1.

[0192] It will be appreciated that whilst the enhanced procedure of Fig. 8 is described in the specific context of an A-IoT device reader and A-IoT device 3-1, the principles encompassed by the enhanced procedure can be extended to a non-ambient IoT UE 3-2, 3-3 and an associated RAN node 5-1.

[0193] As seen in Fig. 8, in this example, when the A-IoT device 3-1 has data to transmit (at S806), the A-IoT device may determine whether or not the data available at the A-IoT device 3-1 for a D2R transmission is greater than the amount / size of data that will be provided in a subsequent SDT (e.g., 'TBS1').

[0194] If the data available at the A-IoT device 3-1 for a D2R transmission is greater than the amount / size of data that will be provided in a subsequent SDT (TBS1) (the scenario illustrated in Fig. 8) then the A-IoT device 3-1 determines a remaining data ratio and, based on the remaining data ratio, a bit pattern (of one or more bits) that should be used for an associated indication of the remaining data.

[0195] The indication of remaining data may, for example, be a relative indication. In a case where the indication of remaining data is a relative indication it may a relative indication in accordance with any of the examples described above. For example, the relative indication may indicate a calculated absolute value for the relative amount / size (e.g., a ratio) of the remaining data within a quantised range of possible values. Nevertheless, the relative indication may indicate one of a plurality of different possible relative amount / size (e.g., ratio) ranges from an associated ratio based table (pre)configured at the A-IoT device 3-1. The relative indication may, for example, be based on a ratio based table indicating associated mappings between each of a plurality of different ratio ranges and a respective bit pattern (of one or more bits) to be used for the relative indication. The mappings represented by the ratio based table may, for example, correspond to the mappings illustrated in any of Tables 1 to 4 above.

[0196] It will also be appreciated that the A-IoT device 3-1 may be configured to use a hybrid approach (similar to that described with reference to Fig. 7) in which, depending on the relative amount / size of remaining data at the A-IoT device 3-1, either an absolute (BSR type) indication, or a relative indication (as described above) is provided. Specifically, in a scenario in which a hybrid approach is used, if the data available at the A-IoT device 3-1 is below (or possibly equal to) a configured threshold value then the A-IoT device 3-1 determines, based on the remaining data ratio, a bit pattern (of one or more bits) that should be used for an associated relative indication to be sent to the A-IoT device reader (e.g., based on a ratio based table). If, on the other hand, the remaining data ratio is above (or possibly equal to) that configured threshold value, then the A-IoT device 3-1 determines, based on the amount / size of the remaining data, a bit pattern (of one or more bits) that should be used for an associated absolute (BSR type) indication to be sent to the A-IoT device reader (e.g., based on the absolute data amount / size (BSR) based table). It will be appreciated that the mappings represented by any absolute data amount / size (BSR) based table may, for example, correspond to the mappings illustrated in Table 5 above.

[0197] It will be appreciated that regardless of whether or not a hybrid approach is used, where a ratio based table (and / or an absolute data amount / size (BSR) based table) is used that table may be configured by higher layer signalling in an earlier procedure. If no such ratio based table (and / or absolute data amount / size (BSR) based table) has yet been configured (even when the communication system 1 supports the use of such a ratio / BSR based table), then the A-IoT device 3-1 may be configured to provide a relative indication of a calculated absolute value for the relative amount / size (e.g., a ratio) of the remaining data.

[0198] It will be appreciated that in a scenario in which the data available at the A-IoT device 3-1 for a D2R transmission is not greater than the amount / size of data that will be provided in a subsequent SDT, then the A-IoT device 3-1 need not provide a relative indication (or absolute (BSR type) indication where applicable if a hybrid approach is being used). The A-IoT device 3-1 may, nevertheless, determine a number of padding bits (if applicable) in such a scenario.

[0199] As described above with reference to Figs. 5 and 7, the A-IoT device 3-1 may also determine a recommended / suggested MCS or simply whether or not a different MCS might be beneficial and an associated MCS indication (e.g. 'I_mcs') to be sent to the A-IoT device reader to indicate the recommended / suggested MCS (or that the use of a different (or the same) MCS is suggested / recommended).

[0200] At S808, the A-IoT device 3-1 transmits, to the A-IoT device reader, the first message (MsgA) of the two-step RA based SDT procedure including the small data payload. In the scenario illustrated in Fig. 8 (i.e., there is remaining data), the A-IoT device 3-1 includes, with this transmission, the relative indication (or possibly an absolute (BSR type) indication if a hybrid approach is being used) and any MCS indication (e.g., I_mcs). It will be appreciated that, if a hybrid approach is being used, then this first message (MsgA) of the two-step RA based SDT procedure may also include an indication of whether a relative indication or an absolute (BSR type) indication is included (for example, an identifier of the table (e.g., a table index or the like).

[0201] As those skilled in the art will appreciate, the first message (MsgA) of the two-step RA based SDT procedure including the small data payload may in other respects correspond to the first message of a conventional two-step RA based SDT procedure (including, for example, a random access preamble and a resume request). Nevertheless, the first message (MsgA) of the two-step RA based SDT procedure may be the first message of a modified (e.g., A-IoT specific) two-step RA procedure, and may include information other than a conventional random access preamble or a resume request.

[0202] In a scenario in which there is no remaining data then no such indications need be provided (although it will be appreciated that an explicit indication may be provided indicating that there is no remaining data) and the SDT will include all the data together with any padding bits that may be needed - thus no further scheduling is required.

[0203] In the scenario illustrated in Fig. 8 (i.e., there is remaining data), the A-IoT device reader determines, at S810, an appropriate TBS ('TBS2') to use for subsequent scheduling and, if needed, an appropriate MCS to be used. If an MCS indication is provided with the transmission sent at S808 any determination of an MCS may take the MCS indication into account. The A-IoT device reader also determines appropriate resources to allocate for a subsequent D2R remaining data transmission.

[0204] The A-IoT device reader then sends, at S812, the second message (MsgB) of the two-step RA based SDT procedure including scheduling (allocating resources for) a subsequent D2R remaining data transmission. The message sent at S812 may indicate the new TBS ('TBS2'), based upon which the resources allocated for the remaining data have been determined.

[0205] As those skilled in the art will appreciate, the second message (MsgB) of the two-step RA based SDT procedure may in other respects correspond to the second message of a conventional two-step RA based SDT procedure (including, for example, a random access response and a release (with suspend) instruction). Nevertheless, the second message (MsgB) of the two-step RA based SDT procedure may be the second message of a modified (e.g., A-IoT specific) two-step RA procedure, and may include information other than a conventional random access response and a release (with suspend) instruction.

[0206] It will be appreciated that the subsequent data transmission and any further scheduling rounds may proceed essentially as described with reference to Fig. 5 or Fig. 7.

[0207] It will be appreciated that whilst this example is described in the context of a relative data amount / size defined as a ratio of a (remaining) data amount / size to a current TBS for SDT ('TBS1'), the relative data amount / size may be defined differently. For example, the relative data amount / size may be defined as a ratio of a (remaining) data amount / size to a pre-defined fixed data amount / size - for example the maximum SDT (e.g., 1000 bits for A-IoT), half the maximum SDT (e.g., 500 bits for A-IoT), and / or the like.

[0208] It will also be appreciated that whilst the data transmission / scheduling shown in Fig. 8 is described in the context of an enhanced two-step RA based SDT procedure, the principles described can be applied to data transmission / scheduling as part of a dedicated A-IoT two-step RA procedure. For example, the relative indication (or possibly an absolute (BSR type) indication if a hybrid approach is being used) and any MCS indication (e.g., I_mcs) may be provided as a first message (e.g., A-IoT Msg1) of the dedicated A-IoT two-step RA procedure. Similarly, the scheduling (allocating resources for) a subsequent D2R remaining data transmission may be provided in a second message (e.g., A-IoT Msg2) of the dedicated A-IoT two-step RA procedure.

[0209] <Four-step RA based SDT> 　　As mentioned above, the communication system 1 may support data transmission / scheduling as part of an enhanced four-step RA based SDT procedure in which a relative indication of remaining data may be provided as part of Msg3.

[0210] One such method will be described, by way of example only, with reference to Fig. 9, which illustrates a simplified sequence diagram of an example four-step RA based SDT procedure that may be implemented in the communication system 1.

[0211] It will be appreciated that whilst the enhanced procedure of Fig. 9 is described in the specific context of an A-IoT device reader and A-IoT device 3-1, the principles encompassed by the enhanced procedure can be extended to a non-ambient IoT UE 3-2, 3-3 and an associated RAN node 5-1.

[0212] As seen in Fig. 9, in this example, when the A-IoT device 3-1 has data to transmit (at S906), the A-IoT device 3-1 transmits, at S908, to the A-IoT device reader, the first message (Msg1) of the four-step RA based SDT procedure. As those skilled in the art will appreciate, the first message (Msg1) of the four-step RA based SDT procedure may correspond to the first message of a conventional four-step RA based SDT procedure (including, for example, a random access preamble). Nevertheless, the first message (Msg1) of the four-step RA based SDT procedure may be the first message of a modified (e.g., A-IoT specific) four-step RA procedure, and may include information other than a conventional random access preamble.

[0213] In response (at S910) the A-IoT device reader responds with the second message (Msg2) of the four-step RA based SDT procedure. As those skilled in the art will appreciate, the second message (Msg2) of the four-step RA based SDT procedure may correspond to the second message of a conventional four-step RA based SDT procedure (e.g., a conventional RAR including, for example, a TA command, an uplink grant field indicating resources to be used in a subsequent transmission, an MCS field, a TPC command value, and / or the like). Nevertheless, the second message (Msg2) of the four-step RA based SDT procedure may be the second message of a modified (e.g., A-IoT specific) four-step RA procedure, and may include information other than that used for conventional RAR.

[0214] The A-IoT device 3-1 determines, at S912, whether or not the data available at the A-IoT device 3-1 for a D2R transmission is greater than the amount / size of data that will be provided in a subsequent SDT (e.g., 'TBS1'). If the data available at the A-IoT device 3-1 for a D2R transmission is greater than the amount / size of data that will be provided in a subsequent SDT (TBS1) (the scenario illustrated in Fig. 9) then the A-IoT device 3-1 determines a remaining data ratio and, based on the remaining data ratio, a bit pattern (of one or more bits) that should be used for an associated indication of the remaining data.

[0215] The indication of remaining data may, for example, be a relative indication. In a case where the indication of remaining data is a relative indication it may a relative indication in accordance with any of the examples described above. For example, the relative indication may indicate a calculated absolute value for the relative amount / size (e.g., a ratio) of the remaining data within a quantised range of possible values. Nevertheless, the relative indication may indicate one of a plurality of different possible relative amount / size (e.g., ratio) ranges from an associated ratio based table (pre)configured at the A-IoT device 3-1. The relative indication may, for example, be based on a ratio based table indicating associated mappings between each of a plurality of different ratio ranges and a respective bit pattern (of one or more bits) to be used for the relative indication. The mappings represented by the ratio based table may, for example, correspond to the mappings illustrated in any of Tables 1 to 4 above.

[0216] It will also be appreciated that the A-IoT device 3-1 may be configured to use a hybrid approach (similar to that described with reference to Fig. 7) in which, depending on the relative amount / size of remaining data at the A-IoT device 3-1, either an absolute (BSR type) indication, or a relative indication (as described above) is provided. Specifically, in a scenario in which a hybrid approach is used, if the data available at the A-IoT device 3-1 is below (or possibly equal to) a configured threshold value then the A-IoT device 3-1 determines, based on the remaining data ratio, a bit pattern (of one or more bits) that should be used for an associated relative indication to be sent to the A-IoT device reader (e.g., based on a ratio based table). If, on the other hand, the remaining data ratio is above (or possibly equal to) that configured threshold value, then the A-IoT device 3-1 determines, based on the amount / size of the remaining data, a bit pattern (of one or more bits) that should be used for an associated absolute (BSR type) indication to be sent to the A-IoT device reader (e.g., based on the absolute data amount / size (BSR) based table). It will be appreciated that the mappings represented by any absolute data amount / size (BSR) based table may, for example, correspond to the mappings illustrated in Table 5 above.

[0217] It will be appreciated that regardless of whether or not a hybrid approach is used, where a ratio based table (and / or an absolute data amount / size (BSR) based table) is used that table may be configured by higher layer signalling in an earlier procedure. If no such ratio based table (and / or absolute data amount / size (BSR) based table) has yet been configured (even when the communication system 1 supports the use of such a ratio / BSR based table), then the A-IoT device 3-1 may be configured to provide a relative indication of a calculated absolute value for the relative amount / size (e.g., a ratio) of the remaining data.

[0218] It will be appreciated that in a scenario in which the data available at the A-IoT device 3-1 for a D2R transmission is not greater than the amount / size of data that will be provided in a subsequent SDT, then the A-IoT device 3-1 need not provide a relative indication (or absolute (BSR type) indication where applicable if a hybrid approach is being used). The A-IoT device 3-1 may, nevertheless, determine a number of padding bits (if applicable) in such a scenario.

[0219] As described above with reference to Figs. 5 and 7, the A-IoT device 3-1 may also determine a recommended / suggested MCS or simply whether or not a different MCS might be beneficial and an associated MCS indication (e.g. 'I_mcs') to be sent to the A-IoT device reader to indicate the recommended / suggested MCS (or that the use of a different (or the same) MCS is suggested / recommended).

[0220] At S914, the A-IoT device 3-1 transmits, to the A-IoT device reader, the third message (Msg3) of the four-step RA based SDT procedure including the small data payload. In the scenario illustrated in Fig. 9 (i.e., there is remaining data), the A-IoT device 3-1 includes, with this transmission, the relative indication (or possibly an absolute (BSR type) indication if a hybrid approach is being used) and any MCS indication (e.g., I_mcs). It will be appreciated that, if a hybrid approach is being used, then this third message (Msg3) of the four-step RA based SDT procedure may also include an indication of whether a relative indication or an absolute (BSR type) indication is included (for example, an identifier of the table (e.g., a table index or the like)).

[0221] As those skilled in the art will appreciate, the third message (Msg3) of the four-step RA based SDT procedure including the small data payload may in other respects correspond to the third message of a conventional four-step RA based SDT procedure (including, for example, a resume request). Nevertheless, the third message (Msg3) of the four-step RA based SDT procedure may be the third message of a modified (e.g., A-IoT specific) four-step RA procedure, and may include information other than a resume request.

[0222] In a scenario in which there is no remaining data then no such indications need be provided (although it will be appreciated that an explicit indication may be provided indicating that there is no remaining data) and the SDT will include all the data together with any padding bits that may be needed - thus no further scheduling is required.

[0223] In the scenario illustrated in Fig. 9 (i.e., there is remaining data), the A-IoT device reader determines, at S916, an appropriate TBS ('TBS2') to use for subsequent scheduling and, if needed, an appropriate MCS to be used. If an MCS indication is provided with the D2R transmission sent at S914 any determination of an MCS may take the MCS indication into account. The A-IoT device reader also determines appropriate resources to allocate for a subsequent D2R remaining data transmission.

[0224] The A-IoT device reader then sends, at S918, the fourth message (Msg4) of the four-step RA based SDT procedure including scheduling (allocating resources for) a subsequent remaining data transmission. The message sent at S918 may indicate the new TBS ('TBS2'), based upon which the resources allocated for the remaining data have been determined.

[0225] As those skilled in the art will appreciate, the fourth message (Msg4) of the four-step RA based SDT procedure may in other respects correspond to the fourth message of a conventional four-step RA based SDT procedure (including, for example, a release (with suspend) instruction). Nevertheless, the fourth message (Msg4) of the four-step RA based SDT procedure may be the fourth message of a modified (e.g., A-IoT specific) four-step RA procedure, and may include information other than a conventional release (with suspend) instruction.

[0226] It will be appreciated that the subsequent data transmission and any further scheduling rounds may proceed essentially as described with reference to Fig. 5 or Fig. 7.

[0227] It will be appreciated that whilst this example is described in the context of a relative data amount / size defined as a ratio of a (remaining) data amount / size to a current TBS for SDT ('TBS1'), the relative data amount / size may be defined differently. For example, the relative data amount / size may be defined as a ratio of a (remaining) data amount / size to a pre-defined fixed data amount / size - for example the maximum SDT (e.g., 1000 bits for A-IoT), half the maximum SDT (e.g., 500 bits for A-IoT), and / or the like.

[0228] It will also be appreciated that whilst the data transmission / scheduling shown in Fig. 9 is described in the context of an enhanced four-step RA based SDT procedure, the principles described can be applied to data transmission / scheduling as part of a dedicated A-IoT four-step RA procedure. For example, the relative indication (or possibly an absolute (BSR type) indication if a hybrid approach is being used) and any MCS indication (e.g., I_mcs) may be provided as a third message (e.g., A-IoT Msg3) of the dedicated A-IoT four-step RA procedure. Similarly, the scheduling (allocating resources for) a subsequent D2R remaining data transmission may be provided in a fourth message (e.g., A-IoT Msg4) of the dedicated A-IoT four-step RA procedure.

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

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

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

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

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

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

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

[0236] <Ambient IoT device> 　　Fig. 11 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 of Fig. 1. As shown, the ambient IoT device 3-1 (also referred to simply as an A-IoT device 3-1) has a transceiver circuit 331 that is operable to transmit signals to and to receive signals from a RAN node 5-1 (and / or an assisting node 5-2, and / or an intermediate node 5-2) via one or more antenna 333 (e.g., comprising one or more antenna elements).

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

[0238] It will however be appreciated that the energy harvesting circuitry 331-1 may alternatively not form part of the transceiver circuit 331, but instead is its own module. For example, this may be the case when the energy to be harvested does not originate from signals transmitted to the A-IoT device 3-1. By way of example only, the A-IoT device 3-1 may harvest energy from solar cells such as dye-sensitised solar cells (DSSCs).

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

[0240] In this example, the transceiver circuit 331 may also have a signal amplifier 331-3 (which may utilise energy harvested by the energy harvesting circuitry 331-1) for amplifying any modulated backscattered signal to be reflected by the A-IoT device 3-1 for receipt at another device.

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

[0242] The controller 337 is configured to control overall operation of the A-IoT device 3-1 by, in this example, program instructions or software instructions stored within memory 339. As shown, these software instructions include, among other things, an operating system 341, and a communication control module 343.

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

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

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

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

[0247] As shown, the RAN node 5-1 has a transceiver circuit 51 for transmitting signals to and for receiving signals from the communication devices (such as UEs 3-2; 3-3, A-IoT devices 3-1, and possibly assisting or intermediate devices 5-2) via one or more antenna 53 (e.g., a single or multi-panel antenna array / massive antenna), and a core network interface 55 for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the RAN node 5-1 may also be coupled to other base stations via an appropriate interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR). The RAN node 5-1 has a controller 57 to control the operation of the RAN node 5-1. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the RAN node 5-1 by, in this example, program instructions or software instructions stored within memory 59.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0283] For example, the whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes. 　　(Supplementary note 1) 　　A method performed by a mobile device, the method comprising: 　　transmitting, to an access network node, first data and information indicating that the mobile device has remaining data to be transmitted in a case where the mobile device has data to be transmitted whose transport block size is larger than the transport block size of the first data. 　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　the information indicating that the mobile device has the remaining data to be transmitted includes information indicating a transport block size of remaining data to be transmitted. 　　(Supplementary note 3) 　　The method according to supplementary note 2, wherein 　　the information indicating the transport block size of the remaining data includes at least one of: 　　　　information indicating a ratio of the transport block size of the remaining data and the transport block size for the first data, 　　　　information indicating a ratio of the transport block size of the remaining data and a preconfigured transport block size for the first data, or 　　　　information indicating a ratio of the transport block size of the remaining data and a fixed transport block size. 　　(Supplementary note 4) 　　The method according to supplementary note 3, wherein 　　the information indicating the ratio is represented by a fixed size of bits using a absolute value of ratio. 　　(Supplementary note 5) 　　The method according to supplementary note 3, wherein 　　the information indicating the ratio is represented by variable sizes of bits using at least one preconfigured mapping table. 　　(Supplementary note 6) 　　The method according to any one of supplementary notes 3 to 5, wherein 　　the information indicating the ratio is used by the access network node to calculate an actual transport data size of the remaining data to be transmitted using at least one configured parameter or at least one constant value. 　　(Supplementary note 7) 　　The method according to any one of supplementary notes 3 to 6, wherein 　　the transmitting the information indicating that the mobile device has remaining data to be transmitted is performed by determining whether to perform using a threshold. 　　(Supplementary note 8) 　　The method according to any one of supplementary notes 2 to 7, wherein 　　the information indicating the transport block size of the remaining data includes information indicating a Modulation and Coding Scheme (MCS) index. 　　(Supplementary note 9) 　　The method according to any one of supplementary notes 2 to 8, wherein 　　a location of control information including the information indicating the transport block size of the remaining data is indicated by a preamble or a midamble or as defined in advance. 　　(Supplementary note 10) 　　The method according to any one of supplementary notes 1 to 9, further comprising: 　　receiving, from the access network node, information for scheduling resources for transmitting the first data and information indicating the transport block size for the first data, and wherein 　　the transmitting the first data and the information indicating that the mobile device has the remaining data to be transmitted is performed based on the information for scheduling the resources for transmitting the first data and the information indicating the transport block size for the first data. 　　(Supplementary note 11) 　　The method according to supplementary note 1, wherein 　　the transmitting the first data and the information indicating that the mobile device has remaining data to be transmitted is performed by a 2-step or 4-step random access procedure. 　　(Supplementary note 12) 　　The method according to supplementary note 11, wherein 　　the transmitting the first data and the information indicating that the mobile device has remaining data to be transmitted is performed by transmitting a message A (MsgA) or a message 3 (Msg 3). 　　(Supplementary note 13) 　　The method according to supplementary note 11 or 12, wherein 　　the transmitting the first data and the information indicating that the mobile device has remaining data to be transmitted is performed by a small data transmission (SDT) procedure. 　　(Supplementary note 14) 　　The method according to any one of supplementary notes 1 to 13, wherein 　　the transmitting the first data and the information indicating that the mobile device has remaining data to be transmitted is performed via a physical device-to-reader channel. 　　(Supplementary note 15) 　　A method performed by an access network node, the method comprising: 　　receiving, from a mobile device, first data and information indicating that the mobile device has remaining data to be transmitted in a case where the mobile device has data to be transmitted whose transport block size is larger than the transport block size of the first data. 　　(Supplementary note 16) 　　A mobile device comprising: 　　means for transmitting, to an access network node, first data and information indicating that the mobile device has remaining data to be transmitted in a case where the mobile device has data to be transmitted whose transport block size is larger than the transport block size of the first data. 　　(Supplementary note 17) 　　An access network node, the method comprising: 　　receiving, from a mobile device, first data and information indicating that the mobile device has remaining data to be transmitted in a case where the mobile device has data to be transmitted whose transport block size is larger than the transport block size of the first data.

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

[0285] 1 COMMUNICATION SYSTEM 3 USER EQUIPMENT 5 BASE STATION 7 CORE NETWORK 9 CELL 10 CONTROL PLANE FUNCTIONS 11 USER PLANE FUNCTIONS 21 EXTERNAL DATA NETWORK 31 TRANSCEIVER CIRCUIT 33 ANTENNA 35 USER INTERFACE 37 CONTROLLER 39 MEMORY 41 OPERATING SYSTEM 43 COMMUNICATIONS CONTROL MODULE 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 331 TRANSCEIVER CIRCUIT 331-1 ENERGY HARVESTING CIRCUITRY 331-2 MODULATION CIRCUITRY 331-3 SYGNAL 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

Claims

1. A method performed by a mobile device, the method comprising: 　　transmitting, to an access network node, first data and information indicating that the mobile device has remaining data to be transmitted in a case where the mobile device has data to be transmitted whose transport block size is larger than the transport block size of the first data.

2. The method according to claim 1, wherein 　　the information indicating that the mobile device has the remaining data to be transmitted includes information indicating a transport block size of remaining data to be transmitted.

3. The method according to claim 2, wherein 　　the information indicating the transport block size of the remaining data includes at least one of: 　　　　information indicating a ratio of the transport block size of the remaining data and the transport block size for the first data, 　　　　information indicating a ratio of the transport block size of the remaining data and a preconfigured transport block size for the first data, or 　　　　information indicating a ratio of the transport block size of the remaining data and a fixed transport block size.

4. The method according to claim 3, wherein 　　the information indicating the ratio is represented by a fixed size of bits using a absolute value of ratio.

5. The method according to claim 3, wherein 　　the information indicating the ratio is represented by variable sizes of bits using at least one preconfigured mapping table.

6. The method according to any one of claims 3 to 5, wherein 　　the information indicating the ratio is used by the access network node to calculate an actual transport data size of the remaining data to be transmitted using at least one configured parameter or at least one constant value.

7. The method according to any one of claims 3 to 6, wherein 　　the transmitting the information indicating that the mobile device has remaining data to be transmitted is performed by determining whether to perform using a threshold.

8. The method according to any one of claims 2 to 7, wherein 　　the information indicating the transport block size of the remaining data includes information indicating a Modulation and Coding Scheme (MCS) index.

9. The method according to any one of claims 2 to 8, wherein 　　a location of control information including the information indicating the transport block size of the remaining data is indicated by a preamble or a midamble or as defined in advance.

10. The method according to any one of claims 1 to 9, further comprising: 　　receiving, from the access network node, information for scheduling resources for transmitting the first data and information indicating the transport block size for the first data, and wherein 　　the transmitting the first data and the information indicating that the mobile device has the remaining data to be transmitted is performed based on the information for scheduling the resources for transmitting the first data and the information indicating the transport block size for the first data.

11. The method according to claim 1, wherein 　　the transmitting the first data and the information indicating that the mobile device has remaining data to be transmitted is performed by a 2-step or 4-step random access procedure.

12. The method according to claim 11, wherein 　　the transmitting the first data and the information indicating that the mobile device has remaining data to be transmitted is performed by transmitting a message A (MsgA) or a message 3 (Msg 3).

13. The method according to claim 11 or 12, wherein 　　the transmitting the first data and the information indicating that the mobile device has remaining data to be transmitted is performed by a small data transmission (SDT) procedure.

14. The method according to any one of claims 1 to 13, wherein 　　the transmitting the first data and the information indicating that the mobile device has remaining data to be transmitted is performed via a physical device-to-reader channel.

15. A method performed by an access network node, the method comprising: 　　receiving, from a mobile device, first data and information indicating that the mobile device has remaining data to be transmitted in a case where the mobile device has data to be transmitted whose transport block size is larger than the transport block size of the first data.

16. A mobile device comprising: 　　means for transmitting, to an access network node, first data and information indicating that the mobile device has remaining data to be transmitted in a case where the mobile device has data to be transmitted whose transport block size is larger than the transport block size of the first data.

17. An access network node comprising: 　　means for receiving, from a mobile device, first data and information indicating that the mobile device has remaining data to be transmitted in a case where the mobile device has data to be transmitted whose transport block size is larger than the transport block size of the first data.

Images