Communication based on IoT

Abstract

One disclosure of the present specification provides a method. The method may comprise the steps of: receiving, by a second reader included in a second UE, a random access preamble from an AIoT device; and transmitting, by the second UE, a message including one or more pieces of information to a base station.

Description

IoT-based communication

[0001] This specification relates to mobile communication.

[0002] 3GPP (3rd Generation Partnership Project) LTE (Long-Term Evolution) is a technology designed to enable high-speed packet communication. Many methods have been proposed to achieve LTE goals, such as reducing costs for users and operators, improving service quality, expanding coverage, and increasing system capacity. As high-level requirements, 3GPP LTE demands reduced cost per bit, improved service availability, flexible use of frequency bands, a simple structure, open interfaces, and appropriate power consumption of terminals.

[0003] Work has begun at the ITU (International Telecommunication Union) and 3GPP to develop requirements and specifications for New Radio (NR) systems. 3GPP must identify and develop the technical components necessary to successfully standardize NR in a timely manner, satisfying both urgent market demands and the longer-term requirements presented by the ITU-R (ITU Radio communication sector) IMT (International Mobile Telecommunications)-2020 process. Furthermore, NR must be able to utilize any spectrum band up to at least 100 GHz so that it can be used for wireless communication even in the distant future.

[0004] NR targets a single technical framework that covers all deployment, usage, and requirements, including eMBB (enhanced Mobile Broadband), mMTC (massive Machine Type-Communications), and URLLC (Ultra-Reliable and Low Latency Communications). NR must be forward compatible by nature.

[0005] Communication based on Ambient IoT (AIoT) is being discussed. However, according to conventional technology, there is a problem in that AIoT-based communication cannot be performed effectively and / or accurately.

[0006] According to one embodiment of the present specification, a method is provided. The method may include the step of a second reader included in a second UE receiving a random access preamble from an AIoT device; and the step of the second UE transmitting a message containing one or more pieces of information to a base station.

[0007] According to one embodiment, a device for implementing the above method is provided.

[0008] According to one embodiment of the present specification, a method is provided. The method may include the step of a first UE receiving an AIoT service request message from a base station that includes information related to requesting the transmission of an AIoT paging message; and the step of transmitting the AIoT paging message to an AIoT device that includes a reader ID of a first reader included in the first UE.

[0009] According to one embodiment, a device for implementing the above method is provided.

[0010] FIG. 1 shows an example of a communication system to which the implementation of the present specification is applied.

[0011] FIG. 2 shows an example of a wireless device to which the implementation of the present specification applies.

[0012] FIG. 3 shows an example of a UE to which the implementation of the present specification applies.

[0013] FIG. 4 shows an example of a 5G system structure to which the implementation of the present specification is applied.

[0014] FIGS. 5a through 5e illustrate an example of a RACH procedure applicable to one embodiment of the present disclosure.

[0015] FIGS. 6 and FIGS. 7 illustrate examples of registration procedures to which the implementation of the present specification applies.

[0016] Figures 8a and 8b show examples of topologies related to Ambient IoT.

[0017] FIGS. 9a through 9h illustrate an example of a procedure according to the first example of the disclosure of the present specification.

[0018] FIGS. 10a and FIGS. 10b illustrate a first example of a procedure according to a first example of the disclosure of the present specification.

[0019] FIG. 11 shows an example of an area managed by one or more readers according to one embodiment of the disclosure of the present specification.

[0020] FIGS. 12a and FIGS. 12b illustrate a second example of a procedure according to the first example of the disclosure of the present specification.

[0021] FIGS. 13a and FIGS. 13b illustrate an example of a procedure according to the second example of the disclosure of the present specification.

[0022] FIG. 14 illustrates an example of a procedure according to one embodiment of the disclosure of the present specification.

[0023] The following techniques, devices, and systems may be applied to various wireless multiple access systems. Examples of multiple access systems include Code Division Multiple Access (CDMA) systems, Frequency Division Multiple Access (FDMA) systems, Time Division Multiple Access (TDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, Single Carrier Frequency Division Multiple Access (SC-FDMA) systems, and Multi-Carrier Frequency Division Multiple Access (MC-FDMA) systems. CDMA may be implemented through wireless technologies such as Universal Terrestrial Radio Access (UTRA) or CDMA2000. TDMA may be implemented through wireless technologies such as Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), or Enhanced Data Rates for GSM Evolution (EDGE). OFDMA can be implemented through wireless technologies such as IEEE (Institute of Electrical and Electronics Engineers) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or E-UTRA (Evolved UTRA). UTRA is part of UMTS (Universal Mobile Telecommunications System). 3GPP (3rd Generation Partnership Project) LTE (Long-Term Evolution) is part of E-UMTS (Evolved UMTS) using E-UTRA.3GPP LTE uses OFDMA in the downlink (DL) and SC-FDMA in the uplink (UL). Evolutions of 3GPP LTE include LTE-A (Advanced), LTE-A Pro, and / or 5G NR (New Radio).

[0024] For convenience of explanation, the implementation of this specification is described primarily in relation to 3GPP-based wireless communication systems. However, the technical characteristics of this specification are not limited thereto. For example, the following detailed description is provided based on a mobile communication system corresponding to a 3GPP-based wireless communication system, but aspects of this specification that are not limited to 3GPP-based wireless communication systems may be applied to other mobile communication systems.

[0025] For terms and technologies used in this specification that are not specifically described, reference may be made to wireless communication standard documents published prior to this specification.

[0026] In this specification, "A or B" may mean "only A," "only B," or "both A and B." Alternatively, in this specification, "A or B" may be interpreted as "A and / or B." For example, in this specification, "A, B or C" may mean "only A," "only B," "only C," or "any combination of A, B and C."

[0027] A slash ( / ) or a comma used in this specification may mean "and / or." For example, "A / B" may mean "A and / or B." Accordingly, "A / B" may mean "only A," "only B," or "both A and B." For example, "A, B, C" may mean "A, B or C."

[0028] In this specification, "at least one of A and B" may mean "only A," "only B," or "both A and B." Additionally, in this specification, the expressions "at least one of A or B" or "at least one of A and / or B" may be interpreted as synonymous with "at least one of A and B."

[0029] Additionally, in this specification, "at least one of A, B and C" may mean "only A," "only B," "only C," or "any combination of A, B and C." Furthermore, "at least one of A, B or C" or "at least one of A, B and / or C" may mean "at least one of A, B and C."

[0030] Additionally, parentheses used in this specification may mean "for example." Specifically, when indicated as "control information (PDCCH)," "PDCCH" may be proposed as an example of "control information." In other words, "control information" in this specification is not limited to "PDCCH," and "PDCCH" may be proposed as an example of "control information." Furthermore, even when indicated as "control information (i.e., PDCCH)," "PDCCH" may be proposed as an example of "control information."

[0031] Technical features described individually within a single drawing in this specification may be implemented individually or simultaneously.

[0032] Although not limited thereto, the various descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification may be applied to various fields where wireless communication and / or connectivity between devices (e.g., 5G) is required.

[0033] The present specification will be described in more detail below with reference to the drawings. In the following drawings and / or description, the same reference numerals may refer to the same or corresponding hardware blocks, software blocks, and / or function blocks unless otherwise indicated.

[0034] FIG. 1 shows an example of a communication system to which the implementation of the present specification is applied.

[0035] The 5G usage scenario shown in FIG. 1 is merely an example, and the technical features of this specification may be applied to other 5G usage scenarios not shown in FIG. 1.

[0036] The three main requirement categories for 5G are (1) enhanced Mobile BroadBand (eMBB) category, (2) massive Machine Type Communication (mMTC) category, and (3) Ultra-Reliable and Low Latency Communications (URLLC) category.

[0037] Referring to FIG. 1, the communication system (1) includes wireless devices (100a to 100f), a base station (BS; 200), and a network (300). FIG. 1 illustrates a 5G network as an example of the network of the communication system (1), but the implementation of the present specification is not limited to a 5G system and may be applied to future communication systems beyond a 5G system.

[0038] The base station (200) and the network (300) can be implemented as wireless devices, and a specific wireless device can operate as a base station / network node in relation to another wireless device.

[0039] Wireless devices (100a to 100f) represent devices that perform communication using Radio Access Technology (RAT) (e.g., 5G NR or LTE) and may also be referred to as communication / wireless / 5G devices. Wireless devices (100a to 100f) may include, but are not limited to, robots (100a), vehicles (100b-1 and 100b-2), eXtended Reality (XR) devices (100c), portable devices (100d), home appliances (100e), Internet-Of-Things (IoT) devices (100f), and Artificial Intelligence (AI) devices / servers (400). For example, vehicles may include vehicles with wireless communication capabilities, autonomous vehicles, and vehicles capable of performing communication between vehicles. Vehicles may include unmanned aerial vehicles (UAVs) (e.g., drones). XR devices may include AR (Augmented Reality) / VR (Virtual Reality) / MR (Mixed Reality) devices and may be implemented in the form of HMDs (Head-Mounted Devices) and HUDs (Head-Up Displays) mounted on vehicles, televisions, smartphones, computers, wearable devices, home appliances, digital signs, vehicles, robots, etc. Portable devices may include smartphones, smart pads, wearable devices (e.g., smartwatches or smart glasses), and computers (e.g., laptops). Home appliances may include TVs, refrigerators, and washing machines. IoT devices may include sensors and smart meters.

[0040] In this specification, wireless devices (100a to 100f) may be referred to as User Equipment (UE). The UE may include, for example, a mobile phone, a smartphone, a laptop computer, a digital broadcasting terminal, a PDA (Personal Digital Assistant), a PMP (Portable Multimedia Player), a navigation system, a slate PC, a tablet PC, an ultrabook, a vehicle, a vehicle with autonomous driving capabilities, a connected car, a UAV, an AI module, a robot, an AR device, a VR device, an MR device, a hologram device, a public safety device, an MTC device, an IoT device, a medical device, a fintech device (or financial device), a security device, a weather / environment device, a 5G service-related device, or a device related to the Fourth Industrial Revolution.

[0041] Wireless devices (100a to 100f) can be connected to a network (300) through a base station (200). AI technology may be applied to the wireless devices (100a to 100f), and the wireless devices (100a to 100f) can be connected to an AI server (400) through the network (300). The network (300) can be configured using a 3G network, a 4G (e.g., LTE) network, a 5G (e.g., NR) network, and a network after 5G. The wireless devices (100a to 100f) may communicate with each other through the base station (200) / network (300), but they may also communicate directly (e.g., sidelink communication) without going through the base station (200) / network (300). For example, vehicles (100b-1, 100b-2) can communicate directly (e.g., V2V (Vehicle-to-Vehicle) / V2X (Vehicle-to-everything) communication). Also, IoT devices (e.g., sensors) can communicate directly with other IoT devices (e.g., sensors) or other wireless devices (100a to 100f).

[0042] Wireless communication / connections (150a, 150b, 150c) can be established between wireless devices (100a to 100f) and / or between wireless devices (100a to 100f) and base station (200) and / or between base station (200). Here, the wireless communication / connections can be established through various RATs (e.g., 5G NR), such as uplink / downlink communication (150a), sidelink communication (150b) (or D2D (Device-To-Device) communication), and communication between base stations (150c) (e.g., relay, IAB (Integrated Access and Backhaul)). Through the wireless communication / connections (150a, 150b, 150c), wireless devices (100a to 100f) and base station (200) can transmit / receive wireless signals to / from each other. For example, wireless communication / connection (150a, 150b, 150c) may transmit / receive signals through various physical channels. To this end, based on various proposals in this specification, at least some of the following may be performed: a process for setting various configuration information for transmitting / receiving wireless signals, a process for various signal processing (e.g., channel encoding / decoding, modulation / demodulation, resource mapping / demapping, etc.), and a resource allocation process.

[0043] NR supports multiple numerologies or subcarrier spacings (SCS) to support various 5G services. For example, when the SCS is 15 kHz, it supports a wide area in traditional cellular bands; when the SCS is 30 kHz / 60 kHz, it supports dense-urban areas, lower latency, and wider carrier bandwidth; and when the SCS is 60 kHz or higher, it supports a bandwidth greater than 24.25 GHz to overcome phase noise.

[0044] The NR frequency band can be defined by two types of frequency ranges (FR1, FR2). The numerical values ​​of the frequency ranges may change. For example, the two types of frequency ranges (FR1, FR2) may be as shown in Table 1 below. For convenience of explanation, among the frequency ranges used in the NR system, FR1 may mean "sub 6GHz range" and FR2 may mean "above 6GHz range" and may be referred to as Millimeter Wave (mmW).

[0045] Frequency Range Definition Frequency Range Subcarrier Spacing FR1 450 MHz - 6000 MHz 15, 30, 60 kHz FR2 24 250 MHz - 52600 MHz 60, 120, 240 kHz

[0046] As described above, the numerical values ​​of the frequency range of the NR system may change. For example, FR1 may include a band of 410 MHz to 7125 MHz as shown in Table 2 below. That is, FR1 may include a frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or higher. For example, the frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or higher included within FR1 may include an unlicensed band. The unlicensed band may be used for various purposes, for example, for communication for vehicles (e.g., autonomous driving).

[0047] Frequency Range Definition Frequency Range Subcarrier Spacing FR1 4 10 MHz - 7 125 MHz 15, 30, 60 kHz FR2 24 250 MHz - 5 2600 MHz 60, 120, 240 kHz

[0048] Here, the wireless communication technology implemented in the wireless device of this specification may include LTE, NR, and 6G, as well as NarrowBand IoT (NB-IoT) for low-power communication. For example, NB-IoT technology may be an example of Low Power Wide Area Network (LPWAN) technology and may be implemented according to standards such as LTE Cat NB1 and / or LTE Cat NB2, but is not limited to the names mentioned above. Additionally, or generally, the wireless communication technology implemented in the wireless device of this specification may perform communication based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and may be referred to by various names such as eMTC (enhanced MTC). For example, LTE-M technology may be implemented in at least one of various standards such as 1) LTE CAT 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL (Non-Bandwidth Limited), 5) LTE-MTC, 6) LTE MTC, and / or 7) LTE M, and is not limited to the names mentioned above. Additionally or generally, wireless communication technology implemented in the wireless device of this specification may include at least one of ZigBee, Bluetooth, and / or LPWAN with consideration for low-power communication, and is not limited to the names mentioned above. For example, ZigBee technology may create Personal Area Networks (PANs) related to small / low-power digital communication based on various standards such as IEEE 802.15.4, and may be referred to by various names.

[0049] FIG. 2 shows an example of a wireless device to which the implementation of the present specification applies.

[0050] In FIG. 2, the first wireless device (100) and / or the second wireless device (200) may be implemented in various forms depending on the use example / service. For example, {the first wireless device (100) and the second wireless device (200)} may correspond to at least one of {wireless devices (100a–100f) and base station (200)}, {wireless devices (100a–100f) and wireless devices (100a–100f)} and / or {base station (200) and base station (200)} of FIG. 1. The first wireless device (100) and / or the second wireless device (200) may be composed of various components, devices / parts and / or modules.

[0051] The first wireless device (100) may include at least one transceiver such as a transceiver (106), at least one processing chip such as a processing chip (101), and / or one or more antennas (108).

[0052] The processing chip (101) may include at least one processor, such as a processor (102), and at least one memory, such as a memory (104). Additionally and / or generally, the memory (104) may be placed outside the processing chip (101).

[0053] The processor (102) can control the memory (104) and / or the transceiver (106) and may be configured to implement the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed herein. For example, the processor (102) may process information within the memory (104) to generate a first information / signal and transmit a wireless signal containing the first information / signal through the transceiver (106). The processor (102) may receive a wireless signal containing a second information / signal through the transceiver (106) and process the second information / signal to store the obtained information in the memory (104).

[0054] Memory (104) may be connected to the processor (102) so as to be operable. Memory (104) may store various types of information and / or instructions. Memory (104) may store firmware and / or software code (105) that implements code, instructions, and / or a set of instructions that perform the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification when executed by the processor (102). For example, firmware and / or software code (105) may implement instructions that perform the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification when executed by the processor (102). For example, firmware and / or software code (105) may control the processor (102) to perform one or more protocols. For example, firmware and / or software code (105) may control the processor (102) to perform one or more wireless interface protocol layers.

[0055] Here, the processor (102) and memory (104) may be part of a communication modem / circuit / chip designed to implement RAT (e.g., LTE or NR). A transceiver (106) may be connected to the processor (102) and may transmit and / or receive a wireless signal through one or more antennas (108). Each transceiver (106) may include a transmitter and / or receiver. The transceiver (106) may be interchangeably used with an RF (Radio Frequency) unit. In this specification, the first wireless device (100) may represent a communication modem / circuit / chip.

[0056] The second wireless device (200) may include at least one transceiver such as a transceiver (206), at least one processing chip such as a processing chip (201), and / or one or more antennas (208).

[0057] The processing chip (201) may include at least one processor, such as a processor (202), and at least one memory, such as a memory (204). Additionally and / or alternatively, the memory (204) may be placed outside the processing chip (201).

[0058] The processor (202) can control the memory (204) and / or the transceiver (206) and may be configured to implement the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed herein. For example, the processor (202) may process information within the memory (204) to generate a third information / signal and transmit a wireless signal containing the third information / signal through the transceiver (206). The processor (202) may receive a wireless signal containing a fourth information / signal through the transceiver (206) and process the fourth information / signal to store the obtained information in the memory (204).

[0059] Memory (204) may be connected to the processor (202) so as to be operable. Memory (204) may store various types of information and / or instructions. Memory (204) may store firmware and / or software code (205) that implements code, instructions, and / or sets of instructions that perform descriptions, functions, procedures, proposals, methods, and / or flowcharts disclosed in this specification when executed by the processor (202). For example, firmware and / or software code (205) may implement instructions that perform descriptions, functions, procedures, proposals, methods, and / or flowcharts disclosed in this specification when executed by the processor (202). For example, firmware and / or software code (205) may control the processor (202) to perform one or more protocols. For example, firmware and / or software code (205) may control the processor (202) to perform one or more wireless interface protocol layers.

