Communication method, ambient IoT device, and user device

Abstract

A communication method according to one aspect of the present invention is used by a mobile communication system. The communication method includes a step in which either a reader device or an ambient Internet of Things (IoT) device uses a communication quality reference value, which indicates the number of retransmissions and / or the delay time, to perform Quality of Service (QoS) control with respect to communication between the reader device and the ambient IoT device. The reader device is a network node or a user device in the mobile communication system.

Description

Communication method, ambient IoT device, and user equipment

[0001] The present disclosure relates to a communication method, an ambient IoT device, and a user equipment.

[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] A communication method according to a first aspect is a communication method used in a mobile communication system. The communication method includes a step in which either a reader device or an ambient Internet of Things (IoT) device performs Quality of Service (QoS) control for communication between the reader device and the ambient IoT device using a communication quality reference value indicating at least one of a number of retransmissions and a delay time. The reader device is a network node or a user device in the mobile communication system.

[0010] An ambient IoT device according to a second aspect is an ambient IoT device in a mobile communication system, the ambient IoT device having a control unit that performs QoS control on communication between the ambient IoT device and a leader device that is a network node or user device of the mobile communication system, using a communication quality reference value indicating at least one of a number of retransmissions and a delay time.

[0011] A user device according to a third aspect is a user device in a mobile communication system, the user device including a control unit that performs QoS control on communication between the user device and the ambient IoT device using a communication quality reference value indicating at least one of a number of retransmissions and a delay time.

[0012] FIG. 1 is a diagram showing an example of the configuration of a mobile communication system according to the first embodiment. FIG. 2 is a diagram showing an example of the configuration of a UE (user equipment) according to the first embodiment. FIG. 3 is a diagram showing an example of the configuration of a network node (gNB) according to the first embodiment. FIG. 4 is a diagram showing an example of the configuration of a protocol stack according to the first embodiment. FIG. 5 is a diagram showing an example of the configuration of a protocol stack according to the first embodiment. FIG. 6 is a diagram showing an example of the configuration of an ambient IoT device according to the first embodiment. FIGS. 7(A) and 7(B) are diagrams showing an example of a topology of an ambient IoT device according to the first embodiment. FIG. 8 is a diagram showing an example of the configuration of an ambient IoT device according to the first embodiment. FIG. 9 is a diagram showing an example of the configuration of an ambient IoT device according to the first embodiment. FIG. 10 is a diagram showing an example of the configuration of a protocol stack for an ambient IoT device according to the first embodiment. FIG. 11 is a diagram showing an example of a basic procedure according to the first embodiment. FIG. 12 is a diagram showing an example of a basic procedure according to the first embodiment. FIG. 13 is a diagram showing an example of an operation according to the first embodiment. FIG. 14 is a diagram showing an example of the configuration of a mobile communication system according to the first embodiment. FIG. 15 is a diagram illustrating a first operation example according to the second embodiment. FIG. 16 is a diagram illustrating a second operation example according to the second embodiment. FIG. 17 is a diagram illustrating a third operation example according to the third embodiment. FIG. 18 is a diagram illustrating a Uu protocol stack (Topology 2) of the C-plane for network control. FIG. 19 is a diagram illustrating current assumptions regarding the protocol stack of the ambient IoT link. FIG. 20 is a diagram illustrating the overall protocol stack of Topology 2 with / without visibility of "service requests." FIG. 21 is a diagram illustrating an example of an AS reconfiguration model. FIG. 22 is a diagram illustrating the physical movement of a device from the coverage of leader A to the coverage of leader B.

[0013] The present disclosure aims to realize QoS control for communication between a reader device and an ambient IoT device with a simple configuration.

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

[0015] [First embodiment]

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

[0017] The mobile communication system 1 includes a network (NW) 10 and a user equipment (UE) 100. The UE 100 is a mobile communication device that performs wireless communication with the NW 10. The UE 100 may be any device used by a user, and may be, for example, a mobile phone terminal (including a smartphone) and / or a tablet terminal, a notebook PC (Personal Computer), a communication module (including a communication card or chipset), a sensor or a device 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).

[0018] The NW 10 includes a radio access network (RAN) 20 and a core network (CN) 30. When the mobile communication system is a 5th generation system (5GS), the RAN 20 is referred to as a Next Generation Radio Access Network (NG-RAN), and the CN 30 is referred to as a 5G Core Network (5GC).

[0019] The RAN 20 includes a plurality of network nodes 200 (network nodes 200a to 200c in the example of FIG. 1). The network nodes 200 are connected to each other via inter-network node interfaces. The network nodes 200 may be referred to as base stations in the RAN 20. When the network node 200 is a base station, the network node 200 may be configured (i.e., functionally divided) with a CU (Central Unit) and a DU (Distribution Unit), and the two units may be connected by a fronthaul interface. When the mobile communication system 1 is 5GS, the network node 200 is referred to as a gNB, the inter-network node interface is referred to as an Xn interface, and the fronthaul interface is referred to as an F1 interface.

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

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

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

[0023] 2 is a diagram illustrating an example of the configuration of a UE 100 (user equipment) according to the first 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 a network node 200.

[0024] The receiving unit 110 performs various reception operations 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.

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

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

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

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

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

[0030] The control unit 230 performs various controls and processes in the network node 200. Such processes include processes of each layer described below. The operations of the network node 200 described above and below may be operations under the control of the control unit 230. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used 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.

[0031] 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 CN device 380 via an NG interface, which is an interface between a base station and a core network. Note that the network node 200 may be configured (i.e., functionally divided) with a CU (Central Unit) and a DU (Distributed Unit), and both units may be connected via an F1 interface, which is a fronthaul interface.

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

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

[0034] 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 the UE 100 and the PHY layer of the network node 200 via a physical channel. The PHY layer of the UE 100 receives downlink control information (DCI) transmitted on a physical downlink control channel (PDCCH) from the network node 200. Specifically, the UE 100 performs blind decoding of the PDCCH using a radio network temporary identifier (RNTI) and acquires successfully decoded DCI as DCI addressed to the UE. The DCI transmitted from the network node 200 has a CRC (Cyclic Redundancy Code) parity bit scrambled by the RNTI added.

[0035] 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 network node 200 via a transport channel. The MAC layer of the network node 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.

[0036] The RLC layer transmits data to the RLC layer on the receiving side using the functions of the MAC layer and the PHY layer. Data and control information are transmitted between the RLC layer of the UE 100 and the RLC layer of the network node 200 via logical channels.

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

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

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

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

[0041] RRC signaling for various settings is transmitted between the RRC layer of the UE 100 and the RRC layer of the network node 200. The RRC layer controls logical channels, transport channels, and physical channels in accordance with the establishment, re-establishment, and release of radio bearers. When there is a connection (RRC connection) between the RRC of the UE 100 and the RRC of the network node 200, the UE 100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of the UE 100 and the RRC of the network node 200, the UE 100 is in an RRC idle state. When the connection between the RRC of the UE 100 and the RRC of the network node 200 is suspended, the UE 100 is in an RRC inactive state.

[0042] 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 the UE 100 and the NAS layer of the CN device 380 (AMF). Note that the UE 100 also has an application layer in addition to the radio interface protocol. The layer below the NAS layer is referred to as the AS layer (also simply referred to as "AS").

