Communication method, user device, and network node

Abstract

A communication method according to one embodiment of the present invention is used in a mobile communication system. The communication method includes a step in which a reader device, which is a network node or a user device of the mobile communication system, receives a first message transmitted from an ambient Internet of Things (IoT) device. In addition, the communication method includes a step in which the reader device generates an error detection code on the basis of data included in the first message. Further, the communication method includes a step in which the reader device transmits a second message including an error detection code to the ambient IoT device. Further, in the ambient IoT device, a contention resolution is determined on the basis of the error detection code of the data included in the first message and the error detection code included in the second message.

Description

COMMUNICATION METHOD, USER EQUIPMENT, AND NETWORK NODE

[0001] The present disclosure relates to a communication method, a user equipment, and a network node.

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

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

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

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

[0006] Alternatively, ambient IoT devices are envisioned to function as battery devices with limited energy storage, e.g., energy storage that does not require manual replacement and / or charging.

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

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

[0009] The present disclosure provides a communication method, a user device, and a network node that can improve the efficiency of the entire two-step random access process.

[0010] 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 a reader device, which is a network node or user equipment of the mobile communication system, receives a first message transmitted from an ambient Internet of Things (IoT) device. The communication method also includes a step in which the reader device generates an error detection code based on data included in the first message. The communication method further includes a step in which the reader device transmits a second message including the error detection code to the ambient IoT device. The ambient IoT device then makes a contention resolution decision based on the error detection code of the data included in the first message and the error detection code included in the second message.

[0011] A user device according to a second aspect is a user device included in a mobile communication system. The user device has a receiving unit that receives a first message transmitted from an ambient IoT device. The user device also has a control unit that generates an error detection code based on data included in the first message. The user device also has a transmitting unit that transmits a second message including the error detection code to the ambient IoT device. The ambient IoT device performs contention resolution based on the error detection code of the data included in the first message and the error detection code included in the second message.

[0012] A network node according to a third aspect is a network node included in a mobile communication system. The network node has a receiving unit that receives a first message transmitted from an ambient IoT device. The network node also has a control unit that generates an error detection code based on data included in the first message. The network node also has a transmitting unit that transmits a second message including the error detection code to the ambient IoT device. The ambient IoT device makes a contention resolution decision based on the error detection code of the data included in the first message and the error detection code included in the second message.

[0013] 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 a CRC generation method according to the first embodiment.