[0060] Here, the processor (202) and memory (204) may be part of a communication modem / circuit / chip designed to implement a RAT (e.g., LTE or NR). A transceiver (206) may be connected to the processor (202) and transmit and / or receive a wireless signal through one or more antennas (208). Each transceiver (206) may include a transmitter and / or receiver. The transceiver (206) may be interchangeably used with an RF unit. In this specification, the second wireless device (200) may represent a communication modem / circuit / chip.

[0061] Hereinafter, hardware elements of the wireless device (100, 200) will be described in more detail. Although not limited thereto, one or more protocol layers may be implemented by one or more processors (102, 202). For example, one or more processors (102, 202) may implement one or more layers (e.g., functional layers such as a PHY (physical) layer, a MAC (Media Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, an RRC (Radio Resource Control) layer, and an SDAP (Service Data Adaptation Protocol) layer). One or more processors (102, 202) may generate one or more PDUs (Protocol Data Units), one or more SDUs (Service Data Units), messages, control information, data, or information according to the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification. One or more processors (102, 202) may generate a signal (e.g., baseband signal) including a PDU, SDU, message, control information, data, or information according to the description, function, procedure, proposal, method, and / or operation flowchart disclosed in this specification and provide it to one or more transceivers (106, 206). One or more processors (102, 202) may receive a signal (e.g., baseband signal) from one or more transceivers (106, 206) and may obtain a PDU, SDU, message, control information, data, or information according to the description, function, procedure, proposal, method, and / or operation flowchart disclosed in this specification.

[0062] One or more processors (102, 202) may be referred to as a controller, a microcontroller, a microprocessor, and / or a microcomputer. One or more processors (102, 202) may be implemented by hardware, firmware, software, and / or a combination thereof. For example, one or more Application Specific Integrated Circuits (ASICs), one or more Digital Signal Processors (DSPs), one or more Digital Signal Processing Devices (DSPDs), one or more Programmable Logic Devices (PLDs), and / or one or more Field Programmable Gate Arrays (FPGAs) may be included in one or more processors (102, 202). For example, one or more processors (102, 202) may be composed of a set of communication control processors, application processors (APs), electronic control units (ECUs), central processing units (CPUs), graphic processing units (GPUs), and memory control processors. One or more memories (104, 204) may be connected to one or more processors (102, 202) and may store various forms of data, signals, messages, information, programs, codes, instructions, and / or commands. One or more memories (104, 204) may be composed of Random Access Memory (RAM), Dynamic RAM (DRAM), Read-Only Memory (ROM), Erasable Programmable ROM (EPROM), flash memory, volatile memory, non-volatile memory, hard drive, register, cache memory, computer read storage media, and / or combinations thereof.One or more memories (104, 204) may be located inside and / or outside of one or more processors (102, 202). Additionally, one or more memories (104, 204) may be connected to one or more processors (102, 202) through various technologies such as wired or wireless connections.

[0063] One or more transceivers (106, 206) may transmit user data, control information, wireless signals / channels, etc., as described in the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification to one or more other devices. One or more transceivers (106, 206) may receive user data, control information, wireless signals / channels, etc., as described in the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification from one or more other devices. For example, one or more transceivers (106, 206) may be connected to one or more processors (102, 202) and may transmit and receive wireless signals. For example, one or more processors (102, 202) may control one or more transceivers (106, 206) to transmit user data, control information, wireless signals, etc., to one or more other devices. Additionally, one or more processors (102, 202) can control one or more transceivers (106, 206) to receive user data, control information, wireless signals, etc. from one or more other devices.

[0064] One or more transceivers (106, 206) may be connected to one or more antennas (108, 208). Additionally and / or generally, one or more transceivers (106, 206) may include one or more antennas (108, 208). One or more transceivers (106, 206) may be configured to transmit and receive user data, control information, wireless signals / channels, etc., mentioned in the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed herein through one or more antennas (108, 208). In this specification, one or more antennas (108, 208) may be a plurality of physical antennas or a plurality of logical antennas (e.g., antenna ports).

[0065] One or more transceivers (106, 206) can convert received user data, control information, wireless signals / channels, etc. from RF band signals to baseband signals in order to process received user data, control information, wireless signals / channels, etc. using one or more processors (102, 202). One or more transceivers (106, 206) can convert processed user data, control information, wireless signals / channels, etc. from baseband signals to RF band signals using one or more processors (102, 202). To this end, one or more transceivers (106, 206) may include (analog) oscillators and / or filters. For example, one or more transceivers (106, 206) can up-convert an OFDM baseband signal into an OFDM signal through an (analog) oscillator and / or filter under the control of one or more processors (102, 202) and transmit the up-converted OFDM signal at a carrier frequency. One or more transceivers (106, 206) can receive an OFDM signal at a carrier frequency and down-convert the OFDM signal into an OFDM baseband signal through an (analog) oscillator and / or filter under the control of one or more processors (102, 202).

[0066] Although not illustrated in FIG. 2, the wireless device (100, 200) may include additional components. The additional components (140) may be configured in various ways depending on the type of the wireless device (100, 200). For example, the additional components (140) may include at least one of a power unit / battery, an input / output (I / O) device (e.g., audio I / O port, video I / O port), a driving unit, and a computing unit. The additional components (140) may be connected to one or more processors (102, 202) through various technologies, such as wired or wireless connections.

[0067] In an implementation of the present specification, the UE may operate as a transmitting device in the uplink and as a receiving device in the downlink. In an implementation of the present specification, the base station may operate as a receiving device in the UL and as a transmitting device in the DL. For technical convenience, it is generally assumed that the first wireless device (100) operates as a UE and the second wireless device (200) operates as a base station. For example, a processor (102) connected to, mounted on, or released to the first wireless device (100) may be configured to perform UE operations according to an implementation of the present specification or to control a transceiver (106) to perform UE operations according to an implementation of the present specification. A processor (202) connected to, mounted on, or released to the second wireless device (200) may be configured to perform base station operations according to an implementation of the present specification or to control a transceiver (206) to perform base station operations according to an implementation of the present specification.

[0068] In this specification, the base station may be referred to as Node B, eNode B, or gNB.

[0069] FIG. 3 shows an example of a UE to which the implementation of the present specification applies.

[0070] Referring to FIG. 3, the UE (100) can correspond to the first wireless device (100) of FIG. 2.

[0071] The UE (100) includes a processor (102), memory (104), transceiver (106), one or more antennas (108), a power management module (141), a battery (142), a display (143), a keypad (144), a SIM (Subscriber Identification Module) card (145), a speaker (146), and a microphone (147).

[0072] The processor (102) may be configured to implement the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed herein. The processor (102) may be configured to control one or more other components of the UE (100) to implement the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed herein. Layers of a wireless interface protocol may be implemented in the processor (102). The processor (102) may include an ASIC, other chipsets, logic circuits, and / or data processing devices. The processor (102) may be an application processor. The processor (102) may include at least one of a DSP, a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), and a modem (modulator and demodulator). An example of the processor (102) is the SNAPDRAGON manufactured by Qualcomm®. TM Series processor, EXYNOS made by Samsung® TM Series processors, A Series processors made by Apple®, HELIO made by MediaTek® TM Series processors, ATOM made by Intel® TM It can be found in series processors or corresponding next-generation processors.

[0073] Memory (104) is coupled to the processor (102) so as to be operable and stores various information for operating the processor (102). Memory (104) may include ROM, RAM, flash memory, memory card, storage medium and / or other storage device. When the implementation is implemented in software, the technology described herein may be implemented using modules (e.g., procedures, functions, etc.) that perform the descriptions, functions, procedures, proposals, methods and / or operation flowcharts disclosed herein. Modules may be stored in memory (104) and executed by the processor (102). Memory (104) may be implemented within the processor (102) or outside the processor (102), in which case it may be communicatively coupled to the processor (102) through various methods known in the technology.

[0074] A transceiver (106) is coupled to operate with a processor (102) and transmits and / or receives a wireless signal. The transceiver (106) includes a transmitter and a receiver. The transceiver (106) may include a baseband circuit for processing a wireless frequency signal. The transceiver (106) controls one or more antennas (108) to transmit and / or receive a wireless signal.

[0075] The power management module (141) manages the power of the processor (102) and / or the transceiver (106). The battery (142) supplies power to the power management module (141).

[0076] The display (143) outputs the result processed by the processor (102). The keypad (144) receives input to be used by the processor (102). The keypad (144) can be displayed on the display (143).

[0077] A SIM card (145) is an integrated circuit for securely storing an International Mobile Subscriber Identity (IMSI) and associated keys, and is used to identify and authenticate a subscriber in a mobile device such as a mobile phone or computer. Additionally, contact information can be stored on many SIM cards.

[0078] The speaker (146) outputs sound-related results processed by the processor (102). The microphone (147) receives sound-related input to be used by the processor (102).

[0079] FIG. 4 shows an example of a 5G system structure to which the implementation of the present specification is applied.

[0080] The 5G system (5GS) structure consists of the following network functions (NF).

[0081] - AUSF (Authentication Server Function)

[0082] -AMF (Access and Mobility Management Function)

[0083] - DN (Data Network), for example, operator services, internet access, or third-party services

[0084] - USDF (Unstructured Data Storage Function)

[0085] - NEF (Network Exposure Function)

[0086] - I-NEF (Intermediate NEF)

[0087] - NRF (Network Repository Function)

[0088] - NSSF (Network Slice Selection Function)

[0089] - PCF (Policy Control Function)

[0090] - SMF (Session Management Function)

[0091] - UDM (Unified Data Management)

[0092] - UDR (Unified Data Repository)

[0093] - UPF (User Plane Function)

[0094] - UCMF (UE radio Capability Management Function)

[0095] - AF (Application Function)

[0096] - UE (User Equipment)

[0097] - (R)AN ((Radio) Access Network)

[0098] - 5G-EIR (5G-Equipment Identity Register)

[0099] - NWDAF (Network Data Analytics Function)

[0100] - CHF (CHarging Function)

[0101] 또한, 다음과 같은 네트워크 기능이 고려될 수 있다.

[0102] - N3IWF (Non-3GPP InterWorking Function)

[0103] - TNGF (Trusted Non-3GPP Gateway Function)

[0104] - W-AGF (Wireline Access Gateway Function)

[0105] Figure 4 shows the 5G system structure in a non-roaming case using a reference point representation showing how various network functions interact with each other.

[0106] In Figure 4, UDSF, NEF, and NRF are not described for clarity of the point-to-point diagram. However, all network functions shown can interact with UDSF, UDR, NEF, and NRF as needed.

[0107] For clarity, the connection between UDR and other NFs (e.g., PCF) is not shown in FIG. 4. For clarity, the connection between NWDAF and other NFs (e.g., PCF) is not shown in FIG. 4.

[0108] The 5G system structure includes the following reference points.

[0109] - N1: Reference point between UE and AMF.

[0110] - N2: Reference point between (R)AN and AMF.

[0111] - N3: Reference point between (R)AN and UPF.

[0112] - N4: Reference point between SMF and UPF.

[0113] - N6: Reference point between the UPF and the data network.

[0114] - N9: Reference point between two UPFs.

[0115] The following reference points show the interactions that exist between the NF services of NF.

[0116] - N5: Reference point between PCF and AF.

[0117] - N7: Reference point between SMF and PCF.

[0118] - N8: Reference point between UDM and AMF.

[0119] - N10: Reference point between UDM and SMF.

[0120] - N11: Reference point between AMF and SMF.

[0121] - N12: Reference point between AMF and AUSF.

[0122] - N13: Reference point between UDM and AUSF.

[0123] - N14: Reference point between two AMFs.

[0124] - N15: Reference point between PCF and AMF for non-roaming scenarios, reference point between PCF and AMF of the visited network for roaming scenarios.

[0125] - N16: Reference point between two SMFs (in the case of roaming, between the SMF of the visited network and the SMF of the home network)

[0126] - N22: Reference point between AMF and NSSF.

[0127] In some cases, two NFs may need to be connected to each other to service the UE.

[0128] <Random Access Channel (RACH) 절차>

[0129] FIGS. 5a through 5e illustrate an example of a RACH procedure applicable to one embodiment of the present disclosure.

[0130] With reference to FIGS. 5a through 5e, a RACH procedure according to one embodiment of the present disclosure is described. The embodiment of FIGS. 5a through 5e may be combined with various embodiments of the present disclosure.

[0131] In one embodiment of the present disclosure, where RF requirements (e.g., Tx RF performance requirements and / or Rx RF performance requirements) are described, the UE may satisfy these RF requirements. For example, the UE may be tested to satisfy the RF requirements (e.g., Tx RF performance requirements and / or Rx RF performance requirements) according to one embodiment of the present disclosure. In one embodiment of the present disclosure, a UE satisfying these RF requirements may perform a RACH procedure. When the UE transmits a message, data, signaling, etc. to a gNB, the UE satisfies the Tx RF performance requirements described in the first embodiment of this specification. When the UE receives a message, data, signaling, etc. from a gNB, the UE satisfies the Rx RF performance requirements described in the first embodiment of this specification.

[0132] To connect a UE to a 5G network, the UE and the 5G network must be synchronized in the uplink and downlink. Downlink synchronization is performed when the UE successfully decodes the SSB transmitted by the gNB. To establish uplink synchronization and an RRC connection, the UE must perform the RACH random access procedure.

[0133] Two types of random access procedures are supported. The two types of random access procedures are a 4-stage Random Access (RA) type using MSG1 and a 2-stage RA type using MSGA.

[0134] The two types of RA procedures can support Contention Based Random Access (CBRA) and Contention Free Random Access (CFRA), respectively, as shown in Figures 5a through 5e below. The UE can select the random access type when starting the random access procedure according to the network configuration.

[0135] Referring to Figures 5a and 5c, a four-step RA type using MSG1 is described.

[0136] The MSG1 of the 4-step RA type includes a PRACH preamble. The UE transmits the MSG1. After the UE transmits the MSG1, the UE monitors the network for a response within a set period.

[0137] In the case of a CBRA according to the example of Fig. 5a, when the UE receives a random access response (MSG2) from the gNB, the UE can transmit MSG3 using a UL grant scheduled by the response message. The UE can then monitor contention resolution. If contention resolution is not successful even after the MSG3 (re)transmission, the UE performs the MSG1 transmission again.

[0138] In the case of CFRA according to the example of Fig. 5c, a dedicated preamble for transmitting MSG1 is allocated by the network. The gNB transmits the RA preamble allocation to the UE. The UE transmits MSG1 containing the random access preamble to the gNB. When the UE receives a random access response from the network, it terminates the random access procedure.

[0139] Referring to FIGS. 5b, 5d, and 5e, a two-stage RA type is described. The MSGA of the two-stage RA type includes a random access preamble of PRACH and a PUSCH payload. After the UE transmits the MSGA, the UE monitors the response of the network within a set window.

[0140] In the case of a CBRA according to the example of Fig. 5b, if the UE successfully resolves a race after receiving a network response (e.g., MSGB), the UE terminates the random access procedure. If a fallback indication is received within MSGB, the UE performs an MSG3 transmission using the UL grant reserved in the fallback indication as in Fig. 5e and monitors race resolution. If the resolution is not successful after the MSG3 (re)transmission, the UE performs an MSGA transmission again.

[0141] In the case of CFRA according to the example of Fig. 5d, the UE can receive an RA preamble allocation and a PUSCH allocation from the gNB. Then, dedicated preamble and PUSCH resources can be set for MSGA transmission. The UE transmits MSGA. When the UE receives a network response, the UE terminates the random access procedure.

[0142] If the random access procedure of the 2-stage RA type is not completed even after several MSGA transfers, the UE may be configured to switch to the CBRA of the 4-stage RA type.

[0143] The registration procedure is described. Refer to Section 4.2.2.2 of 3GPP TS 23.502 V16.3.0 (2019-12).

[0144] FIGS. 6 and FIGS. 7 illustrate examples of registration procedures to which the implementation of the present specification applies.

[0145] The UE must register with the network to receive services, enable mobility tracking, and enable reachability. The UE initiates the registration process using one of the following registration types.

[0146] - Initial registration for the 5GS; or

[0147] - Mobility registration update; or

[0148] - Periodic registration update; or

[0149] - Emergency registration

[0150] The general registration procedure of FIGS. 6 and FIGS. 7 applies to all registration procedures described above, but the periodic registration update does not need to include all parameters used in other registration procedures.

[0151] The general registration procedure of FIGS. 6 and 7 is used when a UE is registered to a 3GPP connection when it is already registered to a non-3GPP connection, and vice versa. To register a UE to a 3GPP connection when it is already registered to a non-3GPP connection scenario, an AMF change may be required.

[0152] First, the procedure of Fig. 6 is explained.

[0153] (1) Step 1: The UE sends a Registration Request message to the (R)AN. The Registration Request message corresponds to the AN message.

[0154] A registration request message may include AN parameters. For NG-RAN, AN parameters include, for example, 5G-S-TMSI (5G SAE temporary mobile subscriber identity) or GUAMI (globally unique AMF ID), a selected PLMN (public land mobile network) ID (or PLMN ID and NID (network identifier)), and requested NSSAI (Requested network slice selection assistance information). AN parameters also include an establishment cause. The establishment cause provides the reason for requesting the establishment of an RRC connection. Whether and how the UE includes the requested NSSAI as part of the AN parameters depends on the value of the access stratum connection establishment NSSAI inclusion mode parameter.

[0155] The registration request message may include a registration type. The registration type indicates whether the UE wants to perform an initial registration (e.g., the UE is in the RM-DEREGISTERED state), or a mobility registration update (e.g., the UE is in the RM-REGISTERED state and initiates the registration process because the UE moves, or the UE wants to update a capability or protocol parameter, or requests a change to the set of network slices allowed for the UE to use), or a periodic registration update (e.g., the UE is in the RM-REGISTERED state and initiates the registration process due to the expiration of the periodic registration update timer), or an urgent registration (e.g., the UE is in the restricted service state).

[0156] When a UE performs initial registration, the UE specifies the UE ID in the registration request message as follows, listed in order of decreasing priority.