[0043] (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."

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

[0045] 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 network node 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 capable of reading information from or writing information to an internal memory using the backscattering communication function. In this case, the ambient IoT device 300 may receive transmitted radio waves on which information has been modulated and extract the information by demodulating the received radio waves.

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

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

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

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

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

[0051] 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 type of the identification information may be "Device ID," "Group ID," and / or "ALL." 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.

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

[0053] (2.2) Topology of Ambient IoT Device Fig. 7(A) and Fig. 7(B) are diagrams showing examples of the topology of the ambient IoT device 300. Fig. 7(A) shows an example of "Topology 1", and Fig. 7(B) shows an example of "Topology 2".

[0054] An apparatus that performs wireless communication with the ambient IoT device 300 is referred to as a reader apparatus (or "Reader") 400. As shown in FIG. 7A, in "Topology 1", the reader apparatus 400 is a network node 200 (gNB). The reader apparatus 400 may be a relay node, which is a type of network node. For example, the reader apparatus 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 are transferred between the ambient IoT device 300 and the network node 200.

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

[0056] 7(B), in "Topology 2", the reader device 400 is the UE 100. In this case, the UE 100 corresponds to an intermediate node between the ambient IoT device 300 and the network node 200. In "Topology 2", the ambient IoT device 300 performs bidirectional wireless communication with the UE 100. The reader device 400 transfers data related to the ambient IoT device 300 and / or signaling related to the ambient IoT device 300 between the network node 200 and the ambient IoT device 300.

[0057] In the example shown in FIG. 7B , the UE 100 performs wireless communication with the network node 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 (the receiver 110 and the transmitter 120) of the UE 100 can perform wireless communication with the ambient IoT device 300. For example, the receiver 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 receiver 110 may receive the received reflected wave as a wireless signal, convert it into a baseband signal, and output it to the control unit 130. The transmitter 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.

[0058] (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".

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

[0060] "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.

[0061] "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. Note that both device types have energy storage capabilities.

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

[0063] "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.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0077] FIG. 9 is a diagram illustrating an example of the configuration of an ambient IoT device 300 of the “device 2 a ” according to the first embodiment.

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

[0079] The LNA 365 amplifies the output signal from the RF BPF 354 (i.e., the signal from the reader device (network node 200 or UE 100)) to improve the signal strength and signal sensitivity at the receiving side.

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

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

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

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

[0084] (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 first embodiment.

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

[0086] The physical channel used for transmission from the reader device 400 to the ambient IoT device 300 (hereinafter, sometimes referred to as "R2D (Reader-to-Device) transmission") is called 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 a PRDCH. A message transmitted using the R2D channel is called an R2D message. The R2D message may be a message specified in "A-IoT MAC" or "New AS Protocol."

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

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

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

[0090] 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. In addition, the AS layer above the PHY layer does not support HARQ and RLC AM (Acknowledge Mode).

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

[0092] (3.1) Basic Procedures Fig. 11 is a diagram illustrating an example of basic procedures in the mobile communication system 1 according to the first embodiment. As shown in Fig. 11, one of the basic procedures is "Inventory only." "Inventory only" is used, for example, in a use case in which presence confirmation is performed on the ambient IoT device 300.

[0093] Furthermore, one of the basic procedures is “Command only.” “Command only” is used in a use case in which various commands, such as read, write, or kill, are issued to the ambient IoT device 300.

[0094] Furthermore, one of the basic procedures is “Inventory and Command.” “Inventory and Command” is used in a use case in which, for example, the presence of the ambient IoT device 300 is confirmed and various commands are issued to the ambient IoT device 300.

[0095] 11 , in either case, a paging message for ambient IoT (A-IoT paging message) similar to a conventional paging message is transmitted from the reader device 400 to the ambient IoT device 300 (step S1). The A-IoT paging message may be a message for initiating communication between the reader device 400 and the ambient IoT device 300. Alternatively, the A-IoT paging message may be a call message (or a trigger message) for calling (or triggering) the ambient IoT device 300.

[0096] First, the A-IoT paging message includes device identification information that identifies the ambient IoT device. The device identification information may be used to specify the ambient IoT device to be called. Types of device identification information include a "device ID" (individual identification information) that individually identifies each ambient IoT device 300. Types of device identification information include a "group ID" (group identification information) that identifies the group to which the ambient IoT device belongs. Types of device identification information include "ALL" (all identification information) that indicates all ambient IoT devices. However, if the A-IoT paging message does not include device identification information, it will represent "ALL".

[0097] Second, the A-IoT paging message includes resource information, which is used to transmit a D2R message from the ambient IoT device 300 to the reader device 400.

[0098] Third, the A-IoT paging message may be an initial trigger message. The initial trigger message is, for example, a message including an ambient IoT device that needs to respond to a service request. The service request is received by the leader device 400 from the network 5 (the network node 200 or the CN device 380). For example, the service request includes device identification information of the ambient IoT device 300. The leader device 400 uses the initial trigger message to make a call to the ambient IoT device 300 that has the device identification information.

[0099] In the case of "command only", the A-IoT paging message includes an R2D command. The R2D command allows the reader device 400 to issue various commands to the ambient IoT device 300.

[0100] Step B: In either case, the ambient IoT device 300 transmits its device ID (step S2). For example, the ambient IoT device 300 triggered by an A-IoT paging message transmits its own device ID in this step. The device ID transmission may be performed using a D2R message. The reader device 400 receives the device ID.

[0101] Here, the transmission of the device ID may be performed by an access method similar to random access (RA). This access method is hereinafter referred to as a random access procedure (or an access method using "random access"). In the random access procedure, contention resolution is performed to avoid contention in the transmission of D2R messages. Details of the random access procedure will be described later.

[0102] On the other hand, there are also cases where the device ID is transmitted using a contention-free access method without performing contention resolution. This access method is called a contention-free access procedure (or an access method using "contention-free access"). In the contention-free procedure, the random access procedure is not performed. Operation examples of the random access procedure and the contention-free procedure will be described later.

[0103] Step C1 and Step C2: Step C1 and Step C2 are not performed in the "inventory only" case, but are performed in the "inventory and command" and "command only" cases. In Step C1, the reader device 400 transmits R2D data (Step S3), and in Step C2, the ambient IoT device 300 transmits D2R data (Step S4). For example, the reader device 400 transmits an R2D command (Step C1), and the ambient IoT device 300 transmits feedback for the R2D command to the reader device 400 (Step C2).

[0104] In the case of "inventory and command," both "inventory" and "command" are not performed using a single A-IoT paging message, but rather "inventory" and "command" are performed using separate messages.

[0105] (3.2) Random Access and Contention-Free Access Figure 12 is a diagram showing examples of a random access procedure and a contention-free access procedure according to the first embodiment. Figure 12 shows the procedure performed in step B of Figure 11. As shown in Figure 12, there are two random access procedures: "four-step random access" and "two-step random access." Therefore, there are three access methods performed in step B of Figure 11: "four-step random access," "two-step random access," and "contention-free access." As shown in Figure 12, "four-step random access" is actually completed in three steps, so it may also be called "three-step random access."

[0106] Step 1: In all three procedures, first, the ambient IoT device 300 determines and / or selects a resource (or access opportunity) (step S10).

[0107] Step 2: Step 2 is executed in the case of a random access procedure, but is not executed in the case of a contention-free access procedure. In Step 2, contention resolution is performed.

[0108] In the case of "four-step random access," the ambient IoT device 300 transmits a random ID in message 1 (Msg1) (step S11). The random ID is random identification information generated by the ambient IoT device 300. Msg1 may be a D2R message.

[0109] The reader device 400 transmits the random ID received from the ambient IoT device 300 to the ambient IoT device 300 in a message 2 (Msg2) (step S12). Msg2 may be an R2D message.

[0110] If the random ID transmitted in Msg1 matches the random ID received in Msg2, the ambient IoT device 300 considers the contention resolution to be successful (OK) (step S13). In other words, since the ambient IoT device 300 was able to receive the random ID transmitted in Msg1 in Msg2, it can be determined that the resources used to transmit Msg1 do not conflict with the resources used to transmit Msg1 from other ambient IoT devices. On the other hand, if the two random IDs do not match, the ambient IoT device 300 considers the contention resolution to have failed. In this case, the ambient IoT device 300 cannot receive the random ID transmitted in Msg1 in Msg2, so it can determine that the resource used to transmit Msg1 conflicts with the resource used to transmit Msg1 from another ambient IoT device, and can regard the conflict resolution as having failed. Conflict resolution is also a procedure for determining whether or not the resource used to transmit the D2R message (specifically, Msg1) conflicts.

[0111] On the other hand, in the case of "two-step random access", the ambient IoT device 300 transmits the upper layer data to the reader device 400 using Msg1 (step S20). The upper layer data may include the device ID of the ambient IoT device 300.

[0112] The reader device 400 uses Msg2 to transmit some information (echo) to the ambient IoT device 300. Currently, 3GPP has not determined what information should be transmitted as the echo.

[0113] If the upper layer data transmitted in Msg1 (step S20) matches some information received in Msg2 (step S22), the ambient IoT device 300 determines that the conflict resolution is successful (step S23). If the upper layer data does not match some information, the ambient IoT device 300 determines that the conflict resolution is unsuccessful.

[0114] Step 3: In the case of a random access procedure, the ambient IoT device 300 that has successfully resolved the contention transmits upper layer data to the leader device 400 (steps S14 and S24). The upper layer data may include the device ID of the ambient IoT device 300. The upper layer data may be transmitted in a D2R message.

[0115] On the other hand, in the case of "contention-free access," the ambient IoT device 300 transmits upper layer data to the leader device 400 without performing a random access procedure (step S30).

[0116] In this way, D2R transmission performed after contention resolution can be considered to be a "random access procedure," and D2R transmission performed without contention resolution can be considered to be a "contention-free access procedure." Furthermore, regarding the "random access procedure," contention resolution using random identification information can be considered to be a "four-step random access procedure," and contention resolution using higher layer data can be considered to be a "two-step random access procedure."

[0117] (4) Communication Method According to First Embodiment Currently, 3GPP is discussing latency in the "inventory only" use case. The purpose is to define what latency is, to have a common understanding, and to use latency for evaluation.

[0118] Considering the discussions at 3GPP, it can be assumed that the latency until communication completion is one of the requirements for QoS (Quality of Service) control in the ambient IoT device 300. However, compared to other communications, communication with the ambient IoT device 300 has characteristics such as being realized with simple functions, the use of collision-based access as described above, and a generally unstable wireless environment. Considering these characteristics, it is desirable to realize QoS control with a simpler configuration or function than conventional methods. Furthermore, by performing error detection and the like on communications with the ambient IoT device 300, it becomes possible to appropriately execute QoS control.

[0119] Therefore, the first embodiment aims to realize QoS control for communication between the reader device 400 and the ambient IoT device 300 with a simple configuration.

[0120] Therefore, in the first embodiment, either the reader device (e.g., the reader device 400) or the ambient IoT device (e.g., the ambient IoT device 300) performs QoS (Quality of Service) control for communication between the reader device and the ambient IoT device using a communication quality reference value indicating at least one of the number of retransmissions and the delay time. The reader device is a network node (e.g., the network node 200) or a user device (e.g., the UE 100) of a mobile communication system (e.g., the mobile communication system 1).

[0121] In this way, in the first embodiment, QoS control is performed using a clear criterion, namely, a communication quality reference value that indicates at least one of the number of retransmissions and the delay time, so that QoS control can be achieved with a simple configuration for communication between the reader device 400 and the ambient IoT device 300.

[0122] A typical example of communication between the reader device 400 and the ambient IoT device 300 is, for example, as follows.

[0123] First, there is communication by the random access procedure described above. In communication by the random access procedure, for example, QoS control is performed by the ambient IoT device 300. For example, the ambient IoT device 300 can perform QoS control, specifically error determination, by determining whether or not the communication quality reference values ​​are satisfied for Msg1 and Msg2 used in the random access procedure.

[0124] Second, there is communication using a D2R message transmitted from the ambient IoT device 300 to the reader device. In the case of communication using a D2R message, QoS control may also be performed by the ambient IoT device 300. For example, the ambient IoT device 300 performs error determination by determining whether the D2R message satisfies a communication quality reference value.

[0125] Third, there is communication using an R2D message transmitted from the reader device 400 to the ambient IoT device 300. In this case, QoS control may be performed by the reader device 400. For example, the reader device 400 performs error determination by determining whether the R2D message satisfies a communication quality reference value.

[0126] In this way, the QoS control using the communication quality reference value may be performed by the ambient IoT device 300. The QoS control may be performed by the reader device 400. Below, an example of communication using a random access procedure, in which the ambient IoT device 300 performs error determination, will be described.

[0127] (Operation Example According to First Embodiment) FIG. 13 is a diagram illustrating an operation example according to the first embodiment.

[0128] As shown in FIG. 13, in step S40, the leader device 400 receives a service request from the network 10, the service request including at least one of service priority, data priority, QoS setting information, and communication quality reference value.

[0129] The service priority indicates the priority of each service. Specifically, the service priority indicates the priority used when a certain service is executed using the ambient IoT device 300. For example, in the case of a service using a contactless transportation IC card (such as Suica), the service priority may be set to high when used at a station and low when used at a convenience store.

[0130] The data priority indicates the priority of each piece of data. Specifically, the data priority indicates the transmission priority of data read by the reader device 400 (or transmitted by the ambient IoT device 300), or the transmission priority of data written to the ambient IoT device 300. For example, even for the same ambient IoT device 300, reading a "device ID" may be assigned a high data priority, and reading "data" may be assigned a low data priority. Alternatively, even for the same ambient IoT device 300, the data priority may differ depending on the memory area of ​​the memory 340 from which data is read (for example, a high-priority data area or a low-priority area).

[0131] The QoS setting information represents, for example, setting information related to QoS setting. The QoS setting information may include an index used for QoS. The index may include a packet error rate, a packet delay amount, and / or a maximum data amount. The QoS setting information may include a 5QI (5G QoS Identifier) ​​representing QoS characteristics.

[0132] The communication quality reference value may be indicated by the number of retransmissions of a procedure or transmission. The number of retransmissions may be expressed as an upper limit of the number of retransmissions. The communication quality reference value may also be indicated by a delay time of a procedure or transmission. The delay time may be expressed as an allowable delay time. The communication quality reference value may be indicated by the number of retransmissions and the delay time.

[0133] In the example illustrated in FIG. 13 , the reader device 400 receives the communication quality reference value from the network 10. However, the control unit of the reader device 400 (the control unit 130 of the UE 100 or the control unit 230 of the network node 200) may generate the communication quality reference value. For example, if the receiving unit of the reader device 400 (the receiving unit 110 of the UE 100 or the network communication unit 240 of the network node 200) receives at least one of the service priority, data priority, and QoS setting information but does not receive the communication quality reference value, the control unit of the reader device 400 may generate the communication quality reference value based on at least one of the service priority, data priority, and QoS setting information. The communication quality reference value may be associated with at least one of the service priority, data priority, and QoS setting information. In this case, the control unit may set the communication quality reference value to different values ​​depending on the service priority. For example, the control unit may set at least one of the number of retransmissions and the delay time to different values ​​when the service priority is high and when the service priority is low. This allows, for example, a different communication quality reference value to be set for each service, thereby enabling QoS control for each service. Similarly, in the case of data priority and QoS setting information, different communication quality reference values ​​may be set depending on the priority, or different communication quality reference values ​​may be set depending on the setting information included in the QoS setting information. The communication quality reference value may be applied to each ambient IoT device 300. This allows, for example, QoS control for each ambient IoT device 300.

[0134] The service request represents a message that the network 10 requests from the ambient IoT device 300. When the leader device 400 is the network node 200, the service request may be included in a message transmitted from the CN device 380 to the network node 200, for example, an NG-AP (Application Protocol) message. Alternatively, when the leader device 400 is the UE 100, the service request may be included in a message transmitted from the network node 200 to the UE 100, for example, an RRC message, or may be included in a message of a layer newly defined for the ambient IoT device 300. The service request may also be received from an upper layer (for example, an application layer). The upper layer may be present in the leader device 400. That is, the radio protocol unit of the leader device 400 may receive the service request from its own application layer.

[0135] In step S41, the transmitter of the reader device 400 (the transmitter 120 of the UE 100 or the transmitter 210 of the network node 200) transmits an A-IoT paging message including at least one of service priority, data priority, QoS setting information, and a communication quality reference value. The transmitter of the reader device 400 may transmit an R2D message including at least one of service priority, data priority, QoS setting information, and a communication quality reference value. The R2D message may include a control bit, and at least one of service priority, data priority, QoS setting information, and a communication quality reference value may be included in the control bit. The R2D message may be used as a pre-configured message. The ambient IoT device 300 receives the A-IoT paging message.

[0136] In step S42, in response to receiving the A-IoT paging message, the control unit 330 of the ambient IoT device 300 sets a communication quality reference value and starts a random access (RA) procedure.

[0137] First, when the communication quality reference value is not included in the A-IoT paging message, the control unit 330 of the ambient IoT device 300 may generate the communication quality reference value based on at least one of the service priority, the data priority, and the QoS setting information included in the A-IoT paging message. When the control unit 330 receives the communication quality reference value from the reader device 400, the control unit 330 may use the communication quality reference value as is.

[0138] Second, when the control unit 330 of the ambient IoT device 300 starts the RA procedure, it performs the following process. That is, the control unit 330 resets the retransmission counter N. The control unit 330 also starts counting (e.g., counting down) the allowable delay time timer. The allowable delay time timer represents a timer corresponding to the allowable delay time of the communication quality reference value.

[0139] In step S43, the control unit 330 of the ambient IoT device 300 transmits Msg1 in the RA procedure. The control unit 330 may transmit Msg1 including a randomly generated random ID ("four-step random access procedure"), or the control unit 330 may transmit Msg1 including upper layer data ("two-step random access procedure"). The receiving unit of the reader device 400 receives Msg1.

[0140] In step S44, the transmitter of the reader device 400 transmits Msg 2 in response to receiving Msg 1. The transmitter of the reader device 400 may transmit Msg 2 including the random ID received in Msg 1 as echo information (a "four-step random access procedure"), or may transmit Msg 2 including some other information as echo information (a "two-step random access procedure").

[0141] In step S45, the control unit 330 of the ambient IoT device 300 performs an error determination. The error determination is performed, for example, as follows.

[0142] That is, if the control unit 330 fails to receive Msg2, if it receives Msg2 but the echo information included in Msg2 does not match the information included in Msg1, or if it receives Msg2 indicating a NACK, it increments the retransmission counter N and retransmits Msg1 (step S43). Thereafter, the control unit 330 increments the retransmission counter N each time it retransmits Msg1. If the retransmission counter N exceeds the upper limit of the number of retransmissions indicated as the communication quality reference value (or if the retransmission counter N reaches the upper limit), or if the allowable delay time timer expires (for example, if it counts down to "0"), the control unit 330 determines that the RA procedure (or the transmission of Msg1) is in error (Yes in step S45). That is, if the communication quality reference value is not satisfied, the control unit 330 determines that the RA procedure (or the transmission of Msg1) is in error.

[0143] On the other hand, when the control unit 330 receives Msg2 and the echo information included in Msg2 matches the information included in Msg1, it determines that no error occurred in the RA procedure (or in the transmission of Msg1) (No in step S45). In this case, the control unit 330 may determine that the communication quality reference value is satisfied.

[0144] If it is determined that there is an error (Yes in step S45), the process proceeds to step S46. On the other hand, if it is determined that there is no error (No in step S45), the process proceeds to step S47.

[0145] In step S46, the control unit 330 of the ambient IoT device 300 stops (or ends) the RA procedure. The control unit 330 may stop (or end) the transmission of Msg1. In this way, the ambient IoT device 300 performs an error determination based on the communication quality reference value (step S45), and if the communication quality reference value is not satisfied (Yes in step S45), stops (communication by) the random access procedure (step S46). In this case, the control unit 330 may transmit a communication error to the reader device 400.

[0146] In step S47, the control unit 330 of the ambient IoT device 300 determines whether to resolve the conflict in the random access procedure. Step S47 is processing corresponding to step S13 or step S23 shown in FIG.

[0147] (Another operation example 1 according to the first embodiment) In the first embodiment, the RA procedure has been described as an example, but it is also possible to perform error determination (i.e., QoS control) by applying a communication quality reference value to a D2R message from the ambient IoT device 300.

[0148] For example, this is applicable to a sequence in which the ambient IoT device 300 transmits a D2R message and the reader device 400 returns a response message in response to the D2R message. For example, the following processing may be performed.

[0149] That is, when the control unit 330 of the ambient IoT device 300 transmits a D2R message to the reader device 400, it resets the retransmission counter N and starts counting the allowable delay time timer. When the ambient IoT device 300 retransmits the D2R message because it is unable to (successfully) receive a response message to the D2R message, it increments the retransmission counter N. Thereafter, the control unit 330 repeats this process, and when the retransmission counter N exceeds the upper limit of the number of retransmissions indicated as the communication quality reference value (or the retransmission counter N reaches the upper limit of the number of retransmissions), or when the allowable delay time timer expires, it determines that a transmission error has occurred in the D2R message and stops transmitting the D2R message. The control unit 330 may also transmit a communication error to the reader device 400. This is an example in which the control unit 330 of the ambient IoT device 300 performs the error determination.

[0150] (Another Operation Example 2 According to First Embodiment) It is also possible to perform error determination by applying the communication quality reference value to an R2D message transmitted from the reader device 400 .

[0151] For example, in all use cases including "inventory only," the transmission of an A-IoT paging message (Step A in FIG. 11) is followed by the transmission of a device ID (Step B) or upper layer data (Step 3 in FIG. 12). By regarding the A-IoT paging message as an R2D message and the transmission of the device ID as a response message to the R2D message, the R2D message and the response message can be considered as one sequence.

[0152] Then, when the control unit of the reader device 400 transmits the A-IoT paging message, it resets the retransmission counter N and starts counting the allowable delay time timer. When the control unit of the reader device 400 retransmits the A-IoT paging message because it is unable to properly receive the device ID (or upper layer data), it increments the retransmission counter N. Thereafter, the control unit repeats this process, and when the retransmission counter N exceeds the upper limit of the number of retransmissions indicated as the communication quality reference value (or the retransmission counter N reaches the upper limit of the number of retransmissions), or when the allowable delay time timer expires, it may determine that there is an R2D message transmission error and stop transmitting the R2D message. The control unit may transmit a communication error to the ambient IoT device 300. In this case, the control unit of the reader device 400 performs the error determination.

[0153] Second Embodiment Next, a second embodiment will be described, focusing on the differences from the first embodiment.

[0154] In the second embodiment, the explanation will be given focusing on the retransmission explained in the first embodiment.

[0155] In 3GPP, it is agreed that with regard to retransmission between the ambient IoT device 300 and the reader device 400, retransmission (retransmission / repetition) like RLC is not supported in upper layers above the PHY layer. On the other hand, it is also agreed that it is not excluded for the upper layer to transmit data that has failed to be transmitted as new data. In other words, it is possible for the upper layer to retransmit data that has failed to be transmitted as new data.

[0156] Here, it is assumed that the leader device 400 determines retransmission. In such a case, when the leader device is the network node 200 (i.e., topology 1), the network node 200 has a function as a leader device as well as a radio resource control function, and therefore, even if the network node 200 itself determines retransmission, it is possible to execute retransmission.

[0157] On the other hand, when the leader device is UE 100 (i.e., topology 2), although UE 100 has the function as a leader device, UE 100 does not have a radio resource control function, and the radio resource control function exists in network node 200. Therefore, even if UE 100 determines to perform retransmission, it may not be able to allocate radio resources to be used for communication with ambient IoT device 300 and may not be able to perform retransmission. On the other hand, in the case of topology 2, since network node 200 does not have the leader function, it may not be able to directly communicate with ambient IoT device 300 and may not be able to perform retransmission.

[0158] Therefore, the second embodiment aims to enable the UE 100 to appropriately perform retransmission to the ambient IoT device 300.

[0159] Therefore, in the second embodiment, the UE 100 performs R2D transmission to the ambient IoT device 300, and when the ambient IoT device 300 fails to receive the data transmitted by the R2D transmission, the UE 100 transmits failure information to the network node 200. In response to receiving the failure information, the network node 200 determines to retransmit the R2D transmission and instructs the UE 100 to retransmit the R2D transmission.

[0160] Specifically, first, a user equipment (e.g., UE 100) performs an R2D transmission to an ambient IoT device (e.g., ambient IoT device 300). Second, the user equipment receives failure information from the ambient IoT device. Third, the user equipment transmits the failure information to a network node (e.g., network node 200). Fourth, the user equipment receives a retransmission instruction for the R2D transmission from the network node. Here, the failure information is information indicating that the ambient IoT device has either failed to receive data transmitted in the R2D transmission or failed to execute a command.

[0161] In this way, for example, the UE 100 can receive a retransmission instruction from the network node 200, and can appropriately retransmit the R2D transmission by following the retransmission instruction. In particular, when resource information is included in the retransmission instruction, the UE 100 can also perform the R2D retransmission using the resource indicated by the resource information, and can therefore appropriately retransmit the R2D transmission.

[0162] (Example of Operation According to Second Embodiment) Next, an example of operation according to the second embodiment will be described.

[0163] The second embodiment is premised on topology 2. Fig. 14 is a diagram showing a configuration example of a mobile communication system 1 based on topology 2 according to the second embodiment. As shown in Fig. 14 , a UE 100 is interposed between a network node 200 and an ambient IoT device 300 as an intermediate node (specifically, a leader device 400). The UE 100 can communicate with the network node 200 and also with the ambient IoT device 300. An operation example according to the second embodiment will be described based on the configuration example shown in Fig. 14 .

[0164] Note that the operation examples according to the second embodiment include an operation example in which retransmission is determined in the network node 200 and an operation example in which retransmission is determined in the UE 100. The former will be described below as a first operation example, and the latter as a second operation example.

[0165] (First Operation Example According to Second Embodiment) The first operation example is an operation example in which the network node 200 determines retransmission.

[0166] 15 is a diagram illustrating a first operation example according to the second embodiment. It is assumed that the UE 100 is in an RRC connected state with the network node 200.

[0167] 15, in step S50, the transmitter 120 of the UE 100 transmits an A-IoT paging message. The controller 330 of the ambient IoT device 300 receives the A-IoT paging message.

[0168] In step S51, the control unit 330 of the ambient IoT device 300 starts a procedure using random access (which may be "four-step random access" or "two-step random access") or contention-free access, triggered by receiving an A-IoT paging message.

[0169] In step S52, the transmitter 120 of the UE 100 performs R2D data transmission. The data transmitted in the R2D data transmission (hereinafter, sometimes referred to as "R2D data") may include a command (R2D command) that the UE 100 instructs the ambient IoT device 300. Alternatively, the R2D data may be the command. The ambient IoT device 300 may fail to receive the R2D data transmitted in the R2D transmission. Alternatively, the ambient IoT device 300 may successfully receive the R2D data but fail to execute the processing instructed by the command. For example, in the case of a command instructing data writing to memory, the ambient IoT device 300 may fail to write the data.

[0170] In step S53, the control unit 330 of the ambient IoT device 300 transmits failure information to the UE 100. The failure information may indicate that the ambient IoT device 300 failed to receive data transmitted by R2D transmission. Alternatively, the failure information may indicate that the ambient IoT device 300 failed to execute a process instructed by a command. The failure information may be transmitted as a NACK (Negative Acknowledgement). Alternatively, the failure information may be transmitted as feedback information (or included in the feedback information) in response to a command from the UE 100. The UE 100 may recognize that the R2D data transmission has failed by receiving the failure information. Note that the UE 100 may recognize that the R2D data transmission has failed in response to the fact that the UE 100 has not received a response signal (or a response message) in response to the R2D data transmission even after a predetermined time has elapsed since the UE 100 performed the R2D data transmission in step S52 without receiving the failure information.

[0171] In the second embodiment, the retransmission is performed in a layer higher than the PHY layer. Therefore, the failure information in step S53 may also be transmitted from the upper layer of the ambient IoT device 300 to the upper layer of the UE 100. The receiving unit 110 of the UE 100 receives the failure information.

[0172] In step S54, the transmitter 120 of the UE 100 transmits failure information to the network node 200. The transmitter 120 of the UE 100 may transmit the failure information received in step S53 to the network node 200 as is. The failure information may include an identifier (device ID) of the ambient IoT device 300. The failure information may be transmitted using an RRC message. The failure information may be transmitted using a MAC Control Element (MAC CE). Alternatively, the failure information may be transmitted using a message of a new layer newly defined for the ambient IoT device 300. The receiver 220 of the network node 200 receives the failure information.

[0173] In step S55, the control unit 230 of the network node 200 determines to retransmit the R2D data transmission based on the failure information. However, the control unit 230 may determine not to perform the retransmission when a best-effort service is provided in the communication between the UE 100 and the ambient IoT device 300.

[0174] In step S56, the transmission unit 210 of the network node 200 transmits a data retransmission instruction to the UE 100 in response to the decision to retransmit the R2D data transmission in step S55.

[0175] First, the data retransmission instruction may include resource information indicating resources for the UE 100 to perform retransmission to the ambient IoT device 300. The resources may be resources for R2D communication and / or resources for D2R communication.

[0176] Second, the data retransmission instruction may include data (payload) to be retransmitted. This is effective when the UE 100 has not buffered the data for retransmission in memory. The failure information of step S54 may include information indicating that the UE 100 has not buffered the data for retransmission, and the transmitter 210 may transmit a data retransmission instruction including the data based on the information.

[0177] Third, the data retransmission instruction may include an identifier (device ID) of the ambient IoT device 300. The identifier is used by the UE 100 to identify the ambient IoT device 300 that performs the data retransmission. For example, the UE 100 may include the identifier in the failure information (step S54) and transmit it, or the network node 200 may include the identifier in the data retransmission instruction and transmit it.

[0178] Fourth, the data retransmission instruction may also be sent using an RRC message, a MAC CE, or a new message for the ambient IoT device 300.

[0179] The receiving unit 110 of the UE 100 receives the data retransmission instruction.

[0180] In step S57, in response to receiving the data retransmission instruction, the transmitter 120 of the UE 100 transmits the R2D data (step S52) that the ambient IoT device 300 failed to receive as new data. Step S57 may be a transmission of new data in terms of procedure, or may be a retransmission of the R2D data (step S52) that the ambient IoT device 300 failed to receive. The RRC layer of the UE 100 may output a data retransmission instruction to the A-IoT MAC layer (FIG. 10) (or a layer higher than the A-IoT MAC, such as the AS layer). Alternatively, the RRC layer of the UE 100 may output a data transmission instruction to a higher layer (such as the NAS layer, a newly defined A-IoT control layer, or an entity representing a reader device), and the higher layer may output a data transmission instruction to the A-IoT MAC layer (or a layer higher than the A-IoT MAC). Data retransmission may be performed in the A-IoT MAC layer. As described above, in the second embodiment, retransmission is performed in a layer higher than the PHY layer. Therefore, the transmission of new data (i.e., retransmission) in step S57 is also performed in the higher layer.

[0181] (Second operation example according to second embodiment) Next, a second operation example will be described. The second operation example is an example in which the UE 100 decides to perform retransmission. When the UE 100 decides to perform retransmission, the UE 100 requests resources to be used for retransmission from the network node 200, and receives allocation of the resources from the network node 200. The UE 100 performs retransmission to the ambient IoT device 300 using the resources.

[0182] Specifically, first, a user equipment (e.g., UE 100) performs R2D data transmission to an ambient IoT device (e.g., ambient IoT device 300). Second, the user equipment receives failure information from the ambient IoT device. Third, the user equipment determines retransmission to the ambient IoT device in response to receiving the failure information. Fourth, the user equipment transmits request information indicating a resource request to a network node. Fifth, the user equipment receives resource information indicating the resource from the network node.

[0183] In this way, even when the UE 100 decides to retransmit data, the UE 100 transmits request information indicating a resource request to the network node 200 and receives resource information indicating the resources from the network node 200. Therefore, the UE 100 can appropriately perform retransmission to the ambient IoT 300 by using the resources.

[0184] 16 is a diagram illustrating a second operation example according to the second embodiment. The second operation example will be described focusing on differences from the first operation example.

[0185] In FIG. 16, steps S60 to S63 are the same as steps S50 to S53 in the first operation example, respectively.

[0186] In step S64, the control unit 130 of the UE 100 determines to retransmit the R2D data transmission. The control unit 130 may determine to retransmit in response to receiving failure information. Alternatively, the control unit 130 may perform the R2D data transmission (step S62) and determine to retransmit in response to not receiving a response signal (or a response message) to the R2D data transmission even after a predetermined time has elapsed. The control unit 130 may determine not to retransmit when communication between the UE 100 and the ambient IoT device 300 is performed by a best-effort service.

[0187] In step S65, the transmitter 120 of the UE 100 transmits request information indicating a resource request to the network node 200. The request information may be request information indicating a resource to be used for R2D data transmission, specifically, a resource for R2D communication and / or a resource for D2R communication. The request information may include cause information indicating a cause for requesting the resource. The request information may include the cause information shown below.

[0188] To perform data retransmission To receive failure information from the ambient IoT device 300 The request information may be transmitted using an RRC message, a MAC CE, an uplink control signal (UCI), or a new layer message for ambient IoT. The receiving unit 220 of the network node 200 receives the request information.

[0189] In step S66, the transmitter 210 of the network node 200 transmits, in accordance with the request information, resource information including resources to be used for retransmission of the D2R data transmission (specifically, resources for R2D communication and / or resources for D2R communication) to the UE 100. The resource information may be transmitted by using an RRC message, a MAC CE, a downlink control signal (DCI), or a new layer message for ambient IoT. The receiver 110 of the UE 100 receives the resource information.

[0190] In step S67, the transmitter 120 of the UE 100 transmits the R2D data that the ambient IoT device 300 failed to receive (step S62) as new data, using the resources notified from the network node 200. The transmission of the new data can be a retransmission of the R2D data.

[0191] Third Embodiment Next, a third embodiment will be described, focusing on the differences from the first and second embodiments.

[0192] For example, assume the following case. That is, in topology 2 (FIG. 14), UE 100 moves, performs handover, and moves from a source cell to a target cell. In the source cell, UE 100 supports a function for communicating with ambient IoT device 300, but the target cell does not support this function. This function will be referred to as an "ambient IoT function" hereinafter.

[0193] In such a case, even if the UE 100 is handed over to the target cell, since the target cell does not support the ambient IoT function, the UE 100 cannot function as a reader device and may not be able to communicate with the ambient IoT device 300. It is preferable that the UE 100 can be handed over to a target cell having the ambient IoT function.

[0194] Therefore, the third embodiment aims to enable the UE 100 to properly communicate with the ambient IoT device 300 even at the handover destination.

[0195] Therefore, in the third embodiment, the UE 100 transmits information indicating that it is operating as a leader device 400 (hereinafter, this may be referred to as "leader operation information") to the source network node 200-1, so that the source network node 200-1 that triggered the handover decision selects a network node 200 that supports ambient IoT functionality as the target network node 200-2.

[0196] Specifically, first, a source network node (e.g., source network node 200-1) receives leader operation information from a user equipment (e.g., UE 100) indicating that the user equipment is operating as a leader device. Second, the source network node determines a handover of the user equipment. Third, the source network node transmits a handover request message to a target network node (e.g., target network node 200-2) that supports the user equipment's ability to communicate with an ambient IoT device (e.g., ambient IoT device 300).

[0197] In this way, the source network node 200-1 transmits a handover request to the target cell that supports the ambient IoT function, and the UE 100 can be handed over to the target cell. Therefore, since the UE 100 has the ambient IoT function at the handover destination, it can appropriately communicate with the ambient IoT device 300 at the handover destination.

[0198] (Example of Operation According to Third Embodiment) Next, an example of operation according to the third embodiment will be described.

[0199] Fig. 17 is a diagram illustrating an example of operation according to the third embodiment. Fig. 17 illustrates an example in which the UE 100 moves from the source network node 200-1 to the target network node 200-2 by handover. It should be noted that the UE 100 is assumed to be in an RRC connected state with the source network node 200-1 at the stage of starting the operation illustrated in Fig. 17.

[0200] As shown in FIG. 17, in step S71, when the UE 100 is operating as the leader device 400, the transmitter 120 of the UE 100 transmits leader operation information to the source network node 200-1.

[0201] First, the leader operation information may be information indicating that the UE 100 is operating as the leader device 400. The leader operation information may be transmitted when an ambient IoT device 300 is present under the control of the UE 100. Alternatively, the leader operation information may be transmitted when the CN device 380 is permitted (or authenticated) to operate as the leader device 400. When the CN device 380 is an AMF, the UE 100 may be notified by a NAS message including information indicating the permission.

[0202] Secondly, when the UE 100 leaves the state of functioning as the leader device 400, the transmitter 120 may transmit, to the source network node 200-1, leader removal information indicating the removal, instead of the leader operation information. The leader removal information may be transmitted when the UE 100 ceases to operate as the leader device. The leader removal information may be transmitted when the UE 100 no longer has the function as the leader device 400.

[0203] Third, the leader operation information may be transmitted from the CN device 380 to the source network node 200-1. In response to permitting the UE 100 to operate as a leader device, the CN device 380 may transmit the leader operation information about the UE 100 (or information indicating that the UE 100 has the leader operation information) to the source network node 200-1.

[0204] The leader operation information transmitted from the UE 100 may be transmitted in an RRC message (for example, a UE Assistance Information message). In addition, the leader operation information transmitted from the CN device 380 may be transmitted in an NG message if the CN device 380 is an AMF. The receiving unit 220 of the source network node 200-1 receives the leader operation information.

[0205] In step S72, the transmitting unit 120 of the UE 100 transmits a measurement report to the source network node 200-1. The receiving unit 220 of the source network node 200-1 receives the measurement report.

[0206] In step S73, the control unit 230 of the source network node 200-1 makes a handover decision based on the measurement report: The control unit 230 selects the target network node 200-2.

[0207] First, the control unit 230 may determine a network node 200 that supports the ambient IoT function as the target network node 200-1. Alternatively, the control unit 230 may determine a cell that supports the ambient IoT function as the target cell.

[0208] Second, the information indicating whether the ambient IoT function is supported may be notified by an Xn message from a network node (or cell) adjacent to the source network node 200-1 (or source cell). The Xn message may be a message including information (or an indicator) indicating that the adjacent network node (or the adjacent cell) supports the ambient IoT function. Alternatively, whether the ambient IoT function is supported may be notified by the CN device 380. If the CN device is an AMF, the information may be notified by an NG message. The NG message may be a message including information (or an indicator) indicating that the adjacent network node (or the adjacent cell) supports the ambient IoT function. Alternatively, whether the adjacent network node (or the adjacent cell) has the ambient IoT function may be notified by the OAM.

[0209] In step S74, the transmitter 210 of the source network node 200-1 transmits a handover request message to the target network node 200-2. The target network node 200-2 is a network node selected by the source network node 200-1 as a network node having an ambient IoT function. The transmitter 210 may include the leader operation information received in step S71 in a handover request message and transmit it. Note that the handover request message is a HANDOVER REQUEST message, which is an Xn message. The receiver 220 of the target network node 200-2 receives the handover request message.

[0210] In step S75, the control unit 230 of the target network node 200-2 decides to accept the handover request received in step S74.

[0211] In step S76, the transmitter 210 of the target network node 200-2 transmits a handover request permission message to the source network node 200-1. The handover request permission message is a HANDOVER REQUEST ACKNOWLEDGE message, which is an Xn message. This message includes a handover command (Handover Command), which is an RRC message, in an RRC container. The receiver 220 of the source network node 200-1 receives the handover request permission message.

[0212] In step S76, in response to receiving the handover request message, transmission unit 210 of source network node 200-1 transmits a handover command to UE 100. Reception unit 110 of UE 100 receives the handover command.

[0213] In step S77, the control unit 130 of the UE 100 performs connection processing, including a random access procedure, with the target network node 200-2 in accordance with the handover command. The UE 100 establishes a connection with the target network node 200-2. As a result, the UE 100 is handed over from the source network node 200-1 to the target network node 200-2 having the ambient IoT function.

[0214] [Other Embodiments] In the above-described embodiments, it has been described that a D2R message and an R2D message are transmitted. These are assumed to be messages from the perspective of a layer higher than the PHY layer (e.g., a New AS layer). For example, from the perspective of the PHY layer, a D2R message may be transmitted as a D2R signal. From the perspective of the PHY layer, an R2D message may be transmitted as an R2D signal.

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

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

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

[0218] A program may be provided that causes a computer to execute each process performed by the UE 100 or the network node 200. The program may be recorded on a computer-readable medium. Using the 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 network node 200 may be integrated, and at least a part of the UE 100 or the network node 200 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).

[0219] The functions performed by the above-described communication devices (such as the UE 100 or the network node 200) may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), a Central Processing Unit (CPU), conventional circuitry, 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 programs 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.

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

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

[0222] This application claims priority to U.S. Provisional Application No. 63 / 679,716, filed August 6, 2024, the entire contents of which are incorporated herein by reference.

[0223] (First Supplementary Note) The above-described embodiment can be summarized as in the supplementary note, but the supplementary note does not limit the embodiment.

[0224] (Supplementary Note 1) A communication method used in a mobile communication system, comprising a step in which either a reader device or an ambient IoT (Internet of Things) device performs QoS (Quality of Service) control for communication between the reader device and the ambient IoT device using a communication quality reference value indicating at least one of the number of retransmissions and delay time, wherein the reader device is a network node or a user device of the mobile communication system.

[0225] (Supplementary Note 2) The communication method according to Supplementary Note 1, wherein the step of performing the QoS control includes a step in which either the reader device or the ambient IoT device uses the communication quality reference value to determine whether an error has occurred in the communication.

[0226] (Supplementary Note 3) The communication method according to Supplementary Note 1 or Supplementary Note 2, wherein the step of making the error determination includes a step of the ambient IoT device making the error determination, and the communication is communication performed by a random access procedure.

[0227] (Supplementary Note 4) The communication method according to any one of Supplementary Note 1 to Supplementary Note 3, wherein the step of making the error determination includes a step of the ambient IoT device making the error determination, and the communication is communication using a D2R (Device-to-Reader) message.

[0228] (Supplementary Note 5) The communication method according to any one of Supplementary Notes 1 to 4, wherein the step of making the error determination includes a step of the reader device making the error determination, and the communication is communication using an R2D (Reader-to-Device) message.

[0229] (Supplementary Note 6) The communication method according to any one of Supplementary Note 1 to Supplementary Note 5, further comprising the step of the ambient IoT device receiving the communication quality reference value from the reader device.

[0230] (Supplementary Note 7) The communication method according to any one of Supplementary Notes 1 to 6, further comprising: a step in which the ambient IoT device receives at least one of a service priority indicating a priority for each service, a data priority indicating a priority for each data, and QoS setting information for setting QoS; and a step in which the ambient IoT device generates the communication quality reference value based on at least one of the service priority, the data priority, and the QoS setting information.

[0231] (Supplementary Note 8) The communication method according to any one of Supplementary Note 1 to Supplementary Note 7, wherein the step of making the error determination includes a step of stopping the communication in response to either the reader device or the ambient IoT device not satisfying the communication quality reference value.

[0232] (Supplementary Note 9) An ambient IoT device in a mobile communication system, comprising: a control unit that performs QoS (Quality of Service) control for communication between the ambient IoT device and a leader device that is a network node or user device of the mobile communication system, using a communication quality reference value that indicates at least one of the number of retransmissions and a delay time.

[0233] (Supplementary Note 10) A user device in a mobile communication system, comprising: a control unit that performs QoS (Quality of Service) control for communication between the user device and the ambient IoT device using a communication quality reference value indicating at least one of a number of retransmissions and a delay time.

[0234] (Supplementary Note 11) A communication method in a mobile communication system, comprising: a user equipment transmitting R2D data to an ambient IoT device; the user equipment receiving failure information from the ambient IoT device; the user equipment transmitting the failure information to a network node; and the user equipment receiving an instruction to retransmit the R2D data transmission from the network node, wherein the failure information is information indicating that the ambient IoT device has either failed to receive data transmitted in the R2D data transmission or failed to execute processing instructed by a command.

[0235] (Supplementary Note 12) The communication method according to Supplementary Note 11, wherein the retransmission instruction includes resource information indicating resources for the user equipment to perform retransmission.

[0236] (Supplementary Note 13) A communication method in a mobile communication system, comprising: a user equipment transmitting R2D data to an ambient IoT device; the user equipment receiving failure information from the ambient IoT device; the user equipment deciding to retransmit to the ambient IoT device in response to receiving the failure information; the user equipment transmitting request information indicating a resource request to a network node; and the user equipment receiving resource information indicating the resources from the network node, wherein the failure information is information indicating either that the ambient IoT device has failed to receive the data transmitted in the R2D data transmission or that it has failed to execute a command included in the data.

[0237] (Supplementary Note 14) The communication method according to Supplementary Note 13, wherein the request information includes cause information indicating a cause for requesting the resource.

[0238] (Supplementary Note 15) A communication method in a mobile communication system, comprising: a step by a source network node receiving leader operation information from a user equipment indicating that the user equipment is operating as a leader device; a step by the source network node deciding to hand over the user equipment; and a step by the source network node sending a handover request message to a target network node that supports the function of the user equipment to communicate with an ambient IoT device.

[0239] (Supplementary Note 16) The communication method according to Supplementary Note 15, wherein the step of sending the handover request comprises the step of the source network node receiving, from a neighboring network node, information indicating whether the source network node supports the feature.

[0240] (Supplementary Note 17) The communication method according to Supplementary Note 15 or Supplementary Note 16, wherein the step of sending the handover request includes a step of the source network node receiving, from a core network device, information indicating whether the source network node supports the function.

[0241] (Supplementary Note 18) The communication method according to any one of Supplementary Note 15 to Supplementary Note 17, further comprising the step of the source network node receiving leader disengagement information from the user equipment, indicating that the user equipment has ceased to act as a leader device for the ambient IoT device. (Second Supplementary Note) Introduction At the RAN#102 meeting, a new study item on Ambient IoT solutions was approved. As a general scope, two deployment scenarios, namely Topology 1 and Topology 2, have been identified for this study as follows:

[0242] B. Deployment scenarios with the following characteristics, referring to the table in section 4.2.2 of TR 38.848: Deployment scenario 1 with topology 1; Base station and coexistence characteristics: microcell, co-located; Network controlled deployment scenario 2 with topology 2 and UE as intermediate node; Base station and coexistence characteristics: macrocell, co-located; Indoor location of intermediate node.

[0243] This appendix presents a discussion of the issues related to Topology 2.

[0244] Discussion In TR38.848, Topology 1 and Topology 2 are described as follows: Here, as described in the SID (Study Item Description), the intermediate node in this study is a UE.

[0245] In Topology 2, Ambient IoT devices communicate bidirectionally with intermediate nodes between the devices and the base station. In this topology, the intermediate nodes can be Ambient IoT-enabled relays, IAB nodes, UEs, repeaters, etc. The intermediate nodes forward Ambient IoT data and / or signaling between the BS and the Ambient IoT devices.

[0246] Figure 7(B) shows that the Uu interface is used between the BS and the intermediate node. Therefore, it is a natural approach for the gNB to reuse the Uu interface to control the UE acting as an ambient IoT reader, for example, by allocating radio resources to the UE to perform ambient IoT transmission and reception. This is a very natural interpretation from the SID and TR, but it is worth explicitly confirming with RAN2.

[0247] Note: In Topology 1, the gNB acts as the Ambient IoT reader, and therefore it is assumed that the Uu interface is not required to control the transmission and reception of Ambient IoT.

[0248] Proposal 1: RAN2 should ensure that the Uu interface is reused for the gNB to control the UE acting as the leader.

[0249] In RAN2#125-bis, it was agreed that RRC, SDAP, PDCP (except security), and RLC (except segmentation) will not be included. According to the current SA2 TR, some solutions may require higher layer protocols, such as a "command protocol." According to the current progress in each WG, the expected protocol stack for the ambient IoT link (i.e., between the reader and the device) can be shown as in Figure 19 (the dashed boxes / lines require further consideration).

[0250] RAN2 further states, "Step A: Based on the service request, the leader sends an initial trigger message indicating the devices that need to respond. It was agreed that the details are matters that require further study. Therefore, the A-IoT procedure will always be initiated by a "service request" from higher layers. The "service request" can be assumed to include some important information such as device ID for A-IoT paging."

[0251] Considering the above possible protocol stacks, there are several possible options for protocol design of Topology 2, as shown in FIG.

[0252] Option 1: The "Service Request" is visible to the RAN. In this case, the gNB can appropriately prepare radio resources for A-IoT communications such as R2D / D2R transmissions in advance based on the received "Service Request." From the RAN2 perspective, (part of) the content of the "Service Request" is provided to the UE via an RRC message.

[0253] Option 2: The "Service Request" is transparent to the RAN. In this case, the CN directly signals to the UE acting as the leader, similar to NAS signaling. Therefore, before initiating A-IoT paging, the UE needs to request radio resources for A-IoT communications, such as R2D / D2R transmissions, from the gNB based on the received "Service Request."

[0254] Both options (and any other possible options) can be envisioned in the study phase, but should be clarified before the actual protocol design in the specification phase. Among these options, option 1 is slightly more desirable because it is expected to provide more precise control over the AS layer, but it will have more impact on the RAN specifications (i.e., RAN2 and RAN3). Therefore, RAN2 should discuss whether the "service request" is visible or transparent to the RAN.

[0255] Proposal 2: RAN2 should discuss whether the "service request" is supposed to be visible or transparent to the RAN, and discuss the advantages and disadvantages of these options.

[0256] Regardless of the above protocol design options, radio resource control remains the responsibility of the gNB. Therefore, the gNB should provide the UE with radio resource information for A-IoT communication. According to the current specifications, there are two possible baselines: dynamic grant (or sidelink mode 1) and configured grant (or sidelink mode 2 with resource pool). Since it is generally assumed that there are multiple UEs acting as leaders in a cell, the gNB is in a good position to perform resource coordination between leaders.

[0257] Proposal 3: RAN2 should discuss whether dynamic grant-like and configured grant-like resource allocation is supported for ambient IoT communications.

[0258] In addition to Proposal 3, it is worth discussing whether the detailed channel allocation for backscattering transmissions (i.e., D2R transmissions) within the resources allocated to a UE is performed by the UE or the gNB. The channels may include contention-free access channels and contention-based random access channels. For example, in the case of FDD, channel #1 is for contention-free access and channel #2 is for contention-based access. Such channel allocation may change from time to time depending on whether a "service request" is triggered for a single device, a group of devices, or all devices.

[0259] Proposal 4: RAN2 should discuss whether detailed channel placement within the allocated radio resources should be performed by the UE acting as a leader or by the gNB.

[0260] RAN2 agreed not to support RLC-like retransmission / repetition, which is expected to be treated as a new data transmission by layers above MAC as follows:

[0261] 4. RLC-like retransmission / repeat at the AS layer (above the PHY layer) is not supported. This does not prevent readers and devices from retransmitting the payload as a new transmission from a MAC perspective. Further study is needed on how to handle segmentation cases (if necessary).

[0262] Additionally, RAN2 agreed on the following baseline procedures for A-IoT communications, which include D2R transmissions from devices to readers in steps B and D in response to R2D transmissions in steps A and C.

[0263] 1. As a baseline, the "inventory only" case is supported by the following procedures: - Step A: A-IoT Paging; - Step B: Device ID transmission (via random access or without RA). Details require further study.

[0264] 2. As a baseline, the "inventory and command" case is supported by the following procedures: - Step A: A-IoT paging; - Step B: Device ID transmission (via random access or without RA). Details require further study; - Step C: Data transmission from reader to device (e.g., R2D command); and - Step D: Data transmission from corresponding device to reader (e.g., feedback). Whether this is optional or not is a matter for further discussion in other WGs.

[0265] In Topology 2, the UE receives a D2R transmission in response to its R2D transmission. For example, in the "inventory and command" case, the D2R transmission (e.g., feedback) in step D is used by the UE to determine whether its R2D transmission (e.g., command) in step C was successfully received by the device.

[0266] If it is determined that the R2D transmission was not received by the device, the leader should retransmit the R2D transmission, but it must be treated by higher layers (above the A-IoT MAC) as a new transmission of the same data. In this case, the leader requires additional radio resources for this R2D retransmission. In Topology 1, the leader function and radio resource control are the responsibility of the gNB, i.e., the same entity. However, in Topology 2, the leader function is the responsibility of the UE, while radio resource control is the responsibility of the gNB, i.e., a different entity.

[0267] Therefore, for higher layer retransmissions in Topology 2, it is worth discussing whether the retransmission decision is made by the UE or by the gNB. In the latter case, it is also questionable whether the content of the D2R transmission from the device (e.g., NACK) needs to be forwarded by the UE to the gNB in ​​order for the gNB to decide and indicate higher layer retransmission. Note that this can only be an issue if option 1 of Figure 20 (i.e., the "service request" is visible to the RAN) is adopted.

[0268] Proposal 5: RAN2 should discuss whether higher layer retransmissions are decided by the UE or the gNB.

[0269] Considering that the UE acts as a leader, mobility aspects need to be discussed. When the UE is in IDLE / INACTIVE state, it will prioritize frequencies / cells that support A-IoT in the cell reselection procedure. When the UE is in Connected state, it will expect to be handed over to a cell that supports A-IoT. Otherwise, the UE will no longer be able to function as a leader or provide A-IoT services. It is expected that current mechanisms, e.g., for sidelink, will be reused to support leader mobility, but details can be deferred to a future specification phase. At this point, RAN2 only needs to agree to support the mobility of a UE acting as a leader.

[0270] Proposal 6: RAN2 should agree that mobility of UEs acting as leaders is supported. Introduction At the RAN#102 meeting, a new study item on Ambient IoT solutions was approved. The RAN2#125-bis meeting started its study and reached the following agreements:

[0271] Agreements 1. RRC connection management is not supported. How resource configuration is provided to devices (if required based on RAN1 progress) needs further study.

[0272] 2. RRM L3 measurement reporting is not supported by ambient IoT devices.

[0273] 3. RAN2 assumes that AIot devices do not need to support ASN.1 encoding / decoding.

[0274] 4. Periodic system information and MIB are not supported by AIoT devices. This does not preclude any broadcast signals defined in RAN1.

[0275] 5. RAN2 assumes that no RRC layer is required between the reader and the device. RAN2 will continue to consider the required functionality and later discuss whether to 1) have a new AS protocol on top of the A-IoT MAC layer, or 2) have A-IoT MAC.

