Communication method

Abstract

This communication method comprises: a reader apparatus, which is a network node or a user equipment of a mobile communication system, transmitting, to an ambient Internet of Things (IoT) device, a Reader-to-Device (R2D) message for enabling Device-Originated (DO) data transmission; the reader apparatus, in response to receiving DO data from the ambient IoT device, performing an error detection process on the received DO data; and the reader apparatus, in response to detection of an error by the error detection process, retransmitting the R2D message to the ambient IoT device.

Description

Communication Method

[0001] The present disclosure relates to a communication method for use in a mobile communication system.

[0002] In recent years, the Internet of Things (IoT) has been attracting attention in wireless communication technology. It is expected that interconnecting more "things" will improve production efficiency and enhance the comfort of daily life compared to the past. Technologies used in IoT include barcodes and radio frequency identifiers (RFIDs). However, barcodes and RFIDs cannot perform long-distance wireless communication, making it difficult to support large-scale networks.

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

[0004] Most existing wireless communication devices use batteries that must be manually replaced and / or charged. However, powering all IoT devices with batteries is difficult because it requires not only the cost of the IoT devices themselves but also the maintenance costs for the IoT devices.

[0005] The above-mentioned ambient IoT devices are envisioned to function as battery-less devices with no energy storage capabilities, in which case the ambient IoT devices function as pure battery-less devices with no power storage capabilities whatsoever and are completely dependent on the availability of an external energy source.

[0006] Alternatively, ambient IoT devices are envisioned to function as battery devices with limited energy storage, e.g., energy storage that does 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 development of new markets.

[0008] 3GPP TR 38.848 V18.0.0 (2023-09)

[0009] The present disclosure provides a technique that enables appropriate communication between a reader device, which is a network node or user device in a mobile communication system, and an ambient IoT device.

[0010] A communication method according to a first aspect includes a reader device, which is a network node or user equipment of a mobile communication system, transmitting a Reader-to-Device (R2D) message to an ambient Internet of Things (IoT) device to enable Device-Originated (DO) data transmission; the reader device, in response to receiving the DO data from the ambient IoT device, performing an error detection process on the received DO data; and, in response to detecting an error in the error detection process, the reader device retransmitting the R2D message to the ambient IoT device.

[0011] A communication method according to a second aspect includes a reader device, which is a network node or a user device of a mobile communication system, receiving Device-Originated (DO) data from one or more ambient Internet of Things (IoT) devices in at least one time slot of a plurality of time slots, the reader device determining whether the DO data has been received for each time slot, and the reader device transmitting a Reader-to-Device (R2D) message including information indicating whether the DO data has been received for each time slot, and enabling retransmission of the DO data.

[0012] 1 is a diagram illustrating an example of the configuration of a mobile communication system according to an embodiment. FIG. 1 is a diagram illustrating an example of the configuration of a UE (user equipment) according to an embodiment. FIG. 2 is a diagram illustrating an example of the configuration of a gNB (network node) according to an embodiment. FIG. 3 is a diagram illustrating a protocol stack configuration of a radio interface of a user plane that handles data. FIG. 4 is a diagram illustrating a protocol stack configuration of a radio interface of a control plane that handles signaling (control signals). FIG. 4 is a diagram illustrating an example of the configuration of an ambient IoT device according to an embodiment. FIG. 5 is a diagram illustrating "Topology 1" and "Topology 2" as topology examples of a mobile communication system having an ambient IoT device according to an embodiment. FIG. 6 is a diagram illustrating an example of the configuration of an ambient IoT device of "Device 1" according to an embodiment. FIG. 7 is a diagram illustrating an example of the configuration of an ambient IoT device of "Device 2a" according to an embodiment. FIG. 8 is a diagram illustrating an example of the configuration of a protocol stack for an ambient IoT device according to an embodiment. FIG. 9 is a diagram illustrating an example of a basic procedure of communication between an ambient IoT device and a reader device according to an embodiment. FIG. 10 is a diagram illustrating an overview of a first operation pattern according to an embodiment. FIG. 11 is a diagram illustrating a first operation example of the first operation pattern according to an embodiment. FIG. 12 is a diagram illustrating a second operation example of the first operation pattern according to an embodiment. FIG. 13 is a diagram illustrating the operation of a reader device according to the second operation pattern according to an embodiment. FIG. 14 is a diagram illustrating an operation example of a mobile communication system according to the second operation pattern according to an embodiment. 10A to 10C are diagrams illustrating an operation example according to a third operation pattern of the embodiment, a first operation example according to a fourth operation pattern of the embodiment, and a second operation example according to the fourth operation pattern of the embodiment.

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

[0014] (1) Configuration of a Mobile Communication System FIG. 1 is a diagram showing an example of the configuration of a mobile communication system 1 according to an embodiment. The mobile communication system 1 conforms to the 3GPP standard 5th Generation System (5GS). While the following description uses 5GS as an example, the mobile communication system may also be at least partially based on an LTE (Long Term Evolution) system. The mobile communication system may also be at least partially based on a 6th Generation (6G) system.

[0015] The mobile communication system 1 includes a user equipment (UE) 100, a 5G radio access network (NG-RAN: Next Generation Radio Access Network) 10, and a 5G core network (5GC: 5G Core Network) 20. Hereinafter, the NG-RAN 10 may be simply referred to as the RAN 10. Furthermore, the 5GC 20 may be simply referred to as the core network (CN) 20. The RAN 10 and the CN 20 constitute a network 5 of the mobile communication system 1.

[0016] The UE 100 is a mobile wireless communication device. The UE 100 may be any device used by a user. For example, the UE 100 may be a mobile phone terminal (including a smartphone) and / or a tablet terminal, a notebook PC, a communication module (including a communication card or chipset), a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle (Vehicle UE), or an aircraft or a device provided in an aircraft (Aerial UE). A link in the transmission direction from the UE 100 to the network 5 is referred to as an uplink (UL), and a link in the transmission direction from the network 5 to the UE 100 is referred to as a downlink (DL).

[0017] The NG-RAN 10 includes a base station (referred to as "gNB" in the 5G system) 200, which is a type of network node. The gNBs 200 are connected to each other via an Xn interface, which is an interface between base stations. The gNB 200 manages one or more cells. The gNB 200 performs wireless communication with the UE 100 that has established a connection with its own cell. The gNB 200 has a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), a measurement control function for mobility control and scheduling, etc. 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 (hereinafter simply referred to as "frequency").

[0018] In addition, gNBs can also be connected to the Evolved Packet Core (EPC), which is the core network of LTE. LTE base stations can also be connected to 5GC. LTE base stations and gNBs can also be connected via an inter-base station interface.

[0019] 5GC20 includes an AMF (Access and Mobility Management Function) and a UPF (User Plane Function). The AMF performs various mobility controls for the UE 100. The AMF manages the mobility of the UE 100 by communicating with the UE 100 using NAS (Non-Access Stratum) signaling. The UPF controls data forwarding. The AMF and UPF are connected to the gNB 200 via an NG interface, which is an interface between a base station and a core network.

[0020] 2 is a diagram illustrating an example configuration of a UE 100 (user equipment) according to an embodiment. The UE 100 includes a receiving unit 110, a transmitting unit 120, and a control unit 130. The receiving unit 110 and the transmitting unit 120 configure a wireless communication unit 140 that performs wireless communication with the gNB 200.

[0021] 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 a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 130.

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

[0023] The control unit 130 performs various controls and processes in the UE 100. Such processes include processes of each layer described below. The operations of the UE 100 described above and below may be operations controlled by the control unit 230. 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 the processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes.

[0024] 3 is a diagram showing an example configuration of a gNB 200 (network node) according to an embodiment. The gNB 200 has a transmitter 210, a receiver 220, a controller 230, and a network communication unit 240. The transmitter 210 and the receiver 220 constitute a wireless communication unit 250 that performs wireless communication with the UE 100. The network communication unit 240 has a transmitter 241 that transmits and a receiver 242 that receives.

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

[0026] 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 a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 230.

[0027] The control unit 230 performs various controls and processes in the gNB 200. Such processes include processes for each layer described below. The operations of the gNB 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 in 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. The CPU executes programs stored in the memory to perform various processes.

[0028] The network communication unit 240 is connected to adjacent base stations via an Xn interface, which is an interface between base stations. The network communication unit 240 is connected to the AMF / UPF via an NG interface, which is an interface between a base station and a core network. Note that the gNB 200 is composed of a CU (Central Unit) and a DU (Distributed Unit) (i.e., functionally divided), and the two units may be connected by an F1 interface, which is a fronthaul interface.

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

[0030] The user plane radio interface protocol includes a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, and a service data adaptation protocol (SDAP) layer.

[0031] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the PHY layer of UE100 and the PHY layer of gNB200 via a physical channel. The PHY layer of UE100 receives downlink control information (DCI) transmitted from gNB200 on a physical downlink control channel (PDCCH). Specifically, UE100 performs blind decoding of the PDCCH using a radio network temporary identifier (RNTI) and acquires the successfully decoded DCI as DCI addressed to the UE. The DCI transmitted from gNB200 has a CRC parity bit scrambled by the RNTI added.

[0032] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat reQuest (HARQ), random access procedures, etc. Data and control information are transmitted between the MAC layer of the UE 100 and the MAC layer of the gNB 200 via a transport channel. The MAC layer of the gNB 200 includes a scheduler. The scheduler determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to the UE 100.

[0033] The RLC layer transmits data to the receiving RLC layer using the functions of the MAC layer and PHY layer. Data and control information are transmitted between the RLC layer of the UE 100 and the RLC layer of the gNB 200 via a logical channel.

[0034] The PDCP layer performs header compression / decompression, encryption / decryption, and the like.

[0035] The SDAP layer maps IP flows, which are units for Quality of Service (QoS) control by the core network, to radio bearers, which are units for QoS control by the Access Stratum (AS). Note that if the RAN is connected to the EPC, SDAP may not be required.

