Reader device, communication device, and method

Abstract

A method is performed by a reader device. The method includes: receiving, from a communication device, at least one Medium Access Control (MAC) protocol data unit (PDU), each of which includes a MAC header including segmentation information indicating at least one of:　whether a corresponding MAC PDU is segmented data from an application data payload, whether a corresponding MAC PDU is an initial segment data, whether a corresponding MAC PDU is a middle segment data, whether a corresponding MAC PDU is a last segment data, or whether there is any segmentation for current transmitted data; and aggregating the at least one MAC PDU into the application data payload, in a case where the each of the at least one MAC PDU has segmentation information.

Description

READER DEVICE, COMMUNICATION DEVICE, AND METHOD

[0001] The present disclosure relates to a communication system and to parts thereof. The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards, equivalents, or derivatives thereof (including Long Term Evolution (LTE)-Advanced, Next Generation or 5G networks, future generations, and beyond). The present disclosure in particular relates to transmissions, including segmented data transmissions, between 'Ambient' Internet-of-Things (IoT) devices, and an ambient IoT device reader.

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

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

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

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

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

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

[0008] NPL 1: 'NGMN 5G White Paper' V1.0, the Next Generation Mobile Networks (NGMN) Alliance, February 2015, https: / / ngmn.org / wp-content / uploads / NGMN_5G_White_Paper_V1_0.pdf

[0009] Ambient IoT 　　'Ambient' 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 communications (described below) to communicate with other devices. Type 1 devices typically have an initial sampling frequency offset (SFO) up to 10Xppm, wherein X = 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 communications (described below) to communicate with other devices. For example, the device can use stored energy to amplify backscattered signals. Type 2a devices similarly have a typical initial sampling frequency offset (SFO) up to 10Xppm, wherein X = 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. Type 2b devices also have both DL and UL amplification capabilities. For example, the device can use its stored energy to amplify backscattered signals. Type 2b devices similarly have a typical initial sampling frequency offset (SFO) up to 10Xppm.

[0010] 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 communications to communicate with other devices.

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

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