[0276] Agreements 1. SDAP is not supported in the UP protocol stack.

[0277] 2. The PDCP layer is not required. Further consideration is needed on how to handle AS security (if required pending SA3 discussion) and other truly required features.

[0278] 3. No RLC layer is required. How to handle segmentation (if required and depends on RAN1 design and higher layer packet size) requires further study. RAN2 believes that segmentation and reassembly would add complexity, but further discussion is needed.

[0279] 4. No HARQ and RLC AM.

[0280] 5. The level of visibility required by the reader and the information required for the operation of the AS layer requires further study.

[0281] 6. RAN2 assumes that per-packet QoS and per-flow QoS are not supported at the AS level (for both UL / DL). Further study is needed on how to handle general QoS requests from SA2.

[0282] The RAN2#126 meeting further agreed to the following statement:

[0283] Functionality Agreements 1. Multiple "AIoT logical channels" for upper layer data are not supported. Depending on the final modeling issue, further consideration is needed as to whether the concept of AIoT logical channels will be used.

[0284] 2. Legacy NR BSR / SR is not necessary for A-IoT communication.

[0285] 3. Further study is needed as to whether further indication of device message size / status is necessary.

[0286] 4. RLC-like retransmission / repeat at the AS layer (above the PHY layer) is not supported. This does not prevent readers and devices from retransmitting the payload as a new transmission from a MAC perspective. Further study is needed on how to handle segmentation cases (if necessary).