[0036] FIG. 5 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals).

[0037] The protocol stack of the radio interface of the control plane has an RRC (Radio Resource Control) layer and an NAS (Non-Access Stratum) layer instead of the SDAP layer shown in FIG.

[0038] RRC signaling for various settings is transmitted between the RRC layer of UE100 and the RRC layer of gNB200. The RRC layer controls logical channels, transport channels, and physical channels according to the establishment, re-establishment, and release of radio bearers. When there is a connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC idle state. When the connection between the RRC of UE100 and the RRC of gNB200 is suspended, UE100 is in an RRC inactive state.

[0039] The NAS layer (also simply referred to as "NAS") located above the RRC layer performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of UE 100 and the NAS layer of AMF. Note that UE 100 has an application layer and the like in addition to the radio interface protocol. Also, a layer lower than the NAS layer is referred to as the AS layer (also simply referred to as "AS").

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

[0041] (2.1) Overview of Ambient IoT Device Fig. 6 is a diagram illustrating an example configuration of an ambient IoT device 300 according to an embodiment. The ambient IoT device 300 is a wireless communication device capable of wireless communication with a reader device that is the UE 100 or the gNB 200. The ambient IoT device 300 may perform wireless communication within the frequency band of the mobile communication system 1.

[0042] The ambient IoT device 300 may transmit information within the ambient IoT device 300 by reflecting radio waves transmitted from a reader device (UE 100 or gNB 200) and modulating the reflected waves. Generally, the technology 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 or write information to an internal memory using the backscattering communication function. In this case, the ambient IoT device 300 may receive a transmitted radio wave on which information has been modulated and extract the information by demodulating the received radio wave.

[0043] The ambient IoT device 300 may be a battery-less IoT device. In this case, the ambient IoT device 300 converts the received radio waves into energy (specifically, power) and operates using the energy. The ambient IoT device 300 may use an energy source other than radio waves, for example, light, heat, magnetism, vibration, or sound, to convert energy. Generally, such energy conversion is called energy harvesting. A known method for energy harvesting may be used. In this way, 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 for charging the power obtained by the energy harvesting function. The ambient IoT device 300 may be a wireless tag.

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

[0045] The antenna 310 receives an unmodulated carrier wave. Hereinafter, this unmodulated carrier wave will be referred to as a CW (Continuous Wave). The antenna 310 converts the received CW into a received signal and outputs this received signal to the modulator 320. The antenna 310 also reflects the CW in accordance with the transmission signal output from the modulator 320 and transmits a reflected wave. Hereinafter, this reflected wave will be referred to as a BS (Back Scattering or Back Scatter). The antenna 310 performs BS transmission.

[0046] The modulator 320 may generate a transmission signal by modulating data read from the memory 340 under the control of the control unit 330. The modulator 320 outputs the modulated signal to the antenna 310. Furthermore, the modulator 320 may acquire data by demodulating a signal received from the antenna 310 under the control of the control unit 330. 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 reception signal from the antenna 310, the switch turns on and outputs the reception signal to the control unit 330. Furthermore, the switch is controlled to be on or off under the control of the control unit 330, 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 configured with a transistor. Alternatively, the switch may be a mechanical switch that can be physically switched on or off.

[0047] The control unit 330 may have an energy harvesting function that converts the received signal received from the modulator 320 into power. The control unit 330 may control the modulator 320 and the memory 340 using the power as driving power for the ambient IoT device 300. The control unit 330 may also read information stored in the memory 340 and control the modulator 320 to transmit a transmission signal corresponding to the information. For example, the control unit 330 may control the reflectivity of the reflected wave (BS) (e.g., whether the reflectivity is 100% or 0%) by turning the modulator 320 on or off, and output a transmission signal corresponding to information (e.g., 1 bit) stored in the memory 340 from the modulator 320 to the antenna 310. For example, the control unit 330 may control the timing of turning the modulator 320 on or off, and output a transmission signal corresponding to multiple bits from the modulator 320 to the antenna 310. In this way, the control unit 330 may control the reflectivity of the reflected wave (BS) by controlling the on or off of the modulator 320, and transmit a modulated reflected wave corresponding to the information stored in the memory 340 from the antenna 310.

[0048] The memory 340 stores various types of information. The information stored in the memory 340 may be information acquired when the ambient IoT device 300 functions as a sensor. Alternatively, the information stored in the memory 340 may be information specific to the ambient IoT device 300 that has been stored in advance in the memory 340. The specific information may include, for example, identification information of the ambient IoT device 300 (or the group to which the ambient IoT device 300 belongs). The identification information may be a "Device ID" and / or a "Group ID" (described later). The memory 340 can read the stored information under the control of the control unit 330. Information may be written to the memory 340 under the control of the control unit 330. In this case, the control unit 330 (or the modulator 320) converts the received signal received from the antenna 310 into a baseband signal in a baseband band, reads information from the baseband signal, and writes the read information to the memory 340.

[0049] The ambient IoT device 300 may have a limited battery. As described above, "limited" means a battery that does not need to be manually replaced and / or charged. The ambient IoT device 300 may have the ability to generate signals by itself. In this case, the ambient IoT device 300 does not need to receive the CW signal or perform the BS transmission. That is, the ambient IoT device 300 transmits a transmission signal that it generates by itself via the antenna 310.

[0050] (2.2) Topology of Ambient IoT Device FIG. 7 is a diagram showing "Topology 1" and "Topology 2" as examples of topologies of the mobile communication system 1 having the ambient IoT device 300 according to the embodiment.

[0051] A device that performs wireless communication with the ambient IoT device 300 is referred to as a reader device (or "Reader") 400. The reader device 400 may transmit an unmodulated carrier wave (CW). That is, the reader device 400 may perform CW transmission. The ambient IoT device 300 may reflect the unmodulated carrier wave and transmit a reflected wave. The reflected wave may be modulated according to data transmitted from the ambient IoT device 300. That is, the ambient IoT device 300 may perform BS transmission, and the reader device 400 may perform BS reception.

[0052] FIG. 7A shows an example configuration of "Topology 1." In "Topology 1," the leader device 400 is a network node (gNB200). The leader device 400 may be a relay node, which is a type of network node. For example, the leader device 400 may be an IAB (Integrated Access and Backhaul) node or an NCR (Network-Controlled Repeater). In "Topology 1," data related to the ambient IoT device 300 and / or signaling related to the ambient IoT device 300 is transferred between the ambient IoT device 300 and the network node (gNB200).

[0053] In the illustrated example, the ambient IoT device 300 communicates directly and bidirectionally with the gNB 200, which corresponds to the reader device 400. In this case, the wireless communication unit 250 (transmitter 210 and receiver 220) of the gNB 200 is capable of wireless communication with the ambient IoT device 300. For example, the transmitter 210 of the gNB 200 may transmit an unmodulated carrier wave under the control of the control unit 230. The carrier wave may be reflected at the ambient IoT device 300. The receiver 220 of the gNB 200 may receive a reflected wave reflected at 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.

[0054] 7B shows a configuration example of "Topology 2". In "Topology 2", the leader 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 gNB 200. In "Topology 2", the ambient IoT device 300 performs bidirectional wireless communication with the UE 100. The leader device 400 transfers data related to the ambient IoT device 300 and / or signaling related to the ambient IoT device 300 between the gNB 200 and the ambient IoT device 300.

[0055] In the illustrated example, the UE 100 performs wireless communication with the network node (gNB 200) over the Uu interface. 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 is capable of wireless communication with the ambient IoT device 300. For example, the receiving unit 110 of the UE 100 may receive a reflected wave reflected at the ambient IoT device 300 under the control of the control unit 130. The receiving unit 110 may receive the received reflected wave as a radio signal, convert it into a baseband signal, and output it 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. The carrier wave may be reflected at the ambient IoT device 300.

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

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

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

[0059] "Device 2b" is, for example, a device with peak power consumption of "several hundred μW" or less, with amplification in the DL and / or UL directions, and with UL transmissions generated internally within the device. Note that both device types have energy storage capabilities.

[0060] FIG. 8 is a diagram illustrating an example of the configuration of an ambient IoT device 300 of “device 1” according to the embodiment.

[0061] "Device 1" includes an antenna 310, a matching network 350, an RF energy harvester 351, a power management unit (PMU) 352, an energy storage unit 353, an RF radio frequency band pass filter (RF BPF) 354, an RF envelope detector (or envelope detector) 355, a base band low pass filter (BB LPF) 356, a comparator 357, baseband logic 358, a memory 359, a backscattering modulator 360, and a clock generator 361.

[0062] The matching network 350 matches the impedance between the antenna 310 and 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.

[0063] The RF energy harvester 351 has an energy harvesting function and extracts energy from the radio signal. The RF energy harvester 351 may also include a rectifier that converts the radio signal from an AC component to a DC component.

[0064] The PMU 352 manages (or controls) the accumulation of energy from the RF energy harvester 351 and manages (or controls) the supply of power to the blocks that require it.

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

[0066] The RF BPF 354 outputs a radio signal in a specific frequency band. The RF BPF 354 is used to improve selectivity. Note that the RF BPF 354 may not be included in the "device 1" depending on the implementation.

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

[0068] The BB LPF 356 removes high frequency components from the baseband signal output from the RF envelope detector 355 and improves the quality of the signal input to the comparator 357 .

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

[0070] The baseband logic 358 includes functional blocks such as an encoder, a decoder, and a controller.

[0071] Memory 359 stores device identification information (or device ID) and the like for identifying (or distinguishing) 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 the like. Memory 359 may also be a memory (register) that temporarily stores information required only while the energy stored in energy storage unit 353 is available.