[0157] i) If the UE has a valid EPS (evolved packet system) GUTI (globally unique temporary identifier), the 5G-GUTI mapped from the EPS GUTI;

[0158] ii) Native 5G-GUTI assigned by the PLMN for which the UE is attempting to register (if available);

[0159] iii) Native 5G-GUTI assigned by a PLMN equivalent to the PLMN for which the UE is attempting to register;

[0160] iv) Native 5G-GUTI assigned by other PLMNs (if available);

[0161] v) Otherwise, the UE includes SUCI (subscriber concealed identifier) ​​in the registration request message.

[0162] If the UE performing the initial registration has both a valid EPS GUTI and a native 5G-GUTI, the UE also marks the native 5G-GUTI as an additional GUTI. If one or more native 5G-GUTIs are available, the UE selects the 5G-GUTIs from items (ii)-(iv) in the list above in decreasing order of priority.

[0163] When the UE performs initial registration with native 5G-GUTI, the UE displays relevant GUAMI information in AN parameters. When the UE performs initial registration with SUCI, the UE does not display GUAMI information in AN parameters.

[0164] In the case of emergency registration, SUCI is included if the UE does not have a valid 5G-GUTI, and PEI is included if the UE does not have a SUPI (subscriber permanent identifier) ​​and does not have a valid 5G-GUTI. In other cases, a 5G-GUTI is included, which indicates the last serving AMF.

[0165] The registration request message may also include security parameters, PDU session status, etc. Security parameters are used for authentication and integrity protection. The PDU session status indicates a previously established PDU session in the UE. When the UE is connected to two AMFs belonging to different PLMNs via a 3GPP connection and a non-3GPP connection, the PDU session status indicates the established PDU session of the current PLMN in the UE.

[0166] (2) Step 2: (R)AN selects AMF.

[0167] If 5G-S-TMSI or GUAMI is not included, or if 5G-S-TMSI or GUAMI does not represent a valid AMF, (R)AN selects an AMF based on (R)AT and the requested NSSAI, where available.

[0168] If the UE is in the CM-CONNECTED state, (R)AN can forward a registration request message to the AMF based on the UE's N2 connection.

[0169] If (R)AN cannot select a suitable AMF, (R)AN performs AMF selection by forwarding a registration request message to the AMF configured in (R)AN.

[0170] (3) Step 3: (R)AN sends a registration request message to the new AMF. The registration request message corresponds to the N2 message.

[0171] The registration request message may include all information and / or part of the information contained in the registration request message received from the UE described in Step 1.

[0172] The registration request message may include N2 parameters. When NG-RAN is used, the N2 parameters include the selected PLMN ID (or PLMN ID and NID), location information and cell ID associated with the cell where the UE is camping, and a UE context request indicating that a UE context including security information in NG-RAN must be established. When NG-RAN is used, the N2 parameters also include the cause for establishment.

[0173] If the registration type indicated by the UE is a periodic registration update, steps 4-19 described below may be omitted.

[0174] (4) Step 4: If the UE's 5G-GUTI is included in the registration request message and the serving AMF has changed since the last registration procedure, the new AMF may call the Namf_Communication_UEContextTransfer service operation on the previous AMF, including the full registration request NAS (non-access stratum) message to request the UE's SUPI and UE context.

[0175] (5) Step 5: The previous AMF can respond to the new AMF for the Namf_Communication_UEContextTransfer call, including the UE's SUPI and UE context.

[0176] (6) Step 6: If SUCI is not provided by the UE or is not retrieved from the previous AMF, the new AMF may initiate the identity request procedure by sending an identity request message to the UE to request SUCI.

[0177] (7) Step 7: The UE may respond with an Identity Response message containing SUCI. The UE derives SUCI using the provided public key of the home PLMN (HPLMN).

[0178] (8) Step 8: The new AMF may decide to call AUSF to initiate UE authentication. In this case, the new AMF selects AUSF based on SUPI or SUCI.

[0179] (9) Step 9: Authentication / security may be established by UE, new AMF, AUSF and / or UDM.

[0180] (10) Step 10: If the AMF is changed, the new AMF may call the Namf_Communication_RegistrationCompleteNotify service operation to notify the previous AMF that UE registration is complete for the new AMF. If the authentication / security procedure fails, registration is rejected and the new AMF may call the Namf_Communication_RegistrationCompleteNotify service operation with a reject indication reason code for the previous AMF. The previous AMF may continue as if no UE context passing service operation was received.

[0181] (11) Step 11: If the PEI is not provided by the UE or has not been retrieved from the previous AMF, the new AMF may initiate an Identity Request procedure by sending an Identity Request message to the UE to retrieve the PEI. The PEI is transmitted in encryption, except in cases where the UE cannot perform emergency registration and be authenticated.

[0182] (12) Step 12: Optionally, the new AMF can call the N5g-eir_EquipmentIdentityCheck_Get service operation to start ME ID checking.

[0183] Now, the procedure of Fig. 7 following the procedure of Fig. 6 is explained.

[0184] (13) Step 13: If you perform Step 14 below, the new AMF can select a UDM based on SUPI, and the UDM can select a UDR instance.

[0185] (14) Step 14: New AMFs can be registered with UDM.

[0186] (15) Step 15: The new AMF can select PCF.

[0187] (16) Step 16: The new AMF may optionally establish / modify AM policy associations.

[0188] (17) Step 17: The new AMF can send update / release SM context messages (e.g., Nsmf_PDUSession_UpdateSMContext and / or Nsmf_PDUSession_ReleaseSMContext) to the SMF.

[0189] (18) Step 18: If the new AMF and the previous AMF are in the same PLMN, the new AMF can send a request to modify the UE context to N3IWF / TNGF / W-AGF.

[0190] (19) Step 19: N3IWF / TNGF / W-AGF can send a UE context modification response to the new AMF.

[0191] (20) Step 20: After the new AMF receives a response message from N3IWF / TNGF / W-AGF in Step 19, the new AMF can register with UDM.

[0192] (21) Step 21: The new AMF sends a Registration Accept message to the UE.

[0193] The new AMF sends a registration acceptance message to the UE indicating that the registration request has been accepted. If the new AMF assigns a new 5G-GUTI, the 5G-GUTI is included. If the UE is already in the RM-REGISTERED state via another connection on the same PLMN, the UE uses the 5G-GUTI received in the registration acceptance message for both registrations. If the registration acceptance message does not include a 5G-GUTI, the UE uses the 5G-GUTI assigned to the existing registration for the new registration as well. If the new AMF assigns a new registration area, it transmits the registration area to the UE via the registration acceptance message. If the registration acceptance message does not contain a registration area, the UE considers the previous registration area to be valid. Mobility Restrictions are included when mobility restrictions apply to the UE and the registration type is not an urgent registration. The new AMF indicates the PDU session established for the UE in the PDU session state. The UE locally removes internal resources associated with PDU sessions that are not marked as established in the received PDU session state. When a UE connects to two AMFs belonging to different PLMNs via a 3GPP connection and a non-3GPP connection, the UE locally removes internal resources associated with the PDU session of the current PLMN that are not indicated as established in the received PDU session state. If PDU session state information is present in the registration acceptance message, the new AMF instructs the UE on the PDU session state.

[0194] The allowed NSSAI (allowed NSSAI or partially allowed NSSAI) provided in the registration acceptance message is valid in the registration area and applies to all PLMNs having a tracking area included in the registration area. Mapping of (partially) allowed NSSAI is mapping the HPLMN S-NSSAI to each S-NSSAI of the allowed NSSAI. Mapping of Configured NSSAI is mapping the HPLMN S-NSSAI to each S-NSSAI of the configured NSSAI for the serving PLMN.

[0195] Additionally, the new AMF optionally performs UE policy association establishment.

[0196] (22) Step 22: If the UE succeeds in updating itself, it can send a Registration Complete message to the new AMF.

[0197] The UE can send a registration completion message to the new AMF to check if a new 5G-GUTI has been assigned.

[0198] (23) Step 23: In the case of registration via a 3GPP connection, if the new AMF does not release the signaling connection, the new AMF may send RRC Inactive Assistance information to the NG-RAN. In the case of registration via a non-3GPP connection, if the UE is in a CM-CONTENED state on the 3GPP connection, the new AMF may send RRC Inactive Assistance information to the NG-RAN.

[0199] (24) Step 24: AMF can perform information updates on UDM.

[0200] (25) Step 25: The UE can execute network slice-specific authentication and authorization (NSSAA) procedures.

[0201] Ambient IoT refers to Internet of Things (IoT) technology that operates on low power and continuously collects and transmits data in the ambient environment. Traditional IoT systems often required batteries or wired power. Ambient IoT utilizes technologies such as energy harvesting and backscattering to enable devices to operate for extended periods without a power supply.

[0202] For example, energy harvesting can refer to a technology in which a device collects a small amount of energy from the ambient and converts it into electricity. For example, backscattering can refer to a technology in which a device transmits data using the principle of radio wave reflection (backscattering).

[0203] Ambient IoT can be utilized in various application fields such as smart packaging, logistics management, environmental monitoring, and healthcare.

[0204] For reference, in the disclosure of this specification, Ambient IoT and AIoT may be used as terms with the same meaning. An AIoT device may refer to a device that supports operations based on Ambient IoT.

[0205] Technologies are being developed to support terminals that acquire energy and transmit data using methods such as harvesting and backscattering. It is necessary to acquire the location information of AIoT devices as accurately as possible and transmit it to the network.

[0206] Architecture support for ambient power-enabled IoT devices is being researched.

[0207] Methods to support AIoT devices can be studied with the following goals:

[0208] - Architecture for supporting Ambient IoT, including security support, device ID verification, and security support for Ambient IoT devices or groups of Ambient IoT devices, including security support, device operation and service security.

[0209] - Identification, subscription, registration, and connection management for supporting Ambient IoT devices. For example, it may be studied whether subscription management, registration management, and / or connection management are required, and if necessary, to identify the necessary state machines, procedures, and functions by considering the functions and characteristics of Ambient IoT devices. For example, considering the functions and characteristics of Ambient IoT devices, it may be studied whether reachability and paging are applied to Ambient IoT devices and how they are applied, and if so, what impact they have. Methods for identifying Ambient IoT devices or device groups and the format of the identifiers may be studied.

[0210] - Ambient IoT service. For example, a method to support the transmission of information regarding Ambient IoT services and related system functions can be studied. An Ambient IoT service and a method enabled to be exposed to AF can be studied.

[0211] For example, RAN3 is also seeking ways to support Ambient IoT Devices through a study titled FS_Ambient_IoT_Solutions_RAN (Study on solutions for Ambient IoT (Internet of Things) in NR - RP-234058) in Rel-19. The objectives of the aforementioned study are as follows. The contents of the study are to be captured in TR 38.769. For example, it is necessary to study the signaling and procedures for the CN-RAN interface to enable paging, device context management, and / or data transport. As another example, aspects of the RAN architecture need to be identified, including whether to support a split architecture (e.g., an architecture separated into gNB-DU and gNB-CU). As another example, there is a need to identify potential solutions for locating ambient IoT devices without affecting standard specifications (e.g., by reusing existing user location reporting procedures or by making minimal changes to specifications for conveying location information to the core network).

[0212] Referring to Figures 8a and 8b, examples of connectivity topologies for Ambient IoT networks and devices defined in TR 38.848 V18.0.0 are described. For reference, in the case of Topology 2 of Figure 8b, a UE may act as an intermediate node.

[0213] The following drawings are made to illustrate a specific example of the present specification. The names of specific devices or specific signals / messages / fields described in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the following drawings.

[0214] Figures 8a and 8b show examples of topologies related to Ambient IoT.

[0215] FIG. 8a shows an example of topology 1, and FIG. 8b shows an example of topology 2. In FIG. 8a and FIG. 8b, BS may mean a base station.

[0216] Referring to Fig. 8a, an example of Topology 1 is described. In Topology 1, the base station can communicate directly with the Ambient IoT device.

[0217] In Topology 1, Ambient IoT devices can communicate directly and bidirectionally with a base station. Communication between the base station and the Ambient IoT device may include Ambient IoT device data and / or signaling. In this topology, there may be a possibility that the base station transmitting signals to the Ambient IoT device and the base station receiving signals from the Ambient IoT device are different.

[0218] For reference, in various examples of the disclosure of this specification, an Ambient IoT device may also be referred to as an Ambient device.

[0219] In topology 2 according to the example of Fig. 8b, the Ambient IoT device can communicate indirectly with the base station.

[0220] In Topology 2, Ambient IoT devices can communicate bidirectionally with intermediate nodes between the device and the base station. In this topology, intermediate nodes can be Ambient IoT-enabled relays, IAB nodes, UEs, repeaters, etc. Intermediate nodes can transmit Ambient IoT data and / or signals between the BS and the Ambient IoT device.

[0221] For reference, in the disclosure of this specification,

[0222] Regarding the study on AIoT, the scenarios considered in RAN1 are as shown in Figures 9a to 9h and Table 3.

[0223] Scenario Carrier-Wave (CW) Inside / Outside Topology Scenario Diagram Scenario Description Device 1 / 2a / 2b CW Spectrum D2R Spectrum R2D Spectrum D1T1-A1 CW inside topology (Refer to Diagram 9a) CW node inside topology 1. 'CW' in CW2D and 'R2' in D2R are different. 'CW' in CW2D and 'R1' in R2D are identical. 'R1' in R2D and 'R2' in D2R are different. Device 1, 2a Case 1-1 (inside topology, DL) Case 1-2 (inside topology, UL) Same as CW D1T1-A2 (Refer to Diagram 9b) CW node inside topology 1. The 'CW' node and 'R' node for CW2D, D2R, and R2D are identical. D1T1-A1 and Same CW and Same D1T1-BCW outside topology (refer to Diagram 9c) CW node outside topology 1. 'CW' in CW2D and 'R' in D2R are different. 'CW' in CW2D and 'R' in R2D are different. 'R' in R2D and 'R' in D2R are identical. Case 1-4 (outside topology, UL) Same D1T1-CNo CW (refer to Diagram 9d) There is no CW node. Device 2bN / AULD2T2-A1. CW inside topology (refer to Diagram 9e) CW node inside topology 2. 'CW' in CW2D and 'R2' in D2R are different. 'CW' in CW2D and 'R1' in R2D are the same. 'R1' in R2D and 'R2' in D2R are different. BS communicates with R1 and R2. Device 1, 2a Case 2-2 (inside topology, UL) Same as CW D2T2-A2 Refer to 9f CW node inside topology 2CW2D, D2R and R2D The 'CW' node and 'R' node are the same. BS communicates with R.Same as D2T2-A1. Same as D2T2-BCW outside topology (refer to 9g). CW node outside topology. The 'CW' in CW2D and the 'R' in D2R are different. The 'CW' in CW2D and the 'R' in R2D are different. The 'R' in R2D and the 'R' in D2R are the same. BS communicates with R. Case 2-3 (outside topology, DL) Case 2-4 (outside topology, UL). Same as CW. D2T2-CNo. CW (refer to 9h). There is no CW node. BS communicates with R. BS communicates with R device 2bN / AFFS. Note: This table is for the case where D2R is in the same spectrum as CW2D.

[0224] Table 3 is an example of evaluation scenarios for TR38.769 V1.0.0. In this regard, TR 38.769 V1.0.0 Table 4.2.1-1: Evaluation scenarios may be referenced.

[0225] D2R stands for Device to Reader, and R2D can stand for Reader to Device.

[0226] In the examples in Table 3, CW inside topology refers to examples where the leader includes CW, and CW outside topology refers to examples where the leader does not include CW. No CW refers to cases where CW does not exist.

[0227] In the examples in Table 3, TR38.769 V1.0.0 may be referenced for Device 1 / 2a / 2b. Device 1, Device 2a, and Device 2b may support AIoT-related operations. For example, Device 1 / 2a / 2b may each mean the following.

[0228] Device 1: Device 1 supports a peak power consumption of ~1 μW. Device 1 possesses energy storage capabilities. Device 1 supports an initial sampling frequency offset (SFO) of up to 10X ppm. Device 1 does not support in-device DL amplification or UL amplification. UL transmission by Device 1 is achieved by backscattering an externally provided carrier wave.

[0229] Device 2a: The peak power consumption of Device 2a is less than several hundred μW. Device 2a possesses energy storage capabilities. The initial SFO of Device 2a can be up to 10X ppm. Device 2a can support in-device DL amplification and / or UL amplification. UL transmission of Device 2a is achieved by backscattering an externally provided carrier wave.

[0230] Device 2b: The peak power consumption of Device 2b is less than several hundred μW. Device 2b possesses energy storage capabilities. The initial SFO of Device 2b can be up to 10X ppm. Device 2b can support in-device DL amplification and / or UL amplification. The UL transmission signal of Device 2b can be generated internally within the device without the aid of an externally provided carrier wave.

[0231] In the example in Table 3, DL may mean downlink and UL may mean uplink. BS may be a base station.

[0232] With regard to the diagram of the scenario in Table 3, refer to Figures 9a to 9h below.

[0233] The following drawings are made to illustrate a specific example of the present specification. The names of specific devices or specific signals / messages / fields described in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the following drawings.

[0234] FIGS. 9a through 9h illustrate an example of a procedure according to the first example of the disclosure of the present specification.

[0235] For reference, in FIGS. 9a through 9h, D may represent an AIoT device. R may represent a leader. CW may be a CW node that transmits a CW signal.

[0236] Figure 9a is an example of the D1T1-A1 scenario. R1 and CW may be located in the same position. Alternatively, R1 and CW may be included in the same device. For example, a single device may function as R1 and CW. In the example of Figure 9a, R1 / CW may transmit CW2D and R2D to the AIoT device. In the example of Figure 9a, R2 may receive D2R transmitted by the AIoT device. In Figure 9a, 'CW' in CW2D and 'R2' in D2R are different. 'CW' in CW2D and 'R1' in R2D are the same. 'R1' in R2D and 'R2' in D2R are different. In Figure 9a, R1 may be a reader transmitting the R2D message, and R2 may be a reader receiving the D2R message.