[0287] This appendix discusses open or potential challenges related to the functioning of Ambient IoT.

[0288] Discussion segmentation / reassembly and message size / status indication

[0289] RAN2 stated that "how to handle segmentation (if required and depending on RAN1 design and higher layer packet size) is an issue for further study. Since segmentation / reassembly is used when the data size is larger than the transport block size, the question is whether such a condition occurs in ambient IoT communications.

[0290] Although the definition and details of the transport block still need to wait for the progress of RAN1, this problem can be avoided if the leader provides sufficient radio resources for data transfer, i.e., if the PHY always allows a larger transport block size. However, this is not optimal from the perspective of resource efficiency. In Topology 1, the gNB handles both radio resource control and leader operation, so ultimately, it is up to the gNB implementation to provide the radio resources necessary for ambient IoT communication. On the other hand, in Topology 2, the gNB still handles radio resource control, but the UE acts as the leader. Therefore, the leader (i.e., the UE) cannot increase or decrease the radio resources for ambient IoT communication by itself. In this sense, a condition may occur in which the data size is larger than the transport block size. This clearly suggested that the data size can easily be larger than the transport block size. In general, it is assumed that the message "size" indication reports the amount of data, while the message "status" indication reports whether the current D2R transmission is carrying the last segment of data or whether there are still remaining segments in the device's buffer.

