Communication method and ambient IoT device

Abstract

A communication method according to one embodiment of the present invention is used in a mobile communication system. The communication method includes a step in which an ambient Internet of Things (IoT) device receives a predetermined message including a plurality of pieces of predetermined information from a reader device, which is a network node or a user device of a mobile communication system. The communication method also includes a step in which the ambient IoT device transmits Device to Reader (D2R) data to the reader device using transmission resources corresponding to the order in which the prescribed information is included in the prescribed message.

Description

Communication methods and ambient IoT devices

[0001] This disclosure relates to a communication method and ambient IoT device used in a mobile communication system.

[0002] In recent years, IoT (Internet of Things) has attracted attention in wireless communication technology. It is expected that the interconnection of more "things" will improve production efficiency and enhance the comfort of daily life compared to the past. Technologies used in IoT include, for example, barcodes and RFID (Radio Frequency Identifier). However, barcodes and RFID cannot perform long-distance wireless communication, making it difficult to support large-scale networks.

[0003] Therefore, the 3GPP (The Third Generation Partnership Project) (registered trademark; hereinafter the same), a standardization project for mobile communication systems, is considering the feasibility of new IoT technologies. This IoT technology is envisioned to have a higher number of connections and higher device density than existing IoT technologies in 3GPP, such as NB-IoT (Narrow Band-IoT) or LTE-MTC (Long Term Evolution-Machine Type Communication). Furthermore, this IoT technology is envisioned to have lower complexity and power consumption than existing 3GPP LPWA (Low Power Wide Area) technology. The IoT devices used in this IoT technology are called Ambient IoT devices.

[0004] Most existing wireless communication devices use batteries that require manual replacement and / or charging. On the other hand, powering all IoT devices with batteries is difficult to achieve because it would require not only the cost of the IoT devices themselves, but also the maintenance costs of those IoT devices.

[0005] The ambient IoT devices described above are intended to function as battery-less devices without energy storage capabilities. In this case, the ambient IoT devices function as purely battery-less devices that have no energy storage function whatsoever and are entirely dependent on the availability of external energy sources.

[0006] Alternatively, ambient IoT devices are envisioned to function as battery devices with limited energy storage capabilities. Limited energy storage capabilities refer to, for example, energy storage capabilities that do not require manual replacement and / or charging.

[0007] The use of such ambient IoT devices is expected to lead to automation and digitalization in various industries, as well as the opening up of new markets.

[0008] 3GPP TR 38.848 V18.0.0 (2023-09) 3GPP TR 38.769 V19.0.0 (2024-12)

[0009] This disclosure provides a communication method that enables appropriate D2R data transmission in ambient IoT devices.

[0010] The first embodiment of the communication method is a communication method used in a mobile communication system. The communication method includes the step of an ambient IoT (Internet of Things) device receiving a predetermined message containing a plurality of predetermined pieces of information from a network node or a reader device which is a user device of the mobile communication system. The communication method also includes the step of the ambient IoT device transmitting D2R (Device to Reader) data to the reader device using transmission resources corresponding to the order in which the predetermined pieces of information are included in the predetermined message.

[0011] The second aspect of the communication method is a communication method used in a mobile communication system. The communication method includes the step of an ambient IoT (Internet of Things) device receiving a predetermined message, which includes additional information indicating whether or not it includes an AS ID (Access Stratum ID), from a network node or user device, which is a reader device of the mobile communication system. The communication method also includes the step of the ambient IoT device communicating with the reader device using the additional information.