[0237] Figure 9b is an example of the D1T1-A2 scenario. In the example of Figure 9b, R / CW can transmit CW2D and R2D to the AIoT device. The AIoT device can transmit D2R to R / CW. The 'CW' node and 'R' node for CW2D, D2R, and R2D are identical.

[0238] Figure 9c is an example of the D1T1-B scenario. In the example of Figure 9c, R can transmit R2D to the AIoT device. CW can transmit CW2D to the AIoT device. The AIoT device can transmit D2R to R. The 'CW' in CW2D and the 'R' in D2R are different. The 'CW' in CW2D and the 'R' in R2D are different. The 'R' in R2D and the 'R' in D2R are identical.

[0239] Figure 9d is an example of the D1T1-C scenario. In the example of Figure 9d, R can transmit R2D to the AIoT device. The AIoT device can transmit D2R to R. In the example of Figure 9d, there is no CW node.

[0240] Figure 9e is an example of the D2T2-A1 scenario. R1 / CW can communicate with the base station (BS). R2 can communicate with the base station. R1 / CW can transmit CW2D and R2D to the AIoT device. The AIoT device can transmit D2R to R2. 'CW' in CW2D and 'R2' in D2R are different. 'CW' in CW2D and 'R1' in R2D are the same. 'R1' in R2D and 'R2' in D2R are different. The BS communicates with R1 and R2.

[0241] Figure 9f is an example of a D2T2-A2 scenario. BS can communicate with R / CW. R / CW can transmit CW2D and R2D to the AIoT device. The AIoT device can transmit D2R to R / CW. The 'CW' node and 'R' node for CW2D, D2R, and R2D are identical. BS communicates with R.

[0242] Figure 9g is an example of a D2T2-B scenario. In the example of Figure 9g, BS can communicate with R. R can transmit R2D to the AIoT device. CW can transmit CW2D to the AIoT device. The AIoT device can transmit D2R to R. The 'CW' in CW2D and the 'R' in D2R are different. The 'CW' in CW2D and the 'R' in R2D are different. The 'R' in R2D and the 'R' in D2R are the same. BS communicates with R.

[0243] Figure 9h is an example of a D2T2-C scenario. R can transmit R2D to an AIoT device. The AIoT device can transmit D2R to R. In the example of Figure 9h, there is no CW node.

[0244] For example, as described above in the examples of Table 3 and Figures 9a through 9h, there may be a situation where Reader #1 transmits a CW or R2D message to an AIoT device, and Reader #2 receives a D2R message transmitted by the AIoT device. According to the prior art, there was no method to effectively and / or accurately support AIoT communication in such a situation.

[0245] For example, in the examples of Table 3 and Figures 9a through 9h, for D1T1-A1 and D2T2-A1, a situation is considered in which Reader #1, which performs R2D transmission to the AIoT device, and Reader #2, which receives D2R transmission from the AIoT device, are different. In this case, the power of the D2R transmitted by the AIoT device may be relatively smaller than the power of the R2D sent by Reader #1. Consequently, for D1T1-A1 and D2T2-A1, a situation may be considered in which Reader #2, which is relatively closer than Reader #1 or can reach without obstacles (or can transmit the signal without obstacles), receives the D2R of the AIoT device. Additionally, in the above scenario, it is assumed that the CW node transmitting CW2D for the D2R backscattering of the AIoT device is located at the same position as Reader #1 (or the same position as Reader #1).

[0246] In this situation, if the CW node transmits CW2D with excessive power, CW2D may act as a form of interference at Reader #2. This could hinder Reader #2 from receiving D2R transmitted by the AIoT device. Furthermore, if the power of the CW2D transmitted by the CW node is too low, the AIoT device may not be able to meet the energy requirements for transmitting D2R. Therefore, measures such as the following example are necessary for Reader #1 and / or the CW node to appropriately regulate the power of R2D or CW2D. For instance, a method is required for the AIoT device to transmit measurement results (e.g., CW2D reception power) to Reader #1 or the CW node via Reader #2.

[0247] Additionally, for Reader #1 to transmit R2D to the AIoT device, Reader #2 needs to obtain some information included in the D2R message (e.g., Random ID included in D2R), and Reader #2 needs to transmit this information to Reader #1. Specifically, regarding Random ID, TR38.769 V1.0.0 may be referenced. For example, an example of an AIoT device performing a random access procedure is as follows. For example, the AIoT device may transmit a random access preamble (e.g., A-IoT Msg1). When the AIoT device identifies the start of its own access occupation, it may transmit a random access preamble (e.g., A-IoT Msg1) containing a single 16-bit random ID generated by the AIoT device to the reader. In the case of D1T1-A1 and D2T2-A1, Reader #2 may receive the random access preamble. In this situation, Reader #1 needs to send a random access response (e.g., A-IoT Msg2) to the AIoT device. For example, Reader #1 can send a random access response (e.g., A-IoT Msg2) containing a random ID that the reader has successfully received to the AIoT device. If the AIoT device receives the random access response (e.g., A-IoT Msg2) and the random ID included in the random access response (e.g., A-IoT Msg2) is the same as the random ID previously sent in the random access preamble (e.g., A-IoT Msg1), contention resolution can be considered successful. However, as previously explained, since Reader #2 has received the random access preamble (e.g., A-IoT Msg1) from the AIoT device, Reader #2 needs to convey some of the information included in the D2R message (e.g., Random ID included in D2R) to Reader #1.

[0248] According to one embodiment of the disclosure of this specification, information related to resource scheduling (e.g., energy required for D2R transmission, UL data size, etc.) and / or measurement results (e.g., received power for CW2D / R2D, etc.) may be included in a D2R message transmitted by an AIoT device to a Reader. A Reader that receives a D2R message (e.g., Reader #2) may transmit the information (e.g., information included in the D2R message) to a Reader that transmits R2D (e.g., Reader #1) via a base station (e.g., CU in a CU-DU split situation) or AIoTF.

[0249] The method proposed in the disclosure of this specification, in which Reader #2 measures / collects information related to the measurement results and / or resource scheduling of an AIoT Device and transmits it to Reader #1, is composed of a combination of one or more operations / configurations / steps described below.

[0250] In this specification, UE (User Equipment) and terminal may be used interchangeably.

[0251] In this specification, Subscriber and User may be used interchangeably.

[0252] In this specification, network, Core Network (CN), 5G CN, 3GPP network, and 3GPP system may be used as terms with the same meaning.

[0253] In this specification, terms such as zone, area, region, sector, zone, area, region, etc., may be used interchangeably.

[0254] In this specification, AIoTF (AIoT Function) is a Network Function or Functionality that supports Ambient IoT.

[0255] For reference, AIoT may be co-located to or supported by conventional NFs (e.g., AMF, NEF, UPF, etc.), or may exist in a standalone form. Additionally, the names of AIoTFs disclosed in this specification are merely examples, and AIoTFs may be referred to by various names (e.g., AIoT NF, AIoT GW, etc.).

[0256] In this specification, AIoT-RAN (A-RAN) can be interpreted as a base station, RAN, Base Station, RAN node, etc., having a reader function.

[0257] In this specification, the NG or NG-like (NG') interface may be an N2 or N2-like (N2') interface, an N3 or N3-like (N3') interface, or an N2 / N3 or N2 / N3-like (N2' / N3') interface. Alternatively, an interface with a new name may be defined for the interface between the A-RAN and the Core Network.

[0258] For some or all of the service operations between Core NFs described in the various examples disclosed in this specification, a new service operation may be defined and used. Additionally, for some or all of the NG messages between AMF and NG-RAN described in the disclosure of this specification, a new NG message may be defined and used. Additionally, for some or all of the RRC messages between NG-RAN and the terminal described in the disclosure of this specification, a new RRC message may be defined and used.

[0259] Some of the steps described in the various examples disclosed in this specification may be performed simultaneously / in parallel, or in an alternate order.

[0260] The names of indication or parameter information proposed in various examples of the disclosure of this specification are merely examples, and for the procedures / purposes / methods proposed in the disclosure of this specification, the following names may be interpreted as being replaced by other names.

[0261] The first to third examples of the disclosure of this specification described below may be combined with each other or applied independently.

[0262] 1. First example of the disclosure of this specification

[0263] In the first example of the disclosure of this specification, an example of a procedure for supporting an AIoT device based on topology 1 is described.

[0264] Hereinafter, with reference to FIGS. 10a and FIGS. 10b, an example of alternative #1 (intra-CU inter-DU case) of the first example disclosed herein will be described.

[0265] The following drawings are made to illustrate a specific example of the present specification. The names of specific devices or specific signals / messages / fields described in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the following drawings.

[0266] FIGS. 10a and FIGS. 10b illustrate a first example of a procedure according to a first example of the disclosure of the present specification.

[0267] The examples in Figures 10a and 10b are examples of the entire procedure for supporting an AIoT device in topology 1.

[0268] In FIGS. 10a and 10b, it is assumed that Reader #1 is included in DU#1, Reader #2 is included in DU#2, and DU#1 and DU#2 are connected to the same CU (e.g., Intra-CU inter-DU case).

[0269] In addition, it is assumed that the CW node sending the carrier wave for D2R backscattering (for UL transmission) of the AIoT device is located in Reader #1 or DU #1. An embodiment according to the example of FIGS. 10a and 10b may also be applied even when Reader #1, Reader #2, and the CW node are included in the same DU.

[0270] In addition, the embodiment of the example in FIG. 10a and FIG. 10b may also be applied when Reader #1 and Reader #2 are included in DU #1 and a CW node is included in DU #2. In this case, the AIoT device can perform D2R / R2D transmission with Reader #1 and Reader #2 included in DU #1. In this case, the CW node included in DU #2 may also transmit a carrier-wave. Therefore, in this case, to perform power control for the CW node included in DU #2, the CU may receive measurement results from the AIoT device through the Reader included in DU #1 and transmit them to the CW node.

[0271] Step 1: In Step 1a, a DU of an A-RAN with one or more Readers may send an F1 (or F1') SETUP REQUEST message to a CU of the A-RAN. The setup request message may include, for example, a supported area index and / or CW information (or information related to the CW).

[0272] For reference, in the disclosure of this specification, CW information (or information related to CW) may include information related to whether the Reader and the CW are collocations; and / or characteristics of the carrier-wave waveform.

[0273] For example, the DU of the A-RAN (DU#1 and / or DU#2) can start the setup process for the F1 interface or F1-like (i.e., F1') interface with the CU by sending an F1 (or F1') SETUP REQUEST message to the CU of the A-RAN.

[0274] The DU of an A-RAN may include one or more of the following Reader information (e.g., Reader-related information) related to each Reader in the F1 (or F1') SETUP REQUEST message:

[0275] - Reader ID;

[0276] - Location information for the area handled by the Reader:

[0277] i) Geographical location information;

[0278] ii) TAI, cell ID information; and / or

[0279] iii) External area information (e.g., Warehouse #1, Warehouse #2, address information, etc.).

[0280] - When the area managed by the Reader is divided into multiple areas or zones, the coordinate information of the said area or zone and the corresponding area index or zone index. If the DU of the A-RAN provides the CU with geographical location information managed by the Reader, the CU may compile this information and provide it to the AIoTF. For example, based on the geographical location information managed by the Reader and the corresponding area index, the DU of the A-RAN may transmit the ID of the reader to whom the A-IoT device sent a response, the area index, etc., to the CU. Then, the CU may convert the area index received from the DU into geographical location information and transmit it to the AIoTF, or perform the reverse operation. For example, the reverse operation may include the operation where, if the AIoTF transmits geographical location information to the CU, the CU generates area index information based on the geographical location information and transmits the area index information to the DU;

[0281] - Information regarding whether Reader and CW are collocationd; and / or

[0282] - Characteristics of the carrier-wave waveform:

[0283] i) spectrum used for CW transmission (e.g., DL or UL); and / or

[0284] ii) Carrier frequency used in CW transmission.

[0285] The above geographical location information and coordinate information may be various forms of information defined, for example, in TS 23.032 V18.1.0 "Universal Geographical Area Description (GAD)". This may be applied throughout this specification.

[0286] Area index and / or zone index information may represent area index and / or zone index related to an area that is jointly managed by one or more readers, rather than being handled by only one Reader. For example, as shown in the example of FIG. 11, multiple areas may be assigned to multiple readers.

[0287] The following drawings are made to illustrate a specific example of the present specification. The names of specific devices or specific signals / messages / fields described in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the following drawings.

[0288] FIG. 11 shows an example of an area managed by one or more readers according to one embodiment of the disclosure of the present specification.

[0289] Referring to the example in Fig. 11, Leader A can be in charge of areas 1 and 2. Leader B can be in charge of areas 3 and 4. Leader C can be in charge of areas 1 and 3. Leader D can be in charge of areas 2 and 4.

[0290] For example, Area 1 can be handled by both Leader A and Leader C.

[0291] Referring again to FIG. 10a and FIG. 10b, a procedure according to the first example of the disclosure of this specification will be described.

[0292] The CU of the A-RAN can store information related to the Reader received from the DU of the A-RAN. Subsequently, when it receives a request for an AIoT Service operation from the AIoTF, the CU of the A-RAN can utilize the information related to the Reader.

[0293] For reference, if the Reader belongs to the CU, the CU may pre-transmit information necessary for transmitting signaling for energy harvesting to the DU through the F1 (or F1') Setup process or other F1 (or F1') signaling so that the AIoT Device can perform energy harvesting. Additionally, to support the case where the AIoT Device sends a response to an Inventory Request message, the CU may pre-transmit configuration information necessary for the DU to receive the response and / or information necessary for the DU to transmit the response to the CU.

[0294] Step 2: The CU of A-RAN can perform a process to set up an AIoTF and NG interface or an NG-like (i.e., NG') interface.

[0295] For example, during the process of setting up an NG interface or an NG-like (i.e., NG') interface, a CU of an A-RAN may collect Reader information (e.g., information related to the Reader) received from a DU managed by the CU and transmit it to the AIoTF. For example, the Reader information (e.g., information related to the Reader) may be the information described in Step 1.

[0296] For reference, FIGS. 10a and 10b assume that the A-RAN is directly connected to the AIoTF, or that the AMF and AIoTF are co-located, or that the AMF has the functions of the AIoTF (e.g., the operation of the AIoTF in FIGS. 10a and 10b may be the operation of the AMF), but this is merely an example. The example in FIGS. 10a and 10b may also apply to a situation where the A-RAN is connected to the AIoTF through the AMF. In this case, the AMF may separately transmit information related to the Reader received in Step 2 (e.g., Supported area index) to the AIoTF.

[0297] Step 3: The CU of the A-RAN can complete the F1 (or F1') setup process by sending an F1 SETUP RESPONSE message or an F1' SETUP RESPONSE message to the DU.

[0298] Step 4: AIoTF can perform procedures related to AIoT services for CU.

[0299] For example, based on a request from AF, etc., AIoTF may request an AIoT service (e.g., for Inventory) for specific AIoT Device(s) and / or AIoT Device(s) located in a specific region from the CU of the A-RAN. In Step 4, the NG' AIoT Service message (e.g., a message related to the AIoT service) transmitted by AIoTF to the CU may include the following information. For example, the information related to the NG' AIoT Service message may include some or all of the following:

[0300] - AIoT service operation you want to request (eg, Inventory-only, Command-only, Inventory and Command)

[0301] - Assistance information regarding service operation. For example, it may include one or more of the following information:

[0302] i) Information on whether to perform a new service operation;

[0303] ii) Allowed age information (information on how long ago information obtained may be sent instead of performing a new operation);

[0304] iii) an indication requesting already stored information instead of a new service operation; and / or

[0305] iv) Information on how to transmit AIoT Device information (e.g., a response transmitted by the AIoT device) (e.g., immediate, periodic, timer-based (e.g., timer information may also be included in this case), whether aggregation is needed or not, information to transmit AIoT Device information when a response is received for all AIoT Devices that are targets of the AIoT service, etc.). For example, if inventory is used as the AIoT service, the AIoT Device information (e.g., a response transmitted by the AIoT device) may be the ID of the AIoT Device. For example, in the disclosure of this specification, the response transmitted by the AIoT device may be information included in a random access preamble transmitted by the AIoT device. For example, in this case, the AIoT Device information may include at least one of the receiving power of the AIoT device for the waveform transmitted by the CW, the size of the UL data that the AIoT device intends to transmit, and / or the energy required for the AIoT device to perform D2R transmission. In this case, the AIoT Device information may include one or more of the information described in the example of Step 8.

[0306] - List of Reader IDs to perform AIoT service operations

[0307] - List of AIoT Device IDs eligible for the AIoT service

[0308] - Information about the area where AIoT services are to be provided (e.g., area info). May include one or more of the following:

[0309] i) Geographical location information;

[0310] ii) External area information (e.g., Warehouse #1, Warehouse #2, address information, etc.).

[0311] Additionally, TR 23.700-13 V1.0.0 and TR 38.769 V1.0.0 may be referenced for parameters included in the NG' AIoT Service message.

[0312] Step 5: The CU of the A-RAN can send AIoT paging messages to DU#1.

[0313] For example, in Step 5a, the CU of the A-RAN may decide to trigger AIoT Paging to find specific AIoT Device(s) and / or AIoT Device(s) located in a specific region based on the information received in Step 4. Accordingly, the CU of the A-RAN may include information such as the ID of the device to be found and / or the region in the F1' AIoT PAGING message and transmit it to a Reader located in the DU (e.g., DU#1).

[0314] In this case, service operations for the AIoT Device may be performed through one or more Readers as needed. For example, if the Area index is an area jointly managed by one or more Readers, service operations may be performed based on one or more Readers.

[0315] A Reader located in the DU can generate an AIoT Paging message based on the information received in Step 5a and transmit the AIoT Paging message to an AIoT device.

[0316] Step 6: The AIoT device may determine the Random access type and access occasion / resource, etc., to perform a Random access procedure. The AIoT device may decide to use contention-based Random access. In this case, at Step 6a, the AIoT device may transmit a Random access preamble containing some or all of the following information toward the base station. Reader #2, included in DU #2, may receive the Random access preamble transmitted by the AIoT device. FIGS. 10a and 10b assume that Reader #1 (in DU #1), which transmitted the AIoT Paging message in Step 5, and Reader #2, which receives the Random access preamble, are included in different DUs. One or more of the following information may be included in the Random access preamble transmitted by the AIoT device:

[0317] - Random ID generated or assigned by the terminal (e.g., AIoT device) itself and / or Device ID received from an upper layer, and / or Device ID stored within the terminal (e.g., AIoT device), etc.;

[0318] - Assistance information for power control of the CW located in Reader #1. For example, assistance information may include one or more of the following information:

[0319] i) the receiving power of the AIoT device for the waveform transmitted by the CW; and / or