[0291] From the device's perspective, it may be difficult to know if the assigned transport block size is dynamically changed by the leader. This means that the device may not be able to know in advance whether the data can be completely transmitted via a single D2R transmission opportunity. If so, it may be infeasible for the AS to perform segmentation. In addition, if the AS layer does not perform segmentation, there is no reason to send a message size / status indication, since the leader's AS will not do anything about this, assuming that the upper layers will simply trigger a new command for a subsequent new data transmission (for the remaining data).

[0292] On the other hand, if the transport block size is always fixed, it is known to everyone, not only to the AS layer but also to higher layers, and not only to the device but also to the CN function (e.g., AF). In addition, the higher layers (or CN) can know the message size / status since the "commands" are issued by them, which means that no message size / status indication in the AS is necessary.

[0293] Therefore, RAN2 should inquire from SA2 whether the upper layer supports the segmentation / reassembly function, where the upper layer may be located in the CN, the leader, or both.

[0294] Proposal 1: RAN2 should inquire of SA2 whether the upper layers can handle segmentation / reassembly, and if upper layer segmentation / reassembly is present, it should be assumed that the device's message size / status indication is not required.

[0295] AS Configuration / Reconfiguration Function Currently, the RRC layer handles all UE configuration via RRC Reconfiguration. On the other hand, RAN2 agreed that the RRC layer is not required for ambient IoT. This means that RRC Reconfiguration for devices is ruled out, but "how resource configuration is provided to devices (if required based on RAN1 progress) remains an issue for further study."