[0013] Typically, where such ambient IoT devices are implemented in a communication network (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.

[0014] 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 signal are within the same radio frequency (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 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.

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

[0016] However, during such a 1s time period the channel conditions can change greatly, resulting in the transmission of a message of 1000 bits on the D2R or R2D link failing, especially as modulation and code adaptation procedures that may be typically used to compensate for such changes in channel conditions are not workable for such a long time period.

[0017] As will be appreciated, if the transmission of such message on the D2R or R2D link fails, the whole payload of bits of the message needs to be retransmitted on the link, which in turn reduces resource utilisation and in inefficient use of such resources. One possible way of addressing that reduction in resource utilisation, and to enhance the efficiency of the system, data payload segmentation may be implemented for a data packet coming from the application layer. By segmenting the data payload and spreading the data payload transmission over multiple smaller messages rather than one message, the size of the data payload that may need to be retransmitted on the link in the event of a link failure during the transmission of one of the smaller messages is reduced.

[0018] However, the current protocol stack architecture used in topology 1 and topology 2 does not support an appropriate interface at a high layer (such as the network, transport, session, presentation, application layer, or the like) between the ambient IoT device, and the ambient IoT device reader (e.g., RAN node and / or intermediate node) for implementing such data segmentation.

[0019] There is therefore a need to develop a new harmonised air interface design in the protocol stack architecture used in topology 1 and topology 2.

[0020] Furthermore, in the case of topology 1, it will be appreciated that in addition to needing to develop a new harmonised air interface design in the protocol stack architecture, there will also be a need to develop appropriate data transmission mechanisms for the DL and the UL between the ambient IoT device and the ambient IoT device reader (e.g., a RAN node ) to support data forwarding between the ambient IoT device and the core network (e.g., a 5G core network - 5GC).

[0021] Additionally, in the case of topology 2, it will be appreciated that in addition to needing to develop a new harmonised air interface design in the protocol stack architecture 1, there will also be a need to develop new data transmission / data forwarding mechanisms to support data transmission / data forwarding via an intermediate node (e.g., between the ambient IoT device and a RAN node), as neither the existing protocol architectures specified for L2 relay, or existing data transmission mechanism specified for Small Data Transmission (SDT) can be used.

[0022] In particular, the existing protocol architectures specified for L2 relaying cannot be used in the case of topology 2 because of the limitations of ambient IoT device / reader technologies and existing data transmission mechanisms specified for SDT cannot be used in the case of topology 2 because the mechanism is designed for User Plane (UP) based data transmissions.

[0023] Therefore, to summarise, for the successful implementation of ambient IoT device systems comprising ambient IoT devices of type 1, 2a, and / or type 2b as defined above in either topology 1 or topology 2, there is a need to develop: 　　- A new harmonised air interface design for the protocol stack architecture used in topology 1 and topology 2 to allow the implementation of data segmentation. 　　- For topology 1, a new mechanism for specifying, especially at the ambient IoT device reader (e.g., RAN node), the data transmissions on the DL and UL between the ambient IoT device and the ambient IoT device reader (e.g., RAN node) to support data forwarding between the ambient IoT device and the core network (e.g., 5GC); and 　　- For topology 2, new data transmission / data forwarding mechanisms to support data transmission / data forwarding between the ambient IoT device and a RAN node (i.e., via an intermediate node acting as an ambient IoT device reader).

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

[0025] In one aspect, the present disclosure provides a method performed by a reader device, the method comprising: receiving, from a communication device, at least one Medium Access Control (MAC) protocol data unit (PDU), each of which includes a MAC header including segmentation information indicating at least one of: whether a corresponding MAC PDU is segmented data from an application data payload, whether a corresponding MAC PDU is an initial segment data, whether a corresponding MAC PDU is a middle segment data, whether a corresponding MAC PDU is a last segment data, or whether there is any segmentation for current transmitted data; and aggregating the at least one MAC PDU into the application data payload, in a case where the each of the at least one MAC PDU has segmentation information.

[0026] In one aspect, the present disclosure provides a method performed by a communication device, the method comprising: segmenting an application data payload to at least one Medium Access Control (MAC) protocol data unit (PDU); and transmitting the MAC PDU to a reader device, and wherein each of the MAC PDU includes a MAC header including segmentation information indicating at least one of: whether a corresponding MAC PDU is segmented data from the application data payload, whether a corresponding MAC PDU is an initial segment data, whether a corresponding MAC PDU is a middle segment data, whether a corresponding MAC PDU is a last segment data, or whether there is any segmentation for current transmitted data.

[0027] In one aspect, the present disclosure provides a reader device comprising: means for receiving, from a communication device, at least one Medium Access Control (MAC) protocol data unit (PDU), each of which includes a MAC header including segmentation information indicating at least one of: whether a corresponding MAC PDU is segmented data from an application data payload, whether a corresponding MAC PDU is an initial segment data, whether a corresponding MAC PDU is a middle segment data, whether a corresponding MAC PDU is a last segment data, or whether there is any segmentation for current transmitted data; and means for aggregating the at least one MAC PDU into the application data payload, in a case where the each of the at least one MAC PDU has segmentation information.

[0028] In one aspect, the present disclosure provides a communication device comprising: means for segmenting an application data payload to at least one Medium Access Control (MAC) protocol data unit (PDU); and means for transmitting the MAC PDU to a reader device, and wherein each of the MAC PDU includes a MAC header including segmentation information indicating at least one of: whether a corresponding MAC PDU is segmented data from the application data payload, whether a corresponding MAC PDU is an initial segment data, whether a corresponding MAC PDU is a middle segment data, whether a corresponding MAC PDU is a last segment data, or whether there is any segmentation for current transmitted data.

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

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

[0031] Examples of apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:Fig. 1 illustrates schematically a mobile (cellular or wireless) communication system to which example embodiments of the disclosure may be applied;Fig. 2 illustrates schematically a first connectivity topology (topology 1) that may be used in the communication system of Fig. 1;Fig. 3 illustrates schematically a second connectivity topology (topology 2) that may be used in the communication system of Fig. 1;Fig. 4A illustrates schematically a third connectivity topology (topology 3) that may be used in the communication system of Fig. 1;Fig. 4B illustrates schematically another arrangement of the third connectivity topology (topology 3) of Fig. 4A;Fig. 5 illustrates an example protocol stack architecture between the core network, an ambient IoT device reader (e.g., a RAN node), and an ambient IoT device used in topology 1 of Fig. 2;Fig. 6 illustrates an example protocol stack architecture between the core network, an ambient IoT device reader (e.g., an intermediate node), a RAN node, and an ambient IoT device used in topology 2 of Fig. 3;Fig. 7A illustrates an example flow for the delivery of an unsegmented PDU from the NAS layer of a device to its MAC layer;Fig. 7B illustrates an example flow for the delivery of a segmented PDU from the NAS layer of a device to its MAC layer;Fig. 7C illustrates an example of a MAC PDU sent over the ambient IoT interface;Fig. 8A illustrates an example flow for the delivery of a segmented PDU from the NAS layer of a device to its PHY layer;Fig. 8B illustrates an example of a segmented PHY data burst sent over the ambient IoT interface;Fig. 9 illustrates a simplified flow diagram of an UL data transmission procedure performed between a RAN node, an intermediate UE that acts as an ambient IoT device reader, and an ambient IoT devices;Fig. 10 illustrates a simplified flow diagram of a DL data transmission procedure performed between a RAN node, an intermediate UE that acts as an ambient IoT device reader, and an ambient IoT devices;Fig. 11 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. 12 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. 13A is a more detailed block schematic illustrating the main components of an ambient IoT device that may be used in the communication system of Fig. 1;Fig. 13B is another more detailed block schematic illustrating the main components of an ambient IoT device that may be used in the communication system of Fig. 1;Fig. 14 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. 15 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.

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

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

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

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

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

[0037] The 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 IoT device 3-1 may be configured for uplink (backscatter) communication and / or downlink communication directly with the RAN node 5-1 and / or may be configured for uplink (backscatter) communication and / or downlink communication indirectly via communication (e.g., 'sidelink' or similar communication) with intermediate, or assisting, node 5-2. It will be appreciated that the intermediate, or assisting, node 5-2 may, in effect, be another node of the RAN or a separate node. The intermediate, or assisting, node 5-2 may, for example, be a relay node, an integrated access and backhaul (IAB) node, another UE, a repeater and / or the like, which is capable of ambient IoT operation including receiving backscatter / reflected signals from, and / or transmitting unmodulated carrier signals to, the IoT device 3-1.

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

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

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

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

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

[0043] 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 interface (e.g. an N6 reference point) for communication of the user data.

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

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

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

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

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

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

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

[0051] Connectivity Topologies 　　The 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. 3 to 5.

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

[0053] As shown in Fig. 2, in topology 1 the functionality of the IoT device reader is implemented as part of a RAN node 5-1. An 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 IoT device 3-1 directly and bidirectionally communicates with the RAN node 5-1. The communication 20 (20-1, 20-2) between the RAN node 5-1 and the IoT device 3-1 may, for example, include ambient IoT data and / or other ambient IoT signalling (e.g., control signals or the like). The communication 20 between the RAN node 5-1 and the 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.

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

[0055] Nevertheless, although not shown in Fig. 3, topology 1 allows for the possibility that the RAN node (IoT device reader) transmitting to the IoT device 3-1 is a different RAN node 5-1 (IoT device reader) from the RAN node 5-1 (IoT device reader) receiving from the 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 IoT device 3-1, and a second RAN node 5-1 (IoT device reader) may receive a resulting backscattered signal 20-2 from the 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).

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

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

[0058] Topology 1 may also be deployed for outdoor scenarios with one or more 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.

[0059] 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 IoT device 3-1. The RAN node 5-1 will send an unmodulated carrier signal as a 'stimulus' signal to the IoT device 3-1 which will automatically respond with the required data encoded in the resulting backscattered / reflected signal.

[0060] Topology 2: RAN node ⇔ Intermediate node ⇔ IoT device: 　　Fig. 3 illustrates schematically a second connectivity topology (topology 2) of a mobile (cellular or wireless) communication system.

[0061] As shown in Fig. 3, in topology 2 the functionality of the IoT device reader is implemented as part of an intermediate node 5-2. Specifically, an 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 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 IoT device 3-1 and that is capable of supporting ambient IoT signalling.

[0062] In this example, the IoT device 3-1 communicates bidirectionally with the intermediate node 5-2, which is located between the IoT device 3-1 and RAN node 5-1, and which is able to transfer ambient IoT data and / or signaling between the RAN node 5-1 and the IoT device 3-1.

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

[0064] In a first (downlink) direction (RAN node 5-1 → intermediate node 5-2 → ambient 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 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 IoT device 3-1 or may be a trigger signal for triggering transmission of the unmodulated carrier signal 20-1.

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

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

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

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

[0069] Topology 2 may be deployed for scenarios with a type 1, 2a, and / or 2b IoT device 3-1, in which the 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.

[0070] Topology 2 may also be deployed for indoor scenarios with a type 1, 2a, and / or 2b 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.

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

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

[0073] Topology 3: RAN node ⇔ Assisting node ⇔ Ambient IoT device ⇔ RAN node: 　　Figs. 4A and 4B illustrate schematically a third connectivity topology (topology 3) of a mobile (cellular or wireless) communication system 1.

[0074] As shown in Figs. 4A and 4B, in topology 3 part of the functionality of the IoT device reader is implemented as part of an assisting node 5-2 and part of the functionality of the IoT device reader is implemented as part of a RAN node 5-1. Specifically, an 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 5-2). It will be appreciated that while the assisting node 5-2 is depicted in Fig. 4A and Fig. 4B as a type of base station, the assisting node 5-2 may in fact be any one of an IAB node, a UE 3, a repeater, or the like, or any other appropriate device that can act as an intermediary between a RAN node 5-1 and an IoT device 3-1.

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

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

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

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

[0079] 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 IoT device 3-1. The RAN node 5-1 will send an unmodulated carrier signal as a 'stimulus' signal to the IoT device 3-1 which will automatically respond with the required data encoded in the resulting backscattered / reflected signal sent to the assisting node 5-2 for relaying / forwarding to the RAN node 5-1.

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

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

[0082] 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 IoT device 3-1. The RAN node 5-1 will send an unmodulated carrier signal as a 'stimulus' signal to the IoT device 3-1 which will automatically respond with the required data encoded in the resulting backscattered / reflected signal sent to the assisting node 5-2. The resulting backscattered / reflected signal (or at least the data encoded in it) will then be forwarded / relayed to the RAN node 5-1 by the assisting node 5-2.

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

[0084] 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 IoT device 3-1, also occurs over an appropriate air interface. For example, they may communicate over a Uu or a dedicated interface.

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

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

[0087] The communication system 1 is configured to support one or more improved protocol stack architectures for use in ambient IoT device-based scenarios with topology 1 and 2 that facilitate data segmentation / assembly at the MAC and / or PHY layers of the protocol stack. Beneficially, by segmenting the data payload into multiple smaller payloads, the time required to transmit each separate message is reduced, and thus the channel conditions over which each message is transmitted is less likely change during the transmission of each individual message.

[0088] In one exemplary improved protocol stack architecture for use in topology 1 described in more detail later, a corresponding ambient IoT (A-IoT) MAC layer and a corresponding A-IoT PHY layer is provided in the protocol stack of the ambient IoT device 3-1 and the ambient IoT device reader that are in communication with one another. The ambient IoT device 3-1 and the ambient IoT device reader are provided with corresponding A-IoT MAC layer and A-IoT PHY layer entities that are configured to perform operations and functions associated with the corresponding A-IoT MAC and A-IoT PHY layers, including data segmentation procedures to enable the segmentation of data payload into multiple smaller payloads for transfer between the ambient IoT device 3-1 and the ambient IoT device reader.

[0089] In the improved protocol stack architecture for use in topology 1 described in more detail later, the IoT MAC layer and A-IoT PHY layer entities may be configured to perform operations and functions such as data assembly procedures to enable the assembly of segmented data payloads into a single data payload following transfer of the segmented data payloads between the ambient IoT device 3-1 and the ambient IoT device reader.

[0090] In another exemplary improved protocol stack architecture for use in topology 2 described in more detail later, a corresponding A-IoT MAC layer and a corresponding A-IoT PHY layer is provided in the protocol stack of the ambient IoT device 3-1 and the ambient IoT device reader that are in communication with one another. The ambient IoT device 3-1 and the ambient IoT device reader are provided with corresponding A-IoT MAC layer and A-IoT PHY layer entities that are configured to perform operations and functions associated with the corresponding A-IoT MAC and PHY layers, including data segmentation procedures to enable the segmentation of data payload into multiple smaller payloads for transfer between the ambient IoT device 3-1 and the ambient IoT device reader.

[0091] In the improved protocol stack architecture for use in topology 2 described in more detail later, the IoT MAC layer and A-IoT PHY layer entities may be configured to perform operations and functions such data assembly procedures to enable the assembly of segmented data payloads into a single data payload following transfer of the segmented data payloads between the ambient IoT device 3-1 and the ambient IoT device reader.

[0092] In the exemplary improved protocol stack architecture for use in topology 2 described in more detail later, the ambient IoT device reader may be provided with appropriate layers (e.g., RRC, PDCP, RLC, MAC, and PHY layers) in its protocol stack to establish a connection with a RAN node 5-1 for forwarding the aggregated payload, aggregated by the ambient IoT device reader from the received smaller data payloads, to the RAN node 5-1.

[0093] In an exemplary data transmission procedure / technique used with the exemplary improved protocol stack architecture for use in topology 2 described in more detail later, an ambient IoT device reader and / or ambient IoT device 3-1 may be configured to be able to perform data segmentation and assembly procedures at their respective MAC and / or PHY layers. This allows the transmission / backscatter of multiple segments, each with a relatively small data payload, such that the transmission time for each segment is reduced (relative to sending an unsegmented payload), and thus the channel conditions over which each transmission occurs are less likely change during transmission.

[0094] Improved Protocol Stack Architectures and Data Segmentation MethodsExample protocol stack architectures for topology 1 & 2 　　Fig. 5 illustrates an example protocol stack architecture for communication between the core network 7 and an ambient IoT device reader (e.g., a RAN node 5-1), and between the ambient IoT device reader 5-1 and an ambient IoT device 3-1, arranged in topology 1 as described above.

[0095] As shown in Fig. 5 the protocol stack architecture comprises an ambient IoT device protocol stack comprising an application layer 32, an ambient IoT non-access stratum (A-IoT NAS) layer 34, an optional A-IoT radio resource control (RRC) layer 35 (which may be part of a network layer), an A-IoT medium access control (MAC) layer 36, and an A-IoT physical (PHY) layer 38.

[0096] It will be appreciated that the IoT device 3-1 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer.

[0097] The protocol stack architecture also comprises an ambient IoT device reader protocol stack. The ambient IoT device reader protocol stack includes a number of IoT device side layers for communication with corresponding layers of the ambient IoT device protocol stack over one or more associated interfaces. The ambient IoT device reader protocol stack also includes a number of core network side layers for communication with the core network 7 over one or more associated interfaces.

[0098] The IoT device-side layers include: an optional A-IoT RRC layer 55 (which may be part of a network layer) for communication with a corresponding optional A-IoT radio resource control (RRC) layer 35 of the ambient IoT device 3-1; an A-IoT MAC layer 56 for communication with a corresponding A-IoT MAC layer 36 of the ambient IoT device 3-1; and an A-IoT PHY layer 58 for communication with a corresponding A-IoT PHY layer 38 of the ambient IoT device 3-1.

[0099] The core network side layers include: a next generation application protocol (NGAP) layer 52 (which may be part of a radio network layer) for communication with a corresponding NGAP layer 76 of core network 7; and one or more other lower layers 54 for communication with a corresponding one or more other lower layers 78 of core network 7.

[0100] It will be appreciated that the IoT device reader 5-1 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer.

[0101] The protocol stack architecture also comprises a core network protocol stack comprising: an application layer 72; an ambient IoT non-access stratum (A-IoT NAS) layer 74 for communication with a corresponding A-IoT NAS layer 34 of the ambient IoT device 3-1; an NGAP layer 76 (which may be part of a radio network layer) for communication with a corresponding NGAP layer 52 of the ambient IoT device reader 5-1; and one or more other lower layers 78 for communication with corresponding one or more other lower layers 54 of the ambient IoT device reader 5-1.

[0102] It will be appreciated that the core network has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer. The core network functional entities may form part of the same or different core network functions.

[0103] The purpose of the layers mentioned above will be understood by the skilled person and so are only briefly introduced below for the purposes of completeness:

[0104] Application layers 32, 72: Each application layer entity of the respective application layers 32, 72, at the ambient IoT device 3-1 and the core network 7, performs operations and functions associated with the application layer such as providing network services to end users as well as file transfer, access, and management (FTAM).

[0105] A-IoT NAS layers 34, 74: Each A-IoT NAS layer entity of the A-IoT NAS layers 34, 74, of the ambient IoT device 3-1 and the core network 7, performs operations and functions associated with the NAS layer such as supporting traffic and signalling messages between the core network 7 and the ambient IoT device 3-1. The A-IoT NAS layer entities also manage the establishment of communication sessions and maintain continuous communications with the ambient IoT device 3-1 as it moves.

[0106] Where the respective A-IoT NAS layer entities of the A-IoT NAS layers 34, 74 are responsible for supporting traffic and signalling messages between the core network 7 and the ambient IoT device 3-1, they may also be responsible for encapsulating data packets received from the application layer into specific NAS packet data units (PDUs) for both the DL and UL.

[0107] Specifically, for the UL, e.g., 'device-to-reader' ('D2R') link, at the ambient IoT device 3-1 data packets from the application layer may be encapsulated, by the associated application layer entity, into specific NAS PDUs, which in turn are delivered to the A-IoT MAC layer 36 and further to the A-IoT PHY layer 38 for transmission to the ambient IoT device reader 5-1. In that scenario, the corresponding A-IoT MAC layer entity and / or A-IoT PHY layer entity at the ambient IoT device 3-1 may thus perform data segmentation on the data. The A-IoT MAC layer entity or A-IoT PHY layer entity of the ambient IoT device reader 5-1 may in turn perform corresponding data aggregation on the received data segments, before forwarding the data to core network 7, e.g., via an appropriate NGAP message.

[0108] For the DL, e.g., 'reader-to-device' ('R2D') link, the ambient IoT device reader 5-1 may firstly receive the data (encapsulated into a NAS PDU) from the core network 7 over the NG interface via a specific NGAP message. Subsequently, the A-IoT MAC layer entity and / or A-IoT PHY layer entity of the ambient IoT device reader 5-1 may perform data segmentation at the corresponding A-IoT MAC layer 56 and / or A-IoT PHY layer 58. The A-IoT MAC layer entity or A-IoT PHY layer entity of the ambient IoT device 3-1, upon receiving the segmented data, may in turn perform data aggregation with the received data segments before delivering them to its A-IoT NAS layer 34.

[0109] It will be appreciated that from a data forwarding perspective, the data may be encapsulated into a transparent container within the signaling message send over NG interface and / or F1 interface for both DL and UL.

[0110] Furthermore, it will be appreciated that where the ambient IoT device reader is a RAN node with a CU-DU split architecture, for both the DL and UL, the data to be transmitted to, or received from the ambient IoT device 3-1 may be transmitted between the CU and DU via an appropriate F1AP message where necessary.

[0111] A-IoT RRC layer 35, 55: Each A-IoT RRC layer entity of the A-IoT RRC layers 35, 55, of the ambient IoT device 3-1 and the ambient IoT device reader 5-1, is an optional entity that, if present, performs operations and functions associated with the corresponding A-IoT RRC layer 35, 55 (i.e., part of the network layer) such as managing the establishment, modification, and release of connections between the ambient IoT device 3-1 and the ambient IoT device reader 5-1. This may include both initial connection setup and subsequent handovers. The A-IoT RRC entities of the A-IoT RRC layers 35, 55 are also responsible for controlling the establishment, modification, and release of radio bearers, the handling of the configuration and release RAN protocols, such as measurement reporting, mobility procedures, and beam management, as well as mobility management, radio resource management (RRM), and security control. The A-IoT RRC entities of the A-IoT RRC layers 35, 55 may be also responsible for paging alike function.

[0112] In such ambient IoT device-based systems however, the A-IoT RRC layers 35, 55 are optional as neither RRC signaling connections nor RRC states need to be supported in all cases. Nevertheless, it will be appreciated that where such A-IoT RRC layers 35, 55 are provided, the ambient IoT device 3-1 may also need to support an ASN.1 encoder / decoder, which may introduce complexity at ambient IoT device 3-1.

[0113] Where no A-IoT RRC layer 35, 55 is provided (and thus no corresponding A-IoT RRC layer entities), the A-IoT MAC layer 36, 56 and the corresponding A-IoT MAC layer entities may handle some of the A-IoT RRC entity functions, e.g., when the ambient IoT device reader 5-1 receives the paging-like messages over NGAP from core network 7.

[0114] A-IoT MAC layers 36, 56: Each A-IoT MAC layer entity of the A-IoT MAC layers 36, 56, of the ambient IoT device 3-1 and the ambient IoT device reader 5-1, performs operations and functions associated with the MAC layer (i.e., part of the data link layer) such as ensuring reliable and efficient communication between two or more devices, and providing unique identification of each device. In particular, the A-IoT MAC layer entities assist in the transferal of data packets over the network.

[0115] A-IoT physical (PHY) layers 38, 58: Each A-IoT PHY layer entity of the A-IoT PHY layers 38, 58, of the ambient IoT device 3-1 and the ambient IoT device reader 5-1, performs operations and functions associated with the PHY layer such as establishing, maintaining, and deactivating the physical connection between the ambient IoT device 3-1 and the ambient IoT device reader 5-1, and the transmission of individual bits between the ambient IoT device 3-1 and the ambient IoT device reader 5-1.

[0116] NGAP layers 52, 76: Each NGAP layer entity of the NGAP layers 52, 76, of the ambient IoT device reader 5-1 and the core network 7, perform operations and functions associated with the radio network layer such as the establishment, maintenance, and release of the NG-RAN part of PDU sessions between the ambient IoT device reader 5-1 and the core network 7.

[0117] It will be appreciated that the description above of the various layers and associated entities are by way of example only, and that those layers and associated entities may also be able to support performance of any other appropriate operations associated with their respective layers, as would be known by the skilled person.

[0118] Fig. 6 illustrates an example protocol stack architecture between the core network 7, a RAN node 5-1, an ambient IoT device reader (e.g., an intermediate node 5-2) and an ambient IoT device 3-1 arranged in topology 2 as described above.

[0119] As shown in Fig. 6 the protocol stack architecture comprises an ambient IoT device protocol stack comprising an application layer 32, an A-IoT NAS layer 34, an optional A-IoT RRC layer 35 (which may be part of a network layer), an A-IoT MAC layer 36, and an A-IoT PHY layer 38.

[0120] It will be appreciated that the IoT device 3-1 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer.

[0121] The protocol stack architecture also comprises an ambient IoT device reader protocol stack. The ambient IoT device reader protocol stack includes a number of IoT device side layers for communication with corresponding layers of the ambient IoT device protocol stack over one or more associated interfaces. The ambient IoT device reader protocol stack also includes a number of RAN node side layers for communication with the RAN node 5-1 over one or more associated interfaces.

[0122] The IoT device side layers include: an optional A-IoT RRC layer 35-2 (which may be part of a network layer) for communication with a corresponding optional A-IoT RRC layer 35 of the ambient IoT device 3-1; an A-IoT MAC layer 36-2 for communication with a corresponding A-IoT MAC layer 36 of the ambient IoT device 3-1; and an A-IoT PHY layer 38-2 for communication with a corresponding A-IoT PHY layer 38 of the ambient IoT device 3-1.

[0123] The RAN node side layers include: an RRC layer 60-2 for communication with a corresponding RRC layer 60-1 of a RAN node 5-1; a PDCP layer entity 62-2 for communication with a corresponding PDCP layer 62-1 of the RAN node 5-1; an RLC layer 64-2 for communication with a corresponding RLC layer 64-1 of the RAN node 5-1; a MAC layer 66-2 for communication with a corresponding MAC layer 66-1 of the RAN node 5-1; and a PHY layer 68-2 for communication with a corresponding PHY layer 68-1 of the RAN node 5-1.

[0124] It will be appreciated that the IoT device reader 5-2 has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer.

[0125] The protocol stack architecture also comprises a RAN node protocol stack comprising reader side layers including: an RRC layer 60-1 for communication with a corresponding MAC layer 60-2 of the ambient IoT device reader 5-2; a PDCP layer 62-1 for communication with a corresponding PDCP layer 62-2 of the ambient IoT device reader 5-2; a RLC layer 64-1 for communication with a corresponding RLC layer 64-2 of the ambient IoT device reader 5-2; a MAC layer entity 66-1 for communication with a corresponding MAC layer 66-2 of the ambient IoT device reader 5-2; and a PHY layer entity 68-1 for communication with a corresponding PHY layer 68-2 of the ambient IoT device reader 5-2.

[0126] The RAN node protocol stack also comprises core network side layers including: an NGAP layer 52 (which may be part of a radio network layer) for communication with a corresponding NGAP layer 76 of the core network 7; and other lower layers 54 for communication with corresponding lower layers 78 of the core network 7.

[0127] The protocol stack architecture also comprises a core network protocol stack comprising: an application layer 72; an A-IoT NAS layer 74 for communication with a corresponding A-IoT NAS layer 34 of the ambient IoT device 3-1; an NGAP layer 76 (which may be part of a radio network layer) for communication with a corresponding NGAP layer 52 of the RAN node 5-1, and other lower layers 78 for communication with corresponding lower layers 54 of the RAN node 5-1.

[0128] It will be appreciated that the core network has at least one functional entity respectively corresponding to each layer for performing the functionality (data processing, data transfer / transmission etc.) of that layer. The core network functional entities may form part of the same or different core network functions.

[0129] The purpose of the layers mentioned above will be understood by the skilled person and so are only briefly introduced below for the purposes of completeness:

[0130] Application layers 32, 72: Each application layer entity of the respective application layers 32, 72, at the ambient IoT device 3-1 and the core network 7, performs operations and functions associated with the application layer such as providing network services to end users as well as file transfer, access, and management (FTAM).

[0131] A-IoT NAS layers 34, 74: Each A-IoT NAS layer entity of the A-IoT NAS layers 34, 74, of the ambient IoT device 3-1 and the core network 7, performs operations and functions associated with the A-IoT NAS layer such as supporting traffic and signalling messages between the core network 7 and the ambient IoT device 3-1. The A-IoT NAS layer entities also manage the establishment of communication sessions and maintain continuous communications with the ambient IoT device 3-1 as it moves.

[0132] Where the respective A-IoT NAS layer entities of the A-IoT NAS layers 34, 74 are responsible for supporting traffic and signalling messages between the core network 7 and the ambient IoT device 3-1, they may also be responsible for encapsulating data packets received from the application layer into specific NAS packet data units (PDUs) for both the DL and UL.

[0133] Specifically for the DL, e.g., 'reader-to-device' ('R2D') link, the RAN node 5-1 may firstly receive application data (encapsulated into NAS PDUs) from the core network 7 (e.g., an AMF 10-1) in the form of a specific message. For example, the core network 7 may send the NAS PDUs to the RAN node 5-1 over the NG interface e.g., via an NGAP message. By way of example only, the NGAP message may comprise an identity of the ambient IoT device 3-1 where the data is destined, as well as the NAS PDUs. Additionally (or alternatively) the NGAP message may include an indication of a category of ambient IoT device 3-1 where the data is destined, since the application data may be destined for multiple ambient IoT devices 3-1 with the same category. Additionally (or alternatively) the NGAP message may include an indication of a subgroup of the same category of ambient IoT device 3-1 where the data is destined, since the application data may be destined for multiple ambient IoT devices 3-1 within a subgroup of the same category. Subsequently, the RAN node 5-1, having received the NGAP message may forward the data to the ambient IoT device reader 5-2 e.g., via an RRC message.

[0134] At the ambient IoT device reader 5-2 the NAS PDUs can be delivered to (RLC layer 64-2), MAC layer 66-2, and further to the PHY layer 68-2 for transmission. The whole of the NAS PDUs may be encapsulated as a MAC PDU. Or a portion of the NAS PDUs may be encapsulated as a MAC PDU. In the latter case, the MAC layer entity and / or PHY layer entity of the ambient IoT device reader 5-2 may perform data segmentation at its corresponding MAC layer 66-2 or PHY layer 68-2. The A-IoT MAC layer entity or A-IoT PHY layer entity of the ambient IoT device 3-1, upon receiving the segmented data, may in turn perform data aggregation with the received data segments before delivering them to its A-IoT NAS layer 34.

[0135] For the UL, e.g., 'device-to-reader' ('D2R') link, at the ambient IoT device 3-1 data packets from the application layer may be encapsulated, by the associated application layer entity, into specific NAS PDUs, which in turn are delivered to the A-IoT MAC layer 36 and further to the A-IoT PHY layer 38 for transmission to the ambient IoT device reader 5-2. The whole of the NAS PDU may be encapsulated as a MAC PDU, or a portion of the NAS PDU may be encapsulated as a MAC PDU. In that scenario, the A-IoT RLC layer entity, A-IoT MAC layer entity and / or A-IoT PHY layer entity at the ambient IoT device 3-1 may thus perform data segmentation on the data before UL transmission. The MAC layer entity or PHY layer entity of the ambient IoT device reader 5-2 may in turn perform corresponding data aggregation on the received data segments, before forwarding the data to RAN node 5-1 e.g., via an RRC message.

[0136] It will be appreciated that from a data forwarding perspective, the data may be encapsulated into a transparent container within the signaling message sent over NG interface and / or F1 interface for both DL and UL.

[0137] Furthermore, it will be appreciated that where the RAN node 5-1 is a RAN node with a CU-DU split architecture, for both the DL and UL, the data to be transmitted to, or received from the ambient IoT device 3-1 (i.e., via the intermediate node 5-2) may be transmitted between the CU and DU via an appropriate F1AP message where necessary.

[0138] A-IoT RRC layer 35, 35-2: Each A-IoT RRC layer entity 35, 35-2 of the A-IoT RRC layers 35, 35-2 of the ambient IoT device 3-1 and the ambient IoT device reader 5-2 is an optional entity that, if present, performs operations and functions associated with the corresponding A-IoT RRC layer 35, 35-2 (i.e., part of the network layer) such as managing the establishment, modification, and release of connections between the ambient IoT device 3-1 and the RAN node 5-1. This may include both initial connection setup and subsequent handovers.

[0139] The A-IoT RRC entities of the A-IoT RRC layers 35, 35-2 are also responsible for controlling the establishment, modification, and release of radio bearers, the handling of the configuration and release RAN protocols, such as measurement reporting, mobility procedures, and beam management, as well as mobility management, radio resource management (RRM), and security control. The A-IoT RRC entities of the A-IoT RRC layers 35, 35-2 may be also responsible for paging alike functions.

[0140] In such ambient IoT device-based systems however, the A-IoT RRC layers 35, 35-2 are optional as neither RRC signaling connections nor RRC states need to be supported in all cases. Nevertheless, it will be appreciated that where such A-IoT RRC layers 35, 35-2 are provided, the ambient IoT device 3-1 may also need to support an ASN.1 encoder / decoder, which may introduce complexity at ambient IoT device 3-1.

[0141] Where no A-IoT RRC layer 35, 35-2 is provided (and thus no corresponding A-IoT RRC layer entities), the A-IoT MAC layer 36, 36-2 and the corresponding A-IoT MAC layer entities may handle some of the A-IoT RRC entity functions, e.g., when the ambient IoT device reader 5-2 receives the paging-like messages over NGAP from core network 7.

[0142] A-IoT physical (PHY) layers 38, 38-2: Each A-IoT PHY layer entity of the A-IoT PHY layers 38, 38-2, of the ambient IoT device 3-1 and the ambient IoT device reader 5-2 performs operations and functions associated with the PHY layer such as establishing, maintaining, and deactivating the physical connection between the ambient IoT device 3-1 and the ambient IoT device reader 5-2, and the transmission of individual bits between the ambient IoT device 3-1 and the ambient IoT device reader 5-2.

[0143] NGAP layers 52, 76: Each NGAP layer entity of the NGAP layers 52, 76, of the RAN node 5-1 and the core network 7, perform operations and functions associated with the radio network layer such as the establishment, maintenance, and release of the NG-RAN part of PDU sessions between the RAN node 5-1 and the core network 7.

[0144] RRC layers 60-1, 60-2: Each RRC layer entity of the RRC layers 60-1, 60-2 of RAN node 5-1 and ambient IoT device reader 5-2, perform operations and functions associated with the RRC layer (i.e., part of the network layer) such as managing the establishment, modification, and release of connections between the ambient IoT device 3-1, the ambient IoT device reader 5-2, and the RAN node 5-1. This may include both initial connection setup and subsequent handovers. The RRC layer entities also control the establishment, modification, and release of radio bearers, the handling of the configuration and release RAN protocols, such as measurement reporting, mobility procedures, and beam management, as well as mobility management, radio resource management (RRM), and security control. The RRC layer entities also support traffic and signalling messages between the ambient IoT device reader 5-2 and the RAN node 5-1 via a full signaling message-based data transmission path between the ambient IoT device 3-1, the ambient IoT device reader 5-2, and the RAN node 5-1.

[0145] In this scenario, during UL data forwarding, the ambient IoT device reader 5-2 receives UL data at its A-IoT MAC layer 36-2 from the corresponding A-IoT MAC layer 36 of the ambient IoT device 3-1, which can then be forward to the RAN node 5-1 using e.g., an Uu RRC message carried by a signaling radio bearer (SRB). For DL data, the ambient IoT device reader 5-2 can receive DL data from the RAN node 5-1, e.g., via an Uu RRC message by an SRB, which is then in turn delivered to the A-IoT MAC layer 36-2 of the ambient IoT device reader 5-2 for forwarding to the corresponding A-IoT MAC layer 36 of the ambient IoT device 3-1 over an ambient IoT air interface.

[0146] It will be appreciated that to enable such UL and DL transmission of data, the ambient IoT device reader 5-2 may need to be in an RRC connected mode. For example, SRBs may need to be established between the ambient IoT device reader 5-2 and the RAN node 5-1 to allow data forwarding from the ambient IoT device reader 5-2 and the RAN node 5-1.

[0147] PDCP layers 62-1, 62-2: Each PDCP layer entity of the PDCP layers 62-1, 62-2 of RAN node 5-1 and ambient IoT device reader 5-2 perform operations and functions associated with the PDCP layer (i.e., part of the data link layer) such as the transfer of user plane and control plane data, header compression, and ciphering and integrity protection procedures.

[0148] RLC layers 64-1, 64-2: Each RLC layer entity of the RLC layers 64-1, 64-2 of RAN node 5-1 and ambient IoT device reader 5-2, perform operations and functions associated with the RLC layers 64-1, 64-2 (i.e., part of the data link layer) such as transfer of upper layer PDUs, error corrections through automatic repeat request (ARQ), duplication detection, protocol error detection and recovery, and the like.

[0149] MAC layers 66-1, 66-2: Each MAC layer entity of the MAC layers 66-1, 66-2 of RAN node 5-1 and ambient IoT device reader 5-2, perform operations and functions associated with the MAC layers 66-1, 66-2 (i.e., part of the data link layer) such as ensuring reliable and efficient communication between two or more devices, and providing unique identification of each device.

[0150] PHY layers 68-1, 68-2: Each PHY layer entity of the PHY layers 68-1, 68-2 of RAN node 5-1 and ambient IoT device reader 5-2, perform operations and functions associated with the PHY layers 68-1, 68-2 such as establishing, maintaining, and deactivating the physical connection between the ambient IoT device reader 5-2 and the RAN node 5-1, and the transmission of individual bits between the ambient IoT device reader 5-2 and the RAN node 5-1.

[0151] It will be appreciated that the description above of the various layers and associated entities are by way of example only, and that those layers and associated entities may also be able to support performance of any other appropriate operations associated with their respective layers, as would be known by the skilled person.

[0152] Data payload handling and forwarding without segmentation 　　As described above, in the example protocol stack architectures of Figs. 5 & 6, segmentation of the data payload may be performed at the MAC and / or PHY layers. Prior to describing such segmentation procedures however, the scenario where the data payload is not segmented is described.

[0153] Fig. 7A illustrates an example flow for the delivery of an unsegmented PDU from the NAS layer of a device to its MAC layer. As will be appreciated, the device may be an ambient IoT device 3-1, or an ambient IoT device reader such as a RAN node 5-1 or an intermediate node 5-2. As shown in Fig. 7A, where the data payload is not segmented at the MAC and / or PHY layers, the application data payload is modelled as a specific NAS PDU, which is in turn delivered to the MAC layer as a whole NAS PDU for conversion into a whole MAC PDU.

[0154] Where the data payload is not segmented at the MAC and / or PHY layers and the application data payload is modelled as a specific NAS PDU, each type of ambient IoT device 3-1 may be configured to support a different fixed payload data size, and specific ambient IoT devices 3-1 may respond to specific inquiry signalling from an ambient IoT device reader based on the fixed payload data size with which it is configured. For example, an ambient IoT device 3-1 will only respond to inquiry signalling from the ambient IoT device reader if the inquiring signalling corresponds to the fixed payload data size with which the ambient IoT device 3-1 is configured. The inquiry signals may take the form of a specific inquiry signaling message, or a set of such messages defined for each type of ambient IoT device 3-1 at the application layer or other upper layers (i.e., NAS layer).

[0155] In the case of a single specific inquiry signaling message being used, the MAC layer of the device (e.g., the ambient IoT device 3-1 and / or ambient IoT device reader) can assemble a MAC PDU with the data (i.e., NAS PDU) following a predefined / preconfigured transport block size (TBS) and modulation coding scheme (MCS). For example, for a D2R link, the ambient IoT device 3-1 does not need to adjust the MCS used based on the channel quality of the D2R link (for backscattered data transmission), when performing backscattered data transmission in response to inquiry signaling. In the case of multiple inquiry signaling messages being used, the MAC layer can assemble a MAC PDU with the data (i.e., NAS PDU) based on the type of the message following a predefined / preconfigured TBS and MCS. In either scenario, the MAC PDU will then be delivered to the PHY layer for transmission immediately as a whole transport block (TB). For example, the PHY layer may transmit the TB in one shot without segmentation over the D2R or the R2D link.

[0156] The MAC PDU, sent over the ambient IoT interface, may include one MAC header and one MAC payload corresponding to the whole NAS PDU (i.e., the payload is not segmented). The MAC header may also include a length indicator to indicate the length of the whole payload. Upon reception of the MAC PDU, the device receiving the MAC PDU delivers the payload of the MAC PDU to the upper layers (i.e., NAS layer) with the MAC header removed. For example, the device receiving the MAC PDU delivers the payload of the MAC PDU to the upper layers (i.e., NAS layer) when it is determined by the device that the MAC PDU does not include a segmentation indicator, or the like, indicating that the MAC PDU is one of a plurality of MAC PDUs formed through segmentation of the NAS PDU payload.

[0157] Data payload segmentation and forwarding: Segmentation at the MAC layer 　　Fig. 7B illustrates an example flow for the delivery of a segmented PDU from the NAS layer of a device to its MAC layer. As will be appreciated, the device may be an ambient IoT device 3-1, or an ambient IoT device reader such as a RAN node 5-1 or an intermediate node 5-2. As shown in Fig. 7B, where the data payload is segmented at the MAC layer, the application data payload is modelled as a specific NAS PDU (e.g., typically with a size of 1K bits), which is in turn delivered to the MAC layer as a whole NAS PDU and stored at a MAC layer buffer for future conversion into segmented MAC PDUs (e.g., MAC PDU #1, MAC PDU #2, and MAC PDU #3). In this scenario the MCS is fixed, such that the MAC layer knows how much data the ambient IoT device 3-1 can send via backscattered transmission to the ambient IoT device reader at one access occasion. The TBS is also fixed such that the MAC layer knows how to segment the data when it receives the NAS PDU. For example, if the TBS is 100 bits, then the NAS PDU may be segmented into 10 segments for the backscattered transmission if MAC header is not considered.

[0158] Fig. 7C illustrates an example of a MAC PDU sent over the ambient IoT interface between devices. As will be appreciated, the devices may be an ambient IoT device 3-1, or an ambient IoT device reader such as a RAN node 5-1 or an intermediate node 5-2.

[0159] As is shown in Fig. 7C, in the case of an unsegmented MAC PDU, the MAC PDU that is to be sent over the ambient IoT interface includes one MAC header and one MAC payload, the MAC payload corresponding to a whole NAS PDU.

[0160] Alternatively, in the case of a segmented MAC PDU, the segmented MAC PDU that is to be sent over the ambient IoT interface includes one MAC header and one MAC payload. the MAC payload corresponding to a segment of the NAS PDU. In this scenario the MAC header of each segmented MAC PDU may include a segmentation Indicator, and segmentation information of the NAS PDU. In addition, the MAC header of each segmented MAC PDU may include a length indicator indicating the length of the payload.

[0161] The segmentation indicator may comprise a one-bit indicator to indicate if the current data being transmitted is segmented data i.e., whether the MAC PDU being received comprises a whole MAC PDU payload, or a segmented payload. The segmentation information may comprise a one- or two-bit indicator used to indicate information about the segment associated with the NAS PDU. For example, the indicator may indicate whether the MAC PDU is a first, second, third, etc., segment. The indicator may, by way of example only, indicate whether a specific MAC PDU corresponds to a 'Segment's Start,' 'Segment's Middle,' or 'Segment's End,' of the segmented NAS PDU.

[0162] Alternatively, rather than providing segment information, an exact segment number may be provided with an end marker and encoded in the MAC PDU header. For example, if up to 64 segments is supported, 6 bits can be used in each MAC PDU header of each MAC PDU for numbering the segments.

[0163] Upon reception of the MAC PDU, the device receiving the MAC PDU may determine whether the MAC PDU includes a segmentation indication. Where it is determined that the MAC PDU does not include a segmentation indicator, the device receiving the MAC PDU may deliver the payload of the MAC PDU to the upper layers (i.e., NAS layer) of the device with the MAC header removed. On the other hand, if upon reception of the MAC PDU, the device receiving the MAC PDU determines that the MAC PDU includes a segmentation indication, then the receiving device will check for segmentation information in the MAC PDU header, and using that segmentation information, may assemble all of the MAC PDU segments to convert them into a single NAS PDU prior to delivering the whole re-assembled data payload to the upper layers (i.e., NAS layer) of the device.

[0164] For example, where the segmentation information indicates that the MAC PDU corresponds with a segment start and / or segment middle, the receiving device may wait for further MAC PDUs (i.e., further MAC PDU segments) to arrive at the receiving device prior to assembling all of the MAC PDU segments to convert them into a single NAS PDU for delivery to the upper layers (i.e., NAS layer) of the device. Where the segmentation information indicates that the MAC PDU corresponds with a segment end, the receiving device may assemble all of the MAC PDU segments to convert them into a single NAS PDU for delivery to the upper layers (i.e., NAS layer) of the device. It will be appreciated that in either scenario, the segments are assembled in a sequential manner based on the sequence in which the data was received by the receiving device.

[0165] In the scenario where segmentation information is incorporated into the MAC PDUs that indicates that the MAC PDUs correspond with a segment start, middle, or end, the receiving device may be configured with a timer that specifies a time within which the receiver device should wait to receive further segments prior to assembling the MAC PDUs for conversion to a NAS PDU. For example, when the segmentation information of the received MAC PDU indicates that the MAC PDU corresponds to a segment start and / or segment middle, but the receiving side does not receive a further segment before the expiration of the timer, the receiver may drop the received MAC PDUs and flush the receiving buffer. For symmetric design, the transmitter device may also be configured with such timer and can give up the data transmission for the further segments after the expiration of that timer.

[0166] Furthermore, where a receiving device receives a MAC PDU corresponding to a segment end, but the receiving device did not receive MAC PDUs corresponding to a segment start and middle (where applicable), the receiving device may drop the received MAC PDUs and flush the receiving buffer.

[0167] Alternatively, where the segmentation information indicates an exact segment number and an end marker, the receiving device may wait for further MAC PDU segments to arrive prior to assembling all of the MAC PDU segments to convert them into a single NAS PDU for delivery to the upper layers (i.e., NAS layer) of the device. It will be appreciated that in this scenario, the segments are assembled in a sequential manner based on their respective exact segment number.

[0168] In the scenario where the segmentation information indicates an exact segment number and an end marker, a timer may be specified at the receiving device that specifies a time within which the receiver device should wait to receive further segments prior to assembling the MAC PDUs for conversion to a NAS PDU. If the receiving device does not receive all of the MAC PDU segments, or determines, based on the segment numbers, that it cannot receive all of the MAC PDU segments before the expiration of the timer, the receiving device may drop the received MAC PDUs and flush the receiving buffer.

[0169] Upon reception of the MAC PDU, the device receiving the MAC PDU does not provide feedback to the device transmitting the MAC PDU indicating that it has correctly received and / or decoded the MAC PDU. Instead, in the event that the device receiving the MAC PDU does not receive it correctly and / or cannot decode it correctly, the receiving device may drop the whole MAC PDU or MAC PDUs and does not convert them to a NAS PDU for forwarding to higher layers.

[0170] Data payload segmentation and forwarding: Segmentation at the PHY layer 　　Fig. 8A illustrates an example flow for the delivery of a segmented PDU from the NAS layer of a device to its PHY layer. As will be appreciated, the device may be an ambient IoT device 3-1, or an ambient IoT device reader such as a RAN node 5-1 or an intermediate node 5-2. As shown in Fig. 8A, where the application data payload is segmented at the PHY layer, the application data payload is modelled as a specific NAS PDU (e.g., typically with a size of 1K bits), which is in turn delivered to the MAC layer as a whole NAS PDU and which is assembled / converted to a whole MAC PDU. That MAC PDU may comprise a single MAC header and a MAC payload as shown in Fig. 7C. The MAC header may comprise a length indicator which indicates the length of the MAC payload.

[0171] Following receipt of the MAC PDU, the receiving device may deliver the MAC PDU straight to the PHY layer without buffering the MAC PDU through a MAC layer buffer. At the PHY layer the MAC PDU is segmented into multiple PHY bursts (e.g., PHY bursts #1, #2, and #3) according to the size of the TBS that the receiving device supports for backscattered transmission from ambient IoT devices 3-1. By way of example only, if the size of the MAC PDU is 800 bits and the supported TBS is 200 bits, then the MAC PDU may be segmented into 4 data bursts for PHY transmission.

[0172] Fig. 8B illustrates an example of a segmented PHY data burst sent over the ambient IoT interface. As is shown in Fig. 8B, one typical data burst to be carried by physical downlink reader channel (PDRCH) from the ambient IoT device 3-1 to the ambient IoT device reader, or by a physical reader downlink channel (PRDCH) from the ambient IoT device reader to the ambient IoT device 3-1, may include a preamble, a midamble (not shown), a postamble (not shown), and / or data, wherein the data is the PHY data burst (i.e., PHY data segment) segmented from the MAC PDU.

[0173] The preamble, a midamble (not shown), and / or a postamble (not shown), may contain appropriate information about the segmented data. For example, they may contain control information associate with the data part of the PHY data burst. The preamble, a midamble (not shown), and / or a postamble (not shown), may contain appropriate information pertaining to the segmentation of the MAC PDU such as a segmentation indicator and / or segmentation information. For example, the preamble, a midamble (not shown), and / or a postamble (not shown), may contain a one-bit indicator to indicate if the current data being transmitted is segmented data. The segmentation information may comprise a one- or two-bit indicator used to indicate information about the segment associated with the MAC PDU. For example, the indicator may indicate whether the PHY data burst is a first, second, third, etc., segment. The indicator may, by way of example only, indicate whether a specific PHY data burst corresponds to a 'Segment's Start,' 'Segment's Middle,' or 'Segment's End,' of the segmented MAC PDU.

[0174] Alternatively, rather than providing segment information, an exact segment number may be provided with an end marker and encoded in the preamble, midamble (not shown), and / or postamble (not shown) of the PHY data burst. For example, if up to 64 segments is supported, 6 bits can be used in each MAC PDU header of each MAC PDU for numbering the segments.

[0175] Upon reception of a PHY data burst, the device receiving the PHY data burst may determine whether the PHY data burst includes a segmentation indication. Where it is determined that the PHY data burst does not include a segmentation indicator, the device receiving may deliver the payload of the PHY data burst to the upper layers (i.e., MAC layer) of the device. On the other hand, if upon reception of the PHY data burst, the device receiving the PHY data burst determines that the it includes a segmentation indication, then the receiving device will check for segmentation information in the pre-, mid-, and / or post- amble, and using that segmentation information, may assemble all of the PHY data burst segments to convert them into a single MAC PDU prior to delivering the whole re-assembled data payload to the upper layers (i.e., MAC layer) of the device.

[0176] For example, where the segmentation information indicates that the PHY data burst corresponds with a segment start and / or segment middle, the receiving device may wait for further PHY data bursts (i.e., further PHY data segments) to arrive at the receiving device prior to assembling all of the PHY data burst segments to convert them into a single MAC PDU for delivery to the upper layers (i.e., MAC layer) of the device. Where the segmentation information indicates that the PHY data burst corresponds with a segment end, the receiving device may assemble all of the PHY data burst segments to convert them into a single MAC PDU for delivery to the upper layers (i.e., MAC layer) of the device. It will be appreciated that in either scenario, the segments are assembled in a sequential manner based on the sequence in which the data was received by the receiving device.

[0177] In the scenario where segmentation information is incorporated into the PHY data bursts that indicates that the PHY data bursts correspond with a segment start, middle, or end, the receiving device may be configured with a timer that specifies a time within which the receiver device should wait to receive further segments prior to assembling the PHY data bursts for conversion to a MAC PDU. For example, when the segmentation information of the received PHY data burst indicates that the PHY data burst corresponds to a segment start and / or segment middle, but the receiving side does not receive a further segment before the expiration of the timer, the receiver may drop the received PHY data bursts and flush the receiving buffer. For symmetric design, the transmitter device may also be configured with such timer and can give up the data transmission for the further segments after the expiration of that timer.

[0178] Furthermore, where a receiving device receives a PHY data burst corresponding to a segment end, but the receiving device did not receive PHY data bursts corresponding to a segment start and middle (where applicable), the receiving device may drop the received PHY data bursts and flush the receiving buffer.

[0179] Alternatively, where the segmentation information indicates an exact segment number and an end marker, the receiving device may wait for further PHY data burst segments to arrive prior to assembling all of the PHY data burst segments to convert them into a single MAC PDU for delivery to the upper layers (i.e., MAC layer) of the device. It will be appreciated that in this scenario, the segments are assembled in a sequential manner based on their respective exact segment number.

[0180] In the scenario where the segmentation information indicates an exact segment number and an end marker, a timer may be specified at the receiving device that specifies a time within which the receiver device should wait to receive further segments prior to assembling the PHY data bursts for conversion to a MAC PDU. If the receiving device does not receive all of the PHY data burst segments, or determines, based on the segment numbers, that it cannot receive all of the PHY data burst segments before the expiration of the timer, the receiving device may drop the received PHY data bursts and flush the receiving buffer.

[0181] Upon reception of the PHY data burst, the device receiving the PHY data burst does not provide feedback to the device transmitting the PHY data burst indicating that it has correctly received and / or decoded the PHY data burst. Instead, in the event that the device receiving the PHY data burst does not receive it correctly and / or cannot decode it correctly, the receiving device may drop the whole PHY data burst or PHY data bursts and does not convert them to a MAC PDU for forwarding to higher layers.

[0182] There now follows a description of the UL and DL data transmission flows used in topology 2 where there is a RAN node 5-1 and an ambient IoT device 3-1 that communicate with one another via ambient IoT device reader (e.g., an intermediate / assisting node 5-2 such as an intermediate UE 3).

[0183] UL data transmission in topology 2 　　Fig. 9 illustrates a simplified flow diagram of an UL data transmission procedure performed between a RAN node 5-1, an intermediate node 5-2 that acts as an ambient IoT device reader, and an ambient IoT devices 3-1.

[0184] As shown in Fig. 9 there is provided an ambient IoT device 3-1, an ambient IoT device reader (e.g., an intermediate node 5-2), and a RAN node 5-1 in communication with the core network 7.

[0185] Although not shown, prior to the steps in Fig. 9, an association may be defined between the ambient IoT device reader (e.g., the intermediate node 5-2) and ambient IoT devices 3-1 in its vicinity. Accordingly, the core network 7 may be aware in advance of which ambient IoT device reader (e.g., the intermediate node 5-2) serves which ambient IoT devices 3-1. For example, the association may be defined via an appropriate device registration procedure whereby ambient IoT devices 3-1 register with a specific ambient IoT device reader in their vicinity. It will be appreciated that in the scenario where the ambient IoT device reader is an intermediate node 5-2, standard procedures known to the skilled person may be used by the core network 7 to track the intermediate node 5-2. For simplicity, the ambient IoT device reader throughout following description is an intermediate node in the form of a UE 3. Nevertheless, it will be appreciated that the ambient IoT device reader may be any appropriate intermediate node 5-2 and the procedure may be adapted appropriately (if necessary).

[0186] At step S902, the core network 7 may send an inventory request over an appropriate NGAP message to the RAN node 5-1. The inventory request may, by way of example, indicate one or more specific ambient IoT devices 3-1 that the core network 7 wishes to query, or a special category of ambient IoT device 3-1 that the core network 7 wants to query.

[0187] At step S904, if the intermediate node 5-2 is not in RRC connected state (and thus not able to perform data / message forwarding to the ambient IoT device 3-1, then the RAN node 5-1 sends an appropriate paging message to the intermediate node 5-2. That paging message may contain an appropriate paging cause indication to indicate to the intermediate node 5-2 that an inventory request for an ambient IoT device 3-1 has been received by the RAN node 5-1.

[0188] At step S906, having received the paging message, the intermediate node 5-2, and the RAN node 5-1 may perform an appropriate RRC (re)establishment procedure to (re)establish an RRC connection between the intermediate node 5-2 and the RAN node 5-1, and thus enter RRC connected mode. For example, a random access channel (RACH) procedure may be performed between the intermediate node 5-2 and the RAN node 5-1. By way of example only, the intermediate node 5-2 and the RAN node 5-1 may perform a 2- or 4-step RACH procedure as is appropriate.

[0189] During the RACH procedure, the RAN node 5-1 may (re)configure the intermediate node 5-2 to perform an inventory request procedure. For example, the RAN node 5-1 may (re)configure the intermediate node 5-2 to provide resource allocations for an inventory request.

[0190] At step S908, the intermediate node 5-2 may broadcast an appropriate paging or paging alike message (e.g., a 'message 0' / 'Msg0' message) to ambient IoT devices 3-1 in the vicinity of the intermediate node 5-2. Whilst there may be a plurality of ambient IoT devices 3-1, for simplicity in Fig. 9 only one ambient IoT device 3-1 is shown.

[0191] For example, the intermediate node 5-2 may, for example, send a physical downlink channel message such as a physical 'receiver' downlink channel (PRDCH) access order message ('Msg0') to the ambient IoT devices 3-1, although it will nevertheless be appreciated that a similar alternative message could be used.

[0192] Msg0 serves as a 'query' type message that is used to indicate which ambient IoT devices 3-1 are to initiate an initial access procedure with the intermediate node 5-2. For example, Msg0 may include an indication of which ambient IoT devices 3-1 need to respond to the intermediate node 5-2. Alternatively (or additionally) Msg0 may also include an indication of a category of ambient IoT devices 3-1 that need to respond to the ambient IoT device reader 5-2. Alternatively (or additionally) Msg0 may also be configured to trigger the transmission of information reports from ambient IoT devices 3-1 that receive the message. Alternatively (or additionally) Msg0 may also configure specific information relevant to the ambient IoT devices 3-1 that are the intended recipients of the broadcast message.

[0193] It will be appreciated that as Msg0 may be used to indicate which ambient IoT devices 3-1 need to respond to the intermediate node 5-2, it also in turn indicates which ambient IoT devices 3-1 are to perform backscatter transmissions to the intermediate node 5-2.

[0194] Having received Msg0 at step S908, the indicated ambient IoT devices 3-1 and the intermediate node 5-2 perform an appropriate initial access procedure at step S910.

[0195] At step S912, the ambient IoT device 3-1 performs a first PDRCH transmission over the D2R link to the intermediate node 5-2. For example, the ambient IoT device 3-1 performs a first backscatter transmission to the intermediate node 5-2. Having received that backscatter transmission, the intermediate node 5-2 determines, based for example on the contents of transmission, whether the first backscattered transmission comprises a whole data payload, or whether the first backscattered transmission comprises a segment of a data payload in accordance with the segmentation procedures performed at the MAC and / or PHY layer as described above.

[0196] Where the intermediate node 5-2 determines that the first backscattered transmission is a segmented transmission comprising only a segment of the expected data payload (e.g., if the transmission includes a segmentation indicator and / or segmentation information), and that subsequent transmissions are necessary to complete the payload, then the intermediate node 5-2 may decide not to immediately forward the data of the backscattered transmission (e.g., send an inventory response) to the RAN node 5-1. Instead, the intermediate node 5-2 may store the data temporarily in its buffer and / or memory and await the arrival of the remaining segmented transmissions before converting them into a single transmission for forwarding to the RAN node 5-1. In this scenario, other subsequent backscattered transmissions may be received by the intermediate node 5-2 from the ambient IoT device 3-1 at step S914.

[0197] Where the data payload is segmented and backscattered to the intermediate node 5-2 via several backscattered transmissions, at step S916, having received all of the backscattered transmissions necessary to reassemble the segmented data, the intermediate node 5-2 may aggregate the segmented data transmissions into a single RRC message for forwarding to the RAN node 5-1.

[0198] It will be appreciated that in practice, the intermediate node 5-2 may receive multiple data payloads coming from multiple different ambient IoT devices 3-1 at any one time, and that the intermediate node 5-2 may reassemble those respective segmented payloads at step S916 once all of the segments of each respective payload is successfully received by the intermediate node 5-2.

[0199] At step S918, having reassembled the payload, the intermediate node 5-2 forwards the data payload (e.g., inventory data) to the RAN node 5-1 in an appropriate RRC message. That RRC message may, by way of example only, include an ID of the ambient IoT device or devices 3-1 that backscattered the payload data to the intermediate node 5-2.

[0200] At step S920, the RAN node 5-1 sends the inventory data as a response to the inventory request (in step S902) to the core network 7. For example, the inventory response, which may include the inventory data in conjunction with the appropriate ambient IoT device IDs, may be sent to the core network 7 via an appropriate NGAP message. Alternatively, a specific GPRS tunneling protocol (GTP) tunnel can be established between RAN node 5-1 and core network 7 following the inventory request (in step S902) for the purpose of inventory data transmission.

[0201] It will be appreciated that in practice, the RAN node 5-1 may receive multiple inventory responses from multiple different ambient IoT device readers (i.e., intermediate nodes) at any one time. As such, the RAN node 5-1 (where appropriate) may aggregate some or all inventory responses prior to sending them to the core network 7 via an appropriate NGAP message. Thus, the RAN node 5-1 may send one or more NGAP messages to the core network 7 as inventory responses in response to the inventory requests sent at step S902.

[0202] DL data transmission in topology 2 　　Fig. 10 illustrates a simplified flow diagram of a DL data transmission procedure performed between a RAN node 5-1, an intermediate node 5-2 that acts as an ambient IoT device reader, and an ambient IoT devices 3-1.

[0203] As shown in Fig. 10 there is provided an ambient IoT device 3-1, an ambient IoT device reader (e.g., an intermediate node 5-2), and a RAN node 5-1 in communication with the core network 7.

[0204] Although not shown, prior to the steps in Fig. 10, an association may be defined between the ambient IoT device reader (e.g., the intermediate node 5-2) and ambient IoT devices 3-1 in its vicinity. Accordingly, the core network 7 may be aware in advance of which ambient IoT device reader (e.g., the intermediate node 5-2) serves for which ambient IoT devices 3-1. For example, the association may be defined via an appropriate device registration procedure whereby ambient IoT devices 3-1 register with a specific ambient IoT device reader in their vicinity. It will be appreciated that in the scenario where the ambient IoT device reader is an intermediate node 5-2, standard procedures known to the skilled person may be used by the core network 7 to track the intermediate node 5-2.

[0205] For simplicity, the ambient IoT device reader throughout following description is an intermediate node in the form of a UE 3. Nevertheless, it will be appreciated that the ambient IoT device reader may be any other appropriate intermediate node 5-2 and the procedure may be adapted appropriately (if necessary).

[0206] At step S1002, the core network 7 may send an inventory command (or appropriate specific configuration data) over an appropriate NGAP message to the RAN node 5-1. The inventory command (or appropriate specific configuration data) may, by way of example, indicate one or more specific ambient IoT devices 3-1 that the core network 7 wishes to query, or a special category of ambient IoT device 3-1 that the core network 7 wants to query. Where the core network 7 sends specific configuration data to the RAN node 5-1, that configuration data may be ciphered (e.g., encoded) and encapsulated into a transparent container.

[0207] At step S1004, if the intermediate node 5-2 is not in RRC connected state (and thus not able to perform data / message forwarding to the ambient IoT device 3-1, then the RAN node 5-1 sends an appropriate paging message to the intermediate node 5-2. That paging message may contain an appropriate paging cause indication to indicate to the intermediate node 5-2 that an inventory request for an ambient IoT device 3-1 has been received by the RAN node 5-1.

[0208] At step S1006, having received the paging message, the intermediate node 5-2, and the RAN node 5-1 may perform an appropriate RRC reestablishment procedure to re-establish an RRC connection between the intermediate node 5-2 and the RAN node 5-1, and thus enter RRC connected mode. For example, a random access channel (RACH) procedure may be performed between the intermediate node 5-2 and the RAN node 5-1. By way of example only, the intermediate node 5-2 and the RAN node 5-1 may perform a 2- or 4-step RACH procedure as is appropriate.

[0209] During the RACH procedure, the RAN node 5-1 may (re)configure the intermediate node 5-2 to perform an inventory request procedure. For example, the RAN node 5-1 may (re)configure the intermediate node 5-2 to provide resource allocations for an inventory request.

[0210] At step S1008, the intermediate node 5-2 may broadcast an appropriate paging or paging alike message (e.g., a 'message 0' / 'Msg0' message) to an ambient IoT devices 3-1 in the vicinity of the intermediate node 5-2. Whilst there may be a plurality of ambient IoT devices 3-1, for simplicity in Fig. 10 only one ambient IoT device 3-1 is shown.

[0211] For example, the intermediate node 5-2 may, for example, send a physical downlink channel message such as a physical 'receiver' downlink channel (PRDCH) access order message ('Msg0') to the ambient IoT devices 3-1, although it will nevertheless be appreciated that a similar alternative message could be used.

[0212] Msg0 serves as a 'query' type message that is used to indicate which ambient IoT devices 3-1 are to initiate an initial access procedure with the intermediate node 5-2. For example, Msg0 may include an indication of which ambient IoT devices 3-1 need to respond to the intermediate node 5-2. Alternatively (or additionally) Msg0 may also include an indication of a category of ambient IoT devices 3-1 that need to respond to the ambient IoT device reader. Alternatively (or additionally) Msg0 may also be configured to trigger the transmission of information reports from ambient IoT devices 3-1 that receive the message. Alternatively (or additionally) Msg0 may also configure specific information relevant to the ambient IoT devices 3-1 that are the intended recipients of the broadcast message.

[0213] It will be appreciated that as Msg0 may be used to indicate which ambient IoT devices 3-1 need to respond to the intermediate node 5-2, it also in turn indicates which ambient IoT devices 3-1 are to perform backscatter transmissions to the intermediate node 5-2.

[0214] Having received Msg0 at step S1008, the indicated ambient IoT devices 3-1 and the intermediate node 5-2 perform an appropriate initial access procedure at step S1010.

[0215] At step S1012, the RAN node 5-1 may send a specific Uu RRC message to the intermediate node 5-2 that includes the encapsulated inventory command or specific configuration data received by the RAN node 5-1 at step S1002. Within the Uu RRC message, the RAN node 5-1 may also indicate which ambient IoT device 3-1 or which type of ambient IoT device 3-1 needs to receive such data.

[0216] Notwithstanding the above however, it will be appreciated that the RAN node 5-1 may send the specific Uu RRC message to the intermediate node 5-2 at any point after the completion of RRC connection establishment between the RAN node 5-1 and the intermediate node 5-2 at step S1006.

[0217] At step S1014, having received the Uu RRC message (either at step S1012, or at some other appropriate earlier time), the intermediate node 5-2 may convert the received data within Uu RRC message into an RRC message over an ambient IoT interface if there is an A IoT RRC layer defined over the ambient IoT interface. Otherwise, the intermediate node 5-2 may convert the received data within Uu RRC message into a (RLC layer), MAC layer PDU, and / or PHY layer transport block. Additionally, the intermediate node 5-2 may perform data segmentation at the (RLC layer), MAC layer, or PHY layer prior to transmission of the data to an ambient IoT device 3-1.

[0218] At step S1016, the intermediate UE 3 (the intermediate node 5-2) may perform a first transmission over the R2D link to ambient IoT device or devices 3-1. For example, the intermediate UE 3 may perform a first transmission of a DL command and / or configuration data to the ambient IoT device or devices 3-1. Having received that first transmission, the ambient IoT device 3-1 determines, based for example on the contents of the transmission, whether the first transmission comprises a whole data payload, or whether the first transmission comprises a segment of a data payload in accordance with the segmentation procedures performed at the (RLC layer), MAC and / or PHY layer as described above.

[0219] Where the ambient IoT device 3-1 determines that the first transmission is a segmented transmission comprising only a segment of the expected data payload (e.g., if the transmission includes a segmentation indicator and / or segmentation information), and that subsequent transmissions are necessary to complete the payload, then the ambient IoT device 3-1 may decide not to immediately process the data of the transmission. Instead, the ambient IoT device 3-1 may store the data temporarily in its buffer and / or memory and await the arrival of the remaining segmented transmissions before converting them into a single transmission. In this scenario, other subsequent backscattered transmissions may be received by the ambient IoT device 3-1 from the RAN node 5-1 at step S1018.

[0220] Where the data payload is segmented, at step S1020, having received all of the segmented transmissions necessary to reassemble the segmented data, the ambient IoT device 3-1 may aggregate the segmented data transmissions prior to delivering the data payload to the upper layers of the ambient IoT device 3-1.

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

[0222] As shown, the UE 3-2; 3-3 has a transceiver circuit 131 that is operable to transmit signals to and to receive signals from a RAN node 5-1 via one or more antenna 133 (e.g., comprising one or more antenna elements). The UE 3 has a controller 137 to control the operation of the UE 3. The controller 137 is associated with a memory 139 and is coupled to the transceiver circuit 131. 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 135, 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 139 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

[0223] The controller 137 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 139. As shown, these software instructions include, among other things, an operating system 141, and a communication control module 143.

[0224] The communication control module 143 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 143 is configured for the overall handling of uplink communications 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 143 is also configured for the overall handling of receipt of downlink communications 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 143 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 communications (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.

[0225] It will be appreciated that the communication control module 143 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 143 may include the intermediate node protocol stack layers and corresponding entities to control functions at those layers as described above with reference to Figs. 5 & 6 when the intermediate node is a UE 3. The communication control module 143 is configured, in particular, to control the UE's communications, where applicable, in accordance with any of the methods described herein.

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

[0227] As shown, the ambient IoT device 3-1 (also referred to simply as an IoT device 3-1) has a transceiver circuit 331 that is operable to transmit signals to and to receive signals from a RAN node 5-1 (and / or an assisting node 5-2, and / or an intermediate node 5-2) via one or more antenna 333 (e.g., comprising one or more antenna elements).

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

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

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

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

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

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

[0234] The communication control module 343 is operable to control the communication between the IoT device 3-1, a RAN node 5-1, and / or an assisting node 5-2. The communication control module 343 may, for example, be configured for the overall handling of uplink communications via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 343 may also be configured for the overall handling of receipt of downlink communications 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).

[0235] It will be appreciated that the communication control module 343 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 343 may include the ambient IoT device protocol stack layers and corresponding entities to control functions at those layers as described above with reference to Figs. 5 & 6.

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

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

[0238] Fig. 13A is a more detailed block schematic illustrating the main components of an example of a UE 3 comprising an ambient IoT device 3-1 for possible implementation in the communication system 1 of Fig. 1.

[0239] As shown, the ambient IoT device 3-1 (also referred to simply as an IoT device 3-1) has a transceiver circuit 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-1 (e.g., comprising one or more antenna elements) which may be either shared or separate for the RF energy harvester and receiver / transmitter. The antenna is in turn connected to a matching network (i.e., an impedance transformer) module 333-5 configured to match impedance between the antenna and other components (including RF energy harvester and receiver related blocks).

[0240] The matching network module 333-5 is in turn connected (optionally) to a radio frequency (RF) bandpass filter (RF BPF) 333-2 for improving selectivity, a RF envelope detector 333-3 for converting RF signal to baseband, optionally a baseband low-pass filter (BB LPF) 333-4 configured to filter out harmonics and high frequency components to improve input signal quality to a comparator 333-6, and the comparator 333-6 to determine highs and lows of the input signal.

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

[0242] The energy harvesting circuitry 331-1 may include, by way of example only, inductive and / or capacitive architectures to harvest energy from incoming signals. For example, the energy harvesting circuitry 331-1 may include a RF energy harvester 331-1a, which may include can include a rectifier for performing RF signal (AC) to DC conversion, a power management unit (PMU) 331-1b configured to manage energy storage from energy harvester and suppling power to active component blocks which need power supply, and an energy storage unit 331-1c, e.g., a capacitor configured to store harvested energy from RF energy harvester.

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

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

[0245] In this example, the IoT device 3-1 also has baseboard (BB) logics 340 with a controller 337, an encoder, and a decoder. The controller 337 is configured to control the overall operation of the IoT device 3-1. The controller 337 is associated with a memory 339 and is coupled to the transceiver circuit 331. The memory 339 may comprise one of two types of memory: 1) Non-Volatile Memory (NVM) such as EEPROM for permanently storing device ID, etc., and 2) registers for temporarily keeping any information required for its operation only while energy is available in energy storage.

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

[0247] The controller 337 is configured to control overall operation of the IoT device 3-1 by, in this example, program instructions or software instructions stored within memory 339.

[0248] In addition, a clock generator 344 may also be provided as part of the BB logics 340.

[0249] Fig. 13B is another more detailed block schematic illustrating the main components of an example of a UE comprising an ambient IoT device 3-1 for possible implementation in the system of Fig. 1.

[0250] As shown, the ambient IoT device 3-1 (also referred to simply as an IoT device 3-1) has a transceiver circuit 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-1 (e.g., comprising one or more antenna elements) which may be either shared or separate for the RF energy harvester and receiver / transmitter. The antenna is in turn connected to a matching network (i.e., an impedance transformer) module 333-5 configured to match impedance between the antenna and other components (including RF energy harvester and receiver related blocks).

[0251] The matching network module 333-5 is in turn connected (optionally) to a radio frequency (RF) bandpass filter (RF BPF) 333-2 for improving selectivity, a RF envelope detector 333-3 for converting RF signal to baseband, optionally a baseband low-pass filter (BB LPF) 333-4 configured to filter out harmonics and high frequency components to improve input signal quality to a comparator 333-6, and the comparator 333-6 to determine highs and lows of the input signal. In addition, there may be provided, between the BB LPF 333-4 and the RF envelope detector 333-3, an BB amplifier (amp) 333-7 configured to amplify the BB signal from the RF envelope detector 333-3 to improve signal strength. Furthermore, there may also be provided, between the RF envelope detector 333-3 and the RF BPF 333-2, a low-noise amplifier (LNA) 333-8.

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

[0253] The energy harvesting circuitry 331-1 may include, by way of example only, inductive and / or capacitive architectures to harvest energy from incoming signals. For example, the energy harvesting circuitry 331-1 may include a RF energy harvester 331-1a, which may include can include a rectifier for performing RF signal (AC) to DC conversion, a power management unit (PMU) 331-1b configured to manage energy storage from energy harvester and suppling power to active component blocks which need power supply, and an energy storage unit 331-1c, e.g., a capacitor configured to store harvested energy from RF energy harvester. In addition, the energy harvesting circuitry 331-1 may include another energy harvester 331-1d for harvesting other types of energy.

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

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

[0256] Additionally, the transceiver circuit may also have a large frequency shifter 342 configured to shift backscattered signals from one frequency (e.g., FDD-DL frequency) to another frequency (e.g., FDD-UL frequency) - i.e., shift the frequency of the backscattered signals by tens of MHz. Additionally, the transceiver circuit may also have reflection amplifier 331-3 configured to amplify the backscattered signal.

[0257] In this example, the IoT device 3-1 also has baseboard (BB) logics 340 with a controller 337, an encoder, and a decoder. The controller 337 is configured to control the overall operation of the IoT device 3-1. The controller 337 is associated with a memory 339 and is coupled to the transceiver circuit 331. The memory 339 may comprise one of two types of memory: 1) Non-Volatile Memory (NVM) such as EEPROM for permanently storing device ID, etc., and 2) registers for temporarily keeping any information required for its operation only while energy is available in energy storage.

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

[0259] The controller 337 is configured to control overall operation of the IoT device 3-1 by, in this example, program instructions or software instructions stored within memory 339.

[0260] In addition, a clock generator 344 may also be provided as part of the BB logics 340.

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

[0262] As shown, the RAN node 5-1 has a transceiver circuit 551 for transmitting signals to and for receiving signals from the communication devices (such as UEs 3-2; 3-3, IoT devices 3-1, and possibly assisting or intermediate devices 5-2) via one or more antenna 553 (e.g., a single or multi-panel antenna array / massive antenna), and a core network interface 555 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 557 to control the operation of the RAN node 5-1. The controller 557 is associated with a memory 559. Software may be pre-installed in the memory 559 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The controller 557 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 559.

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

[0264] The communication control module 563 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 563 is configured for the overall control of the reception and decoding of uplink communications, 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 563 is also configured for the overall control of the transmission of downlink communications 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 563 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 communications (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the base station side; for configuring slots / symbols appropriately (e.g., for UL, DL or full duplex communication, or the like); for configuring bandwidth parts for the UE 3; for providing related configuration signalling to a UE 3; and the like.

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

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

[0267] Assisting (or intermediate) node 　　Fig. 15 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.

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

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

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

[0271] The communication control module 163 is operable to control the communication between the assisting node 5-2, the RAN node 5-1, and any IoT devices (including the ambient IoT device 3-1). The communications control module 163 is configured, in particular, for the overall handling of uplink communications to the RAN node 5-1. For example, where the assisting node 5-2 is a UE 3 (or at least operates like a UE 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 communications from the RAN node 5-1. For example, where the assisting node 5-2 is a UE 3 (or at least operates like a UE 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.

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

[0273] It will be appreciated that the communication control module 163 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 163 may include the intermediate node protocol stack layers and corresponding entities to control functions at those layers as described above with reference to Figs. 5 & 6. The communication control module 163 is configured, in particular, to control the assisting node's communications, in accordance with any of the methods described herein.

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

[0275] For example, it will be appreciated that whilst the described signalling procedures may involve data segmentation procedures at the MAC and / or PHY layer, such data segmentation procedure may also be performed at the RLC sublayer with its transparent mode enabled.

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

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

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

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

[0280] The software module or the program includes instructions (or software codes) that, when loaded into a computer, cause the computer to perform one or more of the functions described in the above examples. The program may be stored in a non-transitory computer readable medium or a tangible storage medium. By way of example, and not a limitation, non-transitory computer readable media or tangible storage media can include a random-access memory (RAM), a read-only memory (ROM), a flash memory, a solid-state drive (SSD) or other types of memory technologies, a CD-ROM, a digital versatile disc (DVD), a Blu-ray disc or other types of optical disc storage, and magnetic cassettes, magnetic tape, magnetic disk storage or other types of magnetic storage devices. The program may be transmitted on a transitory computer readable medium or a communication medium. By way of example, and not a limitation, transitory computer readable media or communication media can include electrical, optical, acoustical, or other forms of propagated signals.

[0281] Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input / output (IO) circuits; internal memories / caches (program and / or data); processing registers; communication buses (e.g. control, data and / or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and / or timers; and / or the like. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0282] The User Equipment (or "UE," "mobile station," "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface.

[0283] It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.

[0284] The terms "User Equipment" or "UE" (as the term is used by 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with one another, and include standalone mobile stations, such as terminals, cell phones, smart phones, tablets, cellular IoT devices, IoT devices, and machinery. It will be appreciated that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for an extended period of time.

[0285] A UE may, for example, be an item of equipment for production or manufacture and / or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and / or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and / or their application systems; tools; moulds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and / or related machinery; paper converting machinery; chemical machinery; mining and / or construction machinery and / or related equipment; machinery and / or implements for agriculture, forestry and / or fisheries; safety and / or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and / or application systems for any of the previously mentioned equipment or machinery etc.).

[0286] A UE may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motorcycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.).

[0287] A UE may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).

[0288] A UE may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and / or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).

[0289] A UE may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).

[0290] A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and / or system, a weapon, an item of cutlery, a hand tool, or the like.

[0291] A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).