[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 types of reception under the control of the control unit 130. The receiving unit 110 includes an antenna and a receiver. The receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 130.

[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 CRC parity bits scrambled by the RNTI added thereto.

[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 within the device. 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 include 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 the First Embodiment As described above, in the "two-step random access," the reader device 400 transmits echo information in Msg2 (step S22 in FIG. 12). However, at present, 3GPP has not determined what information should be used as the echo information.

[0118] Assume that all of the data included in Msg1 is used as echo information. In this case, the amount of data included in Msg2 is constant. Furthermore, the ambient IoT device 300 also uses a certain amount of data or more to determine whether to resolve the conflict (step S23), which makes it impossible to improve the efficiency of the entire two-step random access process.

[0119] Therefore, the first embodiment aims to improve the efficiency of the entire two-step random access process.

[0120] Therefore, in the first embodiment, an error detection code is used as echo information included in Msg2 of two-step random access.

[0121] Specifically, first, a reader device (e.g., reader device 400) receives a first message (e.g., Msg1) transmitted from an ambient IoT device (e.g., ambient IoT device 300). Second, the reader device generates an error detection code based on the data included in the first message. Third, the reader device transmits a second message including the error detection code to the ambient IoT device. Fourth, the ambient IoT device makes a conflict resolution decision based on the error detection code of the data included in the first message and the error detection code included in the second message.

[0122] As described above, in the first embodiment, since Msg2 includes an error detection code, the amount of data included in Msg2 is also below a certain level. Furthermore, the ambient IoT device 300 can determine contention resolution using an error detection code with a data amount below a certain level, thereby improving processing efficiency. Therefore, in the first embodiment, the overall processing efficiency of the two-step random access can be improved.

[0123] In the first embodiment, a CRC (Cyclic Redundancy Check) is used as an example of an error detection code. A CRC is a method of detecting errors using the remainder obtained by dividing the data to be detected for errors by a constant (generator polynomial). This remainder is included in Msg2.

[0124] However, a method other than CRC may be used for the error detection code. For example, a parity bit may be used as the error detection code. A parity bit is a method of performing error detection using a bit in which the sum of each bit ("0" or "1") in the bit string to be error detected indicates whether the sum is even or odd. In this case, the bit (parity bit) indicating an even or odd number is included in Msg2. Alternatively, a checksum may be used as the error detection code. A checksum is a method of using the sum of the numerical values ​​of a data string as a check code. In this case, the check code is included in Msg2. The error detection code is, for example, a code used to detect data errors. Any code for such purposes may be included in Msg2. The ambient IoT device 300 may receive information from the reader device 400 regarding which of these error detection codes will be transmitted in Msg2. The ambient IoT device 300 may also receive information regarding the number of bits of these error detection codes (which may be the number of bits of the above-mentioned "constant" or "remainder") from the reader device 400. Such information may be received in an A-IoT paging message or Msg2, or may be pre-configured in the ambient IoT device 300.

[0125] (5) Operation Example According to First Embodiment Next, an operation example according to the first embodiment will be described.

[0126] Fig. 13 is a diagram showing an example of operation according to the first embodiment. Fig. 13 shows an example of operation corresponding to Step 2 (Fig. 12) in "two-step random access".

[0127] 13, in step S40, the ambient IoT device 300 transmits a message 1 (Msg1) (e.g., a first message). Msg1 may include at least any of the following information:

[0128] (5-1) "Device ID"

[0129] (5-2) Upper layer data and / or control bits

[0130] (5-3) CRC If Msg 1 contains the higher layer data shown in (5-2), it corresponds directly to Msg 1 of two-step random access. Also, if the higher layer data is a "device ID," Msg 1 contains the "device ID" shown in (5-1), which corresponds directly to Msg 1 of two-step random access.

[0131] Fig. 14 is a diagram showing an example of the configuration of Msg1 according to the first embodiment. Msg1 shown in Fig. 14 shows an example in which all of (5-1) to (5-3) are included.

[0132] As shown in FIG. 14, Msg1 includes an ID section (identification information section), an upper layer data section, and a CRC section.

[0133] The ID section contains a "device ID."

[0134] In the upper layer data section, upper layer data and / or control bits are set. The upper layer data may be a "device ID." In this case, upper layer data other than the "device ID" may be set in the upper layer data section. Alternatively, the ID section and the upper layer data section may be combined into one block, and the "device ID" may be set in that block.

[0135] The CRC section contains a CRC for the data set in the ID section and the upper layer data section (i.e., all data included in Msg1). The CRC section is included in Msg1 because it is assumed that the CRC will be generated on the ambient IoT device 300 side.

[0136] The ambient IoT device 300 transmits Msg1 by backscattering transmission. Therefore, the ambient IoT device 300 may perform backscattering transmission using the CW of the A-IoT paging message (Step A in FIG. 11). Alternatively, the ambient IoT device 300 may perform backscattering transmission using a CW transmitted from a reader device different from the reader device 400 that transmitted the A-IoT paging message. The receiver of the reader device 400 (the receiver 110 of the UE 100 or the receiver 220 of the network node 200) receives Msg1.

[0137] 13 , in step S41, the control unit of the leader device 400 (the control unit 130 of the UE 100 or the control unit 230 of the network node 200) generates a CRC in response to receiving Msg1. There are four options for generating the CRC, as follows. This will be explained using FIG. 14 .

[0138] Option 1: The reader device 400 generates a CRC based on the "device ID" set in the ID section of Msg1.

[0139] Option 2: The reader device 400 generates a CRC based on the "device ID" set in the ID section of Msg 1 and the upper layer data and / or control bits set in the upper layer data section of Msg 1. In Option 2, the CRC is generated using data set in blocks other than the CRC section of Msg 1.

[0140] Option 3: The reader device 400 generates a CRC for the entire received signal, including the ID section, upper layer data section, and CRC section of Msg 1. In Option 3, a CRC is generated for the entire received signal received as Msg 1.

[0141] Option 4: The reader device 400 extracts the CRC set in the CRC section of Msg1 from the CRC section and uses the extracted CRC.

[0142] The reader device 400 may generate a CRC using the upper layer data set in the upper layer data section. The CRC may be generated using a known method.

[0143] 13 , in step S42, the transmitter of the leader device 400 (the transmitter 120 of the UE 100 or the transmitter 210 of the network node 200) transmits a message 2 (Msg2) (e.g., a second message) including the CRC generated in step S41. Step S42 shows an example in which the CRC is used as echo information. The ambient IoT device 300 receives Msg2.

[0144] In step S14, the control unit 330 of the ambient IoT device 300 determines whether to resolve the conflict. Specifically, first, the control unit 330 of the ambient IoT device 300 generates a CRC as follows: Note that the following options correspond to the respective options in CRC generation.

[0145] Option 1: The control unit 330 of the ambient IoT device 300 generates a CRC for the "device ID" included in the ID portion transmitted in Msg1.

[0146] Option 2: The control unit 330 of the ambient IoT device 300 generates a CRC for all data (data other than the CRC section) included in the ID section and upper layer data section transmitted in Msg1.

[0147] Option 3: The control unit 330 of the ambient IoT device 300 generates a CRC for the entire transmission signal (including the ID section, upper layer data section, and CRC section) transmitted in Msg 1. Option 4: The control unit 330 of the ambient IoT device 300 uses the CRC set in the CRC section of Msg 1.

[0148] Second, the control unit 330 of the ambient IoT device 300 determines whether or not the CRC generated in any of Option 1 to Option 4 matches the CRC included in Msg 2. If the two CRCs match, the ambient IoT device 300 determines that the conflict resolution is successful (OK), and if the two CRCs do not match, the ambient IoT device 300 determines that the conflict resolution is unsuccessful (NG).

[0149] Note that a lower layer (e.g., a PHY layer or an A-IoT MAC layer) of the ambient IoT device 300 may determine contention resolution (step S43). In this case, the lower layer may notify a higher layer (e.g., an A-IoT MAC layer or a new AS layer for ambient IoT) of the contention resolution result of the ambient IoT device 300. The higher layer that has received the notification of the contention resolution result may perform necessary operations such as data retransmission.

[0150] Alternatively, an upper layer of the ambient IoT device 300 may determine whether to resolve the contention (step S43). In this case, the upper layer may notify the lower layer of the ambient IoT device 300 of the result of the contention resolution. The lower layer, upon receiving the notification of the result of the contention resolution, may perform a necessary operation, such as retransmitting data. In this case, the lower layer may retransmit Msg1 in a transmittable time after the wait time has elapsed, based on Slotted ALOHA. Alternatively, the lower layer may reselect a frequency instead of or in addition to the wait time, and retransmit Msg1 using the reselected frequency.

[0151] (Another Operation Example According to the First Embodiment) In the first embodiment, an example of transmitting Msg2 in two-step random access has been described, but transmission of echo information may be used in a procedure other than two-step random access. In transmission of echo information other than two-step random access, the error detection code described in the first embodiment may be used.

[0152] [Other Embodiments] In the above-described embodiments, it has been described that a D2R message and an R2D message are transmitted. These messages are assumed to be 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, and an R2D message may be transmitted as an R2D signal.

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

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

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

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

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

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

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

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

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

[0162] (Supplementary Note 1) A communication method used in a mobile communication system, comprising the steps of: a reader device which is a network node or user equipment of the mobile communication system receiving a first message transmitted from an ambient Internet of Things (IoT) device; the reader device generating an error detection code based on data contained in the first message; and the reader device transmitting a second message including the error detection code to the ambient IoT device, wherein the ambient IoT device makes a contention resolution decision based on the error detection code of the data contained in the first message and the error detection code contained in the second message.

[0163] (Supplementary Note 2) The communication method according to Supplementary Note 1, wherein the generating step includes a step in which the reader device generates the error detection code based on upper layer data included in the first message.

[0164] (Supplementary Note 3) The communication method according to Supplementary Note 1 or Supplementary Note 2, wherein the generating step includes a step in which the reader device extracts an error detection code included in the first message from the first message and sets the extracted error detection code as the error detection code included in the second message.

[0165] (Supplementary Note 4) The communication method according to any one of Supplementary Note 1 to Supplementary Note 3, wherein the generating step includes a step in which the reader device generates an error detection code based on individual identification information included in the first message.

[0166] (Supplementary Note 5) The communication method according to any one of Supplementary Notes 1 to 4, wherein the generating step includes a step in which the reader device generates an error detection code based on individual identification information included in the first message and upper layer data included in the first message.

[0167] (Supplementary Note 6) The communication method according to any one of Supplementary Note 1 to Supplementary Note 5, wherein the generating step includes a step of generating, by the reader device, an error detection code for the entire received signal received as the first message.

[0168] (Supplementary Note 7) The communication method according to any one of Supplementary Note 1 to Supplementary Note 6, wherein the first message is a message 1 (Msg1) used in two-step random access, and the second message is a message 2 (Msg2) used in the two-step random access.

[0169] (Supplementary Note 8) A user equipment included in a mobile communication system, comprising: a receiving unit that receives a first message transmitted from an ambient IoT device; a control unit that generates an error detection code based on data included in the first message; and a transmitting unit that transmits a second message including the error detection code to the ambient IoT device, wherein conflict resolution is performed in the ambient IoT device based on the error detection code of the data included in the first message and the error detection code included in the second message.

[0170] (Supplementary Note 9) A network node included in a mobile communication system, comprising: a receiving unit that receives a first message transmitted from an ambient IoT device; a control unit that generates an error detection code based on data included in the first message; and a transmitting unit that transmits a second message including the error detection code to the ambient IoT device, wherein the ambient IoT device makes a contention resolution decision based on the error detection code of the data included in the first message and the error detection code included in the second message. (Supplementary Note 2) Introduction At the RAN#102 meeting, a new study item on ambient IoT solutions was approved. In response to receiving an A-IoT paging, a device initiates access to a reader. RAN2 identified three types of device access methods, namely, "four-step" random access (or actually having only three steps), two-step random access, and contention-free access, as follows:

[0171] Agreements for "4-step" RA 1. A-IoT Msg1: Device sends ID to reader. The ID is a random ID generated by the device (how it is generated, e.g., randomly or based on device ID, requires further study). ID size also requires further study. This does not exclude other RAN1 agreed information.

[0172] 2. A-IoT Msg2: The reader echoes the ID received in Msg1. Based on the agreement of RAN1, further information may be included in Msg2.

[0173] 3. A-IoT Msg3: The device sends the device ID and / or other higher layer data (as requested by the higher layer).

[0174] 4. The device considers contention resolution successful if Msg2 is received containing the same random ID as in Msg1. RAN2 assumes that the size of the random ID in Msg1 should be sufficient for contention resolution purposes.

[0175] 5. "Msg4" (i.e., the next R2D transmission after a D2R transmission) does not necessarily have to be transmitted via random access. "Msg4" is considered to handle failure of Msg3 transmission due to various reasons. The use / existence of "Msg4" can be further discussed.

[0176] RAN2 will not use the term "Msg4" in further discussions regarding random access.

[0177] Agreements for 2-step CB RA 1. A-IoT Msg1: Device sends Device ID and / or some other higher layer data (depending on higher layer requirements). What the Device ID is and whether an additional random ID is needed needs further consideration. This does not preclude other RAN1 agreed information.

[0178] 2. A-IoT Msg2: The reader may echo some information from Msg1. What that some information is needs further discussion. The use / existence of "Msg2" can be further discussed.

[0179] Agreements: For contention-free access procedures, we study the single-device and multi-device cases (according to the discussion in RAN1).

[0180] This appendix discusses open and potential challenges regarding A-IoT random access.

[0181] Discussion The agreement for the three access methods cited in the previous section is shown in FIG.

[0182] Regardless of the access method, the device needs to select an access resource / opportunity (step 1 in Figure 12), which will be discussed in a separate agenda item on A-IoT paging, as shown in the proposed agenda.

[0183] If the device is not allowed to initiate contention-free access (e.g., if it has dedicated D2R resources), it must initiate a contention-based random access procedure including Msg1 and Msg2 for contention resolution (step 2 in Figure 12).

[0184] In a "four-step" RA, the device includes a random ID in Msg 1, and the reader echoes the received ID in Msg 2. If the IDs sent in Msg 1 and received in Msg 2 match, the device considers conflict resolution to have been completed successfully.

[0185] In a two-step RA, the device includes its device ID and / or other higher layer data in Msg1, and the reader echoes some information. The data in Msg1 and the information in Msg2 are used for conflict resolution.

[0186] Finally, the device can transmit higher layer data on the dedicated D2R resource (step 3 in Figure 12).

[0187] The following sections discuss the open and potential issues with each random access method separately.

[0188] Regarding "4-Step" Contention-Based Random Access A-IoT Msg1, a random ID is sent by the device, although the details of the random ID still need further study.

[0189] 1. A-IoT Msg1: The device sends its ID to the reader. The ID is a random ID generated by the device (how it is generated, e.g., randomly or based on the device ID, requires further consideration). The ID size also requires further consideration. This does not exclude other RAN1 agreed information.

[0190] According to the existing RF-ID specifications, "tags must implement a random or pseudo-random number generator (RNG)" and "tags must use the RNG to generate a 16-bit random or pseudo-random number (RN16)," and this RN16 is used as a Reply in response to a Cmd (a Query from the reader).

[0191] Regarding A-IoT Msg1, one of the major differences between ambient IoT and RF-ID is the communication range. That is, the coverage design goal for ambient IoT is set to "a maximum distance of 10-50 m when the device is indoors, in accordance with TR 38.848," as stated in the SID general scope. Therefore, if RN16 is used, as in RF-ID, it is logically assumed that there will be a larger number of devices within the reader's coverage area, which may cause a higher probability of Msg1 contention. Msg1 contention is also affected by how much radio resource is allocated to random access opportunities. For example, more radio resource leads to a lower probability of Msg1 contention. Therefore, ultimately, this becomes a matter of deployment policy; for example, if 50 m reachability is required, resources should be allocated sufficiently large.

[0192] Therefore, the size of the random ID can be assumed to be 16 bits, the same as RF-ID. In addition, the advantage of generating the random ID based on the device ID, which was identified as an item requiring further consideration at the previous meeting, is unclear at this time. Therefore, as a working assumption, the random ID in A-IoT Msg1 is RN16. This can be reconsidered in the future if necessary.

[0193] Proposal 1: RAN2 should assume that the random ID in A-IoT Msg1 during the “four-step” RA procedure is a 16-bit random number.

[0194] After receiving A-IoT Msg2 following contention resolution in the device, the device sends A-IoT Msg3 containing "Device ID and / or some other higher layer data (depending on higher layer requirements)" and this should be done using dedicated D2R resources (i.e. A-IoT Msg3 is no longer "contention based access"). Therefore, the final goal of the "four-step" RA is considered to be to determine dedicated D2R resources for Msg3, which is worth confirming by RAN2.

[0195] Proposal 2: RAN2 should agree that A-IoT Msg3 in a "four-step" RA is transmitted on dedicated D2R resources.

[0196] If Proposal 2 is agreeable, the device must determine the dedicated D2R resources from the result of conflict resolution using Msg1 and Msg2.

[0197] For example, the dedicated resources for A-IoT Msg3 are associated with the random access resources for A-IoT Msg1, for which contention resolution was successful. Even in this example, it is unclear how the resource association is made known to the device.

[0198] Proposal 3: If Proposal 2 is agreeable, RAN2 should discuss how devices determine dedicated resources for A-IoT Msg3 transmission.

[0199] In the two-step contention-based random access, the device sends an A-IoT Msg1 containing its device ID, and the reader responds with some information for contention resolution that is checked on the device side, but the details remain to be explored further as follows:

[0200] 1. A-IoT Msg1: The device sends the device ID and / or some other higher layer data (depending on the higher layer requirements). What the device ID is and whether an additional random ID is needed needs further consideration. This does not exclude other RAN1 agreed information.

[0201] 2. A-IoT Msg2: The reader may echo some information from Msg1. What that some information is needs further discussion. The use / existence of "Msg2" can be further discussed.

[0202] Regarding the matter in A-IoT Msg1 that needs further consideration, "What is the device ID and whether an additional random ID is required?", it will depend on whether the device ID is a "full" device ID or some "truncated" device ID. That is, only in the latter case, an "additional random ID" may be required.

[0203] Please note that in this appendix the term "full" device ID is intended to mean a (globally) unique identifier of a device that is assigned by a higher layer.

[0204] In general, a "full" device ID requires more bits than a "truncated" device ID, but the exact ID size is unclear (depending on SA2). For example, the EPC of RF-ID allows a maximum of 496 bits. Therefore, there may be concerns about the appropriateness of transmitting such large data over a contention-based access resource, because of the inefficiency in case of data reception failure.

[0205] On the other hand, the "full" device ID would anyway need to be sent from the device to the reader for inventory and / or command use cases after the random access procedure is completed (i.e., like the A-IoT Msg3 transmission in the "four-step" RA). In addition, such a D2R transmission may fail, for example, due to changes in radio conditions. In that case, it would be assumed that the device / reader would need to restart the entire access procedure, i.e., restart from A-IoT paging and A-IoT Msg1.

[0206] Proposal 4: RAN2 should agree that during the two-step RA procedure, the “full” device ID without any additional random ID is sent in A-IoT Msg1.

[0207] If Proposal 4 is agreeable, it should be clarified whether higher layer data is still sent after contention resolution (i.e., step 3 in Figure 12) because the device ID and / or higher layer data has already been sent via A-IoT Msg1, which may be needed for subsequent data (e.g., the second segment of all data whose first segment was sent via Msg1) or for a retry of the random access procedure (e.g., Msg1 and Msg2 are repeated due to contention resolution failure).

[0208] For simplicity, it is slightly preferable that the two-step RA procedure ends with conflict resolution, i.e., there is no step 3 in FIG.

[0209] Proposal 5: If Proposal 4 is agreeable, RAN2 should further discuss whether D2R transmission after contention resolution is really necessary for the two-step RA procedure.

[0210] Regarding the issue of "what is the certain information" echoed by the reader in A-IoT Msg2, which merits further investigation, it would be simple if the information were exactly the same as that received in A-IoT Msg1, e.g., the "full" device ID, as in the "four-step" RA. However, there is a problem that the bit size transmitted in A-IoT Msg2 becomes too large, especially when the "full" device ID is used in A-IoT Msg1 as in Proposal 4. Therefore, it is worth considering how to reduce the size of A-IoT Msg2 for two-step RA.

[0211] One possible approach is for the reader to echo a portion of the "full" device ID (i.e., a "truncated" ID), but while this is simple, it may not avoid erroneous conflict resolution decisions. For example, if two different "full" device IDs sent by different devices have the same LSB (least significant bit) but different MSB (most significant bit), echoing the LSB of the "full" device ID in Msg2 will cause these different devices to consider the conflict resolution successful, even though their Msg1s actually collide. High accuracy of conflict resolution cannot be expected.

[0212] Another viable approach is for the reader to echo the cyclic redundancy check (CRC) of the "complete" device ID. CRC is widely used for error detection and has good performance with fewer redundant bits. For contention resolution, the device simply compares the CRC of what it sent in A-IoT Msg1 with the CRC received in A-IoT Msg2. Another advantage is that it makes it easier to design a harmonized A-IoT Msg2 format in terms of bit length. For example, if the A-IoT Msg2 for the "four-step" RA as in Proposal 1 requires 16 bits to echo RN16, the A-IoT Msg2 for the two-step RA can simply adopt CRC-16 (i.e., the Msg2 length can be 16 bits for both RA methods).

[0213] Therefore, contention resolution using A-IoT Msg2 with CRC may be more efficient in terms of its bit length and accuracy. It should also be noted that this contention resolution allows the device to determine whether the device ID (and / or any other upper layer data) in A-IoT Msg1 has been successfully delivered.

[0214] Proposal 6: RAN2 should discuss whether the CRC should be echoed in A-IoT Msg2 for two-step RA, where the CRC is calculated from what is received in A-IoT Msg1 (e.g., device ID).

[0215] Contention-Free Access RAN2 agreed to consider contention-free access as follows:

[0216] Agreement - From the reader's perspective, for contention-free access procedures, consider the single and multiple device cases (depending on the RAN1 discussion).

[0217] This topic may need to await progress on RAN1, but some high-level discussion is still possible at this time.

[0218] The above agreement indicates that RAN2 considers two cases from the reader's perspective: single device and multiple devices. This implies that from the device's perspective, the contention-free access procedure should be the same regardless of whether the A-IoT paging message triggers a single device or multiple devices. This further implies that the ID in the A-IoT paging message should be a list of device IDs, i.e., the cases where multiple devices are triggered by a group ID or "all devices" (no ID) are different cases. This assumption is easily agreed upon, as it is similar to the existing NR paging record for individual paging.

[0219] Proposal 7: RAN2 should agree that a list of device IDs is used to trigger multiple devices for contention-free access, i.e., neither a group ID nor "all devices" without an ID.

[0220] For contention-free access, it is clear that a device should be allocated dedicated resources prior to its first D2R transmission.

[0221] Proposal 8: RAN2 should agree that each dedicated D2R resource is associated with each device ID in the A-IoT paging message.

[0222] 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 320: Modulator 330: Control unit 340: Memory 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 380: CN device 400: Reader device

Claims

1. A communication method used in a mobile communication system, comprising: a leader device that is a network node or user device of the mobile communication system receiving a first message transmitted from an ambient Internet of Things (IoT) device; the leader device generating an error detection code based on data contained in the first message; and the leader device transmitting a second message including the error detection code to the ambient IoT device, wherein the ambient IoT device makes a contention resolution decision based on the error detection code of the data contained in the first message and the error detection code contained in the second message.

2. The communication method according to claim 1, wherein said generating step includes said reader device generating said error detection code based on upper layer data included in said first message.

3. The communication method according to claim 1, wherein the generating step includes the reader device extracting an error detection code contained in the first message from the first message and using the error detection code as the error detection code contained in the second message.

4. The communication method according to claim 1, wherein said generating step includes said reader device generating an error detection code based on individual identification information included in said first message.

5. A communication method according to claim 1, wherein the generating step includes the reader device generating an error detection code based on individual identification information included in the first message and upper layer data included in the first message.

6. The communication method according to claim 1, wherein said generating step includes said reader device generating an error detection code for the entire signal received as said first message.

7. A communication method according to any one of claims 1 to 6, wherein the first message is message 1 (Msg1) used in two-step random access, and the second message is message 2 (Msg2) used in the two-step random access.

8. A user equipment included in a mobile communication system, comprising: a receiving unit that receives a first message transmitted from an ambient IoT device; a control unit that generates an error detection code based on data contained in the first message; and a transmitting unit that transmits a second message including the error detection code to the ambient IoT device, wherein conflict resolution is performed in the ambient IoT device based on the error detection code of the data contained in the first message and the error detection code contained in the second message.

9. A network node included in a mobile communication system, comprising: a receiving unit that receives a first message transmitted from an ambient IoT device; a control unit that generates an error detection code based on data contained in the first message; and a transmitting unit that transmits a second message including the error detection code to the ambient IoT device, wherein the ambient IoT device makes a conflict resolution decision based on the error detection code for the data contained in the first message and the error detection code contained in the second message.

Images