[0296] If AS configurations such as "resource configuration" are required and are not changed, pre-configuration such as sidelink should be the baseline.

[0297] Proposal 2: If a device requires an AS configuration and it is a static configuration, RAN2 should assume the pre-configuration as the baseline.

[0298] If some semi-static / dynamic AS reconfiguration for a device is required, RAN2 should consider how the ambient IoT protocol supports this function. Regarding user / upper layer data, SA2 and RAN2 assume that "read" and "write" commands exist, which implies that the device has memory / storage. If an "AS area" exists in the device's memory / storage, AS reconfiguration by the reader can be achieved by a "write" command containing AS configuration data. Therefore, AS reconfiguration can be implemented without the RRC layer.

[0299] AS reconfiguration can be useful for resource efficiency and controllability, such as radio resource configuration (e.g., TDD / FDD parameters), random access parameters, etc., which are up to RAN1. Therefore, it is worth considering whether the AS reconfiguration function is necessary.

[0300] Proposal 3: If an AS configuration exists in the device, RAN2 should discuss whether AS reconfiguration is performed by a "write" command to the AS area of ​​the device's memory / storage, for example, to provide / change resource configuration (if necessary).

[0301] Regarding device mobility and mobility functions of DO-A ambient IoT, SID clearly states that "for topologies 1 and 2 (UE as an intermediate node under NW control) based on TR 38.848, no RRC state, no mobility (i.e., at least no functions such as cell selection / reselection), no HARQ, no ARQ." In addition, RAN2#125-bis states that "RAN2 assumes that devices do not support tracking / RAN area update procedures." Therefore, from the perspective of the AS layer, there is no way to track devices except for "inventory."