[0012] Figure 1 is a diagram showing an example configuration of a mobile communication system according to the first embodiment. Figure 2 is a diagram showing an example configuration of a UE (User Equipment) according to the first embodiment. Figure 3 is a diagram showing an example configuration of a network node (gNB) according to the first embodiment. Figure 4 is a diagram showing an example configuration of a protocol stack according to the first embodiment. Figure 5 is a diagram showing an example configuration of a protocol stack according to the first embodiment. Figure 6 is a diagram showing an example configuration of an ambient IoT device according to the first embodiment. Figures 7(A) and 7(B) are diagrams showing examples of topology of an ambient IoT device according to the first embodiment. Figure 8 is a diagram showing an example configuration of an ambient IoT device according to the first embodiment. Figure 9 is a diagram showing an example configuration of an ambient IoT device according to the first embodiment. Figure 10 is a diagram showing an example configuration of a protocol stack for an ambient IoT device in the first embodiment. Figure 11 is a diagram showing an example of an overall procedure according to the first embodiment. Figure 12 is a diagram showing a first operation example according to the first embodiment. Figures 13(A) and 13(B) are diagrams showing an example configuration of an ambient IoT paging message according to the first embodiment. Figure 14 is a diagram showing an example of operation according to the second embodiment. Figures 15(A) and 15(B) are diagrams showing an example configuration of Msg2 according to the first embodiment. Figure 16 is a diagram showing another example of operation 1 according to the second embodiment. Figure 17 is a diagram showing another example of operation 2 according to the second embodiment. Figure 18 is a diagram showing an example of operation according to the third embodiment. Figure 19 is a diagram showing an example of time slots and frequency channels. Figure 20 is a diagram showing an example of an A-IoT paging message structure. Figure 21 is a diagram showing a general framework of slot-type ALOHA for A-IoT random access procedures. Figure 22 is (N Ｔ × N Ｆ Figure 23 is a diagram showing an example of an access opportunity / resource index in the D2R resource grid. Figure 24 is a diagram showing an example of the Msg2 structure. Figure 24 is a diagram showing the overall AS procedure between the A-IoT device and the reader. Figure 25 is (N Ｔ × N ＦFigure 26 shows an example of an index of access opportunities / resources in a D2R resource grid. Figure 26 shows an R2D time slot that implicitly assigns an index of D2R access opportunities / resources.

[0013] A mobile communication system according to an embodiment will be described with reference to the drawings. In the drawings, identical or similar parts are denoted by the same or similar reference numerals.

[0014] [First Embodiment]

[0015] (1) Configuration of the Mobile Communication System The configuration of the mobile communication system according to the first embodiment will be described. Figure 1 is a diagram showing an example of the configuration of the mobile communication system 1 according to the first embodiment. The mobile communication system 1 conforms to the 5th Generation System (5GS) of the 3GPP standard. In the following description, 5GS will be used as an example, but the mobile communication system may also have an LTE (Long Term Evolution) system applied to it at least partially. The mobile communication system may also have a 6th Generation (6G) system or later system applied to it at least partially.

[0016] The mobile communication system 1 comprises a network (NW) 10 and a user device (UE) 100. The UE 100 is a mobile communication device that performs wireless communication with the NW 10. The UE 100 may be any device used by a user, such as a mobile phone terminal (including a smartphone) and / or a tablet terminal, a notebook PC (Personal Computer), a communication module (including a communication card or chipset), a sensor or a device installed on a sensor, a vehicle or a device installed on a vehicle (Vehicle UE), or an aircraft or a device installed on an aircraft (Aerial UE).

[0017] NW10 includes a radio access network (RAN) 20 and a core network (CN) 30. When the mobile communication system is a fifth-generation system (5GS), RAN20 is referred to as NG-RAN (Next Generation Radio Access Network) and CN30 is referred to as 5GC (5G Core Network).

[0018] RAN20 includes multiple network nodes 200 (network nodes 200a to 200c in the example in Figure 1). The network nodes 200 are interconnected via inter-network node interfaces. In RAN20, network nodes 200 are sometimes referred to as base stations. When a network node 200 is a base station, it consists of a CU (Central Unit) and a DU (Distribution Unit) (i.e., functionally divided), and the two units may be connected by a front-haul interface. When the mobile communication system 1 is 5GS, the network nodes 200 are referred to as gNBs, the inter-network node interfaces as Xn interfaces, and the front-haul interfaces as F1 interfaces.

[0019] Furthermore, if at least a part of the mobile communication system 1 is an LTE system, the network node 200 may be an eNB (evolved Node B) which is an LTE base station. Also, if the mobile communication system 1 is a sixth-generation system or later, the network node 200 has the function of a base station and may be a device equivalent to a gNB or eNB.

[0020] Each network node 200 manages one or more cells. Each network node 200 performs wireless communication with the UE 100 that has established a connection with its own cell. Each network node 200 has functions such as wireless resource management (RRM), routing of user data (also simply referred to as "data"), and measurement and control functions for mobility control and scheduling. The term "cell" is used to indicate the smallest unit of a wireless communication area. The term "cell" is also used to indicate a function or resource that performs wireless communication with the UE 100. One cell belongs to one carrier frequency. One cell may be associated with one downlink component carrier and one uplink component carrier. The bandwidth corresponding to one cell (system bandwidth) may be divided into multiple bandwidth parts (BWP: Bandwidth Part). In the following explanation, the gNB may be used as an example of a network node 200.

[0021] CN30 includes a CN (Core Network) device 380. The CN device 380 may include a C-plane device corresponding to the control plane (C-plane) and a U-plane device corresponding to the user plane (U-plane). The C-plane device performs various mobility controls and paging for the UE100. The C-plane device communicates with the UE100 using NAS (Non-Access Stratum) signaling. The U-plane device controls data transfer. When the mobile communication system is 5GS, the C-plane device is called AMF (Access and Mobility Management Function), the U-plane device is called UPF (User Plane Function), and the interface between the network node 200 and the CN device 380 is called the NG interface.

[0022] Figure 2 shows an example configuration of UE100 (user device) according to the first embodiment. UE100 includes a receiving unit 110, a transmitting unit 120, and a control unit 130. The receiving unit 110 and the transmitting unit 120 constitute a wireless communication unit 140 that performs wireless communication with the network node 200.

[0023] The receiving unit 110 performs various types of reception under the control of the control unit 130. The receiving unit 110 includes an antenna and a receiver. The receiver converts the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 130.

[0024] The transmitting unit 120 performs various types of transmissions under the control of the control unit 130. The transmitting unit 120 includes an antenna and a transmitter. The transmitter converts the baseband signal (transmission signal) output by the control unit 130 into a wireless signal and transmits it from the antenna.

[0025] The control unit 130 performs various control and processing operations in the UE 100. Such processing includes processing in each layer described later. The operation of the UE 100 described above and later may be controlled by the control unit 130. The control unit 130 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing operations.

[0026] Figure 3 shows an example configuration of a network node 200 (gNB) according to the first embodiment. The network node 200 includes a transmitting unit 210, a receiving unit 220, a control unit 230, and a network communication unit 240. The transmitting unit 210 and the receiving unit 220 constitute a wireless communication unit 250 that performs wireless communication with the UE 100.

[0027] The transmitting unit 210 performs various types of transmissions under the control of the control unit 230. The transmitting unit 210 includes an antenna and a transmitter. The transmitter converts the baseband signal (transmission signal) output by the control unit 230 into a wireless signal and transmits it from the antenna.

[0028] The receiving unit 220 performs various types of reception under the control of the control unit 230. The receiving unit 220 includes an antenna and a receiver. The receiver converts the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 230.

[0029] The control unit 230 performs various controls and processes in the network node 200. Such processes include the processes of each layer described later. The operations of the network node 200 described above and below may be operations under the control of the control unit 230. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used for the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals, etc. The CPU executes programs stored in the memory to perform various processes.

[0030] The network communication unit 240 is connected to an adjacent base station via an Xn interface which is a base station-to-base station interface. The network communication unit 240 is connected to the CN device 380 via an NG interface which is a base station-core network interface. Note that the network node 200 may be composed of a CU (Central Unit) and a DU (Distributed Unit) (that is, functionally split), and the two units may be connected by an F1 interface which is a front haul interface.

[0031] FIG. 4 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data.

[0032] The radio interface protocol of the user plane has a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, and an SDAP (Service Data Adaptation Protocol) layer.

[0033] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Between the PHY layer of the UE 100 and the PHY layer of the network node 200, data and control information are transmitted via a physical channel. Note that the PHY layer of the UE 100 receives downlink control information (DCI) transmitted on a physical downlink control channel (PDCCH) from the network node 200. Specifically, the UE 100 performs blind decoding of the PDCCH using a radio network temporary identifier (RNTI), and acquires the DCI that has been successfully decoded as the DCI addressed to the UE itself. The DCI transmitted from the network node 200 is appended with a cyclic redundancy check (CRC) parity bit scrambled by the RNTI.

[0034] The MAC layer performs priority control of data, retransmission processing by hybrid automatic repeat request (HARQ), and random access procedures, etc. Between the MAC layer of the UE 100 and the MAC layer of the network node 200, data and control information are transmitted via a transport channel. The MAC layer of the network node 200 includes a scheduler. The scheduler determines the uplink and downlink transport formats (transport block size, modulation and coding scheme (MCS)) and the resource blocks allocated to the UE 100.

[0035] The RLC layer transmits data to the RLC layer on the receiving side by utilizing the functions of the MAC layer and the PHY layer. Between the RLC layer of the UE 100 and the RLC layer of the network node 200, data and control information are transmitted via a logical channel.

[0036] The PDCP layer performs header compression / decompression, encryption / decryption, etc.

[0037] The SDAP layer maps IP flows, which are the units under which the core network performs QoS (Quality of Service) control, to wireless bearers, which are the units under which the AS (Access Stratum) performs QoS control. Note that if the RAN is connected to the EPC, the SDAP is not required.

[0038] Figure 5 shows the configuration of the protocol stack of the wireless interface of the control plane that handles signaling (control signals).

[0039] The control plane's wireless interface protocol stack includes an RRC (Radio Resource Control) layer and a NAS (Non-Access Stratum) layer, instead of the SDAP layer shown in Figure 4.

[0040] RRC signaling for various settings is transmitted between the RRC layer of UE100 and the RRC layer of network node 200. The RRC layer controls the logical channel, transport channel, and physical channel in response to the establishment, re-establishment, and release of the wireless bearer. If there is a connection (RRC connection) between the RRC of UE100 and the RRC of network node 200, UE100 is in the RRC connected state. If there is no connection (RRC connection) between the RRC of UE100 and the RRC of network node 200, UE100 is in the RRC idle state. If the connection between the RRC of UE100 and the RRC of network node 200 is suspended, UE100 is in the RRC inactive state.

[0041] The NAS layer (also simply referred to as "NAS"), located above the RRC layer, performs session management and mobility management, etc. NAS signaling is transmitted between the NAS layer of the UE100 and the NAS layer of the CN device 380 (AMF). In addition to the wireless interface protocol, the UE100 also has an application layer, etc. Furthermore, the layer below the NAS layer is called the AS layer (also simply referred to as "AS").

[0042] (2) Ambient IoT device The mobile communication system 1 according to the embodiment supports ambient IoT devices. Hereinafter, ambient IoT devices may be simply referred to as "devices".

[0043] (2.1) Diagram 6 of the ambient IoT device overview shows an example configuration of the ambient IoT device 300 according to the first embodiment. The ambient IoT device 300 is a wireless communication device capable of wireless communication with a reader device which is a UE 100 or a network node 200. The ambient IoT device 300 may perform wireless communication within the frequency band of the mobile communication system 1.

[0044] The ambient IoT device 300 may transmit information from within the ambient IoT device 300 by reflecting radio waves transmitted from a reader device (UE 100 or network node 200) and modulating the reflected waves. Generally, the technique of reflecting unmodulated radio waves and modulating the reflected waves to transmit information is called backscattering communication. The ambient IoT device 300 may have a backscattering communication function. The ambient IoT device 300 may be an information medium that can read information from its internal memory or write information to its internal memory by using the backscattering communication function. In this case, the ambient IoT device 300 may receive a transmitted radio wave with modulated information and extract the information by demodulating the received radio wave.

[0045] The ambient IoT device 300 may be a battery-less IoT device. In this case, the ambient IoT device 300 converts received radio waves into energy (specifically, electricity) and operates using that energy. The ambient IoT device 300 may use an energy source other than radio waves, for example, by converting light, heat, magnetism, vibration, or sound into energy. Generally, this type of energy conversion is called energy harvesting. Known methods may be used for energy harvesting itself. Thus, the ambient IoT device 300 may have an energy harvesting function. Alternatively, the ambient IoT device 300 may have a limited battery function. The ambient IoT device 300 may have a battery function that charges the power acquired by the energy harvesting function. The ambient IoT device 300 may also be a wireless tag.

[0046] As shown in Figure 6, the ambient IoT device 300 includes an antenna 310, a modulator 320, a control unit 330, and a memory 340.

[0047] Antenna 310 receives an unmodulated carrier wave. This unmodulated carrier wave will be referred to as CW (Continuous Wave) below. Antenna 310 converts the received CW into a received signal and outputs this received signal to modulator 320. Antenna 310 also reflects the CW according to the transmission signal output from modulator 320 and transmits the reflected wave. This reflected wave will be referred to as BS (Back Scattering or Back Scatter) below. Antenna 310 performs BS transmission.

[0048] The modulator 320 may, under the control of the control unit 330, modulate the data read from the memory 340 to generate a transmission signal. The modulator 320 outputs the modulated signal to the antenna 310. Alternatively, the modulator 320 may, under the control of the control unit 330, demodulate the received signal from the antenna 310 to acquire data. The modulator 320 outputs the acquired data to the control unit 330. In the ambient IoT device 300, the modulator 320 may specifically be a switch. When the switch receives a received signal from the antenna 310, it turns on and outputs the received signal to the control unit 330. The switch is also controlled by the control unit 330 to be on or off, and outputs a transmission signal corresponding to the on or off state to the antenna 310. The switch may be an RF (Radio Frequency) switch. The switch may be made up of transistors. Alternatively, the switch may be a mechanical switch that can be physically switched on or off.

[0049] The control unit 330 may have an energy harvesting function that converts the received signal from the modulator 320 into power. The control unit 330 may use this power to drive the ambient IoT device 300 and control the modulator 320 and the memory 340. The control unit 330 also reads the information stored in the memory 340 and controls the modulator 320 to transmit a transmission signal corresponding to that information. For example, the control unit 330 can control the reflectivity of the reflected wave (BS) by controlling the on or off state of the modulator 320 (for example, setting the reflectivity to 100% or 0%), and output a transmission signal corresponding to the information stored in the memory 340 (for example, 1 bit) from the modulator 320 to the antenna 310. Alternatively, the control unit 330 can control the timing of turning the modulator 320 on or off to output a transmission signal corresponding to multiple bits from the modulator 320 to the antenna 310. Thus, the control unit 330 may control the reflectivity of the reflected wave (BS) by controlling the on or off state of the modulator 320, and transmit the modulated reflected wave corresponding to the information stored in the memory 340 from the antenna 310.

[0050] Memory 340 holds various types of information. The information held in memory 340 may be information acquired when the ambient IoT device 300 functions as a sensor. Alternatively, the information held in memory 340 may be information specific to the ambient IoT device 300 that has been previously stored in memory 340. Examples of such specific information include identification information of the ambient IoT device 300 (or the group to which it belongs). The type of such identification information may be "Device ID", "Group ID", and / or "ALL". Under the control of the control unit 330, the information held in memory 340 can be read. Information may also be written to memory 340 under the control of the control unit 330. In this case, the control unit 330 (or modulator 320) converts the received signal received from the antenna 310 into a baseband signal in the baseband band, reads the information from the baseband signal, and writes the read information to memory 340.

[0051] The ambient IoT device 300 may have a limited battery. Limited means a battery that does not require manual replacement and / or charging, as described above. The ambient IoT device 300 may also have the ability to generate signals itself. In this case, the ambient IoT device 300 does not need to receive the CW signal and does not need to perform the BS transmission. That is, the ambient IoT device 300 transmits a transmission signal it generates itself via the antenna 310. As shown in Figure 6, the communication unit 345 may be configured with the antenna 310 and the modulator 320.

[0052] (2.2) Topology of the Ambient IoT Device Figures 7(A) and 7(B) are diagrams that show examples of the topology of the ambient IoT device 300. Figure 7(A) shows an example of "Topology 1", and Figure 7(B) shows an example of "Topology 2".

[0053] The device that performs wireless communication with the ambient IoT device 300 is referred to as the reader device (or "Reader") 400. As shown in Figure 7(A), in "Topology 1", the reader device 400 becomes the network node 200 (gNB). The reader device 400 may also be a relay node, which is a type of network node. For example, the reader device 400 may be an IAB (Integrated Access and Backhaul) node or an NCR (Network-Controlled Repeater). In "Topology 1", data and / or signaling related to the ambient IoT device 300 are transferred between the ambient IoT device 300 and the network node 200.

[0054] In the example shown in Figure 7(A), the ambient IoT device 300 communicates directly and bidirectionally with the network node 200, which corresponds to the reader device 400. In this case, the wireless communication unit 250 (transmitter 210 and receiver 220) of the network node 200 is capable of wireless communication with the ambient IoT device 300. For example, the transmitter 210 of the network node 200 may transmit an unmodulated carrier wave under the control of the control unit 230. This carrier wave may be reflected by the ambient IoT device 300. The receiver 220 of the network node 200 may receive the reflected wave from the ambient IoT device 300 under the control of the control unit 230, convert it into a baseband signal, and output it to the control unit 230.

[0055] As shown in Figure 7(B), in "Topology 2," the reader device 400 is the UE 100. In this case, the UE 100 corresponds to an intermediate node between the ambient IoT device 300 and the network node 200. In "Topology 2," the ambient IoT device 300 communicates bidirectionally with the UE 100. The reader device 400 transmits data and / or signaling related to the ambient IoT device 300 between the network node 200 and the ambient IoT device 300.

[0056] In the example shown in Figure 7(B), the UE 100 performs wireless communication over the Uu interface with the network node 200. The ambient IoT device 300 communicates directly and bidirectionally with the UE 100, which corresponds to the reader device 400. In this case, the wireless communication unit 140 (receiving unit 110 and transmitting unit 120) of the UE 100 can communicate wirelessly with the ambient IoT device 300. For example, the receiving unit 110 of the UE 100 may receive reflected waves reflected by the ambient IoT device 300 under the control of the control unit 130. The receiving unit 110 may receive the received reflected waves as a wireless signal, convert them into a baseband signal, and output them to the control unit 130. The transmitting unit 120 of the UE 100 may transmit an unmodulated carrier wave under the control of the control unit 130. This carrier wave may be reflected by the ambient IoT device 300.

[0057] (2.3) Detailed Configuration Example of Ambient IoT Devices In 3GPP, it has been agreed that there are three types of ambient IoT devices 300: "Device 1", "Device 2a", and "Device 2b".

[0058] "Device 1" is, for example, a device whose peak power consumption is "1 μW" or less, which does not perform amplification in either the DL direction or the UL direction, and which performs backscattering transmission using an externally provided carrier wave.

[0059] "Device 2a" is, for example, a device whose peak power consumption is "several hundred μW" or less, which performs amplification in the DL direction and / or UL direction, and which performs backscattering transmission using an externally provided carrier wave.

[0060] "Device 2b" is, for example, a device with a peak power consumption of "several hundred μW" or less, which performs amplification in the DL direction and / or UL direction, and which generates UL transmission within the device. Furthermore, all device types have an energy storage function.

[0061] Figure 8 is a diagram showing an example configuration of the ambient IoT device 300 of "Device 1" according to the first embodiment.

[0062] Device 1 includes an antenna 310, a matching network 350, an RF energy harvester 351, a PMU (Power Management Unit) 352, an energy storage unit 353, an RF BPF (Radio Frequency Band Pass Filter) 354, an RF envelope detector (or envelope detector) 355, a BB LPF (Base Band Low Pass Filter) 356, a comparator 357, a baseband logic 358, a memory 359, a backscattering modulator 360, and a clock generator 361.

[0063] The matching network 350 matches the impedance of the antenna 310 with other blocks (including the RF energy harvester 351 and the RF BPF 354) and outputs the radio signal received by the antenna 310 to the other blocks.

[0064] The RF energy harvester 351 has an energy harvesting function and extracts energy from radio signals. The RF energy harvester 351 may also have a rectifier that converts the AC component of the radio signal into the DC component of the radio signal.

[0065] The PMU 352 manages (or controls) the storage of energy from the RF energy harvester 351, as well as managing (or controls) the supply of power to blocks that require power.

[0066] The energy storage unit 353 stores energy from the RF energy harvester 351.

[0067] The RF BPF354 outputs radio signals in a specific frequency band. The RF BPF354 is used to improve selectivity. Note that the RF BPF354 may not be present in "Device 1" depending on the implementation.

[0068] The RF envelope detector 355 converts the radio signal in the radio band output from the RF BPF 354 into a baseband signal in the baseband band.

[0069] The BB LPF 356 removes the high-frequency components of the baseband signal output from the RF envelope detector 355, improving the quality of the signal input to the comparator 357.

[0070] The comparator 357 determines whether the input signal output from the BB LPF 356 is "high" or "low". Note that the comparator 357 may detect not only two values, "high" and "low", but also three or more values.

[0071] The baseband logic 358 includes functional blocks such as encoders, decoders, and controllers.

[0072] Memory 359 stores device identification information (or device ID) for identifying (or distinguishing) the ambient IoT device 300 from other ambient IoT devices. Memory 359 may be a non-volatile memory (for example, an EEPROM (Electrically Erasable Programmable Read-Only Memory)) that permanently stores the device ID and other information. Memory 359 may also be a memory (register) that temporarily stores necessary information only while the energy stored in the energy storage unit 353 is available.

[0073] The backscattering modulator 360 modulates the output signal from the baseband logic 358 into a backscattering signal by switching the impedance. Alternatively, the backscattering modulator 360 modulates the high-frequency signal (e.g., CW) input from the antenna 310 into a backscattering signal by switching the impedance (antenna or transmission line impedance) based on the output signal (digital signal or digital data) from the baseband logic 358. For example, the backscattering modulator 360 can modulate and then reflect the high-frequency signal input from the antenna 310 by terminating the high-frequency input signal at digital data "0" (not reflecting) and leaving the high-frequency input signal open at digital data "1" (reflecting).

[0074] The clock generator 361 generates the necessary clock signal within the device.

[0075] The above is an example of the configuration of "Device 1". The matching network 350, RF BPF 354, RF envelope detector 355, BB LPF 356, comparator 357, and backscattering modulator 360 may be included in the modulator 320 shown in Figure 6. Also, the PMU 352 and baseband logic 358 may be included in the control unit 330 shown in Figure 6. Furthermore, the memory 359 may correspond to the memory 340 shown in Figure 6.

[0076] Figure 9 is a diagram showing an example configuration of the ambient IoT device 300 of "device 2a" according to the first embodiment.

[0077] Device 2a, in addition to Device 1 shown in Figure 8, further includes an LNA (Low Noise Amplifier) ​​365, a baseband amplifier 366, a large frequency shifter 367, a reflection amplifier 368, and an energy harvester 369.

[0078] The LNA365 amplifies the output signal from the RF BPF354 (i.e., the signal from the reader device (network node 200 or UE100)) to improve the signal strength and sensitivity at the receiving end.

[0079] The baseband amplifier 366 amplifies the baseband signal output from the RF envelope detector 355, improving the signal strength.

[0080] The large frequency shifter 367 shifts the frequency of the backscattering signal from one frequency (e.g., FDD-DL frequency) to another frequency (e.g., FDD-UL frequency).

[0081] The Energy Harvester 369 performs energy harvesting using methods other than RF signals. Specifically, energy harvesting methods include sunlight (solar panels), vibration (vibration power generation), and heat (thermal power generation), but are not limited to these.

[0082] The above describes an example configuration of "device 2a". In the example block configuration shown in Figure 9, in relation to the example block configuration shown in Figure 6, the LNA 365, baseband amplifier 366, large frequency shifter 367, and reflection amplifier 368 may be further included in the modulator 320.

[0083] (2.4) Protocol stack for ambient IoT device Figure 10 is a diagram showing an example of the configuration of a protocol stack for an ambient IoT device 300 according to the first embodiment.

[0084] The wireless interface protocol comprises a PHY layer and an Ambient IoT (A-IoT) MAC layer. Communication between the reader device 400 and the Ambient IoT device 300, described later, may be performed by at least one of the layers shown in Figure 10. A new layer (New AS Protocol) may be introduced as a layer above the Ambient IoT MAC layer.

[0085] The physical channel used for transmission from the reader device 400 to the ambient IoT device 300 (hereinafter sometimes referred to as "R2D (Reader-to-Device) transmission") is called the PRDCH (Physical Reader to Device channel). The channel used for R2D transmission is also called the R2D channel. The R2D channel may also be the PRDCH. The message transmitted using the R2D channel is called the R2D message. The R2D message may also be a message defined in "A-IoT MAC" (or "New AS Protocol").

[0086] On the other hand, the physical channel used for transmission from the ambient IoT device 300 to the reader device 400 (hereinafter sometimes referred to as "D2R (Device to Reader) transmission") is called the PDRCH (Physical Device to Reader channel). The channel used for D2R transmission is also called the D2R channel. The D2R channel may also be the PDRCH. The message transmitted using the D2R channel is called the D2R message. The D2R message may also be a message defined in "A-IoT MAC" (or "New AS Protocol").

[0087] For example, in "Topology 1," the physical channel used for R2D transmission from network node 200 to ambient IoT device 300 is PRDCH, and the physical channel used for D2R transmission from ambient IoT device 300 to network node 200 is PDRCH. Similarly, in "Topology 2," the physical channel used for R2D transmission from UE100 to ambient IoT device 300 is PRDCH, and the physical channel used for D2R transmission from ambient IoT device 300 to UE100 is PDRCH.

[0088] Furthermore, the control plane between the reader device 400 and the ambient IoT device 300 lacks an RRC layer, and therefore does not support RRC connection management, Layer 3 (L3) measurement reporting, or periodic system information and master information blocks (MIBs). In addition, the ambient IoT device 300 does not support conventional paging messages.

[0089] The user plane between the reader device 400 and the ambient IoT device 300 does not contain the SDAP layer, PDCP layer, or RLC layer. Furthermore, the AS layer, which is above the PHY layer, does not support HARQ and RLC AM (Acknowledge Mode).

[0090] (3) Operation of the mobile communication system The operation of the mobile communication system 1 having the ambient IoT device 300 will be described.

[0091] (3.1) The overall procedure diagram 11 is a diagram showing an example of the overall procedure in the mobile communication system 1 according to the first embodiment. In Figure 11, an example of the overall procedure after the reader device 400 receives a service request is shown. If the reader device 400 receives a service request again, the overall procedure shown in Figure 11 is repeated. Note that Figure 11 shows an example of "Topology 1" in which the gNB acts as the reader device 400 and communicates with the ambient IoT device 300.

[0092] Step S1: The reader device 400 receives a service request from an upper node. Alternatively, it may receive a service request from a lower layer (e.g., the AS layer) or an upper layer (e.g., the NAS layer) within the reader device 400.

[0093] Firstly, the service request includes, as visible information for the reader device 400, at least one of the following: 1) the type of service, 2) the ambient IoT device 300 to be called, and 3) the approximate number of ambient IoT devices 300 to be called.