[0292] A UE may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)," using a variety of wired and / or wireless communication technologies.

[0293] Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and / or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and / or inactive for an extended period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g., vehicles) or attached to animals or persons to be monitored / tracked.

[0294] It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communications network for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0295] It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be appreciated that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in the following table. This list is not exhaustive and is intended to be indicative of some examples of machine-type communication applications.

[0296] Further, the above-described UE categories are merely examples of applications of the technical ideas and exemplary examples described in the present document. Needless to say, these technical ideas and examples are not limited to the above-described UE and various modifications can be made thereto.

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

[0298] The previous description of the disclosed examples is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these examples will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other examples without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to be limited to the examples shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0299] This application is based upon and claims the benefit of priority from United Kingdom patent application No. 2404845.6, filed on April 4, 2024, the disclosure of which is incorporated herein in its entirety by reference.

[0300] The whole or part of the examples disclosed above can be described as, but not limited to, the following supplementary notes.

[0301] (Supplementary note 1) 　　A method performed by a reader device, the method comprising: 　　receiving, from a communication device, at least one Medium Access Control (MAC) protocol data unit (PDU), each of which includes a MAC header including segmentation information indicating at least one of: 　　　　whether a corresponding MAC PDU is segmented data from an application data payload, 　　　　whether a corresponding MAC PDU is an initial segment data, 　　　　whether a corresponding MAC PDU is a middle segment data, 　　　　whether a corresponding MAC PDU is a last segment data, or 　　　　whether there is any segmentation for current transmitted data; and 　　aggregating the at least one MAC PDU into the application data payload, in a case where the each of the at least one MAC PDU has segmentation information. (Supplementary note 2) 　　The method according to Supplementary note 1, wherein 　　the application data payload comprises at least one Non-Access Stratum (NAS) PDU. (Supplementary note 3) 　　The method according to Supplementary note 1 or 2, wherein 　　the segmentation information is represented by one or two bit information. (Supplementary note 4) 　　The method according to any one of Supplementary notes 1 to 3, further comprising: 　　dropping the at least one MAC PDU in a case where decoding the application data payload is failed. (Supplementary note 5) 　　The method according to Supplementary note 4, wherein 　　the dropping is determined upon an expiry of a timer. (Supplementary note 6) 　　The method according to any one of Supplementary notes 1 to 5, wherein 　　the at least one MAC PDU is stored at another layer than an Access Stratum (AS) layer. (Supplementary note 7) 　　The method according to any one of Supplementary notes 1 to 6, further comprising: 　　receiving, from an access network node, a message for reconfiguring the reader device for allocating a resource for transmitting the application data payload; and 　　transmitting, to the communication device, an access order for transmitting the application data payload, wherein 　　the receiving the at least one MAC PDU is performed upon transmitting the access order. (Supplementary note 8) 　　The method according to Supplementary note 7, wherein 　　the receiving the message is performed in a case where the access network node receives via an application protocol message, from a core network, a request for the application data payload. (Supplementary note 9) 　　The method according to Supplementary note 7 or 8, further comprising: 　　transmitting, to the access network node, the application data payload via a Radio Resource Control (RRC) message. (Supplementary note 10) 　　The method according to Supplementary note 9, wherein 　　the application data payload is transmitted from the access network node to the core network via an application protocol message. (Supplementary note 11) 　　The method according to Supplementary note 9 or 10, wherein 　　the RRC message includes an identity of the communication device. (Supplementary note 12) 　　The method according to any one of Supplementary notes 1 to 11, further comprising: 　　receiving, from an access network node, a Radio Resource Control (RRC) message including a downlink application data payload for transmitting to the communication device; 　　segmenting the downlink application data payload to at least one MAC PDU; and 　　transmitting the MAC PDU to the communication device, and 　　wherein each of the MAC PDU includes a MAC header including segmentation information indicating at least one of: 　　　　whether a corresponding MAC PDU is segmented data from the downlink application data payload, 　　　　whether a corresponding MAC PDU is an initial segment data, 　　　　whether a corresponding MAC PDU is a middle segment data, 　　　　whether a corresponding MAC PDU is a last segment data, or 　　　　whether there is any segmentation for current transmitted data. (Supplementary note 13) 　　A method performed by a communication device, the method comprising: 　　segmenting an application data payload to at least one Medium Access Control (MAC) protocol data unit (PDU); and 　　transmitting the MAC PDU to a reader device, and 　　wherein each of the MAC PDU includes a MAC header including segmentation information indicating at least one of: 　　　　whether a corresponding MAC PDU is segmented data from the application data payload, 　　　　whether a corresponding MAC PDU is an initial segment data, 　　　　whether a corresponding MAC PDU is a middle segment data, 　　　　whether a corresponding MAC PDU is a last segment data, or 　　　　whether there is any segmentation for current transmitted data. (Supplementary note 14) 　　A reader device comprising: 　　means for receiving, from a communication device, at least one Medium Access Control (MAC) protocol data unit (PDU), each of which includes a MAC header including segmentation information indicating at least one of: 　　　　whether a corresponding MAC PDU is segmented data from an application data payload, 　　　　whether a corresponding MAC PDU is an initial segment data, 　　　　whether a corresponding MAC PDU is a middle segment data, 　　　　whether a corresponding MAC PDU is a last segment data, or 　　　　whether there is any segmentation for current transmitted data; and 　　means for aggregating the at least one MAC PDU into the application data payload, in a case where the each of the at least one MAC PDU has segmentation information. (Supplementary note 15) 　　A communication device comprising: 　　means for segmenting an application data payload to at least one Medium Access Control (MAC) protocol data unit (PDU); and 　　means for transmitting the MAC PDU to a reader device, and 　　wherein each of the MAC PDU includes a MAC header including segmentation information indicating at least one of: 　　　　whether a corresponding MAC PDU is segmented data from the application data payload, 　　　　whether a corresponding MAC PDU is an initial segment data, 　　　　whether a corresponding MAC PDU is a middle segment data, 　　　　whether a corresponding MAC PDU is a last segment data, or 　　　　whether there is any segmentation for current transmitted data.