[0320] ii) Amount of energy harvesting in the AIoT device through the waveform transmitted by the CW.

[0321] - The size of the UL data that the AIoT device intends to transmit; and / or

[0322] - Energy required for an AIoT device to perform D2R transmission.

[0323] Additionally, TR 23.700-13 V1.0.0 and TR 38.769 V1.0.0 may be referenced for parameters related to the Random access procedure.

[0324] Reader #2, having received the Random access preamble in Step 6b, can include the information received from the AIoT Device in the F1'AP UL AIoT MESSAGE TRANSFER message and transmit it to the CU. Reader #2 can put the Random access preamble received in Step 6a into a container and transmit it to the CU of the A-RAN. In this case, the CU may transmit the Random access preamble transmitted by the AIoT Device via Step 7a to Reader #1 located at DU #1 of the A-RAN.

[0325] For reference, if the AIoT device decides to use contention-free random access based on SIB information received from the base station, information pre-configured within the device, and / or information received in Step 5, Steps 6 and 7 may be skipped.

[0326] Step 7: Based on the Device ID and / or Group ID included in Step 5, and / or the Device ID and / or Group ID information received in Step 6, the CU of the A-RAN can determine that the AIoT device received an AIoT Paging message through Reader #1 and transmitted a Random access preamble through Reader #2.

[0327] In Step 6, the AIoT device may include a Random ID instead of a Device ID in the Random Access Preamble. In this case, so that the CU can know that Step 6 was executed in response to Step 5 (e.g., so that the CU can know that the Reader performing R2D and the Reader performing D2R for the AIoT device are different), DU#1 in Step 5b may include the Reader ID in the AIoT Paging message and send it to the CU. Additionally, the AIoT device may include the Reader ID received in Step 5 (i.e., the ID for Reader#1) in the Random Access Preamble and transmit the Random Access Preamble to the CU through Reader#2. Therefore, the CU of the A-RAN may know that the Reader performing R2D and the Reader performing D2R for the AIoT device are different based on the ID for Reader#1 included in the Random Access Preamble.

[0328] In Step 7a, the CU of the A-RAN can request contention resolution for the AIoT device by transmitting the information received in Step 6b to Reader #1. For example, the CU of the A-RAN can transmit a DL AIoT MESSAGE TRANSFER message containing the information received in Step 6b to DU #1.

[0329] In Step 7b, Reader #1 can generate a Random access response and send it to the AIoT device after successfully completing contention resolution for the AIoT device based on the information received in Step 7a.

[0330] If Reader #2 delivers a container containing a Random access preamble to CU in Step 6b, CU may deliver the container containing the Random access preamble to Reader #1 in Step 7a. In this case, Reader #1 may perform contention resolution for the AIoT device based on the Random access preamble received through Reader #2 and CU, generate a Random access response, and transmit the Random access response to the AIoT device.

[0331] Step 8: After successfully completing the random access process through Steps 6 and 7, or when using contention-free random access, the AIoT device may transmit a D2R transmission message. For example, the AIoT device may transmit information, such as UL data and / or Device ID received from the upper layer, to Reader #2 via D2R transmission, and Reader #2 may forward the message (or information) transmitted by the AIoT device to the base station. For example, as in Step 6b, Reader #2 may include the D2R transmission message received in Step 8a as is in a container and transmit an F1'AP UL AIoT MESSAGE TRANSFER message containing this container to the CU. As another example, Reader #2 may also forward only the information, such as UL data and / or Device ID, included in the message received in Step 8a to the CU.

[0332] During the D2R transmission process, Reader #1 may transmit to Reader #2, as in Step 6a, some or all of the following information related to resource scheduling for the AIoT device (e.g., information required to perform resource scheduling for the AIoT device). For example, the D2R transmission message of Step 8a may include one or more of the following information:

[0333] - Assistance information for power control of the CW located in Reader #1. For example, assistance information may include one or more of the following information:

[0334] i) the receiving power of the AIoT device for the waveform transmitted by the CW; and / or

[0335] ii) Amount of energy harvesting in the AIoT device through the waveform transmitted by the CW.

[0336] - The size of the UL data that the AIoT device intends to transmit; and / or

[0337] - Energy required for an AIoT device to perform D2R transmission.

[0338] Additionally, TR 23.700-13 V1.0.0 and TR 38.769 V1.0.0 may be referenced for parameters included in the D2R and R2D transmission messages used in Step 8.

[0339] Step 9: The CU of the A-RAN may send an NG (or NG') AIoT SERVICE REPORT message or an NG (or NG') AIoT SERVICE NOTIFY message to the AIoTF. For example, based on the NG (or NG') AIoT SERVICE REPORT or NG (or NG') AIoT SERVICE NOTIFY message, the CU of the A-RAN may forward the response from the AIoT Device received in Step 8 (e.g., Device ID and / or UL data from upper layer in AIoT device) to the AIoTF. The A-RAN may perform authentication on the AIoT Device(s) that sent the response. The A-RAN may include only the responses from AIoT Devices that have passed authentication in the response to the AIoTF. An A-RAN may include one or more of the following information related to the Reader that received the D2R transmission from the AIoT Device and / or the Reader that sent the R2D transmission to the AIoT Device in the NG (or NG') AIoT SERVICE RESPONSE message:

[0340] - Reader ID; and / or

[0341] - Zone index or Area index where an AIoT Device sent a D2R transmission or where the Reader sent an R2D transmission within the area managed by the Reader

[0342] For example, the CU of the A-RAN may receive responses from AIoT Device(s) via Reader(s) for a certain period of time, aggregate all responses, and forward them to the AIoTF, while ignoring any responses from AIoT Device(s) received thereafter. As another example, the CU of the A-RAN may periodically report the responses from AIoT Device(s) aggregated up to that point to the AIoTF at specific intervals within a certain period. Alternatively, whenever a response from an AIoT Device(s) is received, the CU of the A-RAN may immediately forward the response from the AIoT Device(s) to the AIoTF via an NG (or NG') AIoT SERVICE REPORT or NG (or NG') AIoT SERVICE NOTIFY message. The time at which the A-RAN aggregates responses from AIoT Device(s) and / or the pattern of reporting them to the AIoTF may be pre-configured in the A-RAN, or the AIoTF may have pre-configured the A-RAN in Step 1. Alternatively, the A-RAN may receive configuration from the AF or AIoTF through Step 4.

[0343] Step 10: To notify the AIoT device of the successful reception of the D2R transmission in Step 8, the CU of the A-RAN may request an R2D transmission from Reader #1. At this time, the CU of the A-RAN may also transmit to Reader #1 the information received in Step 8b, for example, information related to resource scheduling for the AIoT device. For example, the CU of the A-RAN may transmit a DL AIoT MESSAGE TRANSFER message containing information related to resource scheduling for the AIoT device to DU #1. Alternatively, to enable the CW to continue performing D2R transmissions so that the AIoT device can continue to perform D2R transmissions, the CU of the A-RAN may request only a CW2D transmission from the CW located at Reader #1, without an R2D transmission.

[0344] For example, the DL AIoT MESSAGE TRANSFER message may include information related to R2D transmission and / or information related to CW2D transmission.

[0345] Based on the information received in Step 10a, Reader #1 can perform R2D transmission and / or CW2D transmission to the AIoT device.

[0346] Step 11: Due to a request from AF, etc., AIoTF may request an AIoT service (e.g., for Command) for specific AIoT Device(s) and / or AIoT Device(s) located in a specific region from the CU in A-RAN. For example, AIoTF may send an NG (or NG') AIoT Service message to the CU in A-RAN. Step 4 may be referenced for information related to the NG AIoT Service message. AIoTF may also send information related to the Command sent by AF to the CU in A-RAN.

[0347] Step 12: The CU of the A-RAN can transmit a DL AIoT MESSAGE TRANSFER message to DU#1. For example, the CU of the A-RAN transmits information received from the AIoTF along with a request for R2D transmission to Reader#1 to transmit command-related information to the Reader where the AIoT device is located (e.g., the Reader managing the area where the AIoT device is located) (e.g., Reader#1 and Reader#2 in FIG. 10a and 10b). For example, the DL AIoT MESSAGE TRANSFER message may include information received from the AIoTF and / or information related to R2D transmission. For reference, based on the fact that the DL AIoT MESSAGE TRANSFER message contains information related to R2D transmission, the DU can recognize that an R2D transmission has been requested. If a D2R transmission message was received from the AIoT device in the previous step, the CU of the A-RAN may also transmit information related to resource scheduling included in the D2R transmission message to Reader #1.

[0348] Reader #1, located in DU #1 of A-RAN, can perform R2D transmission and / or CW2D transmission based on information related to resource scheduling received in Step 12a and / or information related to AIoT devices stored by Reader #1, in order to transmit command-related information to AIoT devices.

[0349] Step 13: Based on the command from AF received in Step 12, the AIoT device may execute the command and then transmit a D2R transmission message containing a response to the command to the base station via Reader #2. Step 8 may be referenced for information related to resource scheduling to be included in the D2R transmission.

[0350] Step 14: The CU of the A-RAN can transmit an NG (or NG') AIoT SERVICE REPORT message or an NG (or NG') AIoT SERVICE NOTIFY message to the AIoTF to convey the response from the AIoT Device received in Step 13 (e.g., Device ID, Response to command, and / or UL data from upper layer in AIoT device) to the AIoTF. For the information included in the NG (or NG') AIoT SERVICE REPORT or NG (or NG') AIoT SERVICE REPORT NOTIFY message, Step 9 may be referenced.

[0351] Hereinafter, with reference to FIGS. 12a and FIGS. 12b, an example of alternative #2 (inter-CU case) of the first example disclosed herein will be described.

[0352] The following drawings are made to illustrate a specific example of the present specification. The names of specific devices or specific signals / messages / fields described in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the following drawings.

[0353] FIGS. 12a and FIGS. 12b illustrate a second example of a procedure according to the first example of the disclosure of the present specification.

[0354] The examples in Figs. 12a and 12b are examples of the entire procedure for supporting an AIoT device in topology 1.

[0355] In FIGS. 12a and 12b, it is assumed that Reader #1 is included in A-RAN#1, Reader #2 is included in A-RAN#2, and that A-RAN#1 and A-RAN#2 are connected to the same AIoTF (e.g., Inter-CU case). It is also assumed that the CW node sending the carrier-wave for D2R backscattering (for UL transmission) of the AIoT device is located in Reader #1 or A-RAN#1.

[0356] The embodiments of FIGS. 12a and 12b may also be applied when Reader #1 and Reader #2 are included in A-RAN#1 and a CW node is included in A-RAN#2. In this case, the AIoT device performs D2R / R2D transmission with Reader #1 and Reader #2 included in A-RAN#1. To do this, the CW node included in A-RAN#2 may transmit a carrier-wave. Therefore, to perform power control for the CW node included in A-RAN#2, the AIoTF may receive measurement results from the AIoT device through the Reader included in A-RAN#1 and transmit them to the CW node.

[0357] Step 1: An A-RAN with one or more Readers (e.g., A-RAN#1 and / or A-RAN#2) can start the setup process for an NG interface or an NG-like (i.e., NG') interface with AIoTF by sending an NG (or NG') SETUP REQUEST message to AIoTF.

[0358] An A-RAN (e.g., A-RAN#1 and / or A-RAN#2) may include one or more of the following Reader information (e.g., Reader-related information) related to each Reader within an NG (or NG') SETUP REQUEST message:

[0359] - Reader ID;

[0360] - Location information for the area handled by the Reader:

[0361] i) Geographical location information;

[0362] ii) TAI, cell ID information; and / or

[0363] iii) External area information (e.g., Warehouse #1, Warehouse #2, address information, etc.).

[0364] - When the area managed by the Reader is divided into multiple areas or zones, the coordinate information of the said area or zone and the corresponding area index or zone index. If the DU of the A-RAN provides the CU with geographical location information managed by the Reader, the CU may compile this information and provide it to the AIoTF. For example, based on the geographical location information managed by the Reader and the corresponding area index, the DU of the A-RAN may transmit the ID of the reader to whom the A-IoT device sent a response, the area index, etc., to the CU. Then, the CU may convert the area index received from the DU into geographical location information and transmit it to the AIoTF, or perform the reverse operation. For example, the reverse operation may include the operation where, if the AIoTF transmits geographical location information to the CU, the CU generates area index information based on the geographical location information and transmits the area index information to the DU;

[0365] - Information regarding whether Reader and CW are collocationd; and / or

[0366] - Characteristics of the carrier-wave waveform:

[0367] i) spectrum used for CW transmission (e.g., DL or UL); and / or

[0368] ii) Carrier frequency used in CW transmission.

[0369] The above geographical location information and coordinate information may be various forms of information defined, for example, in TS 23.032 V18.1.0 "Universal Geographical Area Description (GAD)". This may be applied throughout this specification.

[0370] Area index and / or zone index information may represent area index and / or zone index related to an area that is jointly managed by one or more readers, rather than being handled by only one Reader. For example, as shown in the example of FIG. 11, multiple areas may be assigned to multiple readers.

[0371] The CU of the A-RAN can store information related to the Reader received from the DU of the A-RAN. Subsequently, when it receives a request for an AIoT Service operation from the AIoTF, the CU of the A-RAN can utilize the information related to the Reader.

[0372] For reference, if the Reader belongs to the CU, the CU may pre-transmit information necessary for transmitting signaling for energy harvesting to the DU through the F1 (or F1') Setup process or other F1 (or F1') signaling so that the AIoT Device can perform energy harvesting. Additionally, to support the case where the AIoT Device sends a response to an Inventory Request message, the CU may pre-transmit configuration information necessary for the DU to receive the response and / or information necessary for the DU to transmit the response to the CU.

[0373] For reference, FIGS. 12a and 12b assume that the A-RAN is directly connected to the AIoTF, or that the AMF and AIoTF are co-located, or that the AMF has the functions of the AIoTF (e.g., the operation of the AIoTF in FIGS. 12a and 12b may be the operation of the AMF), but this is merely an example. The example in FIGS. 12a and 12b may also apply to a situation where the A-RAN is connected to the AIoTF through the AMF. In this case, the AMF may separately transmit information related to the Reader received in Step 1 (e.g., Supported area index) to the AIoTF.

[0374] Step 2: A-RAN#1 can collect and exchange Reader information managed by each A-RAN (e.g., refer to the information related to the Reader in Step 1) during the process of setting up an Xn interface or an Xn-like (i.e., Xn') interface with A-RAN#2.

[0375] Step 3: AIoTF can send the NG' AIoT Service message to A-RAN#1.

[0376] For example, due to a request from AF, etc., AIoTF may request A-RAN#1 for an AIoT service (e.g., for Inventory) for specific AIoT Device(s) and / or AIoT Device(s) located in a specific region. The NG' AIoT Service message may include one or more of the following information (e.g., information related to the NG' AIoT Service message):

[0377] - AIoT service operation you want to request (eg, Inventory-only, Command-only, Inventory and Command)

[0378] - Assist information for service operation. For example, the assist information may include one or more of the following.

[0379] i) Information on whether to perform a new service operation;

[0380] ii) Allowed age information (e.g., information on how long ago information obtained may be sent instead of performing the service anew);

[0381] iii) an indication requesting already stored information instead of a new service operation; and / or

[0382] iv) Information on how to transmit AIoT Device information (e.g., a response transmitted by the AIoT device) (e.g., immediate, periodic, timer-based (e.g., timer information may also be included in this case), whether aggregation is needed or not, information to transmit AIoT Device information when a response is received for all AIoT Devices that are targets of the AIoT service, etc.). For example, if inventory is used as the AIoT service, the AIoT Device information (e.g., a response transmitted by the AIoT device) may be the ID of the AIoT Device. For example, in the disclosure of this specification, the response transmitted by the AIoT device may be information included in a random access preamble transmitted by the AIoT device. For example, in this case, the AIoT Device information may include at least one of the receiving power of the AIoT device for the waveform transmitted by the CW, the size of the UL data that the AIoT device intends to transmit, and / or the energy required for the AIoT device to perform D2R transmission. In this case, the AIoT Device information may include one or more of the information described in the example of Step 8.

[0383] - List of Reader IDs to perform AIoT service operations

[0384] - List of AIoT Device IDs eligible for the AIoT service

[0385] - Information about the area where AIoT services are to be provided (e.g., area info). May include one or more of the following:

[0386] i) Geographical location information; and / or

[0387] ii) External area information (e.g., Warehouse #1, Warehouse #2, address information, etc.).

[0388] Additionally, TR 23.700-13 V1.0.0 and TR 38.769 V1.0.0 may be referenced for parameters included in the NG' AIoT Service message.

[0389] Step 4: A-RAN#1 can send AIoT paging messages to AIoT devices.

[0390] For example, based on the information received in Step 3, A-RAN#1 decides to trigger AIoT Paging to find specific AIoT Device(s) and / or AIoT Device(s) located in a specific region. Accordingly, the Reader of A-RAN#1 can send an AIoT Paging message to the AIoT device containing information such as the ID of the device to be found and / or the region.

[0391] In this case, service operations for the AIoT Device may be performed through one or more Readers as needed. For example, if the Area index is an area jointly managed by one or more Readers, service operations may be performed based on one or more Readers.

[0392] Step 5: The AIoT device may determine the Random access type and access occasion / resource, etc., to perform a Random access procedure. The AIoT device may decide to use contention-based Random access. In this case, at Step 5, the AIoT device may transmit a Random access preamble containing some or all of the following information to the base station. Reader #2, which is included in A-RAN#2, may receive the Random access preamble transmitted by the AIoT device. FIGS. 12a and 12b assume that Reader #1 (in A-RAN#1), which transmitted the AIoT Paging message in Step 4, and Reader #2, which receives the Random access preamble, are included in different A-RANs. One or more of the following information may be included in the Random access preamble transmitted by the AIoT device:

[0393] - Random ID generated or assigned by the terminal (e.g., AIoT device) itself and / or Device ID received from an upper layer, and / or Device ID stored within the terminal (e.g., AIoT device), etc.;

[0394] - Assistance information for power control of the CW located in Reader #1. For example, assistance information may include one or more of the following information:

[0395] i) the receiving power of the AIoT device for the waveform transmitted by the CW; and / or