[0094] An example of a service type is "inventory." "Inventory" is one of the services (use cases) used, for example, to check for the existence of an ambient IoT device 300. Another example of a service type is "command." "Command" is one of the services (use cases) used to issue various commands to the ambient IoT device 300, such as read, write, or disable. Furthermore, there may be a service type called "inventory and command" which performs both "inventory" and "command" simultaneously. A service request may include information that identifies which service it is as a service type.

[0095] Secondly, service requests also include transparent information that cannot be seen by the reader device 400. Transparent information includes the contents of "commands" (such as read commands). Transparent information also includes "inventory." Transparent information may also include the contents of services instructed by the higher-level node.

[0096] In the case of "Topology 1," the service request may be included in a message sent from the CN device 380 to the gNB, for example, in an NG-AP (Application Protocol) message. In the case of "Topology 2," the service request may be included in a message sent from the gNB to the UE 100, for example, in an RRC message or a System Information Block (SIB).

[0097] Step S2: In response to receiving a service request, the reader device 400 sends an ambient IoT paging message (ambient IoT paging message) to the ambient IoT device 300, similar to a conventional paging message. The ambient IoT paging message may be a message that initiates communication between the reader device 400 and the ambient IoT device 300. Alternatively, the A-IoT paging message may be a call message (or trigger message) that initiates a call (or trigger) to the ambient IoT device 300.

[0098] Firstly, ambient IoT paging messages include device identification information that identifies the ambient IoT device 300. Device identification information may be used to identify the ambient IoT device 300 to be called. There are different types of device identification information, such as a "device ID" (individual identification information) that identifies each ambient IoT device 300 individually. There are also different types of device identification information, such as a "group ID" (group identification information) that identifies the group to which the ambient IoT devices belong. Furthermore, there is a type of device identification information called "ALL" (all identification information) that represents all ambient IoT devices. However, if the ambient IoT paging message does not include device identification information, it will represent "ALL".

[0099] Secondly, the ambient IoT paging message includes resource information. This resource information is used for transmission from the ambient IoT device 300 to the reader device 400 (for example, Msg1 or D2R messages).

[0100] Thirdly, ambient IoT paging messages may include R2D commands. R2D commands represent commands sent from the reader device to the ambient IoT device 300. R2D commands are used in the case of "command" services, and the command included in the service request (step S1) may be an R2D command.

[0101] The ambient IoT paging message may also be an initial trigger message. An initial trigger message is, for example, a message that includes an ambient IoT device that needs to respond to a service request. The reader device 400 can use the ambient IoT paging message as an initial trigger message to call the ambient IoT device 300.

[0102] The ambient IoT device 300 receives an ambient IoT paging message. The ambient IoT device 300 determines whether it successfully received the ambient IoT paging message. If successful, it checks the device identification information. If it matches its own device identification information (i.e., it is being called), it performs the next step S3. The following explanation assumes that the ambient IoT paging message was successfully received.

[0103] Steps S3 to S7 (Random Access Procedure): Steps S3 to S7 represent an RA procedure for ambient IoT devices, similar to normal random access (RA). The RA procedure from steps S3 to S7 performs contention resolution to avoid D2R message transmission conflicts.

[0104] There are two types of RA procedures: "3-step RA" and "2-step RA". In "3-step RA", three messages (Msg1, Msg2, and Msg3) from step S4 to step S7 are used. In "2-step RA", two messages (Msg1 and Msg2) other than Msg3 in step S7 are used. There is also a conflict-free procedure called "conflict-free" as a method of accessing the reader device 400 from the ambient IoT device 300. In "conflict-free", Msg1 to Msg3 are skipped, and after receiving the ambient IoT paging message (step S2), a D2R message is sent (step S9).

[0105] In step S3, the ambient IoT device 300 determines and / or selects a resource (or access opportunity).

[0106] In step S4, the ambient IoT device 300 sends message 1 (Msg1) to the reader device 400 using the resource selected in step S3. Msg1 may include a random ID. In "3-step RA", the random ID is a required component, but in "2-step RA", the random ID is used optionally. The random ID may be random identification information generated by the ambient IoT device. The number of bits in the random ID is fixed at "16" bits.

[0107] In step S5, the reader device 400 sends message 2 (Msg2) containing the random ID to the ambient IoT device 300. Since the random ID is used as is in Msg2, it can become echo information. In the case of "2-step RA", the random ID may not be included in Msg1, but in this case, 3GPP has not yet determined what information in Msg2 will be used as echo information.

[0108] In step S6, the ambient IoT device 300 determines whether or not the conflict has been resolved. The ambient IoT device 300 considers the conflict resolution to be successful (OK) if the random ID sent in Msg1 matches the random ID received in Msg2. In other words, the ambient IoT device 300 can determine that the resources used to send Msg1 did not conflict with the resources used to send Msg1 from other ambient IoT devices, since the random ID sent in Msg1 was received in Msg2. On the other hand, the ambient IoT device 300 considers the conflict resolution to have failed if the two random IDs do not match. In this case, the ambient IoT device 300 could determine that the resource used to send Msg1 was in conflict with a resource used to send Msg1 from another ambient IoT device, since it could not receive the random ID sent in Msg1 in Msg2. Therefore, the conflict resolution could be considered to have failed. Conflict resolution could also be a procedure that determines whether or not the resources used to send Msg1 are in conflict.

[0109] In the case of "3-step RA," in step S7, the ambient IoT device 300 sends message 3 (Msg3) to the reader device 400. The resources used to send Msg3 are explicitly notified by Msg2. Msg3 may also be a response (ACK / NACK) to step S6 (conflict resolution). Msg3 may include higher layer data. The higher layer data may be the device ID of the ambient IoT device 300. Note that in the case of "conflict-free," higher layer data may also be included in the D2R message (step S9).

[0110] In step S7, the ambient IoT device 300 may send a very first D2R message to the reader device 400 separately from Msg3. The ambient IoT device 300 may also send the very first D2R message after step S7.

[0111] The early D2R message may include an energy status report. An ambient IoT device 300 may not have energy, and an early D2R message including an energy status report may be used as a follow-up message for such an ambient IoT device 300. Alternatively, the early D2R message may include a simple message size report. Alternatively, the early D2R message may include a failure indicator or a success indicator. The failure indicator and success indicator may be used for failure and success in conflict resolution (step S6), respectively. Alternatively, the failure indicator and success indicator may be used for failure and success in data transmission and reception (step S8 or step S9), respectively.

[0112] Step S8: The reader device 400 sends an R2D message to the ambient IoT device 300. The R2D message may include an R2D command.

[0113] Step S9: The ambient IoT device 300 sends a D2R message to the reader device 400. The D2R message may include feedback information corresponding to the R2D command (step S8).

[0114] Step S10: The reader device 400 sends a Subsequent Ambient IoT paging message (subsequent Ambient IoT paging message) to the Ambient IoT device 300. The Subsequent Ambient IoT paging message is, for example, a message associated with the same service request as the Ambient IoT paging message (Step S2), and is a message that follows the said Ambient IoT paging message.

[0115] (4) Communication method according to the first embodiment Next, a communication method according to the first embodiment will be described.

[0116] The ambient IoT paging function uses ambient IoT paging messages to indicate ambient IoT devices 300 that require a response. In other words, the reader device 400 can use ambient IoT paging messages to specify the ambient IoT device 300 to be called. Therefore, ambient IoT messages may require an identifier (device ID) of the ambient IoT device 300.

[0117] 3GPP has approved, as a Work Item (WI), that an ambient IoT paging message can either contain one device ID or not contain one. An ambient IoT paging message that does not contain a device ID indicates that all ambient IoT devices 300 that receive the message must respond.

[0118] Regarding the device IDs included in a single ambient IoT paging message, it is anticipated that multiple device IDs may be included in the future. When multiple device IDs are used, each ambient IoT device 300 will need to be allocated a dedicated resource for D2R message transmission. In this case, for example, it is conceivable to allocate a dedicated resource for each device ID in the ambient IoT paging message. However, depending on the number of device IDs, the message length of the ambient IoT paging message will increase, and the load on the ambient IoT device 300 may exceed a certain level.

[0119] In the first embodiment, we focus on the conflict-free (CF) access procedure. In the case of conflict-free access, the ambient IoT device 300 does not perform conflict resolution, and after receiving the ambient IoT paging message, D2R data transmission is performed using the D2R data transmission message. In this case, if the ambient IoT device 300 cannot appropriately select the transmission resource, the D2R data transmission message it sends may collide with a D2R data transmission message sent from another ambient IoT device 300. Therefore, the reader device 400 may not be able to receive the D2R data transmission message properly.

[0120] Therefore, the objective of the first embodiment is to ensure that D2R data transmission is performed appropriately in the ambient IoT device 300.

[0121] Therefore, in the first embodiment, the ambient IoT device 300 performs D2R data transmission using transmission resources corresponding to the order of device IDs included in the ambient IoT paging message.

[0122] Specifically, firstly, an ambient IoT device (e.g., ambient IoT device 300) receives an ambient IoT paging message (an example of a predetermined message) containing multiple device IDs (an example of multiple predetermined pieces of information) from a reader device (e.g., reader device 400) which is a network node (e.g., network node 200) or user equipment (e.g., UE 100) of a mobile communication system. Secondly, the ambient IoT device transmits D2R data to the reader device using transmission resources corresponding to the order in which the device IDs (an example of predetermined information) are included in the ambient IoT paging message.

[0123] As a result, for example, if an ambient IoT device 300 can confirm its own device ID from the paging message, the transmission resource will be determined by the order of that device ID within the ambient IoT paging message, and by using that transmission resource, D2R data can be transmitted appropriately. Furthermore, even when D2R data transmission messages are sent from multiple ambient IoT devices 300, the order of the device IDs included in the ambient IoT paging message is expected to be different for each, so the transmission resource corresponding to that order will be used, and the D2R data sent from multiple ambient IoT devices 300 will also be sent using different transmission resources (i.e., dedicated resources). Therefore, it is possible to reduce the possibility of collisions between D2R data transmission messages to below a certain level. In addition, since the ambient IoT message does not contain a transmission resource, the size of the ambient IoT paging message will not become unnecessarily long, and it is possible to reduce the load on the ambient IoT device 300.

[0124] (5) Example of operation according to the first embodiment Next, an example of operation according to the first embodiment will be described.

[0125] Figure 12 is a diagram showing an example of operation according to the first embodiment. In the following description, an example of topology 1 (where the reader device 400 is a network node 200) will be used, but the example of operation according to the first embodiment can also be implemented in topology 2 (where the reader device 400 is a UE 100). Similarly, in the operation examples of the second embodiment and subsequent embodiments, an example of topology 1 will be used, but implementation is also possible in topology 2.

[0126] As shown in Figure 12, in step S20, the reader device 400 (transmitting unit 210 of the network node 200) transmits an ambient IoT paging message. The ambient IoT paging message according to the first embodiment includes a plurality of device IDs.

[0127] Firstly, the ambient IoT paging message may include multiple device IDs (or call IDs), and the multiple device IDs may be time-multiplexed.