[0302] 1　　COMMUNICATION SYSTEM 3　　USER EQUIPMENT (UE) 3-1　　UE, AMBIENT IoT DEVICE 3-2, 3-3　　NON-IoT UE 5　　RADIO ACCESS NETWORK (RAN) 5-1　　RAN NODE, AMBIENT IoT DEVICE READER 5-2　　INTERMEDIATE NODE, ASSISTING NODE, AMBIENT IoT DEVICE READER 7　　CORE NETWORK 9　　CELL 10　　CONTROL PLANE FUNCTION (CPF) 10-1　　ACCESS AND MOBILITY MANAGEMENT FUNCTION (AMF) 10-2　　SESSION MANAGEMENT FUNCTION (SMF) 10-n　　OTHER FUNCTIONS 11　　USER PLANE FUNCTION (UPF) 20 　　COMMUNICATION 20-1　　UNMODULATED CARRIER SIGNAL 20-2　　MODULATED BACKSCATTERED SIGNAL 20-3　　COMMUNICATION, DOWNLINK SIGNAL 21　　EXTERNAL DATA NETWORK 32　　APPLICATION LAYER 34　　AMBIENT IoT NON-ACCESS STRATUM (A-IoT NAS) LAYER 35, 35-2　　A-IoT RADIO RESOURCE CONTROL (RRC) LAYER 36, 36-2　　A-IoT MEDIUM ACCESS CONTROL (MAC) LAYER 38, 38-2　　A-IoT PHYSICAL (PHY) LAYER 52　　NEXT GENERATION APPLICATION PROTOCOL (NGAP) LAYER 54　　LOWER LAYER 55　　A-IoT RRC LAYER 56　　A-IoT MAC LAYER 58　　A-IoT PHY LAYER 72　　APPLICATION LAYER 74　　A-IoT NAS LAYER 76　　NGAP LAYER 78　　LOWER LAYER 60-1, 60-2　　RRC LAYER 62-1, 62-2　　PDCP LAYER 64-1, 64-2　　RLC LAYER 66-1, 66-2　　MAC LAYER 68-1, 68-2　　PHY LAYER 131　　TRANSCEIVER CIRCUIT 133　　ANTENNA 135　　USER INTERFACE 137　　CONTROLLER 139　　MEMORY 141　　OPERATING SYSTEM 143　　COMMUNICATION CONTROL MODULE 151　　TRANSCEIVER CIRCUIT 153　　ANTENNA 155　　RAN INTERFACE 157　　CONTROLLER 159　　MEMORY 161　　OPERATING SYSTEM 163　　COMMUNICATION CONTROL MODULE 331　　TRANSCEIVER CIRCUIT 331-1　　ENERGY HARVESTING CIRCUITRY 331-1a　　RF ENERGY HARVESTER 331-1b　　POWER MANAGEMENT UNIT (PMU) 331-1c　　ENERGY STORAGE UNIT 331-1d　　ENERGY HARVESTER 331-2　　MODULATION CIRCUITRY, BACKSCATTER MODULATOR 331-3　　SIGNAL AMPLIFIER, REFLECTION AMPLIFIER 332　　DATA SOURCE 333, 333-1　　ANTENNA 333-2　　RADIO FREQUENCY (RF) BANDPASS FILTER (BPF) 333-3　　RF ENVELOPE DETECTOR 333-4　　BASEBAND LOW-PASS FILTER (BB LPF) 333-5　　MATCHING NETWORK MODULE 333-6　　COMPARATOR 333-7　　BB AMPLIFIER (AMP) 333-8　　LOW-NOISE AMPLIFIER (LNA) 335　　USER INTERFACE 337　　CONTROLLER 339　　MEMORY 340　　BASEBOARD (BB) LOGICS 341　　OPERATING SYSTEM 342　　LARGE FREQUENCY SHIFTER 343　　COMMUNICATION CONTROL MODULE 344　　CLOCK GENERATOR 345　　DATA BUFFER 551　　TRANSCEIVER CIRCUIT 553　　ANTENNA 555　　CORE NETWORK INTERFACE 557　　CONTROLLER 559　　MEMORY 561　　OPERATING SYSTEM 563　　COMMUNICATION CONTROL MODULE