[0396] ii) Amount of energy harvesting in the AIoT device through the waveform transmitted by the CW.

[0397] - The size of the UL data that the AIoT device intends to transmit; and / or

[0398] - Energy required for an AIoT device to perform D2R transmission.

[0399] Additionally, TR 23.700-13 V1.0.0 and TR 38.769 V1.0.0 may be referenced for parameters related to the Random access procedure.

[0400] For reference, if the AIoT device decides to use contention-free random access based on SIB information received from the base station, information pre-configured inside the device, and / or information received in Step 4, Steps 5 through 7 may be skipped.

[0401] Step 6: Reader #2, having received the Random access preamble in Step 5, can include the information received from the AIoT Device in an Xn'AP AIoT MESSAGE TRANSFER message and transmit it to A-RAN #1. Alternatively, Reader #2 can put the Random access preamble received in Step 5 into a container and transmit it to Reader #1 located at A-RAN #1.

[0402] Based on the Device ID and / or Group ID included in Step 4 and / or the Device ID and / or Group ID information received in Step 5, Reader #1 of A-RAN#1 or Reader #2 of A-RAN#2 can know that the AIoT device received an AIoT Paging message through Reader #1 and transmitted a Random access preamble through Reader #2.

[0403] If, in Step 5, the AIoT device may include a Random ID instead of a Device ID in the Random Access Preamble, Reader #1 of A-RAN#1 may include the Reader ID in the AIoT Paging message and transmit it in Step 4 so that A-RAN#1 or #2 can know that Step 5 was executed in response to Step 4 (e.g., so that the Reader can know that the Reader performing R2D and D2R for the AIoT device is different). Additionally, the AIoT device may include the Reader ID received in Step 4 (e.g., the ID for Reader #1) in the Random Access Preamble in Step 5 and transmit the Random Access Preamble to A-RAN#1 and / or #2. Thus, based on the ID for Reader #1 included in the Random Access Preamble, A-RAN#1 or A-RAN #2 may know that the Reader performing R2D and D2R for the AIoT device is different.

[0404] Step 7: Reader #1 of A-RAN#1 can transmit a random access response to the AIoT device.

[0405] For example, in Step 6, Reader #2 of A-RAN#2 can transmit the information received in Step 5 to Reader #1 to request contention resolution for the AIoT device. Based on the information received in Step 6, Reader #1 can generate a Random access response after successfully completing contention resolution for the AIoT device and transmit the Random access response to the AIoT device.

[0406] In Step 6, Reader #2 may include a Random access preamble in a container and deliver it to A-RAN #1. In this case, Reader #1 may perform contention resolution for the AIoT device based on the Random access preamble received through Reader #2, generate a Random access response, and deliver the Random access response to the AIoT device.

[0407] Step 8: The AIoT device can transmit D2R transmission messages. For example, the D2R transmission message may include Device ID and / or UL data.

[0408] For example, after successfully completing the Random access process through Steps 5 to 7, or when using Contention-free Random access, the AIoT device can transmit information such as UL data and / or Device ID received from the Upper layer via D2R transmission to the base station through Reader #2.

[0409] During the D2R transmission process, the AIoT device may transmit to Reader #2 some or all of the information related to Reader #1's resource scheduling (e.g., the following information required for Reader #1 to perform resource scheduling for the AIoT device), as in Step 5. For example, the D2R transmission message of Step 8 may include one or more of the following information:

[0410] - Assistance information for power control of the CW located in Reader #1. For example, assistance information may include one or more of the following information:

[0411] i) the receiving power of the AIoT device for the waveform transmitted by the CW; and / or

[0412] ii) Amount of energy harvesting in the AIoT device through the waveform transmitted by the CW.

[0413] - The size of the UL data that the AIoT device intends to transmit; and / or

[0414] - Energy required for an AIoT device to perform D2R transmission.

[0415] In addition, TR 23.700-13 V1.0.0 and TR 38.769 V1.0.0 may be referenced for additional parameters included in D2R transmission messages and R2D transmission messages.

[0416] Step 9: A-RAN#2 may send an NG (or NG') AIoT SERVICE REPORT or NG (or NG') AIoT SERVICE NOTIFY message to AIOTF. For example, A-RAN#2 may send an NG (or NG') AIoT SERVICE REPORT or NG (or NG') AIoT SERVICE NOTIFY message to AIoTF to forward the response from the AIoT Device received in Step 8 (e.g., Device ID and / or UL data from upper layer in AIoT device) to the AIoT. A-RAN#2 may perform authentication on the AIoT Device(s) that sent the response. A-RAN#2 may include only the responses from AIoT Devices that have passed authentication in the response to AIoTF. A-RAN#2 may include one or more of the following information in the NG (or NG') AIoT SERVICE REPORT or NG (or NG') AIoT SERVICE NOTIFY message regarding the Reader that received the D2R transmission from the AIoT Device and / or the Reader that transmitted the R2D transmission to the AIoT device:

[0417] - Reader ID; and / or

[0418] - Zone index or Area index where an AIoT Device sent a D2R transmission or where the Reader sent an R2D transmission within the area managed by the Reader

[0419] At this time, A-RAN#2 may receive responses from AIoT Device(s) through Reader(s) for a certain period of time, aggregate all responses, and forward them to AIoTF, and then ignore any responses from AIoT Device(s) received thereafter. As another example, A-RAN#2 may periodically report the responses from AIoT Device(s) aggregated up to that point to AIoTF at specific intervals within a certain period of time. Alternatively, A-RAN#2 may immediately forward the responses from AIoT Device(s) to AIoTF via an NG (or NG') AIoT SERVICE REPORT or NG (or NG') AIoT SERVICE NOTIFY message whenever it receives a response from an AIoT Device(s). The time at which A-RAN#2 collects responses from AIoT Device(s) and / or the pattern of reporting them to AIoTF may be pre-configured in A-RAN#2, or AIoTF may have pre-configured A-RAN#2 in Step 1. Alternatively, A-RAN#2 may receive configuration from AF or AIoTF through Step 3.

[0420] Step 10: As in Step 6, Reader #2 may include the D2R transmission message received in Step 8 as is in the container and transmit the Xn'AP AIoT MESSAGE TRANSFER message containing the container to A-RAN#1. Alternatively, Reader #2 may transmit information related to resource scheduling for the AIoT device, etc., included in the message received in Step 8, to A-RAN#1.

[0421] Step 11: Reader #1 of A-RAN#1 can perform R2D transmission and / or CW2D transmission.

[0422] For example, Reader #1 of A-RAN#1 may decide to perform an R2D transmission to the AIoT device to notify the AIoT device of successful reception of the D2R transmission in Step 8. Alternatively, Reader #2 may request only a CW2D transmission without an R2D transmission from the CW located at Reader #1 to deliver power / energy to the AIoT device via the CW so that the AIoT device can continue to perform D2R transmissions. As another example, Reader #1 and / or the CW node included in Reader #1 may decide on their own to perform only a CW2D transmission without an R2D transmission so that the AIoT device can continue to perform D2R transmissions by delivering power / energy to the AIoT device via the CW.

[0423] For example, Reader #1 may perform R2D transmission and / or CW2D transmission to the AIoT device based on the information received in Step 10.

[0424] Step 12: Due to a request from AF, etc., AIoTF may request an AIoT service (e.g., for Command) for specific AIoT Device(s) and / or AIoT Device(s) located in a specific region from Reader #1 of A-RAN#1. For information related to the NG' AIoT Service message, Step 3 may be referenced. Additionally, AIoTF may transmit information related to the Command sent by AF to A-RAN#1.

[0425] Step 13: Reader #1 of A-RAN#1 may transmit information received from AIoTF while performing R2D transmission to convey command-related information to the AIoT device. For example, Reader #1 of A-RAN#1 may transmit an R2D transmission message to the AIoT device that includes command-related information and / or information received from AIoTF. Reader #1 may have received a D2R transmission message from the AIoT device via Reader #2 in the previous step. In this case, Reader #1 may perform R2D transmission and CW2D transmission based on information related to resource scheduling included in the D2R transmission message or information related to the AIoT device stored by Reader #1.

[0426] Step 14: Based on the command from AF received in Step 13, the AIoT device may execute the command and then transmit a D2R transmission message containing a response to the command to the base station via Reader #2. Step 8 may be referenced for information related to resource scheduling to be included in the D2R transmission.

[0427] Step 15: A-RAN#2 can transmit an NG (or NG') AIoT SERVICE REPORT message or an AIoT SERVICE NOTIFY message to the AIoTF to convey the response from the AIoT Device received in Step 14 (e.g., Device ID, Response to command, and / or UL data from upper layer in AIoT device) to the AIoTF. For information included in the NG (or NG') AIoT SERVICE REPORT or NG (or NG') AIoT SERVICE REPORT NOTIFY message, Step 9 may be referenced.

[0428] 2. Second example of the disclosure of this specification

[0429] In the second example of the disclosure of this specification, an example of a procedure for supporting an AIoT device based on topology 2 is described. For reference, topology 2 refers to topology 2 according to the example of FIG. 8a and FIG. 8b.

[0430] The following drawings are made to illustrate a specific example of the present specification. The names of specific devices or specific signals / messages / fields described in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the following drawings.

[0431] FIGS. 13a and FIGS. 13b illustrate an example of a procedure according to the second example of the disclosure of the present specification.

[0432] The examples in Figures 13a and 13b are examples of the entire procedure for supporting an AIoT device in topology 2.

[0433] In FIGS. 13a and 13b, it is assumed that Reader #1 is included in UE #1 and Reader #2 is included in UE #2, and that UE #1 and UE #2 are connected to the same base station. It is also assumed that the CW node sending the carrier-wave for D2R backscattering (for UL transmission) of the AIoT device is located in (or included in) Reader #1 or UE #1. The embodiment of FIGS. 13a and 13b may also be applied when Reader #1, Reader #2, and the CW node belong to the same UE.

[0434] In addition, the embodiments of FIGS. 13a and 13b are also applicable when Reader #1 and Reader #2 are included in UE #1 and a CW node is included in UE #2. In this case, the AIoT device can perform D2R / R2D transmission with Reader #1 and Reader #2 included in UE #1. To do this, the CW node included in UE #2 can transmit a carrier wave. Therefore, to perform power control for the CW node included in UE #2, the base station may receive measurement results from the AIoT device through the Reader included in UE #1 and transmit the measurement results to the CW node.

[0435] In the examples of FIGS. 13a and 13b, the UE may include one or more readers. For example, the UE may be connected to one or more readers. As another example, the UE may perform the function of one or more readers.

[0436] Step 1: UE#1 may send a registration request message to AMF. The registration request message may include a supported area index (or supported area index), and / or CW information.

[0437] For example, UE#1, having one or more Readers, can initiate the network registration process by sending a Registration Request message to the AMF via the NG-RAN. For example, the registration request message may include a supported (or supported) area index (e.g., supported area index) and / or CW information (or information related to the CW).

[0438] For reference, in the disclosure of this specification, CW information (or information related to CW) may include information related to whether the Reader and the CW are collocations; and / or characteristics of the carrier-wave waveform.

[0439] UE#1 may include one or more of the following information regarding each Reader in the Registration Request message. Alternatively, after successfully completing the network registration process, the UE may send a separate message to transmit one or more of the following information to the AIoTF via the AMF:

[0440] - Reader ID;

[0441] - Location information for the area handled by the Reader:

[0442] i) Geographical location information;

[0443] ii) TAI, cell ID information; and / or

[0444] iii) External area information (e.g., Warehouse #1, Warehouse #2, address information, etc.).

[0445] - Supported area index. For example, when the area managed by the Reader is divided into multiple areas or zones, the coordinate information of said area or zone and / or the corresponding area index or zone index. If the UE provides the AIoTF with the geographical location information managed by the Reader, the AIoTF may construct this information and provide it to the UE. For example, if the UE transmits the geographical location information managed by the Reader to the AIoTF, the AIoTF may construct the coordinate information of the area or zone of the area managed by the Reader and / or the corresponding area index or zone index based on the geographical location information managed by the Reader. The AIoTF may also transmit the coordinate information of the area or zone of the area managed by the Reader and / or the corresponding area index or zone index to the UE.;

[0446] - Information regarding whether Reader and CW are collocationd; and / or

[0447] - Characteristics of the carrier-wave waveform:

[0448] i) spectrum used for CW transmission (e.g., DL or UL); and / or

[0449] ii) Carrier frequency used in CW transmission.

[0450] The above geographical location information and coordinate information may be various forms of information defined, for example, in TS 23.032 V18.1.0 "Universal Geographical Area Description (GAD)". This may be applied throughout this specification.

[0451] Area index and / or zone index information may represent area index and / or zone index related to an area that is jointly managed by one or more readers, rather than being handled by only one Reader. For example, as shown in the example of FIG. 11, multiple areas may be assigned to multiple readers.

[0452] For reference, the network may inform the UE of its support for AIoT services via the SIB so that the UE can select a network that supports AIoT services. Additionally, the UE may explicitly include a separate indication within the RRC message and / or NAS message that it can perform the role of a Reader for AIoT services when sending a Registration Request message to the network. Alternatively, the UE may implicitly inform the network that it can perform the role of a Reader for AIoT services by including the Reader information from Step 1 (e.g., information related to the Reader) in the registration request message. Furthermore, during the NG Setup process, the capability information of the AMF regarding AIoT services may be transmitted to the NG-RAN in advance so that the NG-RAN can select an AMF that supports AIoT services during the UE registration process.

[0453] Step 2: AMF can send a registration request message (e.g., Namf_AIoT_Registration request) to AIoTF. The registration request message may include a support area index.

[0454] For example, the AMF may decide to authorize a registration request for the corresponding UE#1. In this case, the AMF may determine a serving AIoTF for said UE based on information pre-configured within the AMF, the UE's subscriber data (e.g., UE's subscription data), and / or information provided by the UE (e.g., information transmitted by the UE in Step 1), and / or with the assistance of the NRF. The AMF may request registration for the UE by sending a Namf_AIoT_Registration Request message to the determined serving AIoTF. At this time, the Namf_AIoT_Registration Request message may include information related to the Reader received by the AMF in Step 1. The AIoTF stores the information about the Reader received from the AMF and may subsequently utilize the stored information when a request for an AIoT Service operation is received from the AF via the NEF.

[0455] For reference, FIGS. 13a and 13b assume a situation where AMF and AIoTF are not co-located, but the explanation in FIGS. 13a and 13b is also applicable when AMF and AIoTF are co-located.

[0456] For reference, FIGS. 13a and 13b assume that all information related to the Reader is pre-configured within the UE, but this is merely an example. For instance, the AIoTF may configure or update some information regarding the Reader existing within the UE. For instance, through Steps 1 and 2, the UE transmits the respective Reader ID and location information regarding the area managed by the Reader (e.g., Geographical location information, TAI, cell ID information, External area information, etc.) to the AMF, and the AMF transmits the information received from the UE in Step 2 to the AIoTF. Then, the AIoTF may divide the area managed by each individual Reader into multiple areas or zones, assign / set the coordinate information of each area or zone and the corresponding area index or zone index, and transmit them to the UE through Step 3.

[0457] Step 3: AMF can send a registration acceptance message to UE#1.

[0458] For example, the AMF can send a Registration Accept message to UE#1 to notify it that it has been successfully registered with the network. In this process, the AMF can create a UE context in the NG-RAN and also transmit the CW information received in Step 1 to the NG-RAN.

[0459] Step 4: For UE#2, a registration procedure may be performed. For example, Steps 1 through 3 may be repeated for UE#2.

[0460] For example, a registration procedure for UE#2 can be performed by referring to steps 1 to 3 of FIGS. 13a and FIGS. 13b.

[0461] Step 5: AIoTF can send an AIoT service request message (e.g., Namf_AIoT Service Request) to AMF. For example, the AIoT service request message may include information related to service operations.

[0462] For example, based on a request from AF, etc., AIoTF may request an AMF for an AIoT service (e.g., for Inventory) for a specific AIoT Device(s) and / or AIoT Device(s) located in a specific region. To do this, AIoTF first selects the UE(s) to perform the AIoT service operation, and based on the selected UE(s), can find the UE's serving NG-RAN and serving AMF. AIoTF may request an AIoT service operation for a specific region and / or AIoT Device(s) by sending a Namf_AIoT_Service Request message to the serving AMF(s) of the selected UE(s). The Namf_AIoT_Service Request message may include one or more of the following information (e.g., information related to the Namf_AIoT_Service Request message). Additionally, the following information may be referred to as information related to service operations:

[0463] - AIoT service operation you want to request (eg, Inventory-only, Command-only, Inventory and Command);

[0464] - Assist information for service operation. For example, the assist information may include one or more of the following:

[0465] i) Information regarding whether to perform a new service operation;

[0466] ii) Allowed age information (e.g., information on how long ago information obtained may be sent instead of performing the service anew);

[0467] iii) an indication requesting already stored information instead of a new service operation; and / or