[0128] In other words, multiple device IDs may be time-multiplexed within one time slot (or one ambient IoT paging message). Figure 13(A) is a diagram showing an example of the configuration of an ambient IoT paging message according to the first embodiment. As shown in Figure 13(A), an ambient IoT paging message includes a header area and a device ID area. The header area may include identification information indicating that the message is an ambient IoT paging message. The device ID area includes the device ID of the ambient IoT device 300 to be called. As shown in Figure 13(A), assuming that one ambient IoT paging message is transmitted using one time slot, multiple device IDs (ID#1, ID#2, ..., and ID#2) are included within one such message.

[0129] Alternatively, multiple ambient IoT paging messages may span multiple time slots, resulting in time-multiplexed multiple device IDs. Figure 13(B) shows an example of the configuration of an ambient IoT paging message according to the first embodiment. As shown in Figure 13(B), multiple device IDs are time-multiplexed by linking one ambient IoT message containing one device ID across multiple time slots. As shown in Figure 13(B), a set of multiple ambient IoT paging messages configured by linking multiple ambient IoT paging messages may be defined as a "hyper-ambient IoT paging message". A "hyper-ambient IoT paging message" may also be called a "hyper-paging message".

[0130] Secondly, ambient IoT paging messages may include additional information.

[0131] The additional information may indicate whether or not it contains multiple device IDs. Alternatively, the additional information may indicate whether or not it invokes multiple device IDs. Alternatively, the additional information may indicate whether or not it concatenates ambient IoT paging messages. Alternatively, the additional information may indicate whether or not it is a "hyperpaging message".

[0132] The additional information may be information indicating the number of IDs. This ID may be the ID of the caller. This ID may be a device ID and / or a group ID. Alternatively, the additional information may be information indicating the number of linked ambient IoT paging messages.

[0133] The additional information may indicate the duration of the ambient IoT paging message. Alternatively, the additional information may indicate the period of the hyperpaging message.

[0134] The ambient IoT device 300 can determine the duration of reception of ambient IoT paging messages using additional information. For example, if the number of device IDs is known, the duration of reception of ambient IoT paging messages can be determined, and the reception measurement period can also be directly determined by the duration of the ambient IoT paging messages. If the reception duration is known, the ambient IoT device 300 can also determine the end timing of the ambient IoT paging message or the start timing of the next procedure, making it possible to start sending Msg1 or D2R data in a conflict-free access environment at the appropriate time.

[0135] Thirdly, the ambient IoT paging message may include resource allocation information. The resource allocation information may consist of the number of channels in the frequency direction (M) and the number of time slots in the time direction (N). Each of the M × N resources may be assigned a resource number according to a certain rule. The certain rule may be that each resource is assigned a different resource number from other resources. Each resource indicated by a resource number may be used as a transmission resource for D2R data transmission (step S23).

[0136] Returning to Figure 12, the communication unit 345 of the ambient IoT device 300 receives an ambient IoT paging message (step S20).

[0137] In step S21, the control unit 330 of the ambient IoT device 300 checks whether the ambient IoT paging message in step S20 is addressed to itself. Specifically, the control unit 330 checks whether the device ID included in the ambient IoT paging message is its own device ID. In the following explanation, we will assume that the device ID included in the ambient IoT paging message is its own device ID (i.e., the ambient IoT paging message is addressed to itself).

[0138] In step S22, the control unit 330 of the ambient IoT device 300 determines the transmission resources to be used for D2R data transmission. In the first embodiment, an example of a conflict-free access embodiment is shown, in which the ambient IoT device 300 performs D2R data transmission after receiving an ambient IoT paging message.

[0139] As described above, the transmission resources used for D2R data transmission are transmission resources corresponding to the order in which the device IDs are included in the ambient IoT paging message. For example, in the ambient IoT paging message shown in Figure 13(A) (or Figure 13(B)), resource numbers #1, #2, ..., and #n are assigned according to the order (or time position) of device ID #1 (ID#1), device ID #2 (ID#2), ..., and device ID #n (ID#n). The control unit 330 determines resource number #1, corresponding to the first device #1, as the transmission resource for D2R data transmission if its own device ID is included in the ambient IoT paging message as the first ID, and determines resource number #2, corresponding to the second device, as the transmission resource for D2R data transmission if its own device ID is included in the ambient IoT paging message as the second ID. The relationship between the order of device IDs and the transmitted resources (e.g., resource numbers) may be specified, or it may be hardcoded in the ambient IoT device 300 and the reader device 400.

[0140] Furthermore, if the control unit 330 of the ambient IoT device 300 confirms its own device ID in the ambient IoT paging message, it may stop receiving ambient IoT paging messages even if reception of ambient IoT paging messages is continuing. By stopping reception, for example, it is possible to reduce processing load or power consumption in the ambient IoT device 300.

[0141] Returning to Figure 12, in step S23, the communication unit 345 of the ambient IoT device 300 transmits D2R data using the transmission resources determined in step S22. The communication unit 345 may also transmit D2R data using a D2R data transmission message. The start timing of D2R data transmission may be notified from the reader device 400 to the ambient IoT device 300 by a D2R message. Alternatively, the D2R message may function as a trigger message indicating the start timing of D2R data transmission.

[0142] [Second Embodiment] Next, a second embodiment will be described. In the first embodiment, an example of D2R data transmission in a conflict-free access procedure was described, but in the second embodiment, an example of D2R data transmission after receiving Msg2 will be described. Msg2 (Message 2) is a message used in a conflict resolution-based random access procedure (CBRA).

[0143] In the ambient IoT device 300, if conflict resolution is successful after receiving Msg2, D2R data transmission can be performed. However, 3GPP has not yet discussed what resources should be used for D2R data transmission. Therefore, even if conflict resolution is successful in the ambient IoT device 300, D2R data transmission may not be performed properly.

[0144] Therefore, the second embodiment, like the first embodiment, aims to ensure that D2R data transmission is performed appropriately in the ambient IoT device 300.

[0145] Furthermore, in the case of the ambient IoT device 300, if conflict resolution fails, it is assumed that the resources used to transmit Msg1 will not be used for D2R data transmission. The fact that these resources will not be continuously available is not necessarily desirable from the standpoint of effectively utilizing resources for D2R data transmission.

[0146] Therefore, in the second embodiment, a further objective is to enable the use of transmission resources for D2R data transmission even if conflict resolution fails.

[0147] Therefore, in the second embodiment, the ambient IoT device 300 performs D2R data transmission using transmission resources corresponding to the order of echo information contained in Msg2.

[0148] Specifically, firstly, an ambient IoT device (e.g., ambient IoT device 300) receives Msg2 (an example of a predetermined message) containing multiple echo pieces (an example of multiple predetermined pieces of information) from a reader device (e.g., reader device 400) which is a network node (e.g., network node 200) or user equipment (e.g., UE 100) of a mobile communication system. Secondly, the ambient IoT device transmits D2R data to the reader device using transmission resources corresponding to the order in which the echo pieces are included in Msg2.

[0149] As a result, for example, if the ambient IoT device 300 can confirm the random ID it sent in Msg1 from the echo information contained in Msg2, the transmission resource can be determined by the order of the echo information in Msg2, and by using that transmission resource, D2R data can be transmitted appropriately.

[0150] Furthermore, for example, the D2R data transmission resource is simply linked to the echo information in the order of the echo information. Therefore, even if conflict resolution fails (i.e., the random ID itself is not present in the echo information), the transmission resource can still be used. If the random ID that the user transmitted is confirmed as echo information in the next Msg2, the transmission resource can be used. Thus, even if conflict resolution fails, it is still possible to use the resources for D2R data transmission.

[0151] (1) Example of operation according to the second embodiment Next, an example of operation according to the second embodiment will be described.

[0152] Figure 14 is a diagram illustrating an example of operation according to the second embodiment.

[0153] As shown in Figure 14, in step S30, the transmitting unit of the reader device 400 (the transmitting unit 210 of the network node 200) transmits an ambient IoT paging message.

[0154] Firstly, regarding ambient IoT paging messages, as in the first embodiment, they may be messages in which multiple device IDs are time-multiplexed within a single time slot (Figure 13(A)). Alternatively, ambient IoT messages may be linked across multiple time slots to form a message in which multiple device IDs (or multiple ambient IoT paging messages) are time-multiplexed (Figure 13(B), "hyperpaging message").

[0155] Secondly, the ambient IoT paging message may include resource allocation information, similar to the first embodiment. The resource number is used as the transmission resource for D2R data transmission (step S36), similar to the first embodiment.

[0156] In step S31, the control unit 330 of the ambient IoT device 300 checks whether its own device ID is included in the ambient IoT paging message received in step S30. Hereafter, it is assumed that the ambient IoT paging message is addressed to itself. The CBRA procedure is then performed.

[0157] In step S32, the communication unit 345 of the ambient IoT device 300 transmits Msg1. Msg1 contains a 16-bit random ID. The receiving unit of the reader device 400 (the receiving unit 220 of the network node 200) receives Msg1.

[0158] In step S33, the transmitting unit of the reader device 400 (the transmitting unit 210 of the network node 200) transmits Msg2.

[0159] Firstly, Msg2 contains the random ID of Msg1 as echo information.

[0160] Secondly, Msg2 may time-multiplex echo information to multiple ambient IoT devices 300. Figures 15(A) and 15(B) show examples of the configuration of Msg2 according to the first embodiment. As shown in Figure 15(A), multiple echo information may be time-multiplexed in one time slot (one Msg2). As shown in Figure 15(B), one Msg2 may span multiple time slots, and multiple echo information may be time-multiplexed across multiple time slots.

[0161] Alternatively, multiple Msg2s containing the same echo information may be time-multiplexed in different time slots. For example, assuming that one Msg2 contains one piece of echo information, multiple Msg2s may be time-multiplexed in different time slots. Alternatively, as shown in Figures 15(A) and 15(B), assuming that one Msg2 contains multiple pieces of echo information, multiple Msg2s may be time-multiplexed in different time slots. Considering the backscattering function in the ambient IoT device 300, it is desirable for the reader device 400 to transmit different Msg2s containing the same echo information in units of time slots.

[0162] Furthermore, Msg2 may include the resource allocation information described above. The control unit 330 of the ambient IoT device 300 may determine the resources, which consist of the number of channels (M) and the number of time slots (N), based on the resource allocation information, and determine the resource number corresponding to each resource.

[0163] The communication unit 345 of the ambient IoT device 300 receives Msg2.

[0164] Returning to Figure 14, in step S34, the control unit 330 of the ambient IoT device 300 performs conflict resolution. The control unit 330 may determine whether conflict resolution is successful based on whether the random ID it sent in Msg1 matches the random ID included as echo information in Msg2. In the following explanation, we will assume that the two random IDs match and the control unit 330 has determined that conflict resolution was successful.

[0165] In step S35, the control unit 330 of the ambient IoT device 300 determines the transmission resource for D2R data transmission.

[0166] As described above, the transmission resources used for D2R data transmission are resources corresponding to the order in which the echo information is included in Msg2. For example, in Msg2 shown in Figure 15(A) (or Figure 15(B)), resource numbers #1, #2, ..., and #n are assigned according to the order (or time position) of echo information #1 (Echo#1), echo information #2 (Echo#2), ..., and echo information ID #n (Echo#n). The control unit 330 checks the position in Msg2 of the echo information that contains the same random ID as the random ID transmitted in Msg1, and determines the resource number corresponding to the position of that echo information as the transmission resource for D2R data transmission. For example, if the control unit 330 finds that the random ID transmitted in Msg1 is included in the first echo information #1 (Echo #1), it determines resource number #1 corresponding to the first echo information #1 (Echo #1) as the transmission resource for D2R data transmission. Similarly, if the random ID transmitted in Msg1 is included in the third echo information #3 (Echo #3), the control unit 330 determines resource number #3 corresponding to the third echo information #3 (Echo #3) as the transmission resource for D2R data transmission. The relationship between the order of the echo information and the transmission resources may be specified, or it may be hardcoded in the ambient IoT device 300 and the reader device 400.

[0167] Multiple transmission resources may exist for a single ambient IoT device 300 for D2R data transmission. As described above, multiple Msg2s containing the same random ID as echo information may be transmitted using different time slots. Assuming that each Msg2 contains one piece of echo information, the existence of multiple Msg2s containing the same echo information (or the same random ID) will result in multiple resource numbers. The ambient IoT device 300 can also perform D2R data transmission using multiple resource numbers, i.e., multiple transmission resources. By using multiple transmission resources, for example, it is possible to accommodate situations where one transmission resource is insufficient for the amount of data required for D2R data transmission, and multiple transmission resources are needed. Alternatively, it is possible to transmit the same D2R data using multiple resources, thereby increasing the reliability of the D2R data to a certain level.

[0168] Returning to Figure 14, in step S36, the communication unit 345 of the ambient IoT device 300 transmits D2R data using the transmission resource determined in step S35.

[0169] (2) Another example of operation according to the second embodiment Another example of operation according to the second embodiment is an example of operation for Msg2 used in the CBRA procedure.

[0170] If the reader device 400 can successfully receive Msg1 transmitted from multiple ambient IoT devices 300, it can transmit Msg2, which contains a random ID as echo information, to the multiple ambient IoT devices 300. On the other hand, if the Msg1 transmitted from multiple ambient IoT devices 300 collide and the reader device 400 cannot successfully receive Msg1, it cannot obtain a random ID and therefore cannot transmit Msg2, which contains a random ID as echo information.

[0171] Now, let's focus on Msg2. If we assume that Msg2 is sent if Msg1 is received successfully, and not sent if Msg1 is not received successfully, then the size (duration) of Msg2 will change depending on whether or not Msg1 was received successfully. Therefore, the ambient IoT device 300 may not be able to determine the end timing of Msg2, nor the start timing of D2R data transmission.

[0172] Therefore, in another operation example 1 according to the second embodiment, the objective is to enable the ambient IoT device 300 to understand the termination timing of Msg2 even if the duration of Msg2 is variable.

[0173] Therefore, in the other operation example 1, Msg2 includes an end marker. Specifically, firstly, Msg2 includes an end marker. Secondly, the ambient IoT device (e.g., ambient IoT device 300) detects at least one of the end timing of Msg2 and the start timing of D2R data transmission in response to detecting the end marker.

[0174] Figures 15(A) and 15(B) show examples of the structure of Msg2 including an end marker (EM). As shown in Figures 15(A) and 15(B), Msg2 includes a header area, an echo information area, and an end marker area. The header area may include identification information indicating that the message is Msg2. The echo information area contains echo information. The end marker area contains an end marker (EM). An end marker area exists for each echo information area. That is, an end marker (EM) exists for each echo information.

[0175] As shown in the examples in Figures 15(A) and 15(B), an end marker of "0" may indicate that a subsequent Msg2 exists, or that subsequent echo information exists. Conversely, an end marker of "1" may indicate that a subsequent Msg2 does not exist, or that Msg2 is completed with the echo information. The meanings of "0" and "1" may be reversed.

[0176] The ambient IoT device 300 uses an end marker to determine the end timing of Msg2, and also to determine the start timing of D2R data transmission.

[0177] Figure 16 is a diagram showing another example of operation 1 according to the second embodiment.

[0178] As shown in Figure 16, in step S40, the transmitting unit of the reader device 400 (the transmitting unit 210 of the network node 200) transmits an ambient IoT paging message. The ambient IoT paging message may include time slot information of an R2D message. The time slot information may include time information for one time slot. The R2D message may be an ambient IoT paging message. The R2D message may also be Msg2. The R2D message may also be another message transmitted from the reader device 400 to the ambient IoT device 300 (for example, an R2D data transmission message). The communication unit 345 of the ambient IoT device 300 receives the ambient IoT paging message.

[0179] In step S41, the control unit 330 of the ambient IoT device 300 checks whether the ambient IoT paging message in step S41 is addressed to itself. In the following explanation, we will assume that the ambient IoT paging message is addressed to itself.

[0180] In step S42, the communication unit 345 of the ambient IoT device 300 transmits Msg1. Msg1 may contain a random ID. The receiving unit of the reader device 400 (the receiving unit 220 of the network node 200) receives Msg1.

[0181] In step S43, the transmitting unit (transmitting unit 210) of the reader device 400 transmits Msg2. Msg2 time-multiplexes echo information for multiple ambient IoT devices 300. For example, as shown in Figure 15(A), multiple echo information may be time-multiplexed in one time slot, or as shown in Figure 15(B), one Msg2 may span multiple time slots, and multiple echo information may be time-multiplexed in those multiple time slots. Also, as described above, Msg2 includes an end marker (EM) for each piece of echo information. The communication unit 345 of the ambient IoT device 300 receives Msg2.

[0182] Returning to Figure 16, in step S44, the control unit 330 of the ambient IoT device 300 performs conflict resolution. Here, the control unit 330 was able to detect Msg2, which contains the random ID it sent in Msg1 as echo information, and the conflict resolution is assumed to be successful, as will be explained below.

[0183] At this time, the control unit 330 checks the end marker included in Msg2. Then, the control unit 330 may detect the end timing of Msg2 in response to detecting the end marker indicating completion of Msg2 (for example, an end marker of "1"). Alternatively, the control unit 330 may detect the start timing of D2R data transmission in response to detecting the end marker indicating completion of Msg2. Alternatively, the control unit 330 may detect that the start timing of D2R data transmission has occurred after a predetermined time (or predetermined time slot) has elapsed in response to detecting the end marker indicating completion of Msg2.

[0184] In step S45, the control unit 330 of the ambient IoT device 300 determines the D2R transmission resource. For example, similar to the second embodiment, the control unit 330 may identify the order in Msg2 for the echo information containing the random ID it transmitted in Msg1, and use a transmission resource corresponding to that order. That is, other operation examples 1 according to the second embodiment may be based on the second embodiment. Alternatively, the transmission resource may be determined by other determination methods. That is, other operation examples 1 may be implemented independently without being based on the second embodiment.

[0185] In step S46, the communication unit 345 of the ambient IoT device 300 transmits D2R data using the transmission resources determined in step S45. The communication unit 345 may also transmit D2R data considering the D2R data transmission start timing based on the end marker.

[0186] In addition, although an example of another operation example 1 according to the second embodiment described an example in which the end marker is included in Msg2, the end marker may also be included in the ambient IoT paging message. If a single ambient IoT paging message includes multiple device IDs, including an end marker for each device ID allows the ambient IoT device 300 to understand when the ambient IoT paging message ends (or when the transmission of Msg2 begins).

[0187] (3) Another Operation Example 2 According to the Second Embodiment Next, another operation example 2 according to the second embodiment will be described. In the other operation example 1 according to the second embodiment described above, it was assumed that Msg2 is of variable length. In the other operation example 2, an operation example will be described assuming that Msg2 is of fixed length.

[0188] For example, consider a case where Msg1 sent from multiple ambient IoT devices 300 collide. In such a case, the reader device 400 cannot demodulate the random ID contained in Msg1 and does not know what kind of information to interpret the echo information contained in Msg2. Therefore, the reader device 400 may not be able to transmit Msg2 properly.

[0189] Therefore, in the other operation example 2, the objective is to enable the reader device 400 to properly display Msg2.

[0190] In another example of operation according to the second embodiment, if the reader device 400 fails to receive a random ID successfully, it includes default information (for example, 16 bits of "00...0") as echo information in Msg2 and transmits it. The default information may indicate that the reader device 400 failed to receive Msg1. Alternatively, the default information may indicate that the reader device 400 failed to receive a random ID. Alternatively, the default information may indicate a reception error in the reader device 400. The ambient IoT device 300 determines that the conflict resolution has failed based on the receipt of the default information as echo information.

[0191] Furthermore, Msg1 may be sent from multiple ambient IoT devices 300, and Msg2 may contain multiple pieces of default information. In this case, each ambient IoT device 300 can identify the default information addressed to it in the following way: That is, each ambient IoT device 300 receives Msg2 using the receiving resource (e.g., time slot (or timing)) associated with the transmission resource for Msg1 that it sent. As a result, for example, if the transmission resources for Msg1 are different for each of the multiple ambient IoT devices 300, the receiving resources for Msg2 associated with each transmission resource will also be different for each of the multiple ambient IoT devices 300. Therefore, even if Msg2 contains multiple pieces of default information, each of the multiple ambient IoT devices 300 can use the receiving resource associated with the transmission resource for Msg1 to receive the default information addressed to it and understand that default information.

[0192] Figure 17 is a diagram showing another example of operation according to the second embodiment.

[0193] As shown in Figure 17, in step S50, the transmitting unit of the reader device 400 (the transmitting unit 210 of the network node 200) transmits an ambient IoT paging message. The communication unit 345 of the ambient IoT device 300 receives the ambient IoT paging message.

[0194] In step S51, the control unit 330 of the ambient IoT device 300 checks whether the ambient IoT paging message is addressed to itself. Here, we will explain assuming that it is addressed to itself.

[0195] In step S52, the communication unit 345 of the ambient IoT device 300 transmits Msg1. Msg1 contains a random ID. The control unit 330 of the ambient IoT device 300 may generate a random ID using a random number generator or the like. If the generated random ID matches a predetermined information (for example, "0000"), the control unit 330 generates a random ID again. The control unit 330 can generate different random IDs by giving different random seed values ​​to the random number generator.

[0196] The receiving unit of the reader device 400 (the receiving unit 220 of the network node 200) receives Msg1 (step S52). The control unit of the reader device 400 (the control unit 230 of the network node 200) determines whether or not Msg1 was received successfully. The control unit may detect if Msg1 was received successfully. On the other hand, the control unit may detect a reception error if Msg1 was not received successfully.

[0197] In step S53, the transmitting unit (transmitting unit 210) of the reader device 400 transmits Msg2. If the control unit (control unit 230) of the reader device 400 detects that Msg1 has been received successfully, it includes the random ID contained in Msg1 as echo information in Msg2. Also, if the control unit detects a reception error in Msg1, it includes default information (as echo information) in Msg2. The control unit may generate Msg2 with time-multiplexed echo information. Then, the transmitting unit transmits the Msg2 generated by the control unit. The transmitting unit of the reader device 400 transmits Msg2 using the transmission resource for Msg2 associated with the receiving resource (step S52) that received Msg1.

[0198] The communication unit 345 of the ambient IoT device 300 receives Msg2 (step S53). The communication unit 345 monitors the receiving resource associated with the transmission resource of Msg1 (step S52) and receives Msg2 using that receiving resource.

[0199] In step S54, the control unit 330 of the ambient IoT device 300 performs conflict resolution. The control unit 330 performs conflict resolution based on the echo information contained in Msg2. If the control unit 330 detects default information as echo information, it determines that the conflict resolution has failed. Alternatively, the control unit 330 may determine that the conflict resolution has failed if it detects that the default information is different from the random ID it sent in Msg1. On the other hand, if the random ID it sent in Msg1 matches the echo information (and the random ID contained therein) in Msg2, the control unit 330 determines that the conflict resolution has succeeded.

[0200] [Third Embodiment] Next, a third embodiment will be described. In the third embodiment, an example in which "AS ID" is used will be described.

[0201] Currently, 3GPP is discussing AS IDs (Access Stratum IDs). AS IDs are expected to be used at least for scheduling in D2R transmission and R2D reception. For example, the reader device 400 performs scheduling and allocates resources used for D2R data transmission to each of the multiple ambient IoT devices 300. In this case, the reader device 400 can also perform scheduling by using the AS ID as identification information for each ambient IoT device 300 and allocating the resources to each AS ID. The AS ID may also be identification information used in the AS layer.

[0202] Furthermore, the length of the AS ID (e.g., bit length) is expected to be below a certain threshold. The length of the AS ID may be shorter than the device ID used in the higher layer.

[0203] Regarding the AS ID, the following three options are possible: Option 1: A random ID is used as the AS ID; Option 2: The reader device 400 assigns a new AS ID to the ambient IoT device 300; Option 3: It is up to the reader device 400 whether a random ID is used as the AS ID or whether the reader device 400 assigns a new AS ID.

[0204] The advantages and disadvantages of each option are summarized below.

[0205] First, the advantages of Option 1 are as follows: Since the random ID transmitted in Msg1 is used directly as the AS ID, the reader device 400 does not need to explicitly notify the ambient IoT device 300 of the AS ID. Therefore, compared to the case where it is explicitly notified, for example, there is no signaling load, and the reader device 400 and the ambient IoT device 300 can reduce processing load.

[0206] On the other hand, option 1 has the following drawbacks: If multiple ambient IoT devices 300 send the same random ID in Msg1, and then successfully resolve conflicts among the multiple ambient IoT devices 300, the same random ID will be used as the AS ID. In this case, since the random ID is common to multiple ambient IoT devices 300, it is not possible to identify each ambient IoT device 300 using the AS ID.

[0207] Furthermore, the advantages of Option 2 are as follows: Since the reader device 400 manages the AS IDs and can freely assign them to each ambient IoT device 300, cases of duplicate AS IDs do not occur.

[0208] On the other hand, option 2 has the following drawbacks: the reader device 400 must explicitly notify the ambient IoT device 300 of the AS ID, which may increase the signaling load beyond a certain point.

[0209] Furthermore, the advantage of option 3 is that it combines the advantages of both option 1 and option 2. On the other hand, a disadvantage of option 3 is that it may require rules to distinguish between option 1 and option 2. For example, in ambient IoT device 300, if it is unclear whether the AS ID is used as a random ID or whether the AS ID is notified from reader device 400, it may not be possible to process properly using the AS ID.

[0210] In the third embodiment, we focus on option 3. The objective of the third embodiment is to enable appropriate processing using the AS ID in the ambient IoT device 300.

[0211] Therefore, in the third embodiment, an example is described in which the message (or R2D message) transmitted from the reader device 400 to the ambient IoT device 300 includes additional information indicating whether or not it includes an ASID.

[0212] Specifically, an ambient IoT device (e.g., ambient IoT device 300) receives a predetermined message containing additional information indicating whether or not it includes an AS ID from a reader device (e.g., reader device 400), which is a network node (e.g., network node 200) or user device (or UE 100) of a mobile communication system. Secondly, the ambient IoT device communicates with the reader device using the additional information.

[0213] Thus, when the ambient IoT device 300 receives additional information indicating that it includes an AS ID (or if it includes an AS ID), it can use the AS ID included in the predetermined message as the AS ID assigned to itself and communicate with the reader device 400 using that AS ID.

[0214] On the other hand, if the ambient IoT device 300 receives additional information indicating that it does not contain an AS ID (or does not contain an AS ID), it can use the random ID it sent in Msg1 as its own AS ID.

[0215] In this way, the ambient IoT device 300 can distinguish between option 1 (where a random ID is used as the AS ID) and option 2 (where the reader device 400 newly assigns an AS ID) based on the additional information. Therefore, the ambient IoT device 300 can communicate appropriately with the reader device 400 using the AS ID.

[0216] (1) Example of operation according to the third embodiment Next, an example of operation according to the third embodiment will be described.

[0217] Figure 18 is a diagram illustrating an example of operation according to the third embodiment.

[0218] As shown in Figure 18, in step S60, the transmitting unit of the reader device 400 (the transmitting unit 210 of the network node 200) transmits an ambient IoT paging message. The communication unit 345 of the ambient IoT device 300 receives the ambient IoT paging message.

[0219] In step S61, the control unit 330 of the ambient IoT device 300 checks whether the ambient IoT paging message is addressed to itself. Here, we will assume that it is addressed to itself and explain further.

[0220] In step S62, the communication unit 345 of the ambient IoT device 300 transmits Msg1. Msg1 contains a random ID. The receiving unit of the reader device 400 (the receiving unit 220 of the network node 200) receives Msg1.

[0221] In step S63, the transmitting unit of the reader device 400 (the transmitting unit 210 of the network node 200) transmits Msg2.

[0222] Firstly, Msg2 contains the random ID received in Msg1 (step S62).

[0223] Secondly, Msg2 includes additional information indicating whether or not it contains an AS ID. This additional information may indicate whether or not a random ID is to be used as the AS ID. The additional information may be represented by one bit. Alternatively, the additional information may be represented by dummy echo information. The dummy echo information may be represented as a special pseudo-ID such as 16 bits of "000...0".

[0224] In the third embodiment, an example of additional information being included in Msg2 is described, but additional information may also be included in R2D messages other than Msg2, such as ambient IoT paging messages or R2D data transmission messages.

[0225] Thirdly, Msg2 may include the AS ID assigned by the reader device 400. The AS ID is explicitly notified from the reader device 400 to the ambient IoT device 300. In this case, Msg2 may include additional information indicating that it contains the AS ID.

[0226] The communication unit 345 of the ambient IoT device 300 receives Msg2.

[0227] In step S64, the control unit 330 of the ambient IoT device 300 performs conflict resolution. The control unit 330 determines that the conflict resolution was successful if the device ID transmitted in Msg1 matches the device ID included as echo information in Msg2, and that the conflict resolution failed if they do not match. Hereinafter, the explanation will assume that the conflict resolution was successful.

[0228] At this time, the control unit 330 performs the following processing using the additional information.

[0229] In other words, if the control unit 330 indicates that the additional information includes an AS ID (i.e., it includes an AS ID), it applies the received AS ID as its own AS ID. The AS ID may be included in Msg2. Alternatively, the AS ID may be included in an ambient IoT paging message (step S60). Alternatively, the AS ID may be included in another R2D message (for example, an R2D data transmission message).

[0230] On the other hand, if the control unit 330 indicates that the additional information does not include an AS ID (i.e., does not include an AS ID), it applies the random ID it sent in Msg1 (step S62) as the AS ID.

[0231] The control unit 330 may also determine the size (bit length) of Msg2 based on the additional information. That is, the control unit 330 can determine from the additional information whether or not there is an area (field) (for example, 16 bits) in Msg2 that contains the AS ID, and therefore can determine the size of Msg2 when it contains the AS ID and when it does not contain the AS ID.

[0232] In step S65, the control unit 330 communicates with the reader device 400 using the AS ID. For example, the reader device 400 may use the AS ID (either assigned by itself or using a random ID) to identify each ambient IoT device 300 during scheduling, and may associate scheduling information with each AS ID and send it to the ambient IoT device 300. The ambient IoT device 300 can use the scheduling information associated with its own AS ID to send a D2R message (such as Msg2 or a D2R data transmission message) to the reader device 400.

[0233] (2) Another example of operation according to the third embodiment Although an example in which additional information is used has been described in the third embodiment, additional information is not required to be used. That is, the ambient IoT device 300 defaults to using the random ID it sent in Msg1 as its AS ID, and when it receives an R2D message containing an AS ID, it applies that AS ID as its own AS ID.

[0234] As a result, for example, additional information is not transmitted, making it possible to reduce the signaling load on both the ambient IoT device 300 and the reader device 400.

[0235] Another example of operation 1 according to the third embodiment can be explained in Figure 18, which shows the third embodiment. However, since this would overlap with the explanation of the third embodiment, the following explanation will focus on the differences.

[0236] The message 2 in step S63 does not contain any additional information. However, as in the third embodiment, if the reader device 400 assigns an AS ID, that AS ID may be included in the message 2. The AS ID will be explicitly notified from the reader device 400 to the ambient IoT device 300.

[0237] In step S64, if the ambient IoT device 300 detects that Msg2 contains an AS ID, it applies the received AS ID as its own AS ID. On the other hand, if the ambient IoT device 300 detects that Msg2 does not contain an AS ID, it applies the random ID it sent in Msg1 (step S62) as its own AS ID.

[0238] [Other Embodiments] In the first to third embodiments, when conflict resolution is performed, the determination may be made using the transmission resource of Msg1, not just the random ID. In this case, it is assumed that the transmission resource of Msg1 and the reception resource of Msg2 are linked.

[0239] For example, in step S34 of the second embodiment (Figure 14), the following conflict resolution determination may be performed. That is, the control unit 330 of the ambient IoT device 300 compares the random ID transmitted in Msg1 (step S32) with the random ID included as echo information in Msg2 (step S33), and also compares the transmission resource used in the transmission of Msg1 (step S32) with the transmission resource of Msg1 associated with the reception resource used in the reception of Msg2 (step S33). The control unit 330 then determines that the conflict resolution is successful if both comparisons match, and that the conflict resolution is unsuccessful if either comparison does not match.

[0240] As a result, even if multiple ambient IoT devices 300 send Msg1 containing the same random ID, the transmission resource of Msg1, not just the random ID, is used to determine the conflict resolution. Therefore, the conflict resolution can be determined more accurately than when the conflict resolution is determined solely by the random ID.

[0241] The above-described operation flows can be performed not only independently, but also in combination of two or more operation flows. For example, some steps of one operation flow may be added to another operation flow, or some steps of one operation flow may be replaced with some steps of another operation flow. It is not necessary to execute all steps in each flow; only some steps may be executed. Furthermore, the order of steps in each flow may be changed as appropriate.

[0242] In the embodiments and examples described above, an example in which the base station is an NR base station (gNB) was described, but the base station may also be an LTE base station (eNB) or a 6G base station. Furthermore, the base station may also be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may also be a DU of an IAB node. Furthermore, UE100 may be an MT (Mobile Termination) of an IAB node. That is, UE100 may be a terminal function unit (a type of communication module) for the base station to control a relay device that performs signal relay. Such a terminal function unit is referred to as an MT. Examples of multi-transmission architectures (MTs) include IAB-MT, NCR (Network Controlled Repeater)-MT, and RIS (Reconfigurable Intelligent Surface)-MT.

[0243] Furthermore, the term "network node" primarily refers to a base station, but may also refer to a core network device or a part of a base station (CU, DU, or RU). Additionally, a network node may consist of a combination of at least a part of the core network device and at least a part of a base station.

[0244] A program may be provided that causes a computer to execute each process performed by the UE 100 or the network node 200. The program may be recorded on a computer-readable medium. Using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, but may be a recording medium such as a CD-ROM and / or DVD-ROM. Alternatively, the circuits that execute each process performed by the UE 100 or the network node 200 may be integrated, and at least a part of the UE 100 or the network node 200 may be configured as a semiconductor integrated circuit (chipset, SoC: System on a chip).

[0245] The functions realized by the above-described communication device (UE100 or network node 200, etc.) may be implemented in a circuit or processing circuit, including a general-purpose processor, application-specific processor, integrated circuit, ASICs (Application Specific Integrated Circuits), CPU (a Central Processing Unit), conventional circuitry, and / or a combination thereof, programmed to realize the described functions. The processor includes transistors and / or other circuits and is considered a circuit or processing circuit. The processor may also be a programmed processor that executes a program stored in memory. In this specification, circuit, unit, and means are hardware programmed to perform or execute the functions described herein. Such hardware may be any hardware disclosed herein, or any hardware known to be programmed to perform or execute the functions described herein. If such hardware is a processor that is considered to be of the type of circuit, such circuit, means, or unit is a combination of hardware and software used to constitute such hardware and / or processor.

[0246] The phrases “based on” and “depending on / in response to” as used in this disclosure do not mean “based solely on” or “in response solely” unless otherwise specified. “Based on” means both “based solely on” and “at least partially on.” Similarly, “depending” means both “at least partially on” and “at least partially on.” The terms “include,” “comprise,” and variations thereof do not mean that they include only the listed items, but may include only the listed items or may include additional items in addition to the listed items. Furthermore, the term “or” as used in this disclosure is not intended to mean exclusive OR. Additionally, any reference to elements using designations such as “first,” “second,” etc., as used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used herein as a convenient way to distinguish between two or more elements. Therefore, references to the first and second elements do not imply that only two elements may be adopted therein, or that the first element must precede the second element in any way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall be plural unless it is clearly indicated from the context that they are not.

[0247] Although the embodiments have been described in detail above with reference to the drawings, the specific configuration is not limited to those described above, and various design changes can be made without departing from the gist of the invention.

[0248] This application claims priority to U.S. Provisional Application No. 63 / 754146 (filed February 5, 2025), the entirety of which is incorporated into the specification of this application.

[0249] (First Note) The embodiments described above can be summarized as shown in the note, but the note does not limit the embodiments.

[0250] (Note 1) A communication method for use in a mobile communication system, comprising the steps of: an ambient IoT (Internet of Things) device receiving a predetermined message containing a plurality of predetermined pieces of information from a network node or a reader device which is a user device of the mobile communication system; and the ambient IoT device transmitting D2R (Device to Reader) data to the reader device using transmission resources corresponding to the order in which the predetermined pieces of information are included in the predetermined message.

[0251] (Note 2) The communication method described in Note 1, wherein the predetermined message is an ambient IoT paging message and the predetermined information is a device ID.

[0252] (Note 3) The communication method according to Note 1 or Note 2, wherein the ambient IoT paging message includes a plurality of ambient IoT paging messages, each containing one of the device IDs, which are linked together.

[0253] (Note 4) The communication method according to any one of Notes 1 to 3, wherein the ambient IoT paging message includes additional information indicating whether or not it includes a plurality of device IDs.

[0254] (Note 5) The communication method described in any one of Notes 1 to 4, wherein the ambient IoT paging message includes additional information indicating the number of IDs, and the IDs are the device ID and / or group ID.

[0255] (Note 6) The ambient IoT paging message is a communication method according to any one of Notes 1 to 5, which includes additional information indicating the duration of the ambient IoT paging message.

[0256] (Note 7) The communication method according to any one of Notes 1 to 6, wherein the transmitting step includes the step of stopping the reception of the ambient IoT paging message when the ambient IoT device has confirmed its own device ID.

[0257] (Note 8) The communication method described in any of Notes 1 to 7, wherein the predetermined message is message 2 (Msg2) and the predetermined information is echo information.

[0258] (Note 9) The communication method according to any one of Notes 1 to 8, wherein the receiving step includes the step of the ambient IoT device receiving a plurality of Msg2 at different timings, and the transmitting step includes the step of the ambient IoT device transmitting the D2R data to the reader device using the transmission resources corresponding to the order of each Msg2.

[0259] (Note 10) The communication method according to any one of Notes 1 to 9, wherein the Msg2 includes an end marker, and the transmission step includes a step in which the ambient IoT device detects at least one of the end timing of the Msg2 and the start timing of the transmission of the D2R data in response to the detection of the end marker.

[0260] (Note 11) The communication method according to any one of Notes 1 to 10, further comprising the step of the ambient IoT device performing a conflict resolution based on the echo information contained in the Msg2, wherein the step of performing the conflict resolution includes the step of the ambient IoT device determining that the conflict resolution has failed in response to having received default information as the echo information.

[0261] (Note 12) A communication method for use in a mobile communication system, comprising the steps of: an ambient IoT (Internet of Things) device receiving a predetermined message from a network node or user device which is a reader device of the mobile communication system, which includes additional information indicating whether or not it includes an AS ID (Access Stratum ID); and the ambient IoT device communicating with the reader device using the additional information.

[0262] (Note 13) The communication method described in Note 12, wherein the AS ID is identification information used in the AS layer, and the length of the AS ID is less than or equal to a threshold.

[0263] (Note 14) The communication method according to Note 12 or Note 13, further comprising the step of: if the ambient IoT device indicates that the additional information includes the AS ID, applying the AS ID included in the predetermined message as its own AS ID; if the AS ID is not included, applying a random ID included in Msg1 as the AS ID.

[0264] (Note 15) The communication method according to any one of Notes 12 to 14, further comprising the step of applying a random ID included in Msg1 as the AS ID if the ambient IoT device indicates that the additional information does not include the AS ID.

[0265] (Note 16) The communication method according to any one of Notes 12 to 15, wherein the receiving step includes a step in which the ambient IoT device receives a predetermined message that does not include the additional information, and the ambient IoT device has default behavior of applying the random ID transmitted in Msg1 as the AS ID, and when it receives an R2D message that includes the AS ID, it applies the AS ID.

[0266] (Note 17) The communication method described in any of Notes 12 to 16, wherein the predetermined message is one of an ambient IoT paging message, Msg2, and an R2D (Reader to Device) data transmission message.

[0267] 1: Mobile communication system 10: Network 20: RAN 30: CN 100: UE 110: Receiving unit 120: Transmitting unit 130: Control unit 140: Wireless communication unit 200: Network node 210: Transmitting unit 220: Receiving unit 230: Control unit 240: Network communication unit 250: Wireless communication unit 300: Ambient IoT device 310: Antenna 320: Modulator 330: Control unit 340: Memory 345: Communication unit 350: Matching network 351: RF energy harvester 352: PMU 353: Energy storage unit 354: RF BPF 355: RF envelope detector 356: BB LPF 357: Comparator 358: Baseband logic 359: Memory 360: Backscattering modulator 361: Clock generator 365: LNA 366: Baseband amplifier 367: Large frequency shifter 368: Reflection amplifier 369: Energy harvester 380: CN device 400: Reader device

[0268] (Second Addendum) 1. Introduction In RAN#108, based on the results of the corresponding survey items, a new work item concerning ambient IoT (A-IoT) solutions was approved. The scope of RAN2, as described below, includes the functions and procedures necessary for A-IoT paging, A-IoT random access, and A-IoT data transmission.

[0269] "• Scope of RAN2: • Defines the functions and procedures required for a compact protocol stack and lightweight signaling procedure for ambient IoT to enable DO-DTT and DT data transmission. • A-IoT paging: Includes subsequent paging for the same service. Supports options for paging messages to include one identifier (ID) and options for paging messages to not include an identifier. Temporary identifiers are not supported unless requested by the SA WG. Note: RAN2 aims to design a paging message format that can include multiple identifiers in a single paging message for future compatibility. • A-IoT random access: Includes re-access for failure handling. Conflict-based and non-conflict cases are supported. For conflict-based random access, only Solution 1 (3 steps only) is included (unless RAN2 decides to use Solution 3 (integrated solution) by RAN2#129). • A-IoT data transmission: Includes data (re)transmission for failure handling. Segmentation is supported at least in D2R." "Only the MAC layer is included."

[0270] This appendix provides initial considerations regarding the standard design of A-IoT paging.

[0271] 2. Discussion 2.1 IDs to be paged The most important role of an A-IoT paging message is to page devices. According to WID, an A-IoT paging message may contain one ID or not contain an ID, as shown below.

[0272] "• A-IoT Paging: Includes subsequent paging for the same service. Supports options for paging messages containing one identifier and options for paging messages not containing an identifier. Temporary identifiers are not supported unless requested by the SA WG. Note: RAN2 aims to design a paging message format that can include multiple identifiers within a single paging message for future compatibility purposes."

[0273] While the TR specifies that the ID can be either a device ID or a group ID, it is unclear whether the phrase "one identifier" in the WID refers to both device IDs and group IDs. Therefore, RAN2 should clarify what types of identifiers may be included in the A-IoT paging message. On the other hand, if the A-IoT paging does not include an ID, it is clear that all devices will be paged.

[0274] Regarding A-IoT paging messages, an identifier may be required in this trigger message to identify a device / group of devices (for example, when reaching a single device or group of devices). The following cases are being considered: • An A-IoT paging message containing an identifier for a single A-IoT device. • An A-IoT paging message containing a group ID mapped to multiple A-IoT devices. • An A-IoT paging message containing no identifiers (i.e., indicating that all A-IoT devices capable of receiving the A-IoT paging message must respond). • An A-IoT paging message containing multiple identifiers for A-IoT devices. The need for this use case remains awaiting confirmation or depends on the current situation. From a RAN2 perspective, supporting paging for multiple identifiers of A-IoT devices is feasible, depending on the TB size and the multiplexing design of the A-IoT paging message. Note 1: Further consideration is needed regarding the details of the above identifiers and group IDs, as well as the use cases / scenarios.

[0275] Proposal 1: RAN2 should consider whether A-IoT paging can include either one device ID or one group ID.

[0276] If an A-IoT paging message may contain either a device ID or a group ID, the device may need to distinguish whether the included ID is a device ID or a group ID. For this purpose, a one-bit representation is required.

[0277] Proposal 2: RAN2 should consider whether to introduce a 1-bit display so that the device can distinguish whether the ID included in A-IoT paging is a device ID or a group ID.

[0278] WID also states that "RAN2 aims to design a paging message format that can include multiple identifiers within a single paging message for future compatibility purposes." Therefore, A-IoT paging messages will require a single bit to distinguish whether the paging message contains only one ID or multiple IDs (although this bit is simply reserved in the Rel-19 A-IoT message format). Details of the single bit will be discussed in a future release.

[0279] Proposal 3: RAN2 should agree to reserve one bit for future compatibility, anticipating that A-IoT paging will include multiple IDs in future releases.

[0280] When all devices are paging, A-IoT paging does not include an ID, as described in both the WID and TR. However, from the device's perspective, it is necessary to know whether an A-IoT paging message includes an ID or not when the A-IoT message format changes. In this sense, one approach is to define a one-bit indicator that indicates whether this A-IoT paging message includes an ID or not. The advantage of this one-bit indicator is that it can reduce the message size when there is no ID, i.e., it can eliminate the bit for the ID from A-IoT paging.

[0281] On the other hand, if a special ID (e.g., an "all zeros" ID) can indicate that A-IoT paging has no ID, then such a one-bit representation is unnecessary. Therefore, RAN2 should consider how to page all devices (i.e., the case where there is no ID).

[0282] Proposal 4: RAN2 should consider a method for paging all devices (e.g., a 1-bit display meaning no ID is included, or a special ID meaning no ID is included (e.g., "all zeros")).

[0283] 2.2 Scheduling Information WID specifies that R2D supports TDMA only, and D2R supports TDMA and FDMA. "• Multiplexing / multiple access in R2D is by TDMA only, and in D2R it is by TDMA and FDMA only."

[0284] Furthermore, it is natural to assume that the duplex of R2D and D2R is TDD. Therefore, an example of time slots and frequency channels is shown in Figure 19.

[0285] As agreed in RAN2, regardless of the use case (i.e., "inventory" and "commands"), the A-IoT paging message is always the first message in the baseline procedure. Therefore, the A-IoT paging message can serve as a reference point for time slots for subsequent D2R / R2D transmissions, including competition-based random access and non-competitive access. For example, the first time slot for competition-based random access begins immediately after the A-IoT paging is received. Apart from the details, RAN2 should agree on the basic principles of frame structure for A-IoT communication.

[0286] While RAN2 agreed to "await further progress from RAN1 regarding the indication of the start of access opportunities," the reference points discussed here may differ, and RAN2 may still consider the time slot structure from the perspective of higher layers.

[0287] Proposal 5: RAN2 agrees that A-IoT paging is the reference point for time slots for all D2R / R2D transmissions, including competition-based random access and non-competitive access.

[0288] According to the TR, the A-IoT paging message displays scheduling information for the D2R message, as shown below. "With respect to the A-IoT paging message, additional information may be displayed that allows the device to determine the resources used for the D2R response message. This can be further considered in detail in Section 6.1."

[0289] Further details are also provided in the TR as follows: From a physical layer perspective, scheduling information consists of time-domain resources, frequency-domain resources, MCS-like information, chip length, device-associated ID, repetition, and midamble-related information. Whether scheduling information is transmitted via higher-layer signaling and / or L1 control signaling remains a matter for consideration.

[0290] "6.1.2.8 Scheduling of D2RRegarding D2R scheduling, the following information may be explicitly / implicitly indicated to the device via the corresponding PRDCH.- Time domain resources - Frequency domain resources - MCS-like information - Chip length - ID associated with the device - Repetition - Information related to the millamble (if supported) Regarding each piece of information, further investigation is required as to whether upper layer signaling and / or L1 R2D control signaling is used (see Section 6.1.1.10)."

[0291] Finding 1: The scheduling information for D2R transmissions (for contention-based random access or non-contention access) is indicated by the A-IoT paging message or L1 signaling in the corresponding PRDCH.

[0292] From the perspective of the upper layer, time domain resources and frequency domain resources are most important for the device to select "access opportunities / resources" for CBRA and, in some cases, "D2R opportunities / resources" for non-contention access. Specifically, in order to select one time / frequency resource from (N Ｔ × N Ｆ ) D2R resource grids, the number of time domain resources (N Ｔ ) and the number of frequency domain resources (N [[ID=I3]] Ｆ ) need to be known to the device. If the resource index of each time / frequency resource in the (N Ｔ × N Ｆ ) D2R resource grids is predefined (like existing subframes and physical resource blocks), resource selection (and in some cases resource allocation) will be much simpler. Since these numerical values are used for resource selection in A-IoT MAC, it is preferable for the A-IoT paging message to include this information."

[0293] Proposal 6: RAN2 agreed that the number of time domain resources (N Ｔ ) and the number of frequency domain resources (N Ｆ ) are provided by the A-IoT paging message."

[0294] 2.3 Subsequent A-IoT paging WID specifies that subsequent A-IoT paging is supported, and thereafter, subsequent A-IoT paging is described in the TR as follows:

[0295] "The reader is supported to send multiple (subsequent) A-IoT paging messages associated with the same service request from the CN (Core Network). Duplicate responses from devices to the same service request should be avoided. The A-IoT paging message may include information to avoid this duplicate response from the device to the reader. Further consideration is needed on how to design this information in the A-IoT paging message (e.g., including details from Stage 3, or considering relevant aspects from other WGs). Based on this information, the device will then decide whether to skip sending a response to the A-IoT paging message (if the device has previously responded successfully to the same service). This information should be short and concise. This information is a single ID, but further consideration is needed on whether this ID is generated by the reader or the core network. Further consideration is also needed on the size of this information."

[0296] To support subsequent A-IoT paging, a mechanism is needed to avoid duplicate responses from devices, and RAN2 agreed to introduce a single ID as information for this purpose. According to the TR, two challenges were identified: "whether the ID is generated by the reader or the core network" and "the size of this information."

[0297] Finding 2: By using IDs, the device is expected to be able to avoid duplicate responses caused by subsequent A-IoT paging for the same service.

[0298] Regarding the issue of who generates the ID, if the ID is generated by the core network, it will be associated with a service ID in some way. This is consistent with the concept of subsequent A-IoT paging, namely that the (original) A-IoT paging and subsequent A-IoT paging are associated with the same service ID. However, the core network is likely to request the same service from multiple readers. In this scenario, multiple readers will send A-IoT paging messages containing the same ID, and problems arise when a device receives multiple A-IoT paging messages containing the same ID from different readers. Such problems are described in the TR as follows: During the investigation phase, some companies suggested that reader IDs should be introduced to solve this problem.

[0299] "Further consideration is needed regarding scenarios where different leaders may send A-IoT paging messages associated with the same service request from the CN to the same device for response. If this scenario is within scope, further consideration is needed, taking into account developments from all WGs."

[0300] On the other hand, if the ID is generated by the reader, it will not be associated with any core network ID, but rather will be (pseudo) unique to the reader. This means that even if the ID is a random value, it is very likely that different A-IoT paging messages for the same service ID will have different IDs, which can potentially resolve the multiple-reader scenario. This prevents confusion in the device (without introducing a reader ID).

[0301] Based on the above considerations, regardless of whether the ID is generated by the core network or the leader, the ID can solve the duplicate response problem as shown in Finding 2. Another problem in the multi-leader scenario can also be solved by the ID if it is generated by the leader. Therefore, for these two advantages, it is preferable that the ID be generated by the leader.

[0302] Proposal 7: RAN2 should agree that the reader generates an ID to avoid duplicate responses resulting from subsequent A-IoT paging, and that this ID will also be used to avoid confusion in multi-reader scenarios.

[0303] The size of the ID will be considered as a topic in Stage 3, after the Stage 2 review is completed.

[0304] 2.4 Types of Random Access and IDs According to the TR, the first action of the device after receiving A-IoT paging is to determine whether it is a competition-based random access or a non-competition access. This is described as step 1 of the A-IoT random access procedure, and it is worth considering whether this is explicitly or implicitly indicated.

[0305] "Step 1: Determining the type of random access (i.e., non-conflict or conflict-based) and access opportunities / resources: The A-IoT device determines the type of random access from the A-IoT paging message in accordance with Section 6.3.3. The reader can configure either non-conflict or conflict-based random access (and corresponding configurations). Whether this is explicit or implicit needs further consideration."

[0306] In Rel-19, A-IoT paging contains only one ID, which can be either a device ID or a group ID (as proposed in Proposal 1). If it is possible to distinguish whether the ID containing a device is a device ID or a group ID (as proposed in Proposal 2), or if the ID in the A-IoT paging message is always a device ID (i.e., group IDs are not supported), then the following two assumptions implicitly determine whether A-IoT paging triggers contention-based random access or non-contention access: • If a device ID is included, only one device is paged, and therefore non-contention access is triggered. • If no ID is included, multiple devices are paged, and therefore contention-based random access is triggered.

[0307] Therefore, it is unnecessary to explicitly indicate in A-IoT paging messages whether to trigger competition-based random access or non-competitive access.

[0308] Proposal 8: RAN2 should agree that the device can implicitly determine whether a competition-based random access or a non-competitive access is triggered (i.e., an explicit "random access type" indication is not required).

[0309] 2.5 Overview of A-IoT Paging Message Structure The above proposals are summarized in Figure 20 as an example of an A-IoT paging message structure. Note that this is not intended to exclude additional information or spare bits. (Appendix 3) 1. Introduction In RAN#108, based on the results of the corresponding investigation items, a new work item concerning ambient IoT (A-IoT) solutions was approved. The scope of RAN2, as described below, includes the functions and procedures necessary for A-IoT paging, A-IoT random access, and A-IoT data transmission.

[0310] "• Scope of RAN2: • Defines the functions and procedures required for a compact protocol stack and lightweight signaling procedure for ambient IoT to enable DO-DTT and DT data transmission. • A-IoT paging: Includes subsequent paging for the same service. Supports options for paging messages to include one identifier (ID) and options for paging messages to not include an identifier. Temporary identifiers are not supported unless requested by the SA WG. Note: RAN2 aims to design a paging message format that can include multiple identifiers in a single paging message for future compatibility. • A-IoT random access: Includes re-access for failure handling. Conflict-based and non-conflict cases are supported. For conflict-based random access, only Solution 1 (3 steps only) is included (unless RAN2 decides to use Solution 3 (integrated solution) by RAN2#129). • A-IoT data transmission: Includes data (re)transmission for failure handling. Segmentation is supported at least in D2R." "Only the MAC layer is included."

[0311] This appendix provides initial considerations for the work of defining A-IoT random access procedures.

[0312] 2. Discussion 2.1 Determination of Access Opportunities / Resources After receiving A-IoT paging, the device initiates an A-IoT random access procedure (i.e., either non-conflict or conflict-based access) which involves determining the type of random access and the access opportunities / resources. This is described as Step 1 in the TR as follows:

[0313] If an A-IoT device is selected to respond in accordance with Section 6.3.3, the A-IoT device performs the following steps: • Step 1: Determination of the type of random access (i.e., non-conflict or conflict-based) and access opportunity / resource: • The A-IoT device determines the type of random access from the A-IoT paging message in accordance with Section 6.3.3. The reader can configure either non-conflict access or conflict-based random access (and corresponding configurations). Whether this is explicit or implicit needs further consideration. • If the random access is non-conflict access: • Select the displayed D2R opportunity / resource. • Skip conflict resolution in Step 2 and perform data transmission in accordance with Section 6.3.5. • If the random access is conflict-based random access: • Perform the selection of access opportunity / resource: As a baseline for CBRA, at least in the case of TDMA, the device selects from the access opportunities provided / assigned by the reader. One access opportunity for Msg1 can be randomly selected. Whether this is applicable to the FDMA case needs further consideration. Further extension options may be considered after the detailed physical layer design for TDMA and FDMA has been completed. • Perform step 2 to resolve conflicts.

[0314] The first substep is determining the type of random access, i.e., whether it is non-contested access or contested access. This is a consideration in the A-IoT paging agenda, but in this A-IoT random access agenda, we assume that the device can determine whether A-IoT paging triggers contested random access or non-contested access.

[0315] Finding 1: How the device determines whether to trigger competition-based random access or non-competitive access upon receiving A-IoT paging will be considered in the A-IoT paging agenda.

[0316] The second substep is determining access opportunities / resources, where access opportunities are defined as described below and shown in Figure 21.

[0317] "Access opportunity: An opportunity for an A-IoT device to perform an access (for example, by transmitting A-IoT Msg1). A set of access opportunities for different A-IoT devices is scheduled via R2D messages from the reader (see Section 6.1.4, "R2D Transmissions Triggering Random Access").

[0318] Regarding further details on access opportunities / resources, WID specifies that R2D supports TDMA only, while D2R supports TDMA and FDMA. "• Multiplexing / multiple access in R2D is via TDMA only, while in D2R it is via TDMA and FDMA only."

[0319] Furthermore, it is natural to assume that the duplex of R2D and D2R is TDD. Therefore, an example of time slots and frequency channels is shown in Figure 19.

[0320] According to TR, the A-IoT paging message displays scheduling information for the D2R message, as shown below. Therefore, the device has a time domain (N Ｔ ) and frequency domain (N Ｆ In each of these, it is possible to know how many resources are provided. "With regard to A-IoT paging messages, additional information can be displayed that allows the device to determine which resources are used for D2R response messages. This can be further considered in detail in the discussion in Section 6.1."

[0321] Finding 2: From the scheduling information within A-IoT paging, the device is in the time domain (N Ｔ ) and frequency domain (N Ｆ You can find out how many opportunities / resources are available in each of these areas.

[0322] Based on Finding 2, the D2R resource grid (N Ｔ× N Ｆ ) is known by the device. Therefore, an index of access opportunities / resources can be defined within the D2R resource grid, making each access opportunity / resource identifiable by both the reader and the device. An example of an access opportunity / resource index is shown in Figure 22.

[0323] The index of access opportunities / resources is expected to provide the following benefits: • For conflict-based random access, if the index is included in Msg2, conflict resolution will be more accurate. This allows the device to determine whether conflict resolution was successful or unsuccessful based on both the random ID sent in Msg1 and the index used in the Msg1 transmission. Details will be discussed in the next section. • For non-conflict access, if multiple single device IDs are supported in A-IoT paging messages in the future, resource allocation to multiple devices will be similarly simplified (however, in Rel-19, if one device ID and one access opportunity / resource are provided in the A-IoT paging message, an index may not necessarily be required). • Furthermore, for A-IoT data transmission procedures, resource allocation to multiple devices via Msg2 / R2D messages for D2R data transmission after A-IoT random access will be simpler, for example, by associating the order of devices in the Msg2 / R2D message with the index of access opportunities / resources.

[0324] Therefore, defining an index of access opportunities / resources is beneficial not only for A-IoT random access procedures but also for A-IoT data transmission procedures and for future compatibility.

[0325] Proposal 1: RAN2 should agree to define an index of access opportunities / resources. That is, the upper limit of the index should be (N Ｔ × N Ｆ )

[0326] For non-conflicting access, as described in TR, the device selects the access opportunity / resource displayed in the A-IoT paging message. In Rel-19, one access opportunity / resource (i.e., N) is selected in the A-IoT paging message. Ｔ = 1 and N Ｆ =1. Assuming that only one resource and one device ID are provided within the D2R resource grid, no additional mechanism is required for the device to perform D2R data transmission.

[0327] Proposal 2: Regarding non-conflicting access in Rel-19, RAN2 should assume that only one access opportunity / resource is provided in the A-IoT paging message, and no additional mechanism is required for determining the access opportunity / resource.

[0328] For competition-based random access, the device uses (N) within the D2R resource grid for Msg1 transmission. Ｔ × N Ｆ One of the ) access opportunities / resources can be randomly selected. As mentioned above and as will be discussed in the next section, the index of the access opportunities / resources selected for Msg1 transmission is used in conflict resolution to improve accuracy. Therefore, the device should retain this index after Msg1 transmission.

[0329] Proposal 3: For conflict-based random access, RAN2 should agree that the device should store an index of the access opportunities / resources it selected for Msg1 transmission in order to use the index in conflict resolution after receiving Msg2.

[0330] 2.2 Conflict Resolution for Conflict-Based Random Access Conflict resolution with Msg1 and Msg2 is described as three solutions, in which WID specifies that "for conflict-based random access, only Solution 1 (3 steps only) is included (unless RAN2 decides to use Solution 3 (integrated solution) by RAN2#129)."

[0331] "Step 2: Conflict Resolution for Conflict-Based Random Access: The following three candidate solutions have been investigated for conflict resolution (further consideration is needed for refinement and / or integrated design): Solution 1: A-IoT Msg1 without data A-IoT Msg1: When the A-IoT device identifies the initiation of its access opportunity, it sends a single 16-bit random ID generated by the A-IoT device to the reader. A-IoT Msg2: The reader responds with the random ID that was successfully received. Conflict resolution is considered successful if the A-IoT device receives an A-IoT Msg2 containing the same random ID as the one previously sent in A-IoT Msg1. Solution 2: A-IoT Msg1 with data A-IoT Msg1: When an A-IoT device identifies the start of its access opportunity, it sends A-IoT Msg1 to the reader, which contains a single 16-bit random ID generated by the A-IoT device, plus higher layer data that may include the device ID and / or other arbitrary higher layer data. A-IoT Msg2: The reader may respond with the random ID that was successfully received. If the A-IoT device receives A-IoT Msg2 containing the same random ID as previously sent in A-IoT Msg1, the conflict resolution is considered successful. If the device does not receive A-IoT Msg2, re-access is not performed autonomously; that is, re-access is always controlled by the reader. Solution 3: A-IoT Msg1 optionally contains data (integrated solution supporting both Solutions 1 and 2) A-IoT Msg1: When the A-IoT device identifies the start of its access opportunity, it sends a single 16-bit random ID generated by the A-IoT device to the reader. The reader controls whether or not to include higher layer data (which may be the device ID and / or other arbitrary higher layer data). A-IoT Msg2: The reader responds with the random ID that was successfully received. If the A-IoT device receives an A-IoT Msg2 containing the same random ID as the one previously sent in A-IoT Msg1, the conflict resolution is considered successful.

[0332] While we do not intend to rule out the possibility of adopting Solution 3 as anticipated by WID, this paper assumes Solution 1 for the sake of simplification.

[0333] In Msg1, the device transmits a random ID (16 bits), which is randomly generated by the device. Depending on the device implementation, there may be a correlation between the randomly selected Msg1 access opportunity / resource and the random ID. That is, two devices that generate the same random ID may, through their algorithms, always select the same Msg1 access opportunity / resource, potentially leading to subsequent data transfer failures. Therefore, to avoid these correlations between processes, it is beneficial to specify (or note) that different random values ​​(e.g., using different seeds) are used for selecting the Msg1 access opportunity / resource and generating the random ID, respectively.

[0334] Proposal 4: RAN2 should agree that different random values ​​should be used for selecting access opportunities / resources for Msg1 and for generating random IDs included in Msg1.

[0335] After a device sends Msg1 with a random ID at a selected access opportunity / resource, the reader attempts to receive Msg1 sent from multiple devices at all access opportunities / resources. If different devices generate the same random ID and send it at different access opportunities / resources, the reader can successfully decode these Msg1s. In other words, the reader observes the same random ID for different devices.

[0336] Finding 3: If the same random ID is transmitted via different Msg1 messages from different devices with different access opportunities / resources, the reader may observe the same random ID for multiple devices.

[0337] The TR states that it is necessary to consider whether the AS-ID is assigned by the reader or generated by the device (i.e., a random ID in Msg1), as shown below. However, considering the situation under Finding 3, the reader needs to assign an AS-ID to the device that is different from the random ID received.

[0338] From a higher-layer perspective, it is assumed that at least an "AS ID" (as defined according to the design in Section 6.1) will be used for D2R scheduling and R2D reception purposes. From a higher-layer perspective, it is assumed that this "AS ID" should be a short access layer ID, not a full higher-layer device ID. Further consideration is needed as to whether this "AS ID" can be based on a partial higher-layer device ID. Further consideration is also needed as to the length of this "AS ID". From a higher-layer perspective, the following options are possible for this "AS ID" (aiming to define one common design for all access procedures in Section 6.3.4, where technically possible): Option 1: A random ID (if used in the first D2R message) can be reused. Option 2: The reader assigns this "AS ID" to the device. Further consideration is needed as to which R2D message to use. Option 3: It is up to the reader whether to reuse the random ID (if used in the initial D2R message) as the "AS ID" or assign a new "AS ID". Further consideration is needed regarding which R2D message to use. Note 1: Further refinement of the "AS ID" requires consideration of the messages involved and whether the reader needs to handle collisions.

[0339] On the other hand, the random ID received via Msg1 can be reused as the AS-ID in most cases. Therefore, it is inefficient to always provide an explicit AS-ID in the R2D message. Here, Msg2 is assumed to play the same role as other R2D messages (this should also be confirmed in RAN2). Therefore, it is worth considering whether to introduce a one-bit indication in Msg2 to show whether the random ID sent in Msg1 will become the AS-ID, or whether Msg2 will provide a reader-assigned AS-ID. If the random ID is reused as the AS-ID, this one-bit indication can reduce the size of Msg2. Otherwise, an explicit AS-ID assigned by the reader may be displayed in Msg2.

[0340] Therefore, it is preferable to adopt option 3, at least in cases where Msg2 can provide an AS-ID.

[0341] Proposal 5: RAN2 should agree that the AS-ID for scheduling purposes is determined by the device as a result of receiving Msg2.

[0342] Proposal 6: RAN2 should agree that if the same random ID is observed for multiple devices after receiving Msg1, the AS-ID may be assigned by the reader (i.e., option 3 in TR).

[0343] Proposal 7: RAN2 should agree to introduce a 1-bit indicator in Msg2 to notify the device whether the random ID transmitted in Msg1 will be the AS-ID, or whether Msg2 will provide the leader-assigned AS-ID.

[0344] Regarding conflict resolution, the TR states that "if an A-IoT device receives an A-IoT Msg2 containing the same random ID as one previously transmitted in A-IoT Msg1, the conflict resolution is considered successful." However, as shown in Finding 3, if the same random ID is generated and transmitted by multiple devices, relying solely on comparing the echo (response) of the random ID in Msg2 with the random ID in Msg1 for conflict resolution is insufficient. For example, during the subsequent A-IoT data transmission procedure, even if the random ID may not have been transmitted by the device in question, multiple different devices may consider their own conflict resolution to have been successful due to the same random ID, leading to conflict / interference.

[0345] Finding 4: When multiple devices simultaneously generate and transmit the same random ID in their Msg1, conflict resolution becomes inaccurate (i.e., because an echo of the same random ID is returned via Msg2, the devices consider unsuccessful conflict resolution to be successful).

[0346] To address the issue in Finding 4, it is worth considering additional evaluation criteria in addition to random IDs. As a possible solution, using an index of Msg1 access opportunities / resources for conflict resolution could be considered.

[0347] Upon receiving Msg1, the reader can determine which access opportunity / resource was used for each Msg1 transmission by each device. If Proposal 1 is agreed upon, each access opportunity / resource can be identified by an index. Therefore, the reader can include an index of the Msg1 access opportunity / resource in Msg2, thereby associating each index with each echo of a random ID. Alternatively, the order of the echoes of random IDs in Msg2 may implicitly represent the index. For example, the first echo would be associated with index #1, the second echo with index #2, and so on.

[0348] Upon receiving Msg2, if agreement is reached on Proposal 3, the device can compare the echo of the random ID in Msg2 with the random ID it sent in Msg1, and also compare the index displayed in Msg2 with the index it used to transmit Msg1. The device considers the conflict resolution successful only if both criteria (i.e., no mismatch in random IDs and no mismatch in indices) are met. Otherwise, the device considers it a failure.

[0349] This solution minimizes the possibility of inaccurate conflict resolution, because even if the same random ID is generated by different devices, different access opportunities / resources are used in most cases.

[0350] Proposal 8: To avoid inaccurate conflict resolution results when multiple devices generate the same random ID for Msg1, RAN2 should agree to further implement conflict resolution based on an index of Msg1 access opportunities / resources.

[0351] 2.3 Overview of Msg2 Structure The above proposals are summarized in Figure 23 as an example of an Msg2 structure. Note that this is not intended to exclude additional information or spare bits. (Appendix 4) 1. Introduction In RAN#108, based on the results of the corresponding investigation items, a new work item concerning ambient IoT (A-IoT) solutions was approved. The scope of RAN2, as described below, includes the functions and procedures necessary for A-IoT paging, A-IoT random access, and A-IoT data transmission.

[0352] "• Scope of RAN2: • Defines the functions and procedures required for a compact protocol stack and lightweight signaling procedure for ambient IoT to enable DO-DTT and DT data transmission. • A-IoT paging: Includes subsequent paging for the same service. Supports options for paging messages to include one identifier (ID) and options for paging messages to not include an identifier. Temporary identifiers are not supported unless requested by the SA WG. Note: RAN2 aims to design a paging message format that can include multiple identifiers in a single paging message for future compatibility. • A-IoT random access: Includes re-access for failure handling. Conflict-based and non-conflict cases are supported. For conflict-based random access, only Solution 1 (3 steps only) is included (unless RAN2 decides to use Solution 3 (integrated solution) by RAN2#129). • A-IoT data transmission: Includes data (re)transmission for failure handling. Segmentation is supported at least in D2R." This document provides initial considerations for defining A-IoT data transmission procedures.

[0353] 2. Discussion 2.1 D2R Data Transmission (Device ID Transmission) in Step B The overall AS procedure for ambient IoT consists of steps A, B, and C, where step A performs the A-IoT paging procedure, step B performs the random access procedure and initial D2R data transmission for device ID transmission, and step C performs data transmission with R2D and D2R as shown below.

[0354] "The overall AS procedure can be formulated as follows: Step A: A-IoT paging. Based on the service request, the reader sends an A-IoT paging message indicating the devices that require a response. See Section 6.3.3. Step B: D2R data (device ID) transmission. The triggered A-IoT device performs device ID transmission via or without the A-IoT random access procedure. See Sections 6.3.4 (and 6.3.5). Step C1: Possible R2D data transmission (e.g., to send a command). See Section 6.3.5. Step C2: Possible D2R data transmission (e.g., a corresponding response to a command). See Section 6.3.5."

[0355] The initial D2R data transmission (for device ID transmission) in step B may occur immediately after A-IoT paging in the case of non-conflict access, or immediately after the A-IoT random access procedure in the case of conflict-based random access. Therefore, it can be assumed that scheduling information for dedicated resources for the initial D2R data transmission of a particular device is provided by the A-IoT paging message or Msg2. Accordingly, RAN2 should confirm this assumption.

[0356] Proposal 1: RAN2 should agree that scheduling information for initial D2R data transmission (device ID transmission in step B) is provided by either an A-IoT paging message (in the case of non-conflict access) or Msg2 (in the case of conflict-based random access).

[0357] 2.2 D2R Data Transmission in Step C (Response to Command) In step C shown in Figure 24, the D2R data transmission (C2, corresponding response to command) follows the R2D data transmission (C1, transmission of command). Therefore, scheduling information for the D2R data transmission (C2) can be provided within the preceding R2D data transmission (C1), similar to the initial D2R data transmission (B, device ID transmission) in Proposal 1. If the same principle applies to all D2R data transmissions, i.e., if scheduling information is provided by the preceding R2D message, which may be A-IoT paging, Msg2, or R2D data transmission, it is expected that the complexity of the device will be reduced.

[0358] Proposal 2: RAN2 should agree that scheduling information for D2R data transmission (response corresponding to a command in step C2) is provided by the preceding R2D data transmission (transmission of a command in step C1).

[0359] 2.3 D2R Scheduling Information and D2R Resource Index Regarding the details of D2R / R2D resources, WID specifies that R2D supports TDMA only, and D2R supports TDMA and FDMA. "• Multiplexing / multiple access in R2D is by TDMA only, and in D2R it is by TDMA and FDMA only."

[0360] Furthermore, it is natural to assume that the duplex of R2D and D2R is TDD. Therefore, an example of time slots and frequency channels is shown in Figure 19.

[0361] According to TR, the A-IoT paging message displays scheduling information for the D2R message, as shown below. Therefore, the device can know how many resources are available in the time domain ($N_T$) and the frequency domain ($N_F$). The same applies to the Msg2 and R2D messages.

[0362] "With regard to A-IoT paging messages, additional information may be displayed that allows the device to determine the resources used for D2R response messages. This can be further considered in detail in the discussion in Section 6.1."

[0363] Finding 1: From the scheduling information in the preceding R2D message (i.e., A-IoT paging, Msg2, or R2D data transmission), the device can determine how many opportunities / resources are available in the time domain ($N_T$) and the frequency domain ($N_F$), respectively.

[0364] Based on Finding 1, the D2R resource grid (N Ｔ × N Ｆ The access opportunity / resource is known by the device. Therefore, an index of access opportunities / resources can be defined within the D2R resource grid, making each access opportunity / resource identifiable by both the reader and the device. An example of an access opportunity / resource index is shown in Figure 25.

[0365] Proposal 3: RAN2 should agree to define an index of access opportunities / resources. That is, the upper limit of the index should be (N Ｔ × N Ｆ )

[0366] As shown in Figure 25 (TDMA + FDMA), each D2R access opportunity / resource is assigned an index according to predefined rules. If each index is associated with the order of device-specific information in R2D messages (time domain, TDMA), scheduling information becomes extremely simple because there is no need to explicitly notify the device of dedicated resources.

[0367] For example, if an R2D message has three data blocks, with the first information for device A, the second for device B, and the last for device C, device A knows that it has been allocated access opportunity / resource index #0 for the subsequent D2R transmission. Device B uses index #1, and device C similarly uses index #2.

[0368] As shown in Figure 26 below, the device temporarily connects to the D2R resource grid (N Ｔ × N Ｆ Knowing this, D2R scheduling information is implicitly displayed in the preceding R2D message (i.e., detailed time / frequency resource information is unnecessary). Therefore, it is expected that the signaling overhead for D2R scheduling in all R2D transmissions will be reduced.

[0369] Proposal 4: RAN2 should consider whether access opportunities / resources for D2R transmission are implicitly indicated by the information order of each device in the preceding R2D message.

[0370] 2.4 Segmentation WID stipulates that segmentation (fragmentation) should be supported, at least for D2R. TR describes the findings of RAN2's investigation into segmentation as follows: "The investigation into segmentation focuses on the D2R direction (the R2D direction can be considered further). Candidate solutions for segmentation: • Sequence numbers, segment numbers, and number of segments are not supported. • A display is used to show the reader whether the data is segmented and whether the MAC PDU is the final segment. The size of this display (1 bit or 2 bits) and corresponding further details need to be considered further. • It is beneficial for the reader to be able to trigger segment retransmission. • A-IoT devices do not support AS layer buffering for A-IoT segmentation functionality; i.e., all segments are assumed to be stored in a higher layer."

[0371] Regarding the consideration of "the size of this display (1 bit or 2 bits)," our view is that only a 1-bit display associated with "whether or not it is the final segment" is preferable to having 2 bits. As for the other display in the agreement, namely "whether or not the data is segmented," if the D2R message indicates that it is not the final segment, then it is clear that the data is segmented. For data that indicates it is the final segment, there is no difference between the final segment of segmented data and unsegmented data.

[0372] Proposal 5: RAN2 should agree that the segmentation function should include only a single bit indication to show whether the D2R message is the final segment. No other indications are necessary.

[0373] According to the TR, "it is beneficial for the reader to be able to trigger segment retransmission," which is considered a kind of simple ARQ (Automatic Retransmission Request). For D2R ARQ, the stop-and-wait protocol, a well-known ARQ mechanism, would be a promising solution in terms of its low device complexity. From the device's perspective, the A-IoT MAC requests the start position and length of the bit string from the upper layer, depending on the allocated TB size. If it receives a NACK from the reader, the A-IoT MAC requests the same information from the upper layer. Otherwise (i.e., in the case of an ACK), it similarly requests the next start position and length, where the next start position should be the (previous) start position plus the length.

[0374] Proposal 6: RAN2 should agree to adopt a stop-and-wait protocol to support simple ARQ functionality.

Claims

1. A communication method for use in a mobile communication system, comprising: an ambient IoT (Internet of Things) device receiving a predetermined message containing a plurality of predetermined pieces of information from a reader device which is a network node or user device of the mobile communication system; and the ambient IoT device transmitting D2R (Device to Reader) data to the reader device using transmission resources corresponding to the order in which the predetermined pieces of information are included in the predetermined message.

2. The communication method according to claim 1, wherein the predetermined message is an ambient IoT paging message and the predetermined information is a device ID.

3. The communication method according to claim 2, wherein the ambient IoT paging message includes a plurality of ambient IoT paging messages, each containing one device ID, which are linked together.

4. The communication method according to claim 3, wherein the ambient IoT paging message includes additional information indicating whether or not it includes a plurality of device IDs.

5. The communication method according to claim 3, wherein the ambient IoT paging message includes additional information indicating the number of IDs, and the IDs are the device ID and / or group ID.

6. The communication method according to claim 3, wherein the ambient IoT paging message includes additional information indicating the duration of the ambient IoT paging message.

7. The communication method according to claim 2, wherein the transmission includes stopping the reception of the ambient IoT paging message when the ambient IoT device has confirmed its own device ID.

8. The communication method according to claim 1, wherein the predetermined message is message 2 (Msg2), and the predetermined information is echo information.

9. The communication method according to claim 8, wherein the receiving includes the ambient IoT device receiving a plurality of Msg2 at different timings, and the transmitting includes the ambient IoT device transmitting the D2R data to the reader device using the transmission resources corresponding to the order of each Msg2.

10. The communication method according to claim 9, wherein the Msg2 includes an end marker, and the transmission includes detecting at least one of the end timing of the Msg2 and the start timing of the transmission of the D2R data in response to the ambient IoT device detecting the end marker.

11. The communication method according to claim 8, further comprising the ambient IoT device performing conflict resolution based on the echo information contained in the Msg2, wherein the performance includes the ambient IoT device determining that the conflict resolution has failed in response to receiving default information as the echo information.

12. A communication method for use in a mobile communication system, comprising: an ambient IoT (Internet of Things) device receiving a predetermined message from a network node or user device which is a reader device of the mobile communication system, which includes additional information indicating whether or not it includes an AS ID (Access Stratum ID); and the ambient IoT device communicating with the reader device using the additional information.

13. The communication method according to claim 12, wherein the AS ID is identification information used in the AS layer, and the length of the AS ID is less than or equal to a threshold.

14. The communication method according to claim 12, further comprising: if the ambient IoT device indicates that the additional information includes the AS ID, applying the AS ID included in the predetermined message as its own AS ID; and if the information does not include the AS ID, applying a random ID included in Msg1 as the AS ID.

15. The communication method according to claim 12, further comprising: if the ambient IoT device indicates that the additional information does not include the AS ID, applying a random ID included in Msg1 as the AS ID.

16. The communication method according to claim 12, further comprising: the reception comprising the ambient IoT device receiving the predetermined message which does not include the additional information, the ambient IoT device defaulting to applying the random ID transmitted in Msg1 as the AS ID, and applying the AS ID when it receives an R2D message which includes the AS ID.

17. The communication method according to claim 12, wherein the predetermined message is one of an ambient IoT paging message, Msg2, and an R2D (Reader to Device) data transmission message.

Images