Claims

1. A method performed by a reader device, the method comprising: 　　receiving, from a communication device, at least one Medium Access Control (MAC) protocol data unit (PDU), each of which includes a MAC header including segmentation information indicating at least one of: 　　　　whether a corresponding MAC PDU is segmented data from an application data payload, 　　　　whether a corresponding MAC PDU is an initial segment data, 　　　　whether a corresponding MAC PDU is a middle segment data, 　　　　whether a corresponding MAC PDU is a last segment data, or 　　　　whether there is any segmentation for current transmitted data; and 　　aggregating the at least one MAC PDU into the application data payload, in a case where the each of the at least one MAC PDU has segmentation information.

2. The method according to claim 1, wherein 　　the application data payload comprises at least one Non-Access Stratum (NAS) PDU.

3. The method according to claim 1 or 2, wherein 　　the segmentation information is represented by one or two bit information.

4. The method according to any one of claims 1 to 3, further comprising: 　　dropping the at least one MAC PDU in a case where decoding the application data payload is failed.

5. The method according to claim 4, wherein 　　the dropping is determined upon an expiry of a timer.

6. The method according to any one of claims 1 to 5, wherein 　　the at least one MAC PDU is stored at another layer than an Access Stratum (AS) layer.

7. The method according to any one of claims 1 to 6, further comprising: 　　receiving, from an access network node, a message for reconfiguring the reader device for allocating a resource for transmitting the application data payload; and 　　transmitting, to the communication device, an access order for transmitting the application data payload, wherein 　　the receiving the at least one MAC PDU is performed upon transmitting the access order.