[0072] The backscattering modulator 360 switches impedance to modulate the output signal from the baseband logic 358 into a backscattering signal. Alternatively, the backscattering modulator 360 switches impedance (the impedance of the antenna or the transmission line) using the output signal (digital signal or digital data) from the baseband logic 358 to modulate the high-frequency signal (e.g., CW) input from the antenna 310 into a backscattering signal. For example, the backscattering modulator 360 can modulate and then reflect the high-frequency signal input from the antenna 310 by terminating (not reflecting) the high-frequency input signal for digital data "0" and opening (reflecting) the high-frequency input signal for digital data "1."

[0073] The clock generator 361 generates the clock signals required within the device.

[0074] 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 FIG. 6. The PMU 352 and baseband logic 358 may be included in the control unit 330 shown in FIG. 6. Furthermore, the memory 359 may correspond to the memory 340 shown in FIG. 6.

[0075] FIG. 9 is a diagram illustrating an example of the configuration of an ambient IoT device 300 of a "device 2a" according to the embodiment.

[0076] The "device 2a" 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 in addition to the components of the "device 1" shown in FIG.

[0077] LNA365 amplifies the output signal from RF BPF354 (i.e., the signal from the reader (gNB200 or UE100)) to improve the signal strength and signal sensitivity at the receiving side.

[0078] The baseband amplifier 366 amplifies the baseband signal output from the RF envelope detector 355 to improve the signal strength.

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

[0080] The energy harvester 369 generates energy from an environment using a source other than an RF signal. Specifically, energy harvesting sources include sunlight (solar panels), vibration (vibration power generation), and heat (thermal power generation), but are not limited to these.

[0081] The above has described a configuration example of the "device 2a." In the block configuration example shown in Fig. 9, in relation to the block configuration example shown in Fig. 6, the modulator 320 may further include an LNA 365, a baseband amplifier 366, a large frequency shifter 367, and a reflection amplifier 368.

[0082] (2.4) Protocol Stack for Ambient IoT Device FIG. 10 is a diagram showing an example of the configuration of a protocol stack for the ambient IoT device 300 according to the embodiment.

[0083] The air interface protocol includes a PHY layer and an ambient IoT (A-IoT) MAC layer. A new layer (New AS Protocol) may be introduced as an upper layer of the A-IoT MAC layer. Communication between a reader device 400 (described later) and an ambient IoT device 300 may be performed by at least one of the layers shown in FIG. 10 .

[0084] A 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 a PRDCH (Physical Reader-to-Device channel). A channel used for R2D transmission is also referred to as an R2D channel. The R2D channel may be the PRDCH.

[0085] On the other hand, a physical channel used for transmission from the ambient IoT device 300 to the reader device 400 (hereinafter, sometimes referred to as "Device to Reader (D2R) transmission") is called a Physical Device to Reader channel (PDRCH). A channel used for D2R transmission is also referred to as a D2R channel. The D2R channel may be the PDRCH.

[0086] For example, in "Topology 1", the physical channel used for R2D transmission from gNB200 to ambient IoT device 300 is PRDCH, and the physical channel used for D2R transmission from ambient IoT device 300 to gNB200 is PDRCH. Also 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.

[0087] It should be noted that the control plane between the reader device 400 and the ambient IoT device 300 does not have an RRC layer between the reader device 400 and the ambient IoT device 300, and does not support RRC connection management, Layer 3 (L3) measurement reporting, periodic system information, and Master Information Block (MIB). Also, the ambient IoT device 300 does not support traditional paging messages.

[0088] The SDAP layer, the PDCP layer, and the RLC layer are not present in the user plane between the reader device 400 and the ambient IoT device 300. Furthermore, HARQ and RLC AM (Acknowledge Mode) are not supported.

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

[0090] (3.1) Basic Procedure Fig. 11 is a diagram showing an example of a basic procedure for communication between the ambient IoT device 300 and the reader device 400 according to the embodiment. The basic sequence includes Step A, Step B, and Step C. Two use cases, "inventory" and "command," are supported. "Inventory" is a use case for checking the existence of stock, etc., using the ambient IoT device 300. "Command" is a use case for issuing various commands, such as read, write, or kill, to the ambient IoT device 300.

[0091] Prior to Step A, in step S0, the leader device 400 (gNB200 or UE100) receives a service request from the network 5 (CN20 or gNB200). In the case of "Topology 1", the service request may be a message transmitted from the CN20 to the gNB200, for example, an NG-AP (Application Protocol) message. On the other hand, in the case of "Topology 2", the service request may be a message transmitted from the gNB200 to the UE100, for example, an RRC message (RRC Reconfiguration message) or an SIB (System Information Block). The service request may also be received from an upper layer (for example, an application layer). The upper layer may be present within the leader device 400. That is, the wireless protocol unit of the reader device 400 may receive the service request from its own application layer.

[0092] Step A: Step A is a step similar to conventional paging in the mobile communication system 1. That is, in Step A, random access (RA) of the ambient IoT device 300 is triggered by the reader device 400. Step A may be a step corresponding to "inventory."

[0093] Specifically, in step S1, the reader device 400 transmits an initial trigger message on the R2D channel, indicating the ambient IoT device 300 that needs to respond based on the service request of step S0. The ambient IoT device 300 receives the initial trigger message on the R2D channel. The initial trigger message is a type of R2D message. The R2D message may be a message defined in "A-IoT MAC" or "New AS Protocol." The message may also be referred to as a CE (Control Element) or a control PDU (Protocol Data Unit).

[0094] The initial trigger message may include, as information specifying the destination (target) of the message, an identifier for identifying a single ambient IoT device 300 (also referred to as "Device ID") or an identifier for identifying a group (also referred to as "Device Group") of ambient IoT devices 300 (also referred to as "Group ID"). The initial trigger message may include, as information specifying the destination (target) of the message, information indicating all ambient IoT devices 300 (also referred to as "All"). The initial trigger message may also include a "command" to the ambient IoT device 300. The reader device 400 may provide information (parameters) necessary for the ambient IoT device 300 to respond to the initial trigger message.

[0095] The reader device 400 may continuously or periodically transmit a synchronization signal used by the ambient IoT device 300 to synchronize with the reader device 400 and / or a reference signal used to estimate the channel state. These signals may be included in the R2D message.

[0096] Step B: In Step B, the ambient IoT device 300, which is triggered (specified) by the initial trigger message in Step A, performs an access procedure such as random access (RA) as necessary. A slotted-ALOHA access method may be applied to such an access procedure. The access procedure in Step B may be a four-step random access procedure. The access procedure in Step B may be a two-step random access procedure. The access procedure in Step B may be a contention-based procedure. The access procedure in Step B may be a contention-free procedure.

[0097] In the illustrated example, in step S2, the ambient IoT device 300 transmits a first access message (Msg1) from the ambient IoT device 300 in random access to the reader device 400 on the D2R channel. The reader device 400 receives the first access message (Msg1). The first access message (Msg1) is a type of D2R message. The D2R message may be a message specified in "A-IoT MAC" or "New AS Protocol." The message may also be referred to as a CE or control PDU.

[0098] The first access message (Msg1) may include a temporary identifier (temporary ID) of the ambient IoT device 300 or a permanent identifier (permanent ID) of the ambient IoT device 300. The permanent identifier (permanent ID) may be a unique identifier of the ambient IoT device 300.

[0099] In step S3, the reader device 400 transmits a response message (Msg2) to the ambient IoT device 300 over the R2D channel in response to the initial access message (Msg1) of step S2. The ambient IoT device 300 receives the response message (Msg2). The response message (Msg2) may be used for contention resolution and / or access failure handling.

[0100] In the case of a four-step random access procedure, in step S4, the ambient IoT device 300 may transmit a D2R message (Msg3) to the reader device 400 on the D2R channel. The reader device 400 may receive the D2R message (Msg3). Also, in step S5, the reader device 400 may transmit an R2D message (Msg4) to the ambient IoT device 300 on the R2D channel. The ambient IoT device 300 may receive the R2D message (Msg4).

[0101] Step C: In Step C, the ambient IoT device 300 performs data communication with the reader device 400 as necessary. Step C may be a step corresponding to a "command."

[0102] In the illustrated example, in step S6, the reader device 400 transmits an R2D message including a command and data on the R2D channel to the ambient IoT device 300. The ambient IoT device 300 receives the R2D message.

[0103] In step S7, the ambient IoT device 300 transmits a D2R message including data on the D2R channel to the reader device 400. The reader device 400 receives the D2R message.

[0104] (3.2) First Operation Pattern The first operation pattern of the mobile communication system 1 according to the embodiment will be described.

[0105] The communication types (also referred to as "service types" or "data communication types") between the reader device 400 and the ambient IoT device 300 include DT (Device-Terminated), which is data transmission from the reader device 400 to the ambient IoT device 300, and DO (Device-Originated), which is data transmission from the ambient IoT device 300 to the reader device 400. Note that "data transmission" is not limited to data transmission, and may be a concept that includes command transmission and / or response (ACK / NACK) transmission.

[0106] Further, DO includes DO-DTT (Device-Originated Device-Terminated Trigger), in which only a specific ambient IoT device 300 or a specific device group designated by the reader device 400 can transmit data to the reader device 400, and DO-A (Device-Originated-Autonomous), in which all ambient IoT devices 300 can transmit data to the reader device 400. DO-DTT may transmit DO data in response to a trigger from the reader device 400. On the other hand, DO-A may be a method in which the ambient IoT device 300 autonomously transmits DO data. However, if the ambient IoT device 300 in the DO-A can start transmitting DO data whenever it wants, it could become a source of interference in the mobile communication system 1, so it is preferable that the ambient IoT device 300 transmits data in the DO-A based on some instruction or permission from the reader device 400.

[0107] If the procedures for these communication types are completely separate procedures, it is necessary to specify the communication type in, for example, an initial trigger message, which poses a problem of increasing the complexity of processing in the ambient IoT device 300 (and the reader device 400). In the following first operation pattern, an operation will be described that makes it possible to standardize procedures for multiple communication types between the reader device 400 and the ambient IoT device 300 as much as possible and simplify processing in the ambient IoT device 300.