[0468] iv) Information on how to transmit AIoT Device information (e.g., a response transmitted by the AIoT device) (e.g., immediate, periodic, timer-based (e.g., timer information may also be included in this case), whether aggregation is needed or not, information to transmit AIoT Device information when a response is received for all AIoT Devices that are targets of the AIoT service, etc.). For example, if inventory is used as the AIoT service, the AIoT Device information (e.g., a response transmitted by the AIoT device) may be the ID of the AIoT Device. For example, in the disclosure of this specification, the response transmitted by the AIoT device may be information included in a random access preamble transmitted by the AIoT device. For example, in this case, the AIoT Device information may include at least one of the receiving power of the AIoT device for the waveform transmitted by the CW, the size of the UL data that the AIoT device intends to transmit, and / or the energy required for the AIoT device to perform D2R transmission. In this case, the AIoT Device information may include one or more of the information described in the example of Step 8.

[0469] - List of Reader IDs to perform AIoT service operations;

[0470] - A list of AIoT Device IDs that are targets of the AIoT service; and / or

[0471] - Information about the area where AIoT services are to be provided (e.g., area info). May include one or more of the following:

[0472] i) Geographical location information; and / or

[0473] ii) External area information (e.g., Warehouse #1, Warehouse #2, address information, etc.).

[0474] Additionally, for parameters included in the Namf_AIoT Service Request message, refer to TR 23.700-13 V1.0.0 and TR 38.769 V1.0.0.

[0475] Step 6: AMF can send an NG'AIoT service request message to NG-RAN. The AIoT service request message may include information related to Inventory and / or information related to Command.

[0476] The AMF can request an AIoT service operation for a specific region and / or AIoT Device(s) by sending an NG (or NG') AIoT SERVICE REQUEST message to the serving NG-RAN(s) of the UE(s) selected in Step 5. At this time, the AMF may also forward the information received in Step 5 to the NG-RAN.

[0477] Step 7: The base station (e.g., NG-RAN) can send an AIoT service request message to UE#1.

[0478] In Step 7a, a base station (e.g., NG-RAN) may send an AIoT Service Request message to the UE(s) selected in Step 6 to request an AIoT service operation (for paging) for a specific area and / or AIoT Device(s). At this time, the base station may also transmit the information received in Step 6 to the selected UE(s).

[0479] For reference, the AIoT service request message of step 7a may include a Device ID and / or a Group ID. Examples of Device IDs and / or Group IDs are as follows: - Device ID: A Random ID generated or assigned by the terminal (e.g., AIoT device) itself and / or a Device ID received from an upper layer, and / or a Device ID stored within the terminal (e.g., AIoT device), etc.; - Group ID. For example, a Group ID may include one or more Device IDs. As another example, a Group ID may refer to one or more devices located in a specific region. As yet another example, a Group ID may refer to AIoT devices that match specific parts of the Device ID.

[0480] In step 7b, Reader #1 located in UE#1 can generate an AIoT Paging message based on the information received in Step 7a and transmit the AIoT paging message to the AIoT device.

[0481] In Step 7b, UE#1 may transmit an AIoT Paging message containing a Reader ID (e.g., the Reader ID of Reader #1) to an AIoT device. For example, the Reader ID may be the Reader ID of at least one Reader related to the AIoT service request among one or more Readers included in UE#1. In the following Step 8a, the AIoT device may transmit a Random access preamble by including the Reader ID received in Step 7 (i.e., the ID for Reader #1) together within the Random access preamble. The AIoT device may transmit the Random access preamble to the base station via Reader #2.

[0482] Step 8: The AIoT device may determine the Random access type and access occasion / resource, etc., to perform a Random access procedure. The AIoT device may decide to use contention-based Random access. In this case, at Step 8a, the AIoT device may transmit a Random access preamble containing some or all of the following information to the base station. Reader #2, which is included in UE #2, may receive the Random access preamble transmitted by the AIoT device. FIGS. 13a and 13b assume that Reader #1 (in UE #1), which transmitted the AIoT Paging message in Step 7, and Reader #2, which receives the Random access preamble, are included in different UEs. One or more of the following information may be included in the Random access preamble transmitted by the AIoT device:

[0483] - Random ID generated or assigned by the terminal (e.g., AIoT device) itself and / or Device ID received from an upper layer, and / or Device ID stored within the terminal (e.g., AIoT device), etc.;

[0484] - Group ID. For example, a Group ID may include one or more Device IDs. As another example, a Group ID may refer to one or more devices located in a specific region. As yet another example, a Group ID may refer to AIoT devices where a specific part of the Device ID matches;

[0485] - Assistance information for power control of the CW located in Reader #1. For example, assistance information may include one or more of the following information:

[0486] i) the receiving power of the AIoT device for the waveform transmitted by the CW; and / or

[0487] ii) Amount of energy harvesting in the AIoT device through the waveform transmitted by the CW.

[0488] - The size of the UL data that the AIoT device intends to transmit; and / or

[0489] - Energy required for an AIoT device to perform D2R transmission.

[0490] Additionally, TR 23.700-13 V1.0.0 and TR 38.769 V1.0.0 may be referenced for parameters related to the Random access procedure.

[0491] Reader #2, having received the Random access preamble in Step 8b, can include the information received from the AIoT Device in a UL AIoT Message Transfer message and transmit the UL AIoT Message Transfer message to the base station. Reader #2 can include the Random access preamble received in Step 8a in a container and transmit the UL AIoT Message Transfer message containing the container to the base station. In this case, the base station may transmit the Random access preamble transmitted by the AIoT device to Reader #1 located at UE #1 via Step 9a.

[0492] For reference, if the AIoT device decides to use contention-free random access based on SIB information received from the base station, information pre-configured within the device, and / or information received in Step 7, Steps 8 and 9 may be skipped.

[0493] Step 9: Based on the Device ID and / or Group ID included in Step 7 and the Device ID and / or Group ID information received in Step 8, the base station can determine that the AIoT device received an AIoT Paging message through Reader #1 and transmitted a Random access preamble through Reader #2.

[0494] If, in Step 8, the AIoT device may include a Random ID instead of a Device ID in the Random Access Preamble, UE#1 in Step 7b may include the Reader ID in the AIoT Paging message and transmit it so that the base station or Reader can know that Step 8 was executed in response to Step 7 (e.g., so that the base station or Reader can know that the Reader performing R2D and D2R for the AIoT device is different). Additionally, the AIoT device may include the Reader ID received in Step 7 (e.g., an ID related to Reader#1) in the Random Access Preamble and transmit the Random Access Preamble to the base station through Reader#2. Therefore, the base station or Reader may know that the Reader performing R2D and D2R for the AIoT device is different based on the ID for Reader#1 included in the Random Access Preamble (e.g., the Reader ID of Reader#1).

[0495] For example, in Step 8b, the base station may transmit the information received in Step 8b to Reader #1 to request contention resolution for the AIoT device. Based on the information received in Step 9a, Reader #1 may generate a Random access response after successfully completing contention resolution for the AIoT device and transmit the Random access response to the AIoT device.

[0496] In Step 8b, Reader #2 may include a Random access preamble in a container and transmit it to the base station. In this case, the base station may transmit the container containing the Random access preamble to Reader #1. In this case, Reader #1 may perform contention resolution for the AIoT device based on the Random access preamble received through Reader #2 and the base station, generate a Random access response, and transmit the Random access response to the AIoT device.

[0497] Step 10: The AIoT device can transmit D2R transmission messages. For example, the D2R transmission message may include Device ID and / or UL data.

[0498] For example, after successfully completing the Random access process through Steps 8 and 9, or when using Contention-free Random access, the AIoT device can transmit information such as UL data and / or Device ID received from the Upper layer to the base station through Reader #2 via D2R transmission.

[0499] During the D2R transmission process, the AIoT device may transmit to Reader #2 some or all of the information related to Reader #1's resource scheduling (e.g., the following information required for Reader #1 to perform resource scheduling for the AIoT device), as in Step 8. For example, the D2R transmission message of Step 10 may include one or more of the following information:

[0500] - Assistance information for power control of the CW located in Reader #1. For example, assistance information may include one or more of the following information:

[0501] i) the receiving power of the AIoT device for the waveform transmitted by the CW; and / or

[0502] ii) Amount of energy harvesting in the AIoT device through the waveform transmitted by the CW.

[0503] - The size of the UL data that the AIoT device intends to transmit; and / or

[0504] - Energy required for an AIoT device to perform D2R transmission.

[0505] In addition, TR 23.700-13 V1.0.0 and TR 38.769 V1.0.0 may be referenced for additional parameters included in D2R transmission messages and R2D transmission messages.

[0506] Step 11: The base station may send an NG (or NG') AIoT SERVICE REPORT or an NG (or NG') AIoT SERVICE NOTIFY to the AMF.

[0507] For example, the base station may transmit an NG (or NG') AIoT SERVICE REPORT message or an NG (or NG') AIoT SERVICE NOTIFY message to the AMF to convey the response from the AIoT Device received in Step 10 (e.g., Device ID and / or UL data from upper layer in AIoT device) to the AMF. The base station may perform authentication on the AIoT Device(s) that sent the response. The base station may include only the responses from AIoT Devices that have passed authentication in the response to the AMF (e.g., NG (or NG') AIoT SERVICE REPORT message or NG (or NG') AIoT SERVICE NOTIFY message). The base station may include one or more of the following information related to the Reader that received the D2R transmission from the AIoT Device and / or the Reader that transmitted the R2D transmission to the AIoT device in an NG (or NG') AIoT SERVICE REPORT or NG (or NG') AIoT SERVICE NOTIFY message:

[0508] - Reader ID; and / or

[0509] - Zone index or Area index where an AIoT Device sent a D2R transmission or where the Reader sent an R2D transmission within the area managed by the Reader

[0510] At this time, the base station may receive responses from AIoT Device(s) through Reader(s) for a certain period of time, collect all responses and transmit them to the AMF, and then ignore any responses from AIoT Device(s) received thereafter. As another example, the base station may periodically report the responses from AIoT Device(s) collected up to that point to the AMF at specific intervals within a certain period. Alternatively, the base station may transmit the responses from AIoT Device(s) directly to the AMF via an NG (or NG') AIoT SERVICE REPORT message or an NG (or NG') AIoT SERVICE NOTIFY message whenever it receives a response from an AIoT Device(s). The time for the base station to collect responses from AIoT Device(s) and / or the pattern for reporting them to the AMF may be pre-configured in the base station, or the base station may receive a configuration from the AF or AIoTF through Step 3 for the time for collecting responses from AIoT Device(s) and / or the pattern for reporting them to the AMF.

[0511] Step 12: AMF can send a service response message (e.g., Namf_AIoT Service Response) to AIoTF.

[0512] For example, AMF can send a Namf_AIoT_Service Response message to AIoTF to transmit the response from the AIoT Device received in Step 11 to AIoTF.

[0513] For example, the AMF can transmit the response from the AIoT Device received in Step 11 to the AIoTF by sending the Namf_AIoT_Service Response message to the AIoTF. As in Step 11, the AMF can also collect the responses from each AIoT Device(s) from their respective UEs according to a set time and / or a set pattern and transmit them to the AIoTF. Information such as the time and / or pattern for collecting the responses from the AIoT Device(s) may be pre-configured in the AMF, or the AMF may receive this pre-configuration from the AIoTF in Step 2. Alternatively, through Step 5, the AMF may receive this information such as the time and / or pattern for collecting the responses from the AIoT Device(s) from the AF or the AIoTF. After AMF performs authentication on the AIoT Device(s) included in the response from NG-RAN, it may include only the responses of the AIoT Devices that have passed authentication in the response to AIoTF (e.g., Namf_AIoT_Service Response).

[0514] Step 13: A base station (e.g., NG-RAN) can transmit DL AIoT Message Transfer to UE#1. For example, the base station may request R2D transmission and / or CW2D transmission from UE#1. UE#1 can perform R2D transmission and / or CW2D transmission to an AIoT device.

[0515] In Step 13a, to notify the AIoT device of successful reception of the D2R transmission in Step 10, the base station may request an R2D transmission from Reader #1. For example, the base station may request an R2D transmission from Reader #1 by sending a DL AIoT Message Transfer message. For example, the DL AIoT Message Transfer may contain information related to the R2D transmission, or Reader #1 may perform the R2D transmission if the DL AIoT Message Transfer is received at this time in Step 10b. The base station may also transmit information related to resource scheduling for the AIoT device to Reader #1. For example, the DL AIoT Message Transfer message may contain information related to resource scheduling. Alternatively, to deliver power / energy to the AIoT device via the CW so that the AIoT device can continue to perform D2R transmission, the base station may request only a CW2D transmission from the CW located at Reader #1 without an R2D transmission.

[0516] In Step 13b, Reader #1 can perform R2D transmission and / or CW2D transmission to the AIoT device based on the information received in Step 13a.

[0517] Step 14: Based on a request from AF, etc., AIoTF may request an AMF for an AIoT service (e.g., for Command) for a specific AIoT Device(s) and / or an AIoT Device(s) located in a specific region. Step 5 may refer to information related to the Namf_AIoT Service Request message. Additionally, AIoTF may also transmit information related to the Command sent by AF to the AMF.