8. The method according to claim 7, wherein 　　the receiving the message is performed in a case where the access network node receives via an application protocol message, from a core network, a request for the application data payload.

9. The method according to claim 7 or 8, further comprising: 　　transmitting, to the access network node, the application data payload via a Radio Resource Control (RRC) message.

10. The method according to claim 9, wherein 　　the application data payload is transmitted from the access network node to the core network via an application protocol message.

11. The method according to claim 9 or 10, wherein 　　the RRC message includes an identity of the communication device.

12. The method according to any one of claims 1 to 11, further comprising: 　　receiving, from an access network node, a Radio Resource Control (RRC) message including a downlink application data payload for transmitting to the communication device; 　　segmenting the downlink application data payload to at least one MAC PDU; and 　　transmitting the MAC PDU to the communication device, and 　　wherein each of the MAC PDU includes a MAC header including segmentation information indicating at least one of: 　　　　whether a corresponding MAC PDU is segmented data from the downlink application data payload, 　　　　whether a corresponding MAC PDU is an initial segment data, 　　　　whether a corresponding MAC PDU is a middle segment data, 　　　　whether a corresponding MAC PDU is a last segment data, or 　　　　whether there is any segmentation for current transmitted data.

13. A method performed by a communication device, the method comprising: 　　segmenting an application data payload to at least one Medium Access Control (MAC) protocol data unit (PDU); and 　　transmitting the MAC PDU to a reader device, and 　　wherein each of the MAC PDU includes a MAC header including segmentation information indicating at least one of: 　　　　whether a corresponding MAC PDU is segmented data from the application data payload, 　　　　whether a corresponding MAC PDU is an initial segment data, 　　　　whether a corresponding MAC PDU is a middle segment data, 　　　　whether a corresponding MAC PDU is a last segment data, or 　　　　whether there is any segmentation for current transmitted data.

14. A reader device comprising: 　　means for receiving, from a communication device, at least one Medium Access Control (MAC) protocol data unit (PDU), each of which includes a MAC header including segmentation information indicating at least one of: 　　　　whether a corresponding MAC PDU is segmented data from an application data payload, 　　　　whether a corresponding MAC PDU is an initial segment data, 　　　　whether a corresponding MAC PDU is a middle segment data, 　　　　whether a corresponding MAC PDU is a last segment data, or 　　　　whether there is any segmentation for current transmitted data; and 　　means for aggregating the at least one MAC PDU into the application data payload, in a case where the each of the at least one MAC PDU has segmentation information.

15. A communication device comprising: 　　means for segmenting an application data payload to at least one Medium Access Control (MAC) protocol data unit (PDU); and 　　means for transmitting the MAC PDU to a reader device, and 　　wherein each of the MAC PDU includes a MAC header including segmentation information indicating at least one of: 　　　　whether a corresponding MAC PDU is segmented data from the application data payload, 　　　　whether a corresponding MAC PDU is an initial segment data, 　　　　whether a corresponding MAC PDU is a middle segment data, 　　　　whether a corresponding MAC PDU is a last segment data, or 　　　　whether there is any segmentation for current transmitted data.

Images