[0108] FIG. 12 is a diagram illustrating an outline of the first operation pattern according to the embodiment.

[0109] In the first operation pattern, the reader device 400 generates an R2D message having a destination identifier (destination ID) field and a command field (step S11) and transmits the R2D message to the ambient IoT device 300 on the R2D channel (step S12). The R2D message has a format that is common to multiple communication types between the reader device 400 and the ambient IoT device 300. That is, the reader device 400 transmits an R2D message having multiple common formats (destination ID field and command field) regardless of the communication type. The R2D message may further have a source ID field for identifying the source (the reader device 400).

[0110] This makes it possible to standardize procedures for multiple communication types between the reader device 400 and the ambient IoT device 300 as much as possible, thereby simplifying processing in the ambient IoT device 300. Furthermore, since it is not necessary to include information specifying the communication type in the R2D message, it is possible to suppress an increase in the message size of the R2D message.

[0111] The reader device 400 (gNB200 or UE100) that performs such operations has a control unit (control unit 230 or 130) that generates an R2D message having a destination ID field and a command field, and a transmission unit (transmission unit 210 or 120) that transmits the R2D message on the R2D channel to the ambient IoT device 300. The R2D message has a format that is common to and applicable to multiple communication types between the reader device 400 and the ambient IoT device 300.

[0112] The ambient IoT device 300 also includes a receiver (modulator 320) that receives an R2D message having a destination ID field and a command field from the reader device 400 (step S12), and a controller 330 that performs control according to the contents of the destination ID field and the command field. The control includes interpreting the R2D message (step S13). The control may further include transmitting a D2R message in response to the R2D message (step S14).

[0113] Here, the control unit 330 of the ambient IoT device 300 only needs to perform processing in accordance with the destination ID field and command field of the R2D message, and does not need to recognize the communication type or perform a special procedure depending on the communication type. This simplifies the processing in the ambient IoT device 300. Note that the ambient IoT device 300 generally has low processing capabilities, so it is desirable to simplify the processing.

[0114] In the first operation example of the first operation pattern, the R2D message in step S11 is an initial trigger message for starting communication between the reader device 400 and the ambient IoT device 300.

[0115] In the second operation example of the first operation pattern, the R2D message in step S11 is a command message that is transmitted and received after communication between the reader device 400 and the ambient IoT device 300 starts.

[0116] The leader device 400 may receive a service request including information specifying a communication type between the leader device 400 and the ambient IoT device 300 from the network 5 of the mobile communication system 1 (step S0). For example, in the case of "Topology 1", the gNB 200 corresponding to the leader device 400 may receive the service request from the CN 20 included in the network 5. In the case of "Topology 2", the UE 100 corresponding to the leader device 400 may receive the service request from the gNB 200 included in the network 5. In step S11, the leader device 400 may set information in each of the destination ID field and the command field of the R2D message according to the communication type specified in the service request.

[0117] For example, in step S0, the network 5 (CN20 or gNB200) may send a service request including information on the communication type (DT / DO-DTT / DO-A) to the leader device 400 (gNB200 or UE100). In step S0, the network 5 (CN20 or gNB200) may send a service request including information on the designation method of the ambient IoT device 300 ("Device ID", "Group ID", or "All") to the leader device 400 (gNB200 or UE100).

[0118] In step S11, the reader device 400 may set a write command in the command field of the R2D message in response to the communication type being DT between the reader device 400 and the ambient IoT device 300. In step S11, the reader device 400 may set a read command in the command field of the R2D message in response to the communication type being DO.

[0119] This allows the format of the R2D message to be standardized, while distinguishing between DT and DO depending on whether the command set in the command field of the R2D message is Write or Read. In other words, the format of the R2D message can be standardized regardless of whether it is DT or DO.

[0120] Note that write (Write) is a command for writing data transmitted from the reader device 400 to the ambient IoT device 300. On the other hand, read (Read) is a command for reading data from the ambient IoT device 300 and for the reader device 400 to acquire the data.

[0121] In step S11, the reader device 400 may set an identifier (Device ID) of a specific ambient IoT device 300 or an identifier (Group ID) of a specific device group in the destination ID field of the R2D message in response to the communication type between the reader device 400 and the ambient IoT device 300 being DO-DTT. In step S11, the reader device 400 may set information (All) indicating all ambient IoT devices 300 in the destination ID field of the R2D message in response to the communication type between the reader device 400 and the ambient IoT device 300 being DO-A.

[0122] This allows the format of the R2D message to be standardized, while distinguishing between DO-DTT and DO-A depending on the type of ID set in the destination ID field of the R2D message. In other words, the format of the R2D message can be standardized regardless of whether it is DO-DTT or DO-A.

[0123] 13 is a diagram illustrating a first operation example of the first operation pattern of the embodiment. In the first operation example, the R2D message having a common format is an initial trigger message. In the first operation example, the above-described Step A and Step C are integrated into a procedure.

[0124] In step S101, the reader device 400 identifies the communication type (DT / DO-DTT / DO-A) based on, for example, a service request, and sets the contents of 1) the destination ID field and 2) the command field of the initial trigger message according to the identified communication type as follows, and then transmits the R2D message.

[0125] In the case of DT: 1) Destination ID field: "Device ID", "Group ID", or "All" 2) Command field: "Write" In the case of DT, the initial trigger message may include DT data in addition to the above.

[0126] In the case of DO-DTT: 1) Destination ID field: "Device ID", "Group ID" 2) Command field: "Read" In the case of DO-DTT, the destination ID field may be set to "All".

[0127] In the case of DO-A: 1) Destination ID field: "All" 2) Command field: "Read" Note that "All" may be a predetermined value such as "all 0" or "all 1".

[0128] In step S102, the ambient IoT device 300 that received the initial trigger message in step S101 first checks the destination ID field of the received initial trigger message. Specifically, the ambient IoT device 300 performs the following process.

[0129] When "Device ID" or "Group ID" is set in the destination ID field of the initial trigger message: The ambient IoT device 300 checks whether the "Device ID" or "Group ID" set in the destination ID field matches the ID stored in the memory 340 of the ambient IoT device 300 (i.e., assigned to the ambient IoT device 300). If they match, the ambient IoT device 300 proceeds to check the command field, and if they do not match, the ambient IoT device 300 ends the process.

[0130] If the destination ID field of the initial trigger message is set to "All": The ambient IoT device 300 proceeds to check the command field.

[0131] Second, the ambient IoT device 300 checks the command field of the initial trigger message received in step S101. Specifically, the ambient IoT device 300 performs the following process.

[0132] When "Write" is set in the command field of the initial trigger message: The ambient IoT device 300 writes the DT data to the memory 340. The ambient IoT device 300 may also transmit a D2R message to the reader device 400 as a response to the completion (or failure) of the write. The D2R message may include the "Device ID" (or "Group ID") of the ambient IoT device 300 and an ACK indicating the completion of the write (or a NACK indicating the failure). Alternatively, the ambient IoT device 300 may enter a standby state for writing the DT data.

[0133] When "Read" is set in the command field of the initial trigger message: The ambient IoT device 300 reads the DO data from the memory 340 and transmits a D2R message including the read DO data to the reader device 400. The D2R message may include the "Device ID" (or "Group ID") of the ambient IoT device 300 and the DO data (Data).

[0134] The ambient IoT device 300 may transmit the D2R message using contention-based access, contention-free access, or, in the case of contention-based access, Slotted ALOHA.

[0135] 14 is a diagram illustrating a second operation example of the first operation pattern of the embodiment. In the second operation example, the R2D message having the common format is a command message. In the illustrated example, step S201 corresponds to the above-mentioned step A, step S202 corresponds to the above-mentioned step B, and steps S203 and S204 correspond to the above-mentioned step C.

[0136] Step S201 is the same as Step A (Step S1 in FIG. 11) described above, and Step S202 is the same as Step B (Step S2 in FIG. 11) described above.

[0137] In step S203, the reader device 400 identifies the communication type (DT / DO-DTT / DO-A) based on, for example, a service request, and sets the contents of 1) the destination ID field and 2) the command field of the command message according to the identified communication type as follows, and then transmits the R2D message.

[0138] In the case of DT: 1) Destination ID field: "Device ID", "Group ID", or "All" 2) Command field: "Write" In the case of DT, the command message may include DT data in addition to the above.

[0139] In the case of DO-DTT: 1) Destination ID field: "Device ID", "Group ID" 2) Command field: "Read" In the case of DO-DTT, the destination ID field may be set to "All".

[0140] In the case of DO-A: 1) Destination ID field: "All" 2) Command field: "Read" In step S102, the ambient IoT device 300 that received the command message in step S101 first checks the destination ID field of the received command message. Specifically, the ambient IoT device 300 performs the following process.

[0141] When "Device ID" or "Group ID" is set in the destination ID field of the command message: The ambient IoT device 300 checks whether the "Device ID" or "Group ID" set in the destination ID field matches the ID stored in the memory 340 of the ambient IoT device 300 (i.e., assigned to the ambient IoT device 300). If they match, the ambient IoT device 300 proceeds to check the command field, and if they do not match, the ambient IoT device 300 ends the process.

[0142] If the destination ID field of the command message is set to "All": The ambient IoT device 300 proceeds to check the command field.

[0143] Second, the ambient IoT device 300 checks the command field of the command message received in step S101. Specifically, the ambient IoT device 300 performs the following process.

[0144] When "Write" is set in the command field of the command message: The ambient IoT device 300 writes the DT data to the memory 340. The ambient IoT device 300 may also transmit a D2R message to the reader device 400 as a response to the completion (or failure) of the write. The D2R message may include the "Device ID" (or "Group ID") of the ambient IoT device 300 and an ACK indicating the completion of the write (or a NACK indicating the failure). Alternatively, the ambient IoT device 300 may enter a standby state for writing the DT data.