[0302] However, neither the physical movement of a device nor the behavior of any upper layer is restricted by the above conditions (i.e., no TAU / RNAU and no (re)selection). For example, in an asset tracking scenario, within a smart factory, an asset may physically move from a facility covered by one reader to another facility covered by another reader. Therefore, the application layer may require periodic location tracking of the device depending on its implementation. If such periodic tracking is initiated by the server, it will request DO-DTT traffic from the reader via a service request. Alternatively, if it is initiated by the device as another implementation option, it will intend for the device to initiate DO-A traffic. In the former implementation, the reader needs to trigger DO-DTT periodically, and in the latter implementation, the reader needs to allocate DO-A opportunities periodically.

[0303] Regarding DO-A, the evaluation of whether a "harmonized air interface design" is applicable may be discussed in RAN2 after RAN#104. Considering that licensed spectrum will be used for ambient IoT, DO-A does not mean that devices are always permitted to initiate autonomous transmission without any leader / network control. In other words, DO-A traffic would also be triggered by an A-IoT paging / initial trigger message in step A for DO-DTT. If so, DO-A could be realized by an "inventory" for "all devices" in the A-IoT paging / initial trigger message. Here, "all devices" does not mean a specific single device or a specific device group, as agreed upon by RAN2. Therefore, RAN2 should agree that DO-A access is feasible with a harmonized air interface if it is always initiated by an A-IoT paging without any ID (i.e., meaning "all devices").