[0518] Step 15: The AMF can transmit an NG (or NG') AIoT service request message to the base station. For example, based on the information received in Step 14, the AMF can operate as in Step 6.

[0519] Step 16: The base station can send a DL AIoT Message Transfer message to UE#1. For example, the base station can request R2D transmission and / or CW2D transmission from UE#1. UE#1 can perform R2D transmission and / or CW2D transmission.

[0520] For example, in step 16a, the base station may request R2D transmission from Reader #1 of UE#1 to transmit Command-related information to the AIoT device, and may also transmit information received from AIoTF. For example, the DL AIoT Message Transfer message may include information received from AIoT and / or information related to R2D transmission.

[0521] Reader #1 may have performed D2R transmission from the AIoT device through Reader #2 in the previous step. In this case, Reader #1 can perform R2D transmission and CW2D transmission based on information related to resource scheduling included in the D2R transmission message and / or information related to the AIoT device stored by Reader #1.

[0522] Step 17: The AIoT device may execute the corresponding command according to the command from AF received in Step 16, and then transmit a D2R transmission message containing a response to the command to the base station via Reader #2. The D2R transmission message may include information related to resource scheduling. For example, Step 10 may refer to information related to resource scheduling to be included in the D2R transmission.

[0523] Step 18: The base station may transmit an NG (or NG') AIoT SERVICE REPORT message or an NG (or NG') AIoT SERVICE NOTIFY message to the AIoTF to convey the response from the AIoT Device received in Step 17 (e.g., Device ID, Response to command, and / or UL data from upper layer in AIoT device). The NG (or NG') AIoT SERVICE REPORT message or the NG (or NG') AIoT SERVICE NOTIFY message may include the Device ID of the AIoT device and / or the response from the AIoT Device. For information included in the NG (or NG') AIoT SERVICE REPORT or NG (or NG') AIoT SERVICE NOTIFY message, refer to Step 11.

[0524] Step 19: The AMF may transmit a Namf_AIoT_Service Response message to the AIoTF to convey the response from the AIoT Device received in Step 18. For example, the Namf_AIoT_Service Response message may include the Device ID of the AIoT Device and / or the response of the AIoT Device. For information included in the Namf_AIoT_Service Response message, Step 12 may be referenced.

[0525] 3. Third example of the disclosure of this specification

[0526] The third example of the disclosure of this specification is an example to which the first and / or second examples of the disclosure of this specification apply.

[0527] At NR, a new SID regarding the new Release-19 Ambient IoT (Internet of Things) solution was agreed upon at RAN #102. One of the goals of this SID is to identify the impact on the signaling and procedures required for the CN-RAN interface as follows:

[0528] Identify the necessary impacts on the signaling and procedures required for the Core Network (CN)-RAN interface, enabling the following:

[0529] - Paging

[0530] - Device Context Management

[0531] - Data transport

[0532] Identify RAN architecture aspects, including whether it is necessary to support a split architecture.

[0533] Identify potential solutions to determine the location of Ambient IoT devices without changing specifications (e.g., reusing existing user location reporting or modifying the minimum specifications for transmitting location information to the core network).

[0534] In the third example of the disclosure of this specification, we discuss the impact on RAN architecture aspects, including the need for partitioned architecture support, and propose views thereon.

[0535] As described in Table 3 and Figures 9a through 9h, TR 38.769 V1.0.0 Table 4.2.1-1: Evaluation scenarios may be referenced.

[0536] One of the possible scenarios considered in Topology 1 is the D1T1-A1 scenario in Table 3 and Figure 9a. As shown in Figure 9a, the reader involved in R2D transmission may be different from the D2R backscattering reader.

[0537] In this scenario (e.g., D1T1-A1), coordination between the two leaders may be required. For example, when an A-IoT random access is triggered by a leader, the AIoT device may send a Msg1 (e.g., a random access preamble) to the leader containing a random ID generated by the A-IoT device. For contention resolution, the leader may respond by including the successfully received random ID in Msg2. Therefore, the leader involved in the R2D transmission in D1T1-A1 must know the random ID included in Msg1. Additionally, in D2R, the AIoT device may send a message size / state indication (or information) to the leader in accordance with the RAN2 agreement. This indication (or information) can be used by the R2D leader to allocate resources for subsequent D2R messages.

[0538] Observation 1: In the case of D1T1-A1, coordination between the R2D leader and the D2R leader may be necessary.

[0539] When a non-split AIoT RAN is considered and two leaders are located in the same AIoT RAN, the method of exchanging device-related information (e.g., random IDs generated by AIoT devices) between the two leaders depends on the RAN implementation. However, if a disaggregated architecture for the AIoT RAN is considered, there is a possibility that the two leaders are connected to different DUs. To transmit device-related information from a D2R leader to a D2R leader, improvements to F1 signaling appear necessary. Furthermore, in the D1T1-A1 scenario, if a single AIoT RAN serves only one leader, the R2D leader and the D2R leader may be connected to different BSs. Therefore, a new Xn-like signaling may be defined to support cooperation between the two leaders. Consequently, further discussion is required regarding the feasibility and methods of supporting the D1T1-A1 scenario.

[0540] Proposal 1: In Topology 1, we propose discussing whether to support the D1T1-A1 scenario (e.g., a scenario where the leader involved in R2D transmission is different from the leader in D2R backscattering) and how to do so.

[0541] In Topology 2, the D2T2-A1 scenario of Table 3 and Fig. 9e is considered. For example, in the case of the D2T2-A1 scenario in Topology 2, it is also observed that the leader involved in the R2D transmission is different from the leader in the D2R backscattering:

[0542] In this scenario (e.g., D2T2-A1), as in Observation 1, coordination between the leader of R2D and the leader of D2R is required. Since the leader resides in (or is contained within) an intermediate UE in Topology 2, the D2T2-A1 scenario implies that the two leaders are connected to different UEs. However, as illustrated in Fig. 9e, these UEs are served by the same AIoT-enabled gNB. Therefore, to support the D2T2-A1 case, the leader of D2R must provide device-related information to the leader of R2D. However, there is no direct connection between the leaders of different UEs. If an RRC-based solution is used in Topology 2, device-related information must be transmitted to the leader of R2D via the AIoT-enabled gNB. However, when a Non Access Stratum (NAS) / User Plane (UP) based solution is used, the D2R reader can transmit information to the R2D reader via the AIoT CN, which may cause unnecessary delays. Therefore, it is considered more desirable for the D2R reader to transmit device-related information to the R2D reader via the AIoT-enabled gNB.

[0543] Proposal 2: In Topology 2, the D2R leader can transmit device-related information to the R2D leader via an AIoT-enabled gNB.

[0544] In the third example of the disclosure of this specification, the focus is on the impact on RAN architecture aspects, including whether support for partitioned architectures is necessary, and a view is presented thereon. The following is proposed:

[0545] Proposal 1: In Topology 1, we propose discussing whether to support the D1T1-A1 scenario (e.g., a scenario where the leader involved in R2D transmission is different from the leader in D2R backscattering) and how to do so.

[0546] Proposal 2: In Topology 2, the D2R leader can transmit device-related information to the R2D leader via an AIoT-enabled gNB.

[0547] In the second example of the disclosure of this specification described above, the AIoTF requested an AIoT service operation from the UE(s) via an RRC message, but this is merely an example. The scope of the disclosure of this specification is not limited thereto. For example, the AIoTF may request an AIoT service operation from the UE(s) by using the UE(s)'s NAS message or through the UE(s)'s Protocol Data Unit (PDU) (or Packet Data Unit) Session (e.g., using UP data). In this case, Reader #1 located at UE#1 and Reader #2 located at UE#2 may use the AIoTF instead of a base station to exchange information related to resource scheduling for the AIoT Device. For example, Reader #2 may receive information related to resource scheduling (e.g., information required for resource scheduling) from the AIoT device. In this case, Reader #2 may transmit information related to resource scheduling (e.g., information required for resource scheduling) to AIoTF using NAS messages or PDU Sessions, and AIoTF may then transmit information related to resource scheduling (e.g., information required for resource scheduling) back to Reader #1.

[0548] Alternatively, even when using the UE(s)'s NAS message / PDU session, Reader #2 may receive information related to resource scheduling (e.g., information required for resource scheduling) from the AIoT device via Random access preamble or D2R transmission. In this case, Reader #2 may separately transmit only the information related to resource scheduling to the base station via the UE's RRC message. In this case, the information related to resource scheduling can be transmitted directly to Reader #1 through the base station without passing through AIoTF.

[0549] Hereinafter, with reference to the example of FIG. 14, an example of a procedure according to various examples of the disclosure of the present specification is described. The description with reference to FIG. 14 below may be based on a description according to the disclosure of the present specification including at least one of the first example, the second example, and / or the third example of the disclosure of the present specification.

[0550] According to one embodiment of the disclosure of this specification, the transmission power of a CW node can be effectively adjusted in a situation where a reader transmitting R2D to an AIoT device and a reader receiving D2R transmission from an AIoT device are different.

[0551] For example, Reader #2, having received a D2R transmission from an AIoT device, can transmit information related to resource scheduling (e.g., information required for resource scheduling) to the base station.

[0552] For example, the base station can transmit information related to resource scheduling received from Reader #2 to Reader #1, which transmits R2D to the AIoT device.

[0553] For example, Reader #1, having received information related to resource scheduling, can adjust the transmission power of R2D and / or CW2D transmitted to the AIoT device.

[0554] For reference, in the disclosure of this specification, the relationship between a device (e.g., UE, base station) including a reader related to AIoT and the reader may be based on one or more of the following examples. For example, the device (e.g., UE, base station) may have the ability to perform operations related to the reader. For another example, the device (e.g., UE, base station) may physically include the reader. For another example, the device (e.g., UE, base station) may be connected to the reader. For another example, the device (e.g., UE, base station) may control the reader. For another example, the device (e.g., UE, base station) may be located in a position adjacent to the reader.

[0555] The following drawings are made to illustrate a specific example of the present specification. The names of specific devices or specific signals / messages / fields described in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the following drawings.

[0556] FIG. 14 illustrates an example of a procedure according to one embodiment of the disclosure of the present specification.

[0557] For reference, the procedure illustrated in FIG. 14 is merely an example, and the scope of disclosure of this specification is not limited by the example of FIG. 14.

[0558] For example, regarding the example of FIG. 14, the operations described in the examples of FIG. 1 to FIG. 13b may also be applied. For example, even if the operations, contents, etc. are not directly described in the example of FIG. 14, the operations, contents, etc. described in various examples of the disclosure of this specification may be applied.

[0559] In the example of FIG. 14, the AIoT device may be a device that supports operations related to AIoT.

[0560] In the example of FIG. 14, the first UE may be a device comprising one or more AIoT-related readers. In the following example, an embodiment of the disclosure of this specification is described using the first reader among the one or more readers included in the first UE as an example.

[0561] In the example of FIG. 14, the second UE may be a device comprising one or more AIoT-related readers. In the following example, an embodiment of the disclosure of this specification is described using a first reader among the one or more readers included in the second UE as an example.

[0562] In some implementations, before step (S1401) is performed, the second UE may send a registration request message to a mobility-related network entity (e.g., AMF). The second UE may also receive a registration acceptance message from the mobility-related network entity (e.g., AMF).

[0563] In some implementations, before step (S1401) is performed, the first UE may send a registration request message to a mobility-related network entity (e.g., AMF). The first UE may also receive a registration acceptance message from the mobility-related network entity (e.g., AMF).

[0564] In some implementations, a base station may receive a first AIoT service request message from a network entity related to mobility, for example, the first AIoT service request message may include at least one of information related to an AIoT service operation, support information related to said AIoT service operation, information related to a leader ID to perform said AIoT service operation, information related to an AIoT device ID to be the target of the AIoT service, or area information related to said AIoT service.

[0565] In some implementations, the base station may transmit to the first UE a second AIoT service request message containing information related to requesting the transmission of an AIoT paging message or at least one of the above information.

[0566] For example, a second AIoT service request message may be used to include the leader ID of the first reader in an AIoT paging message transmitted by the first UE to the AIoT device. For example, the first UE may transmit an AIoT paging message containing the leader ID of the first reader to the AIoT device. The leader ID of the first reader may be included in a random access preamble or D2R message transmitted by the AIoT device.

[0567] In some implementations, the AIoT device may include a random ID instead of the device ID of the AIoT device in the random access preamble. In this case, the first UE may include a Reader ID in the AIoT Paging message so that the base station or the first reader (or the first UE including the first reader) can know that the reader performing R2D and D2R for the AIoT device is different. Additionally, the AIoT device may include a Reader ID (e.g., the Reader ID of the first reader) in the access preamble.

[0568] In step (S1401), the AIoT device may transmit a message. The second UE may receive the message transmitted by the AIoT device. For example, the message in step (S1401) may be a random access preamble or a D2R message (or a D2R transmission message).

[0569] For example, a second reader included in the second UE can receive a random access preamble from an AIoT device.

[0570] In some implementations, the random access preamble may include one or more pieces of information among the device ID of the AIoT device, the random ID, the reader ID of the first reader, or supporting information related to the CW. In some implementations, the random access preamble may further include at least one of information related to the size of the uplink data that the AIoT device intends to transmit, or information related to the energy required for the AIoT device to perform Device to Reader (D2R) transmission.

[0571] For example, support information related to the CW may be support information related to power control of a CW node related to a first reader included in the first UE.

[0572] In some implementations, support information related to the CW may include one or more pieces of information such as the receiving power of the AIoT device related to the waveform of the CW node related to the first reader included in the first UE, or the amount of energy harvesting of the AIoT device based on the waveform of the CW node.

[0573] In step (S1402), the second UE can transmit a message to the base station. For example, the message in step (S1402) may be a UL AIoT Message Transfer message.

[0574] For example, a second UE may transmit a message containing one or more of the above information to a base station. Here, the one or more of the above information may be one or more of the following: the random access preamble may be the device ID of the AIoT device, the random ID, the reader ID of the first reader, or support information related to the CW.

[0575] In step (S1403), the base station may transmit a message to the first UE. For example, the message in step (S1403) may be a DL AIoT Message Transfer message.

[0576] For example, a base station may transmit a message (e.g., a DL AIoT Message Transfer message) containing one or more of the above information to a first UE. Here, the one or more of the above information, the random access preamble, may be one or more of the device ID of the AIoT device, the random ID, the reader ID of the first reader, or support information related to the CW.

[0577] In some implementations, the first UE may transmit a random access response to the AIoT device based on one or more of the information above.

[0578] This specification may have various effects.

[0579] For example, communication based on AIoT can be performed effectively and / or accurately.

[0580] For example, in a situation where the Reader transmitting R2D to the AIoT device and the Reader receiving D2R transmission from the AIoT device are different, communication related to AIoT can be effectively supported. For instance, the power of the CW2D signal transmitted to the AIoT device can be appropriately adjusted. Accordingly, situations where data included in the D2R message transmitted by the AIoT device is not properly received by the Reader (e.g., situations where sufficient transmission power is not stored in the AIoT device to attempt D2R transmission, or where the D2R transmission sent by the AIoT device fails to reach the Reader) can be prevented.

[0581] The effects obtainable through the specific examples of this specification are not limited to those listed above. For example, there may be various technical effects that a person with ordinary skill in the related art can understand or derive from this specification. Accordingly, the specific effects of this specification are not limited to those explicitly described herein, but may include various effects that can be understood or derived from the technical features of this specification.

[0582] For reference, the operation of the terminal (e.g., UE, UE#1, UE#1(Reader #1), UE#2(Reader #2), etc.) described in this specification may be implemented by the device of FIGS. 1 to 3 described above. For example, the terminal may be the first device (100) or the second device (200) of FIG. 2. For example, the operation of the terminal described in this specification may be processed by one or more processors (102 or 202). The operation of the terminal described in this specification may be stored in one or more memories (104 or 204) in the form of an instruction / program (e.g., instruction, executable code) executable by one or more processors (102 or 202). One or more processors (102 or 202) can control one or more memories (104 or 204) and one or more transceivers (105 or 206) and execute instructions / programs stored in one or more memories (104 or 204) to perform the operation of the terminal described in the disclosure of the present specification.

[0583] Additionally, instructions for performing operations of a terminal (e.g., UE, AIoT device, etc.) described in the disclosure of this specification may be stored in a non-volatile computer-readable storage medium. The storage medium may be included in one or more memories (104 or 204). And, the instructions recorded in the storage medium may perform operations of the terminal described in the disclosure of this specification by being executed by one or more processors (102 or 202).

[0584] For reference, the operation of a network node (e.g., AIoTF, AMF, SMF, UPF, PCF, NEF, UDM, DN, AF, etc.) or a base station (e.g., NG-RAN, A-RAN, A-RAN#1, A-RAN#2 gNB, gNB-DU, gNB-CU, DU, DU#1, DU#2, CU, CU-UP, CU-CP, etc.) described in this specification may be implemented by the device of FIGS. 1 to 3, which will be described below. For example, the network node or base station may be the first device (100) or the second device (200) of FIG. 2. For example, the operation of the network node or base station described in this specification may be processed by one or more processors (102 or 202). The operation of the terminal described in this specification may be stored in one or more memories (104 or 204) in the form of an instruction / program (e.g., instruction, executable code) executable by one or more processors (102 or 202). One or more processors (102 or 202) may control one or more memories (104 or 204) and one or more transceivers (106 or 206), and execute the instruction / program stored in one or more memories (104 or 204) to perform the operation of the network node or base station described in the disclosure of this specification.

[0585] Additionally, instructions for performing the operation of a network node or base station described in the disclosure of this specification may be stored in a non-volatile (or non-transient) computer-readable storage medium. The storage medium may be contained in one or more memories (104 or 204). And, the instructions recorded in the storage medium may perform the operation of a network node or base station described in the disclosure of this specification by being executed by one or more processors (102 or 202).

[0586] Although preferred embodiments have been described by way of example above, the disclosure of this specification is not limited to such specific embodiments, and may be modified, changed, or improved in various forms within the scope of the spirit and claims of this specification.

[0587] In the exemplary system described above, methods are described based on a flowchart as a series of steps or blocks, but are not limited to the order of the described steps, and some steps may occur in a different order or simultaneously with other steps as described above. Furthermore, a person skilled in the art will understand that the steps shown in the flowchart are not exclusive, and that other steps may be included, or that one or more steps of the flowchart may be omitted without affecting the scope of rights.

[0588] The claims described in this specification may be combined in various ways. For example, the technical features of the method claims in this specification may be combined to be implemented as a device, and the technical features of the device claims in this specification may be combined to be implemented as a method. Furthermore, the technical features of the method claims and the technical features of the device claims in this specification may be combined to be implemented as a device, and the technical features of the method claims and the technical features of the device claims in this specification may be combined to be implemented as a method. Other implementations are within the scope of the following claims.

Claims

1. A second reader included in the second User Equipment (UE) receives a random access preamble from an Ambient Internet on Things (AIoT) device, The above random access preamble includes one or more pieces of information among the device ID of the AIoT device, a random ID, the reader ID of the first reader, or support information related to the Carrier Wave (CW); and A method comprising the step of the second UE transmitting a message containing one or more pieces of information to a base station.

2. In Paragraph 1, A method in which one or more of the above information is transmitted by the base station to a first UE including the first reader.

3. In Paragraph 1 or 2, A method wherein the random access preamble further comprises at least one of information related to the size of uplink data that the AIoT device intends to transmit, or information related to the energy required for the AIoT device to perform Device to Reader (D2R) transmission.

4. In any one of paragraphs 1 through 3, The support information related to the above CW is, A method, which is support information related to power control of a CW node related to a first reader included in the first UE.

5. In any one of paragraphs 1 through 4, The support information related to the above CW is, A method comprising one or more pieces of information including the receiving power of the AIoT device related to the waveform of a CW node related to a first reader included in the first UE, or the amount of energy harvesting of the AIoT device based on the waveform of the CW node.

6. In any one of paragraphs 1 through 5, A method in which the first leader and the second leader are each leaders related to AIoT.

7. In any one of paragraphs 1 through 6, The above-mentioned second User Equipment (UE) transmits a registration request message to a network entity related to mobility; and A method further comprising the step of the second UE receiving a registration acceptance message from a network entity related to the mobility.

8. One or more transmitters and receivers; One or more processors; and It includes one or more memories that store instructions and can be connected to operate with one or more processors, and A device in which the operation performed based on the execution of the above instruction by the above one or more processors is a method according to any one of claims 1 to 7.

9. Receiving a message from a second User Equipment (UE) comprising one or more pieces of information including a device ID of an Ambient Internet on Things (AIoT) device, a random ID, a reader ID of a first reader, or support information related to a Carrier Wave (CW); and A method comprising the step of transmitting one or more of the above information to a first UE including the first reader.

10. In Paragraph 9, The method further includes the step of receiving a first AIoT service request message from a network entity related to mobility, and A method wherein the first AIoT service request message comprises at least one of the following: information related to an AIoT service operation, support information related to the AIoT service operation, information related to a leader ID to perform the AIoT service operation, information related to an AIoT device ID to be the target of the AIoT service, or area information related to the AIoT service.

11. In Paragraph 10, A method further comprising the step of transmitting to the first UE a second AIoT service request message containing information related to requesting the transmission of an AIoT paging message or at least one of the above information.

12. In Paragraph 11, A method in which the second AIoT service request message is used to include the reader ID of the first reader in the AIoT paging message transmitted by the first UE to the AIoT device.

13. In any one of paragraphs 9 through 12, A method wherein a message containing one or more of the above information further comprises at least one of information related to the size of uplink data that the AIoT device intends to transmit, or information related to the energy required for the AIoT device to perform Device to Reader (D2R) transmission.

14. One or more transmitters and receivers; One or more processors; and It includes one or more memories that store instructions and can be connected to operate with one or more processors, and A device in which the operation performed based on the execution of the above instruction by the one or more processors is a method according to any one of claims 9 to 13.

15. A first User Equipment (UE) receiving an AIoT service request message from a base station that includes information related to requesting the transmission of an Ambient Internet on Things (AIoT) paging message; and The method includes the step of transmitting the AIoT paging message, which includes the leader ID of the first reader included in the first UE, to an AIoT device. A method in which the reader ID of the first reader is included in a random access preamble or Device to Reader (D2R) message transmitted by the AIoT device.

16. In Paragraph 15, A method wherein the above AIoT service request message further comprises at least one of the following: information related to an AIoT service operation, support information related to the AIoT service operation, information related to a leader ID to perform the AIoT service operation, information related to an AIoT device ID to be the target of the AIoT service, or area information related to the AIoT service.

17. In Paragraph 15 or 16, A method further comprising the step of receiving a message from a base station containing one or more pieces of information including a device ID of the AIoT device, a random ID, the reader ID of the first reader, or support information related to a Carrier Wave (CW).

18. In Paragraph 17, A method further comprising the step of transmitting a random access response to the AIoT device based on one or more of the above information.

19. One or more transmitters and receivers; One or more processors; and It includes one or more memories that store instructions and can be connected to operate with one or more processors, and A device in which the operation performed based on the execution of the above instruction by the one or more processors is a method according to any one of claims 15 to 18.

Images