[0145] When "Read" is set in the command field of the command message: The ambient IoT device 300 reads the DO data from the memory 340 and transmits a D2R message including the read DO data to the reader device 400. The D2R message may include the "Device ID" (or "Group ID") of the ambient IoT device 300 and the DO data (Data).

[0146] The ambient IoT device 300 may transmit the D2R message using contention-based access, contention-free access, or, in the case of contention-based access, Slotted ALOHA.

[0147] (3.3) Second Operation Pattern The second operation pattern of the mobile communication system 1 according to the embodiment will be described. The second operation pattern may be based on the first operation pattern described above. The second operation pattern does not have to be based on the second operation pattern described above.

[0148] In a scenario in which the ambient IoT device 300 is mobile, for example, in a scenario in which the ambient IoT device 300 attached to cargo moves along with the cargo, the reader device 400 has a problem in that it is not possible to know when the ambient IoT device 300 will move within the communication range of the reader device 400. In the second operation pattern, an operation that enables appropriate communication between the reader device 400 and the ambient IoT device 300 will be described, even when the ambient IoT device 300 is mobile.

[0149] FIG. 15 is a diagram illustrating the operation of the reader device 400 according to the second operation pattern of the embodiment.

[0150] In step S21, the reader device 400 receives, from the network 5 of the mobile communication system 1, configuration information indicating periodic communication opportunities between the reader device 400 and the ambient IoT devices 300. For example, the periodic communication opportunities include DO-A periodic opportunities during which all the ambient IoT devices 300 can transmit data to the reader device 400.

[0151] In step S22, the leader device 400 provides the ambient IoT device 300 with periodic communication opportunities (for example, DO-A periodic opportunities) in accordance with the setting information received in step S21.

[0152] In this way, by the reader device 400 providing periodic communication opportunities (e.g., DO-A periodic opportunities) to the ambient IoT device 300, it becomes possible to appropriately communicate between the reader device 400 and the ambient IoT device 300 even when the ambient IoT device 300 is mobile. Furthermore, because the periodic communication opportunities are set according to setting information from the network 5, the periodic communication opportunities can be provided to the ambient IoT device 300 under the management of the network 5. As a result, it is possible, for example, to optimize the periodic communication opportunities for each reader device 400, or to prevent communication between the reader device 400 and the ambient IoT device 300 from becoming a source of interference in the mobile communication system 1.

[0153] The leader device 400 (gNB200 or UE100) that performs such operations has a receiving unit (receiving unit 242 or receiving unit 110) that receives setting information indicating periodic communication opportunities between the leader device 400 and the ambient IoT device 300 from the network 5 of the mobile communication system 1, and a control unit (control unit 230 or control unit 130) that provides periodic communication opportunities to the ambient IoT device 300 in accordance with the setting information.

[0154] The periodic communication opportunities may include communication opportunities for each of a plurality of communication types between the reader device 400 and the ambient IoT device 300. For example, in step S21, the reader device 400 may receive setting information from the network 5, including information indicating a DT communication opportunity, information indicating a DO-DTT communication opportunity, and information indicating a DO-A communication opportunity, and provide the ambient IoT device 300 with communication opportunities for each of these plurality of communication types.

[0155] In the case of "Topology 1," the leader device 400 is a network node (gNB200) included in the RAN10 of the mobile communication system 1. In this case, the gNB200 corresponding to the leader device 400 receives configuration information indicating periodic communication opportunities from the CN20 of the mobile communication system 1. For example, the gNB200 corresponding to the leader device 400 may receive a message (e.g., a service request message) including the configuration information from the CN20 on the RAN-CN interface (i.e., the NG interface).

[0156] On the other hand, in the case of "Topology 2", the leader device 400 is the UE 100. In this case, the UE 100 corresponding to the leader device 400 receives setting information indicating periodic communication opportunities from a network node (gNB 200) included in the RAN 10 of the mobile communication system 1. For example, the leader device 400 may receive an RRC message (e.g., a service request message) including the setting information from the gNB 200.

[0157] The reader device 400 may provide periodic DO-A opportunities to the ambient IoT device 300 in accordance with the setting information received in step S21. Under such circumstances, the reader device 400 may receive a DT or DO-DTT request from the network 5 (CN 20 or gNB 200). In response to receiving the request, the reader device 400 may prioritize the DT or DO-DTT over the DO-A when providing communication opportunities to the ambient IoT device 300. For example, the reader device 400 may provide the ambient IoT device 300 with a DT or DO-DTT opportunity instead of the periodic DO-A opportunity. This allows the DT or DO-DTT to be interrupt-processed during the DO-A opportunity, assuming that the communication opportunity of the ambient IoT device 300 is basically assigned to the DO-A.

[0158] FIG. 16 is a diagram illustrating an example of operation of the mobile communication system 1 according to the second operation pattern of the embodiment.

[0159] In step S301, the network 5 (CN20 or gNB200) transmits a service request message including configuration information (request information) regarding periodic DO-A service opportunities to the leader device 400 (gNB200 or UE100). The leader device 400 receives the service request message.

[0160] The setting information includes time information indicating periodic DO-A service opportunities. The time information includes at least one of information on the periodicity of the DO-A service opportunities, information on the start timing (radio frame, subframe, and / or time slot) of the DO-A service opportunities, and information on the time slots (which may be radio frames or subframes) of the DO-A service opportunities. The information on the time slots (which may be radio frames or subframes) of the DO-A service opportunities may be a bitmap indicating the time slots to be assigned to the DO-A service opportunities. The time information may be expressed based on the radio frames (which may be subframes and / or time slots) of the Uu.

[0161] The setting information may include time information indicating a service opportunity for each communication type. The time information may be set by associating, for example, DT with service opportunity information A, DO-DTT with service opportunity information B, and DO-A with service opportunity information C. Each piece of service opportunity information may be configured in the same manner as the above-mentioned time information.

[0162] In step S302, the leader device 400 begins providing periodic DO-A opportunities to the ambient IoT device 300 in accordance with the setting information of step S301. For example, the leader device 400 transmits an R2D message for DO-A (R2D signaling for DO-A) at a timing in accordance with the setting information of step S301. The R2D message may be an R2D message with "All" set in the destination ID field and "Read" set in the command field, similar to the first operation pattern described above. In response to receiving the R2D message, the ambient IoT device 300 may read DO data from the memory 340 and transmit a D2R message including the read DO data to the leader device 400, similar to the first operation pattern described above.

[0163] Alternatively, if a service opportunity is set for each communication type, the reader device 400 may transmit an R2D message corresponding to the specified communication type to the ambient IoT device 300 in step S302.

[0164] In each of steps S303 and S304, the leader device 400 provides periodic DO-A opportunities to the ambient IoT device 300 in accordance with the setting information of step S301. Specifically, in each of steps S303 and S304, the leader device 400 transmits an R2D message for DO-A (R2D signaling for DO-A) at a timing in accordance with the setting information of step S301. In response to receiving the R2D message, the ambient IoT device 300 may read DO data from the memory 340 and transmit a D2R message including the read DO data to the leader device 400.

[0165] In step S305, the network 5 (CN20 or gNB200) transmits a service request message including interrupt information requesting or setting (notifying) interrupt execution of DT and / or DO-DTT to the leader device 400 (gNB200 or UE100). The leader device 400 receives the message. The interrupt information includes information specifying DT and / or DO-DTT. In the illustrated example, the interrupt information in step S305 includes information specifying DT. The interrupt information may further include information indicating the number of times interrupt execution of DT is requested.

[0166] In step S306, the leader device 400 executes the DT service requested or set (notified) in step S305 during the DO-A service opportunity. That is, the leader device 400 prioritizes the DT service over the DO-A service. Specifically, the leader device 400 transmits an R2D message for DT (R2D signaling for DT) at a timing according to the setting information in step S301. As with the first operation pattern described above, the R2D message may be an R2D message in which "Device ID," "Group ID," or "All" is set in the destination ID field and "Write" is set in the command field. If the interrupt information in step S305 includes information indicating the number of times DT interrupt execution is requested, the leader device 400 may perform DT interrupt processing the specified number of times.

[0167] In step S307, the leader device 400 resumes providing periodic DO-A opportunities to the ambient IoT device 300 in accordance with the setting information of step S301. For example, the leader device 400 transmits an R2D message for DO-A (R2D signaling for DO-A) at a timing in accordance with the setting information of step S301. In response to receiving the R2D message, the ambient IoT device 300 may read DO data from the memory 340 and transmit a D2R message including the read DO data to the leader device 400, as in the first operation pattern described above.

[0168] In step S308, the network 5 (CN20 or gNB200) transmits a service request message including interrupt information requesting or setting (notifying) the interrupt execution of DO-DTT to the leader device 400 (gNB200 or UE100). The leader device 400 receives the message. The interrupt information includes information specifying DO-DTT. The interrupt information may further include information indicating the number of times that the interrupt execution of DO-DTT is requested. The interrupt information may further include the "Device ID" or "Group ID" that is the target of the DO-DTT.

[0169] In step S306, the leader device 400 executes the DO-DTT service requested or set (notified) in step S305 during the DO-A service opportunity. That is, the leader device 400 prioritizes the DO-DTT service over the DO-A service. Specifically, the leader device 400 transmits an R2D message for DO-DTT (R2D signaling for DO-DTT) at a timing according to the setting information in step S301. The R2D message may be an R2D message with "Device ID" or "Group ID" set in the destination ID field and "Read" set in the command field, as in the first operation pattern described above. If the interrupt information in step S305 includes information indicating the number of times that a DO-DTT interrupt execution is requested, the leader device 400 may execute the DO-DTT interrupt process the specified number of times.