[0304] Proposal 4: RAN2 should assume that the physical movement of the device and the periodic device location tracking of higher layers are not restricted by the no cell (re)selection statement in the SID and the no tracking area updates agreed upon by RAN2.

[0305] Proposal 5: RAN2 should agree that DO-A access is initiated by A-IoT paging without any ID (i.e., triggering "all devices").

[0306] 1: Mobile communication system 5: Network 10: RAN 20: CN 100: UE 110: Receiving unit 120: Transmitting unit 130: Control unit 140: Wireless communication unit 200: Network node 210: Transmitting unit 220: Receiving unit 230: Control unit 240: Network communication unit 250: Wireless communication unit 300: Ambient IoT device 310: Antenna 350: Matching network 351: RF energy harvester 352: PMU (Power Management Unit) 353: Energy storage unit 354: RF BPF (Radio Frequency Band Pass Filter) 355: RF envelope detector (or envelope detector) 356: BB LPF (Base Band Low Pass Filter 357: Comparator 358: Baseband logic 359: Memory 360: Backscattering modulator 361: Clock generator 365: LNA (Low Noise Amplifier) ​​366: Baseband amplifier 367: Large frequency shifter 368: Reflection amplifier 369: Energy harvester 320: Modulator 330: Control unit 340: Memory 380: CN device 400: Reader device

Claims

1. A communication method used in a mobile communication system, comprising: a reader device or an ambient IoT (Internet of Things) device performing QoS (Quality of Service) control for communication between the reader device and the ambient IoT device using a communication quality reference value indicating at least one of the number of retransmissions and delay time; and the reader device being a network node or user device of the mobile communication system.

2. The communication method according to claim 1, wherein performing the QoS control includes either the reader device or the ambient IoT device using the communication quality reference value to determine whether an error has occurred in the communication.

3. The communication method according to claim 2, wherein the performing the error determination includes the ambient IoT device performing the error determination, and the communication is performed by a random access procedure.

4. The communication method according to claim 2, wherein the performing of the error determination includes the ambient IoT device performing the error determination, and the communication is communication using a D2R (Device-to-Reader) message.

5. The communication method according to claim 2, wherein the error determination includes the reader device performing the error determination, and the communication is communication using an R2D (Reader-to-Device) message.

6. The communication method of claim 1, further comprising the ambient IoT device receiving the communication quality reference value from the reader device.

7. The communication method of claim 1, further comprising: the ambient IoT device receiving at least one of a service priority indicating the priority of each service, a data priority indicating the priority of each data, and QoS setting information for setting QoS; and the ambient IoT device generating the communication quality reference value based on at least one of the service priority, the data priority, and the QoS setting information.

8. The communication method of claim 2, wherein performing the error determination includes stopping the communication in response to either the reader device or the ambient IoT device not satisfying the communication quality reference value.

9. An ambient IoT device in a mobile communication system, comprising: a control unit that performs QoS control for communication between the ambient IoT device and a leader device that is a network node or user device of the mobile communication system, using a communication quality reference value that indicates at least one of the number of retransmissions and delay time.

10. A user device in a mobile communication system, comprising: a control unit that performs QoS control for communication between the user device and an ambient IoT device using a communication quality reference value that indicates at least one of the number of retransmissions and delay time.

11. A communication method in a mobile communication system, comprising: a user equipment transmitting R2D data to an ambient IoT device; the user equipment receiving failure information from the ambient IoT device; the user equipment transmitting the failure information to a network node; and the user equipment receiving an instruction to retransmit the R2D data transmission from the network node, wherein the failure information is information indicating either that the ambient IoT device has failed to receive data transmitted in the R2D data transmission or that it has failed to execute processing instructed by a command.

12. The communication method according to claim 11, wherein the retransmission instruction includes resource information indicating resources for the user equipment to perform retransmission.

13. A communication method in a mobile communication system, comprising: a user equipment transmitting R2D data to an ambient IoT device; the user equipment receiving failure information from the ambient IoT device; the user equipment deciding to retransmit to the ambient IoT device in response to receiving the failure information; the user equipment transmitting request information indicating a resource request to a network node; and the user equipment receiving resource information indicating the resources from the network node, wherein the failure information is information indicating either that the ambient IoT device has failed to receive the data transmitted in the R2D data transmission or that it has failed to execute a command included in the data.

14. The communication method according to claim 13, wherein said request information includes cause information indicating a cause for requesting said resource.

15. A communication method in a mobile communication system, comprising: a source network node receiving leader operation information from a user equipment indicating that the user equipment is operating as a leader equipment; the source network node deciding to hand over the user equipment; and the source network node sending a handover request message to a target network node that supports the user equipment's ability to communicate with an ambient IoT device.

16. The communication method of claim 15, wherein transmitting the handover request includes receiving information from a neighboring network node indicating whether the source network node supports the feature.

17. The communication method of claim 15, wherein transmitting the handover request includes receiving information from a core network device indicating whether the source network node supports the feature.

18. The communication method of claim 15, further comprising the source network node receiving leader disengagement information from the user equipment indicating that the user equipment is no longer acting as a leader device for the ambient IoT device.

Images