[0170] In step S307, the leader device 400 resumes providing periodic DO-A opportunities to the ambient IoT device 300 in accordance with the setting information of step S301. For example, the leader device 400 transmits an R2D message for DO-A (R2D signaling for DO-A) at a timing in accordance with the setting information of step S301. In response to receiving the R2D message, the ambient IoT device 300 may read DO data from the memory 340 and transmit a D2R message including the read DO data to the leader device 400, as in the first operation pattern described above.

[0171] (3.4) Third Operation Pattern A third operation pattern of the mobile communication system 1 according to the embodiment will now be described. The third operation pattern may be based on the first and / or second operation patterns described above. The third operation pattern does not necessarily have to be based on the first and / or second operation patterns described above.

[0172] The ambient IoT device 300 is required to have reduced complexity, and therefore, it is assumed that HARQ and RLC AM (i.e., ARQ) are not supported for communication between the reader device 400 and the ambient IoT device 300, as described above.

[0173] However, it is assumed that an error detection process using a cyclic redundancy check (CRC), which is a type of error detection method, is performed in the PHY layer in communication between the reader device 400 and the ambient IoT device 300. Therefore, each of the reader device 400 and the ambient IoT device 300 can detect errors in received data (messages) by error detection process (for example, a cyclic redundancy code (CRC) check).

[0174] In the case of DT, it is preferable that the reader device 400 can determine whether the ambient IoT device 300 has successfully received the transmitted DT data (whether writing to the memory 340 has been completed). Therefore, in the case of DT, a delivery confirmation (ACK / NACK) from the ambient IoT device 300 may be required.

[0175] On the other hand, in the case of DO, in DO-DTT, the ambient IoT device 300 transmits the DO data stored in the memory 340 upon receiving a trigger from the leader device 400, and in DO-A, it is assumed that periodic DO transmission is performed as in the second operation pattern. Therefore, in DO, it is considered not essential for the ambient IoT device 300 to be able to determine whether the leader device 400 has successfully received the DO data. Therefore, in DO, it is considered that ACK / NACK from the leader device 400 is unnecessary. However, ignoring failures in DO data communication is not desirable from the perspective of communication reliability.

[0176] In the third operation pattern, an operation that can improve the reliability of DO data communication even when there is no mechanism for confirming delivery of DO data from the reader device 400 will be described.

[0177] 17 is a diagram illustrating an example of an operation according to the third operation pattern of the embodiment. First, an overview of the operation according to the third operation pattern will be described.

[0178] In the third operation pattern, the leader device 400 first transmits an R2D message to the ambient IoT device 300 to enable DO data transmission (step S401). Second, upon receiving DO data from the ambient IoT device 300 (step S402), the leader device 400 performs error detection processing on the received DO data (step S403). Third, upon detecting an error through the error detection processing, the leader device 400 retransmits the R2D message to the ambient IoT device 300 to enable DO data transmission (step S404).

[0179] The R2D messages in steps S401 and S404 may be messages (also referred to as "DO-DTT trigger messages") that trigger DO-DTT, which allows only a specific ambient IoT device 300 or a specific device group designated by the reader device 400 to transmit DO data. The DO-DTT trigger message may be an R2D message in which "Device ID" or "Group ID" is set in the destination ID field and "Read" is set in the command field, similar to the first operation pattern described above.

[0180] The R2D messages in steps S401 and S404 may be messages (also referred to as "DO-A transmission permission messages") that permit DO-A to transmit DO data to all ambient IoT devices 300. The DO-A transmission permission message may be an R2D message in which "All" is set in the destination ID field and "Read" is set in the command field, similar to the first operation pattern described above.

[0181] In this way, if the reader device 400 fails to receive the DO data, it transmits a DO-DTT trigger or a DO-A permission again to the ambient IoT device 300. This allows the reader device 400 to receive the DO data that it failed to receive again from the ambient IoT device 300. Therefore, even if there is no ACK / NACK mechanism from the reader device 400 for the DO data, it is possible to improve the reliability of DO data communication.

[0182] The reader device 400 (gNB200 or UE100) that performs such operations has a transmitter (transmitter 210 or transmitter 120) that transmits an R2D message to the ambient IoT device 300 to enable DO data transmission, and a control unit (control unit 230 or control unit 130) that performs error detection processing on the received DO data in response to receiving the DO data from the ambient IoT device 300. The transmitter (transmitter 210 or transmitter 120) retransmits the R2D message to the ambient IoT device 300 in response to an error being detected by the error detection processing.

[0183] Next, the operation according to the third operation pattern will be described in detail.

[0184] 17, in step S401, the reader device 400 transmits an R2D message that is a DO-DTT transmission trigger or a DO-A transmission permission to the ambient IoT device 300. The ambient IoT device 300 receives the R2D message.

[0185] In step S402, in response to receiving the R2D message in step S401, the ambient IoT device 300 reads the DO data from the memory 340 and transmits a D2R message including the read DO data to the reader device 400. Here, the ambient IoT device 300 includes a CRC bit for error detection in the D2R message. The reader device 400 receives the D2R message.

[0186] In step S403, the reader device 400 performs error detection processing (CRC check) using the CRC bits included in the received D2R message. If the reader device 400 determines that the D2R message has been received correctly (step S403: Yes), it ends this operation. On the other hand, if the reader device 400 detects an error in the D2R message (step S403: No), it proceeds to step S404. Note that this error detection processing may be performed in a physical layer (e.g., an ambient IoT PHY layer). The physical layer may notify a higher layer (e.g., an ambient IoT MAC layer and / or an application layer) of successful reception (no error detected) and / or unsuccessful reception (error detected). In response to this notification, the higher layer may proceed to step S404. The physical layer may also notify the higher layer of the type (status) of the unsuccessful reception.

[0187] In the above, the success or failure of reception due to the error detection process is notified, but in addition to this, the notification may also be made as to whether the reception power of the R2D message from the ambient IoT device 300 has been detected and / or whether the reception of the identifier (device ID, group ID) included in the R2D message has been successful. By notifying the type information, the upper layer can grasp whether the ambient IoT device 300 is within the communication range (i.e., whether communication is possible or not), and therefore can more appropriately determine whether to perform the process of S404.

[0188] In step S404, the leader device 400 transmits an R2D message, which is a DO-DTT transmission trigger or a DO-A transmission permission, to the ambient IoT device 300. That is, the leader device 400 retransmits the same R2D message as in step S401. The ambient IoT device 300 receives the R2D message.

[0189] In step S405, in response to receiving the R2D message in step S404, the ambient IoT device 300 reads the DO data from the memory 340 and transmits a D2R message including the read DO data to the leader device 400. That is, the ambient IoT device 300 performs the same process as in step S402 and transmits the same D2R message as in step S402 to the leader device 400. The leader device 400 receives the D2R message. Then, the process returns to step S403.

[0190] 17 , it is assumed that the reader device 400 detects an error in the D2R message by a CRC check. However, if a specific or any ambient IoT device 300 is not present within the communication range (communication area) of the reader device 400, it is also assumed that the reader device 400 cannot receive the D2R message itself from the specific or any ambient IoT device 300.

[0191] For example, the reader device 400 may start a timer when transmitting an R2D message that is a DO-DTT transmission trigger or a DO-A transmission permission, and if the reader device 400 cannot receive an R2D message from a specific or any ambient IoT device 300 specified in the R2D message while the timer is running (i.e., if the timer expires), the reader device 400 may determine that communication with the ambient IoT device 300 is not possible. The setting value of the timer (timer value) may be set in the reader device 400 from the network 5.

[0192] In this case, the reader device 400 may transmit a message to the network 5 to notify that communication with the ambient IoT device 300 is not possible. The message may include the ID of the ambient IoT device 300 ("Device ID" or "Group ID"). In this way, the reader device 400 transmits a notification (message) to the network 5 indicating that the ambient IoT device 300 is not present within the communication range of the reader device 400 in response to not receiving DO data from the ambient IoT device 300 within a predetermined time from the transmission of the R2D message for enabling DO data transmission. The notification may be sent to an upper layer (e.g., application layer) of the reader device 400. The upper layer may then transmit the notification to a server on the network 5.

[0193] 17 , if it is determined in step S402 that the D2R message has not been received, the reader device 400 is assumed to discard the D2R message. However, the reader device 400 may store the received DO data (D2R message) received from the ambient IoT device 300 in response to an error being detected in the error detection process (step S403: No). The reader device 400 may receive DO data (D2R message) retransmitted from the ambient IoT device 300 (step S405), and may perform a combination process (e.g., maximum ratio combining) of the received data and the stored data in response to an error being detected in the error detection process (step S403: No). This allows errors to be corrected in the combined DO data (D2R message).

[0194] For example, the reader device 400 may perform a combining process such as HARQ soft combining. If the reader device 400 detects a CRC check error in a received D2R message, the reader device 400 stores the message in a buffer. If the reader device 400 receives a retransmitted D2R message from the ambient IoT device 300, the reader device 400 performs the following process.

[0195] If the CRC check of the retransmitted D2R message is successful, the reader device 400 may provide the data to the upper layer and discard the message held in the buffer.

[0196] If a CRC check error is detected in the retransmitted D2R message, the message is combined with the message stored in the buffer and the CRC check is performed again.

[0197] The reader device 400 may perform a CRC check on a transport block basis.

[0198] (3.5) Fourth Operation Pattern A fourth operation pattern of the mobile communication system 1 according to the embodiment will be described. The fourth operation pattern may be based on any of the first to third operation patterns described above. The fourth operation pattern does not have to be based on any of the first to third operation patterns described above.

[0199] The third operation pattern described above is based on the assumption that there is no mechanism for acknowledging delivery (ACK / NACK) of DO data from the reader device 400. In contrast, the fourth operation pattern introduces an efficient mechanism for acknowledging delivery of DO data from the reader device 400.

[0200] For example, consider a case where a leader device 400 calls a plurality of ambient IoT devices 300 (Group) with an R2D message such as an initial trigger message, and the ambient IoT devices 300 access the leader device 400 using the Slotted ALOHA method. In the Slotted ALOHA method, transmission from the ambient IoT devices 300 to the leader device 400 is performed in units of time slots (also simply referred to as "slots").

[0201] In this case, if the ambient IoT device 300 does not receive an ACK / NACK from the leader device 400, even if the leader device 400 successfully receives the DO data from the ambient IoT device 300, it is likely that the ambient IoT device 300 will transmit the same DO data in response to the next R2D message (DO-DTT trigger / DO-A permission). As a result, there is a problem in that the probability of DO data transmission collisions between the ambient IoT devices 300 increases. If the ambient IoT device 300 successfully receives the DO data from the leader device 400, i.e., the ambient IoT device 300 that no longer needs to transmit DO data, refrains from DO transmission, the total number of transmitting ambient IoT devices decreases, and the probability of such collisions can be reduced.

[0202] In the third operation pattern, the reader device 400 first receives DO data (D2R messages) from one or more ambient IoT devices 300 in at least one of the multiple time slots. Second, the reader device 400 determines whether the DO data was successfully received for each time slot. Third, the reader device 400 transmits an R2D message (e.g., the next DO-DTT trigger or DO-A permission) that includes information (delivery confirmation information) indicating whether the DO data was successfully received for each time slot and enables retransmission of the DO data.

[0203] Thus, in the third operation pattern, the reader device 400 notifies the ambient IoT device 300 of the ACK / NACK for each slot of the previous (past) DO transmission at the next DO-DTT trigger or DO-A permission. The ambient IoT device 300 stores the slot in which it performed the DO transmission, and can determine whether it should perform a DO retransmission by checking the ACK / NACK for that slot.

[0204] However, it is desirable for the ambient IoT device 300 to be able to understand whether the R2D message (DO-DTT trigger or DO-A permission) from the reader device 400 instructs an initial transmission or a retransmission. Therefore, the R2D message for enabling DO data retransmission may include information indicating that DO data retransmission is to be triggered. Similarly, the R2D message for enabling DO data initial transmission may include information indicating that DO data initial transmission is to be triggered. The information for distinguishing between initial transmission and retransmission may be a flag, a toggle, or a counter. In this way, the reader device 400 notifies the ambient IoT device 300 of the identification information of initial transmission / retransmission in the DO-DTT trigger or DO-A permission (R2D message). Alternatively, an implicit notification may be used instead of such an explicit notification. For example, when the reader device 400 notifies ACK for all slots, the ambient IoT device 300 may regard it as a trigger for initial transmission that retransmission is not necessary, or when the reader device 400 notifies NACK for at least one slot, the ambient IoT device 300 may regard it as a trigger for retransmission that retransmission is necessary.

[0205] 18 is a diagram illustrating a first operation example according to a fourth operation pattern of an embodiment. In the illustrated example, one DO transmission opportunity (DO transmission period) is composed of three slots, but the number of slots is not limited to three, and may be two, four, or more. The time length of each slot may be a fixed length defined in advance by a standard. The time length of each slot may be variably set by an R2D message.

[0206] It is also assumed that there are at least five ambient IoT devices 300, "Device 1" to "Device 5," as the plurality of ambient IoT devices 300, but the number of ambient IoT devices 300 is not limited to this. It is assumed that synchronization is achieved between the reader device 400 and the ambient IoT devices 300 based on a synchronization signal transmitted by the reader device 400 and / or a training signal included in the R2D message.

[0207] As shown in FIG. 18 , in step S501, the reader device 400 transmits an R2D message (DO transmission trigger). The R2D message may have "Group ID" or "All" set in the destination ID field. The R2D message may also include information indicating the initial DO transmission (a flag, a toggle, or a counter). In the illustrated example, the R2D message further includes three fields "S1" to "3" corresponding to three slots "Slot S1" to "Slot S3." All three fields "S1" to "3" are set to "1," indicating transmission is permitted.

[0208] In steps S502 to S504, the ambient IoT devices 300 that received the R2D message (and that were specified in the destination ID field) transmit Slotted ALOHA-based D2R messages (DO data). Here, the ambient IoT devices 300 may randomly select one or more DO transmission slots from "Slot S1" to "Slot S3." In the illustrated example, "Device 1" performs a DO transmission (initial transmission) in "Slot S1," "Device 2" and "Device 3" perform a DO transmission (initial transmission) in "Slot S2," and "Device 2" performs a DO transmission (initial transmission) in "Slot S3." Here, each ambient IoT device 300 stores information (slot number) of the slot in which it performed its DO transmission. The reader device 400 attempts to receive a D2R message (DO data) for each slot, and determines whether reception has been successful or unsuccessful by checking the CRC of the received D2R message (DO data).

[0209] Here, a collision occurs between DO transmissions from "Device 2" and "Device 3" in "Slot S2", and therefore the leader device 400 fails to receive the D2R message (DO data) in "Slot S2".

[0210] In step S505, the reader device 400 transmits an R2D message (DO transmission trigger) at the next service opportunity. The R2D message may have "Group ID" or "All" set in the destination ID field. The R2D message may also include information indicating DO retransmission (a flag, a toggle, or a counter). In the illustrated example, the field "S1" is set to "1" corresponding to ACK, the field "S2" is set to "0" corresponding to NACK, and the field "S3" is set to "1" corresponding to ACK.

[0211] The ambient IoT devices 300 that received the R2D message (and that were specified in the destination ID field) check the ACK / NACK information corresponding to the slot that they used for the DO transmission (in the previous service opportunity). If the checked information is ACK, the ambient IoT device 300 does not perform DO transmission (retransmission) based on the R2D message (DO transmission trigger). On the other hand, if the checked information is NACK, the ambient IoT device 300 performs DO transmission (retransmission) based on the R2D message (DO transmission trigger).

[0212] In the illustrated example, "Device 1" performed DO transmission in "Slot S1" in step S502, and since an ACK has been notified for "Slot S1" in the R2D message in step S505, it determines not to perform DO transmission (retransmission) based on the R2D message (DO transmission trigger).

[0213] Furthermore, "Device 2," which performed DO transmission in "Slot S2" and "Slot S3" in step S503, is notified of a NACK for "Slot S2" in the R2D message in step S505, but since an ACK is notified for "Slot S3," it determines not to perform DO transmission (retransmission) based on the R2D message (DO transmission trigger).

[0214] Furthermore, "Device 3," which performed DO transmission in "Slot S2" in step S503, determines to perform DO transmission (retransmission) based on the R2D message (DO transmission trigger) because NACK has been notified for "Slot S2" in the R2D message in step S505.

[0215] In step S506, "Device 3" performs a DO transmission (retransmission) in "Slot S1." In step S507, "Device 4" performs a DO transmission (initial transmission) in "Slot S2." In step S508, "Device 5" performs a DO transmission (initial transmission) in "Slot S3." Here, each ambient IoT device 300 stores information about the slot (slot number) in which it performed a DO transmission. The leader device 400 attempts to receive a D2R message (DO data) for each slot and determines whether reception was successful or unsuccessful by checking the CRC of the received D2R message (DO data). In steps S506 to S508, no DO transmission collision occurs, so the leader device 400 successfully receives the D2R message (DO data) in each slot.

[0216] In step S509, the reader device 400 transmits an R2D message (DO transmission trigger). The R2D message may have "Group ID" or "All" set in the destination ID field. The R2D message may also include information indicating the initial DO transmission (a flag, a toggle, or a counter). In the illustrated example, all three fields "S1" to "3" are set to "1," indicating that transmission is possible.

[0217] In such an operation, the reader device 400 may include in the R2D message (DO transmission trigger) identification information (information for distinguishing between a first transmission and a retransmission) indicating whether the DO transmission is different (new) from the DO transmission up to the previous service opportunity.

[0218] The identification information may be flag information, for example, where "1" indicates that a new DO transmission is being triggered, and "0" indicates that a retransmission DO transmission is being triggered.

[0219] The identification information may be toggle information. In the case of a new DO transmission, the information toggles between "0" and "1." That is, if the previous value was "0," the reader device 400 sets "1" to indicate a new DO transmission, and if the previous value was "1," the reader device 400 sets "0" to indicate a new DO transmission. The ambient IoT device 300 recognizes a new DO trigger when the value is different from the previous value.

[0220] The identification information may implicitly indicate a new DO trigger when the ACK / NACK information for each slot is all ACK. The identification information may implicitly indicate a retransmission DO trigger when one or more NACKs are present. The ambient IoT device 300 recognizes whether the DO transmission trigger is a new DO transmission trigger or a retransmission DO transmission trigger based on such criteria.

[0221] In the case of a new DO trigger, the ambient IoT device 300 performs a DO transmission in response to the reception of the R2D message based on the identification information in the received R2D message. On the other hand, in the case of a retransmission DO trigger, the ambient IoT device 300 performs a DO transmission (in the case of NACK) or does not perform a DO transmission (in the case of ACK) based on the ACK / NACK information of the slot of its own DO transmission in the previous service opportunity.

[0222] FIG. 19 is a diagram illustrating a second operation example according to the fourth operation pattern of the embodiment. In the first operation example, it is assumed that each ambient IoT device 300 performs DO transmission at one frequency (Freq F1). In contrast, in the second operation example, each ambient IoT device 300 is capable of performing DO transmission at multiple frequencies. While FIG. 19 illustrates two frequencies (Freq F1 and Freq F2) as multiple frequencies, three or more frequencies may be used. Each ambient IoT device 300 may randomly select a DO transmission frequency from among the multiple frequencies. Each frequency available for DO transmission may be a fixed frequency defined in advance by a standard. Alternatively, each frequency available for DO transmission may be variably set by an R2D message.

[0223] In the fourth operation pattern, the reader device 400 receives DO data at at least one frequency among the multiple frequencies in each time slot, determines whether the DO data reception was successful for each frequency in each time slot, and transmits an R2D message (DO transmission trigger) including information (ACK / NACK information) indicating whether the data reception was successful for each frequency in each time slot.

[0224] As shown in FIG. 19 , the operation in Freq F1 is the same as that in the first operation example ( FIG. 3 ). In Freq F2, the operation is performed according to the same principle as that of the first operation example. However, each ambient IoT device 300 not only stores information about the slot (slot number) in which it performed the DO transmission, but also stores information about the frequency (frequency number) in which it performed the DO transmission. In the case of a retransmission DO trigger, the ambient IoT device 300 performs a DO transmission (in the case of NACK) or does not perform a DO transmission (in the case of ACK) based on the ACK / NACK information of the slot and frequency of its own DO transmission in the previous service opportunity.

[0225] (4) Other Embodiments In the above-described embodiment, the value of the destination ID field (i.e., the type such as "Device ID," "Group ID," or "All") is implicitly specified, but this is not limited thereto. An indicator specifying the value to be set in the destination ID field may further be included. For example, if the indicator is 2 bits, "00" may indicate that the destination is "All," "01" may indicate that the value of the destination ID field is "Device ID," and "10" may indicate that the value of the destination ID field is "Group ID." Note that the mapping between the indicator and the value of the destination field is not limited thereto (for example, "11" may indicate "All"). The reader device 400 may include the indicator in the R2D message. The ambient IoT device 300 may identify the ID type set in the destination ID field from the indicator included in the R2D message.

[0226] The above-described operational flows are not limited to being implemented independently, but can be implemented by combining two or more operational flows. For example, some steps of one operational flow may be added to another operational flow, or some steps of one operational flow may be replaced with some steps of another operational flow. In each flow, it is not necessary to execute all steps, and only some steps may be executed. Furthermore, the order of steps in each flow may be changed as appropriate.

[0227] In the above-described embodiments and examples, an example in which the base station is an NR base station (gNB) has been described, but the base station may be an LTE base station (eNB) or a 6G base station. 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 the IAB node. The UE 100 may also be an MT (Mobile Termination) of the IAB node. That is, the UE 100 may be a terminal function unit (a type of communication module) for the base station to control a relay that relays signals. Such a terminal function unit is referred to as an MT. Examples of MTs include, in addition to IAB-MT, NCR (Network Controlled Repeater)-MT and RIS (Reconfigurable Intelligent Surface)-MT.

[0228] 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). A network node may also be configured by a combination of at least a part of a core network device and at least a part of a base station.

[0229] A program that causes a computer to execute each process performed by the UE 100 or the gNB 200 may be provided. The program may be recorded on a computer-readable medium. Using a computer-readable medium, the program can be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM and / or a DVD-ROM. Furthermore, circuits that execute each process performed by the UE 100 or the gNB 200 may be integrated, and at least a portion of the UE 100 or the gNB 200 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).

[0230] The functions performed by the above-described communication device (such as the UE 100 or the gNB 200) may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), a CPU (Central Processing Unit), conventional circuits, and / or combinations thereof, programmed to perform the described functions. A processor includes transistors and / or other circuits and is considered to be circuitry or processing circuitry. A processor may be a programmed processor that executes a program stored in a memory. In this specification, a circuitry, unit, or means is hardware that is programmed to realize or executes a described function. The hardware may be any hardware disclosed herein or any hardware known to be programmed to realize or execute the described function. If the hardware is a processor, which is considered to be a type of circuitry, the circuitry, means, or unit is a combination of hardware and software used to configure the hardware and / or processor.

[0231] As used in this disclosure, the terms "based on" and "depending on / in response to" do not mean "based only on" or "depending only on," unless expressly stated otherwise. The term "based on" means both "based only on" and "based at least in part on." Similarly, the term "depending on" means both "depending only on" and "depending at least in part on." The terms "include," "comprise," and variations thereof do not mean including only the listed items, but may mean including only the listed items or may include additional items in addition to the listed items. Additionally, the term "or," as used in this disclosure, is not intended to mean an exclusive or. Furthermore, 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 method of distinguishing between two or more elements. Thus, a reference to a first and a second element does not imply that only two elements may be employed therein or that the first element must precede the second element in some way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall include the plural unless the context clearly indicates otherwise.

[0232] The above describes the embodiments in detail with reference to the drawings, but the specific configuration is not limited to that described above, and various design changes can be made within the scope that does not deviate from the gist of the invention.

[0233] This application claims priority from Japanese Patent Application No. 2024-076697 (filed May 9, 2024), the entire contents of which are incorporated herein by reference.

[0234] (5) Supplementary Notes The following are additional notes regarding the features of the above-described embodiment.

[0235] Supplementary Note 1 A communication method comprising: a leader device which is a network node or user equipment in a mobile communication system, transmitting a Reader-to-Device (R2D) message to an ambient Internet of Things (IoT) device to enable Device-Originated (DO) data transmission; the leader device, in response to receiving the DO data from the ambient IoT device, performing an error detection process on the received DO data; and the leader device, in response to detecting an error in the error detection process, retransmitting the R2D message to the ambient IoT device.

[0236] Supplementary Note 2: The R2D message is a message that triggers a Device-Originated Device-Terminated Trigger (DO-DTT) that allows only a specific ambient IoT device or a specific device group designated by the reader device to transmit DO data. The communication method described in Supplementary Note 1.

[0237] Supplementary Note 3: The communication method according to Supplementary Note 1, wherein the R2D message is a message that permits Device-Originated-Autonomous (DO-A), which enables all ambient IoT devices to transmit DO data.

[0238] Supplementary Note 4: The communication method according to any one of Supplementary Notes 1 to 3, further comprising: transmitting, to a network of the mobile communication system, a notification indicating that the ambient IoT device is not present within a communication range of the reader device, in response to the reader device not receiving DO data from the ambient IoT device within a predetermined time from the transmission of the R2D message.

[0239] Supplementary Note 5: The communication method according to any one of Supplementary Notes 1 to 4, further comprising: the reader device storing the received data in response to an error being detected in the DO data by the error detection process; and the reader device receiving retransmitted DO data from the ambient IoT device, and in response to an error being detected in the received data by the error detection process, performing a synthesis process of the received data and the stored data.

[0240] Supplementary Note 6 A communication method comprising: a reader device which is a network node or user equipment in a mobile communication system receives Device-Originated (DO) data from one or more ambient Internet of Things (IoT) devices in at least one time slot out of a plurality of time slots; the reader device determines whether the DO data has been received for each time slot; and the reader device transmits a Reader-to-Device (R2D) message including information indicating whether the DO data has been received for each time slot, for enabling retransmission of the DO data.

[0241] Supplementary Note 7: The communication method according to Supplementary Note 6, wherein the reader device receives the DO data at at least one frequency among a plurality of frequencies in each of the time slots, and determines whether the DO data has been received for each frequency in each of the time slots, and the R2D message includes information indicating whether the DO data has been received for each of the frequencies in each of the time slots.

[0242] Supplementary Note 8: The communication method according to Supplementary Note 6 or 7, wherein the R2D message includes information indicating that a retransmission of the DO data is to be triggered.

[0243] 1: Mobile communication system 5: Network 10: RAN 20: CN 100: UE 110: Receiver 120: Transmitter 130: Controller 140: Wireless communication unit 200: gNB 210: Transmitter 220: Receiver 230: Controller 240: Network communication unit 241: Transmitter 242: Receiver 250: Wireless communication unit 300: Ambient IoT device 310: Antenna 320: Modulator 330: Controller 340: Memory 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 400: Reader device

Claims

1. A communication method comprising: a leader device, which is a network node or user equipment in a mobile communication system, transmitting a Reader-to-Device (R2D) message to an ambient Internet of Things (IoT) device to enable Device-Originated (DO) data transmission; the leader device, in response to receiving the DO data from the ambient IoT device, performing an error detection process on the received DO data; and the leader device, in response to detecting an error in the error detection process, resending the R2D message to the ambient IoT device.

2. The communication method according to claim 1, wherein the R2D message is a message that triggers a Device-Originated Device-Terminated Trigger (DO-DTT), which allows only a specific ambient IoT device or a specific device group designated by the reader device to transmit DO data.

3. The communication method according to claim 1, wherein the R2D message is a message that permits Device-Originated-Autonomous (DO-A), which allows all ambient IoT devices to transmit DO data.

4. The communication method according to any one of claims 1 to 3, further comprising the step of: in response to the reader device not receiving DO data from the ambient IoT device within a predetermined time from the transmission of the R2D message, transmitting a notification to the network of the mobile communication system indicating that the ambient IoT device is not present within the communication range of the reader device.

5. The communication method according to any one of claims 1 to 3, further comprising: the reader device storing the received data in response to an error being detected in the DO data by the error detection process; and the reader device receiving retransmitted DO data from the ambient IoT device and performing a synthesis process of the received data with the stored data in response to an error being detected in the received data by the error detection process.

6. A communication method comprising: a reader device, which is a network node or user equipment in a mobile communication system, receiving Device-Originated (DO) data from one or more ambient Internet of Things (IoT) devices in at least one of a plurality of time slots; the reader device determining whether the DO data was successfully received for each time slot; and the reader device transmitting a Reader-to-Device (R2D) message including information indicating whether the DO data was successfully received for each time slot, to enable retransmission of the DO data.

7. The communication method according to claim 6, wherein the reader device receives the DO data at at least one frequency among a plurality of frequencies in each of the time slots, determines whether the DO data has been received successfully for each frequency in each of the time slots, and the R2D message includes information indicating whether the DO data has been received successfully for each frequency in each of the time slots.

8. The communication method according to claim 6 or 7, wherein the R2D message includes information indicating that a retransmission of the DO data is to be triggered.

Images