Method of operation of a reader in a wireless communication system and reader
By managing message processing for AIoT services in a wireless communication system, the shortcomings in handling success and failure of AIoT services in existing technologies are addressed, enabling effective service management for low-complexity and low-power AIoT devices.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- KT CORP
- Filing Date
- 2025-12-31
- Publication Date
- 2026-07-03
AI Technical Summary
Existing technologies have failed to effectively handle the success and failure of Ambient Internet of Things (AIoT) services, especially in low-complexity, low-power AIoT devices, where there is a lack of specific operational methods.
A method and apparatus are provided for a reader to manage AIoT services by receiving and sending messages in a wireless communication system, including receiving messages requesting and instructing AIoT services, and ensuring the success and failure handling of AIoT devices.
Effectively handles the success and failure of AIoT services, supports low-complexity, low-power AIoT devices, and implements specific methods for the success and failure of environmental IoT services.
Smart Images

Figure CN122340448A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to wireless communications applicable to 5G NR, 5G-Advanced, and 6G. Background Technology
[0002] With the development of technology, more and more communication devices require greater communication bandwidth, thus necessitating more advanced wireless broadband communication than the existing LTE system—the next-generation 5G system. In this next-generation 5G system, known as NewRAT, communication scenarios are categorized into Enhanced Mobile Broadband (eMBB), Ultra-reliability and low-latency communication (URLLC), and Massive Machine-Type Communications (mMTC), among others.
[0003] Here, eMBB is a next-generation mobile communication scenario with characteristics such as high spectrum efficiency, high user experience data rate, and high peak data rate; URLLC is a next-generation mobile communication scenario with characteristics such as ultra-reliability, ultra-low latency, and ultra-high availability (e.g., V2X, emergency services, remote control); and mMTC is a next-generation mobile communication scenario with characteristics such as low cost, low power consumption, short packet size, and massive connectivity (e.g., Internet of Things, IoT). Summary of the Invention
[0004] One object of this disclosure is to provide a method and apparatus for effectively providing environmental Internet of Things (IoT) services in a wireless communication system.
[0005] One embodiment of this specification provides a method for operating a reader in a wireless communication system, the method comprising: receiving a first message from an Ambient Internet of Things Function (AIoTF) for requesting an AIoT service. Furthermore, the method further comprises: after receiving the first message, receiving from the AIoTF a second message indicating the cancellation of the AIoT service, and in response to the second message, sending to the AIoTF a third message indicating that the cancellation of the AIoT service is complete.
[0006] Furthermore, in one embodiment of this specification, an apparatus in a wireless communication system is provided, the apparatus comprising: at least one processor; and at least one memory storing instructions and operatively electrically connected to the at least one processor, wherein the at least one processor is configured to perform the following operations: receiving from an AIoTF (Internet of Things Function) for requesting an AIoT service; receiving, after receiving the first message, from the AIoTF for indicating cancellation of the AIoT service; and in response to the second message, sending to the AIoTF a third message indicating that the cancellation of the AIoT service is complete.
[0007] After receiving the first message, the reader can send a fourth message for paging to the AIoT device. This fourth message may include information indicating whether security parameters are included.
[0008] Furthermore, the first message may include at least one of AIoT device identification information and security parameters, and may be received via the Next Generation Application Protocol (NGAP) between the AIoTF and the base station.
[0009] The AIoT device identification information may include one of the following: permanent AIoT device identification information, identification information from the first security process, and filtering information; and the security parameter may be a random parameter used to generate the identification information for the second security process.
[0010] In addition, the second message may include identification information, AIoTF identification information, and reason information associated with the request for the AIoT service.
[0011] In addition, the third message may include identification information and AIoTF identification information associated with the request for the AIoT service.
[0012] According to the disclosure in this specification, the present invention can effectively handle the success and / or failure of environmental Internet of Things services in wireless communication systems. Attached Figure Description
[0013] Figure 1 This is a diagram illustrating a wireless communication system. Figure 2 The structure of a radio frame used in NR is shown. Figures 3a to 3c This is an example diagram illustrating an exemplary architecture for wireless communication services. Figure 4 The time slot structure of an NR frame is shown. Figure 5An example of subframe types in NR is shown. Figure 6 The structure of a self-contained time slot is shown. Figures 7a to 7b An example of a connectivity topology for environmental Internet of Things (A-IoT) networks and devices is shown. Figure 8 An example of the process used for the A-IoT inventory service is shown. Figure 9 An example of the AS (Access Layer) process between an A-IoT device and a reader is shown. Figure 10 This is a flowchart illustrating an operation method of a reader according to an embodiment of this specification. Figure 11 This is a flowchart illustrating an operation method of a reader according to another embodiment of this specification. Figure 12 An apparatus according to one embodiment of this specification is shown. Figure 13 This is a block diagram illustrating the configuration of a terminal according to an embodiment of this specification. Figure 14 This is a block diagram illustrating a processor configuration that implements the disclosures of this specification. Figure 15 It is shown in detail Figure 12 The transceiver of the first device shown Figure 13 Block diagram of the transceiver section of the device shown. Detailed Implementation
[0014] It should be noted that the technical terms used in this specification are for describing specific embodiments only and are not intended to limit the content of this specification. Furthermore, unless specifically defined otherwise in this specification, the technical terms used in this specification should be interpreted as having the meaning commonly understood by one of ordinary skill in the art to which this disclosure pertains, and should not be construed as overly generalized or overly narrow. Additionally, when a technical term used in this specification is an incorrect technical term that fails to accurately represent the content and ideas of this specification, those skilled in the art should replace and understand it with a technical term that can be correctly understood. Moreover, general terms used in this specification should be interpreted according to their definitions in a dictionary or according to the context, and should not be construed as overly narrow.
[0015] Furthermore, singular expressions used in this specification include plural expressions unless the context clearly specifies otherwise. In this application, terms such as “comprising” or “having” should not be construed as necessarily including all the multiple components or steps described in the specification, but should be construed as potentially excluding some components or steps, or potentially including additional components or steps.
[0016] Furthermore, the use of ordinal numbers (such as first, second, etc.) in this specification is for the purpose of describing various components, but the components should not be limited by these terms. These terms are used only to distinguish one component from another. For example, without departing from the scope of the claims, a first component may be named a second component, and similarly, a second component may be named a first component.
[0017] When a component is said to be "connected to" or "linked to" another component, it can mean that the connection is direct or linked to that other component, or that there may be other components in between. Conversely, when a component is said to be "directly connected to" or "directly linked to" another component, it should be understood that there are no other components in between.
[0018] Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. However, regardless of the reference numerals, identical or similar components will be given the same reference numerals, and repeated descriptions thereof will be omitted. Furthermore, in describing the contents of this specification, detailed descriptions of relevant well-known technologies will be omitted if it is determined that such descriptions might obscure the key points of this specification. It should also be noted that the accompanying drawings are only for illustrative purposes and should not be construed as limiting the contents and ideas of this specification. The contents and ideas of this specification should be interpreted as extending to all modifications, equivalents, and substitutions other than those shown in the drawings.
[0019] In this specification, "A or B" can mean "A only", "B only", or "both A and B". In other words, in this specification, "A or B" can be interpreted as "A and / or B". For example, in this specification, "A, B or C" can mean "A only", "B only", "C only", or "any combination of A, B and C".
[0020] In this specification, the forward slash ( / ) or comma used can mean "and / or". For example, "A / B" can mean "A and / or B". Therefore, "A / B" can mean "A only", "B only", or "both A and B". For example, "A, B,C" can mean "A, B, or C".
[0021] In this specification, "at least one of A and B" may mean "only A", "only B" or "both A and B". Furthermore, in this specification, the expressions "at least one of A or B" or "at least one of A and / or B" may be interpreted in the same way as "at least one of A and B".
[0022] Furthermore, in this specification, "at least one of A, B and C" can mean "A only", "B only", "C only", or "any combination of A, B and C". Additionally, "at least one of A, B or C" or "at least one of A, B and / or C" can mean "at least one of A, B and C".
[0023] Furthermore, the parentheses used in this specification may mean "for example." Specifically, when referred to as "control information (PDCCH)," it may be an example of proposing "PDCCH (Physical Downlink Control Channel)" as "control information." In other words, "control information" in this specification is not limited to "PDCCH," and may be an example of proposing "PDCCH" as "control information." Moreover, even when referred to as "control information (i.e., PDCCH)," it may be an example of proposing "PDCCH" as "control information."
[0024] In this specification, a technical feature described individually in a single drawing may be implemented individually or simultaneously.
[0025] The accompanying drawings illustrate a UE (User Equipment) by way of example, but the UE shown may also be referred to as a Terminal, ME (Mobile Equipment), or other similar terms. Furthermore, the UE can be a portable device, such as a laptop, mobile phone, PDA, smartphone, or multimedia device, or a non-portable device, such as a PC or in-vehicle device.
[0026] In the following examples, the UE is used as an example of a device capable of wireless communication (e.g., a wireless communication device, a wireless apparatus, or a wireless equipment). The operations performed by the UE can be performed by any device capable of wireless communication. A device capable of wireless communication can also be referred to as a wireless communication device, a wireless apparatus, or a wireless equipment, etc.
[0027] The term "base station" as used below generally refers to a fixed station that communicates with wireless equipment, and can be used as a general term including eNodeB (evolved NodeB), eNB (evolved NodeB), BTS (Base Transceiver System), Access Point, gNB (Next Generation NodeB), RRH (Remote Radio Header), TP (Transmitter Point), RP (Receiver Point), relay, etc.
[0028] This specification uses LTE systems, LTE-A systems, and NR systems to describe embodiments, but these embodiments can be applied to any communication system that conforms to the above definitions.
[0029] Wireless Communication Systems
[0030] Thanks to the success of LTE (Long Term Evolution) / LTE-Advanced (LTE-A) in fourth-generation mobile communications, the commercialization of the next generation, namely the fifth generation (so-called 5G), has been completed, and subsequent research is ongoing.
[0031] The International Telecommunication Union (ITU) defines fifth-generation mobile communication as providing data transmission rates of up to 20 Gbps and experience transmission rates of at least 100 Mbps anywhere. The official name for this fifth-generation mobile communication is "IMT-2020".
[0032] The ITU has proposed three major use cases: eMBB (enhanced mobile broadband), mMTC (massive machine-type communications), and URLLC (ultra-reliable low-latency communications).
[0033] URLLC addresses use cases requiring high reliability and low latency. For example, services like autonomous driving, factory automation, and augmented reality demand high reliability and low latency (e.g., less than 1ms). Currently, 4G (LTE) latency is statistically between 21 and 43ms (optimal 10%), and 33 to 75ms (median). This is insufficient to support services requiring less than 1ms latency. Next, eMBB use cases address use cases requiring ultra-wideband mobile technology.
[0034] In other words, fifth-generation mobile communication systems support higher capacity than current 4G LTE, increase the density of mobile broadband users, and support D2D (device-to-device), high stability, and MTC (machine-type communication). 5G development also aims for lower latency and lower battery consumption than 4G mobile communication systems to better enable the Internet of Things (IoT). For this 5G mobile communication, new radio access technologies (New RAT or NR) can be proposed.
[0035] NR frequency bands can be defined as two types of frequency ranges (FR1, FR2). The numerical values of the frequency ranges can vary; for example, the frequency ranges of the two types (FR1, FR2) can be shown in Table 1 below. For ease of explanation, in the frequency ranges used in NR systems, FR1 can refer to "sub-6GHz range," and FR2 can refer to "above 6GHz range," and can also be referred to as millimeter wave (mmW).
[0036] [Table 1]
[0037] The frequency range of the NR system can be varied. For example, FR1 can include a band from 410 MHz to 7125 MHz, as shown in Table 1. That is, FR1 can include bands above 6 GHz (or 5850, 5900, 5925 MHz, etc.). For example, the bands above 6 GHz (or 5850, 5900, 5925 MHz, etc.) included in FR1 can include unlicensed bands. Unlicensed bands can be used for various purposes, such as vehicle communications (e.g., autonomous driving).
[0038] Furthermore, 3GPP-based communication standards define downlink physical channels corresponding to resource elements carrying information originating from the upper layers, and downlink physical signals for resource elements used by the physical layer but not carrying information originating from the upper layers. For example, the physical downlink shared channel (PDSCH), physical broadcast channel (PBCH), physical multicast channel (PMCH), physical control format indicator channel (PCFICH), physical downlink control channel (PDCCH), and physical hybrid ARQ indicator channel (PHICH) are defined as downlink physical channels, and reference signals and synchronization signals are defined as downlink physical signals. Also known as a pilot reference signal (RS), it refers to a predefined signal with a specific waveform known to both the gNB and the UE. For example, cell-specific RS, UE-specific RS (UE-RS), positioning RS (PRS), and channel state information RS (CSI-RS) are defined as downlink reference signals. The 3GPP LTE / LTE-A standard defines uplink physical channels corresponding to resource elements carrying information originating from the upper layers, as well as uplink physical signals for resource elements used by the physical layer but not carrying information originating from the upper layers. For example, the physical uplink shared channel (PUSCH), physical uplink control channel (PUCCH), and physical random access channel (PRACH) are defined as uplink physical channels, and a demodulation reference signal (DMRS) for uplink control / data signals and a sounding reference signal (SRS) for uplink channel measurement are defined.
[0039] In this specification, PDCCH (Physical Downlink Control Channel), PCFICH (Physical Control Format Indicator Channel), PHICH (Physical Hybrid Automatic Repeat Request Indicator Channel), and PDSCH (Physical Downlink Shared Channel) respectively refer to the set of time-frequency resources or resource elements carrying DCI (Downlink Control Information), CFI (Control Format Indicator), downlink ACK / NACK (Acknowledgment / Negative Acknowledgment), and downlink data. Furthermore, PUCCH (Physical Uplink Control Channel), PUSCH (Physical Uplink Shared Channel), and PRACH (Physical Random Access Channel) respectively refer to the set of time-frequency resources or resource elements carrying UCI (Uplink Control Information), uplink data, and random access signals.
[0040] Figure 1 This is a diagram illustrating a wireless communication system.
[0041] Reference Figure 1 It is known that the wireless communication system includes at least one base station (BS). The BS is divided into gNodeB (or gNB) 20-a and eNodeB (or eNB) 20-b. The gNB 20-a supports fifth-generation mobile communication. The eNB 20-b supports fourth-generation mobile communication, namely LTE (Long Term Evolution).
[0042] Each base station 20-a and 20-b provides communication services for a specific geographical area (usually called a cell) 20-1, 20-2, and 20-3. A cell can be further divided into multiple areas (called sectors).
[0043] A UE (User Equipment) typically belongs to a cell, called the serving cell. The base station that provides communication services to the serving cell is called the serving base station (BS). Since wireless communication systems are cellular systems, there are other cells adjacent to the serving cell. These adjacent cells are called neighboring cells, and the base stations that provide communication services to them are called neighboring base stations (BS). The serving cell and neighboring cells are determined relative to the UE.
[0044] Hereinafter, downlink refers to communication from base stations 20-a and 20-b to UE 10, and uplink refers to communication from UE 10 to base stations 20-a and 20-b. In the downlink, the transmitter can be part of base stations 20-a and 20-b, and the receiver can be part of UE 10. In the uplink, the transmitter can be part of UE 10, and the receiver can be part of base stations 20-a and 20-b.
[0045] Furthermore, wireless communication systems can be broadly categorized into FDD (Frequency Division Duplex) and TDD (Time Division Duplex) methods. In FDD, uplink and downlink transmissions occur on different frequency bands. In TDD, uplink and downlink transmissions occur on the same frequency band but at different times. The channel response in TDD is essentially reciprocal. This means that within a given frequency range, the downlink and uplink channel responses are almost identical. Therefore, in TDD-based wireless communication systems, the downlink channel response can benefit from the advantages gained from the uplink channel response. Because the entire frequency band is time-divided for uplink and downlink transmissions in TDD, downlink transmissions at the base station and uplink transmissions at the user unit cannot occur simultaneously. In TDD systems where uplink and downlink transmissions are distinguished by subframes, they are executed in different subframes.
[0046] Figure 2 The structure of a radio frame used in NR is shown.
[0047] In NR, uplink and downlink transmissions are composed of frames. A radio frame is 10 milliseconds (ms) long and is defined as two 5ms half-frames (HF). A half-frame is defined as five 1ms subframes (SF). Subframes are divided into one or more time slots, the number of which depends on the SCS (subcarrier spacing). Each time slot includes 12 or 14 OFDM(A) symbols depending on the CP (cyclic prefix). When using normal CP, each time slot includes 14 symbols. When using extended CP, each time slot includes 12 symbols. Here, symbols can include OFDM symbols (or CP-OFDM symbols) and SC-FDMA symbols (or DFT-s-OFDM symbols).
[0048] Support for various parameter sets (numerology)
[0049] In NR systems, with the development of wireless communication technology, multiple parameter sets (numerologies) can be provided to terminals. For example, when the SCS is 15kHz, it supports wide area coverage of traditional cellular bands; when the SCS is 30kHz / 60kHz, it supports dense-urban areas, lower latency, and wider carrier bandwidth; when the SCS is 60kHz or higher, it supports bandwidths greater than 24.25GHz to overcome phase noise.
[0050] The parameter set can be defined by the CP (Cyclic Prefix) length and the subcarrier spacing (SCS). A cell can provide multiple parameter sets to the terminal. When the index of the parameter set is represented as μ, each subcarrier spacing and the corresponding CP length can be shown in the table below.
[0051] [Table 2]
[0052] Under normal CP conditions, when the parameter set index is represented as μ, the number of OFDM symbols per time slot (N) slot symb ), Number of time slots per frame (N) frame,μ slot ) and the number of time slots per subframe (N) subframe,μ slot As shown in the table below.
[0053] [Table 3]
[0054] In the case of extended CP, when the index of the parameter set is represented as μ, the number of OFDM symbols per slot (N) slot symb ), Number of time slots per frame (N) frame,μ slot ) and the number of time slots per subframe (N) subframe,μ slot As shown in the table below.
[0055] [Table 4]
[0056] In NR systems, the OFDM(A) parameter sets (numerology) (e.g., SCS, CP length, etc.) of multiple cells aggregated for a single terminal can be set differently. Therefore, the (absolute time) intervals of time resources (e.g., SF, time slots, or TTI) (collectively referred to as TU (Time Unit) for convenience) consisting of the same number of symbols can be set differently between aggregated cells.
[0057] Figures 3a to 3c This is an example diagram illustrating an exemplary architecture for wireless communication services.
[0058] Reference Figure 3a The UE connects to both LTE / LTE-A based cells and NR based cells in DC (dual connectivity) mode.
[0059] The NR-based cell is connected to the core network used for existing fourth-generation mobile communications, namely the EPC (Evolved Packet Core).
[0060] Reference Figure 3b ,and Figure 3a Unlike LTE / LTE-A, LTE-A-based cells connect to the core network used for fifth-generation mobile communications, namely the 5G core network.
[0061] Based on such Figure 3a and Figure 3b The service model shown is called NSA (Non-Standalone).
[0062] Reference Figure 3c The UE only connects to NR-based cells. This service mode based on the architecture is called SA (Standalone).
[0063] Furthermore, in the aforementioned NR, it is possible to consider using downlink subframes to receive data from the base station and using uplink subframes to transmit data back to the base station. This approach can be applied to paired and unpaired spectrum. A pair of spectrums means a spectrum comprising two carriers used for downlink and uplink operation. For example, in a pair of spectrums, a carrier may include a pair of downlink and uplink frequency bands.
[0064] Figure 4 The time slot structure of an NR frame is shown.
[0065] A time slot comprises multiple symbols in the time domain. For example, in normal CP, a time slot comprises 14 symbols, but in extended CP, a time slot comprises 12 symbols. A carrier comprises multiple subcarriers in the frequency domain. An RB (Resource Block) is defined in the frequency domain as multiple (e.g., 12) consecutive subcarriers. A BWP (Bandwidth Component) is defined in the frequency domain as multiple consecutive (physical, P) RBs and can correspond to a set of parameters (e.g., SCS, CP length, etc.). A terminal can configure up to N (e.g., 4) BWPs in both the downlink and uplink. Downlink or uplink transmission is performed through the active BWP, and at a given time, only one BWP can be active for any of the BWPs configured by the terminal. Each element in the resource grid is called a resource element (RE) and can be mapped to a complex number of symbols.
[0066] Figure 5 An example of subframe types in NR is shown.
[0067] Figure 5 The TTI (Transmission Time Interval) shown can be referred to as a subframe or time slot of NR (or new RAT). Figure 5 Subframes (or time slots) can be used in NR (or new RAT) TDD systems to minimize data transmission latency. For example... Figure 5 As shown, a subframe (or time slot) comprises 14 symbols. The first few symbols of a subframe (or time slot) can be used for the downlink (DL) control channel, and the last few symbols can be used for the uplink (UL) control channel. The remaining symbols can be used for either DL or UL data transmission. Based on this subframe (or time slot) structure, downlink and uplink transmissions can proceed sequentially within a single subframe (or time slot). Therefore, downlink data can be received within a subframe (or time slot), and uplink acknowledgment responses (ACK / NACK) can be sent within the same subframe (or time slot).
[0068] This structure of a subframe (or time slot) can be called a self-contained subframe (or time slot).
[0069] Specifically, the first N symbols in a time slot are used to transmit the DL control channel (hereinafter referred to as the DL control area), and the last M symbols in a time slot can be used to transmit the UL control channel (hereinafter referred to as the UL control area). N and M are integers of 0 or greater. The resource area between the DL control area and the UL control area (hereinafter referred to as the data area) can be used for DL data transmission or UL data transmission. For example, the physical downlink control channel (PDCCH) can be transmitted in the DL control area, and the physical downlink shared channel (PDSCH) can be transmitted in the DL data area. The physical uplink control channel (PUCCH) can be transmitted in the UL control area, and the physical uplink shared channel (PUSCH) can be transmitted in the UL data area.
[0070] This subframe (or time slot) structure has the advantage of reducing the time required to retransmit data that has received errors, thereby minimizing the final data transmission delay. In such a self-contained subframe (or time slot) structure, the transition from transmit mode to receive mode or from receive mode to transmit mode may require a time gap. Therefore, in the subframe structure, some OFDM symbols during the transition from DL to UL can be set to a guard period (GP).
[0071] Figure 6 The structure of a self-contained time slot is shown.
[0072] In NR systems, frames are characterized by a self-contained structure, where DL control channels, DL or UL data, and UL control channels can all be included within a single time slot. For example, the first N symbols in a time slot are used to transmit DL control channels (hereinafter referred to as the DL control area), and the last M symbols in the time slot can be used to transmit UL control channels (hereinafter referred to as the UL control area). N and M are integers of 0 or greater. The resource area between the DL control area and the UL control area (hereinafter referred to as the data area) can be used for either DL data transmission or UL data transmission. As an example, the following configuration can be considered. The intervals are listed in chronological order.
[0073] 1. DL configuration only
[0074] 2. UL configuration only
[0075] 3. Hybrid UL-DL configuration
[0076] - DL area + GP (protection period) + UL control area
[0077] - DL control area + GP + UL area
[0078] DL regions: (i) DL data region, (ii) DL control region + DL data region
[0079] UL Areas: (i) UL Data Area, (ii) UL Data Area + UL Control Area
[0080] PDCCH can be transmitted in the DL control area, and PDSCH can be transmitted in the DL data area. PUCCH can be transmitted in the UL control area, and PUSCH can be transmitted in the UL data area. DCI (Downlink Control Information) such as DL data scheduling information and UL data scheduling information can be transmitted in the PDCCH. UCI (Uplink Control Information) such as ACK / NACK (positive acknowledgment / negative acknowledgment) information for DL data, CSI (Channel State Information) information, and SR (Schedule Request) can be transmitted in the PUCCH. GP provides time slots during the transition from transmit mode to receive mode or vice versa between the base station and the terminal. Some symbols at the time point of transition from DL to UL within a subframe can be set to GP.
[0081] Figures 7a to 7b An example of a connectivity topology for ambient Internet of Things (A-IoT / AIoT) networks and devices is shown.
[0082] Ambient Internet of Things (AIoT / AIoT) devices are IoT devices powered by energy harvesting, which have no batteries or only limited energy storage capabilities (e.g., using capacitors). For ease of explanation, AIoT devices may be referred to as devices below. This is for illustrative purposes only and can be changed to any other name. Energy is provided through energy harvesting from radio frequency waves, light, motion, heat, or other suitable sources. Energy harvesting can be continuous (e.g., through vibration) or incidental. Therefore, it cannot be assumed that AIoT devices always have power for data transmission and reception. AIoT devices need to be designed to have lower complexity, smaller size, reduced capabilities, and lower power consumption than previously defined 3GPP IoT endpoints / devices (e.g., NB-IoT (Narrowband Internet of Things) / eMTC (Enhanced Machine-Type Communications) devices). AIoT devices can be designed to have a long lifespan of more than 10 years without maintenance. In this way, they can replace existing 3GPP IoT devices or support various use cases (e.g., inventory, sensors, location, commands) that are not supported by existing 3GPP IoT devices. Functions and procedures designed to support use cases for the Internet of Things (IoT) in the environment can be defined as AIoT services (e.g., inventory services, command services). For example, the primary purpose of an inventory service is to search for which goods (e.g., boxes, containers, packages, tools) exist within a specific area. When a request is sent within the network of these goods, AIoT devices attached to them report identifiers associated with the goods, and additional information such as status, measurement results, and / or location can be added via the AIoT device and / or AIoT RAN (Radio Access Network) / Reader. Inventory services allow the discovery / tracking of AIoT devices within a certain range of a specific reader. Command services represent procedures used to execute commands to AIoT devices within a specific area. These commands can include reading, writing, disabling, and / or enabling services.
[0083] - Read: Request to read information from an AIoT device.
[0084] - Write: Request to write information to an AIoTDevice
[0085] - Disable: Request that an AIoT device has the capability to transmit RF permanently or temporarily disabled.
[0086] - Enable: Request to enable a temporarily disabled AIoT device.
[0087] For environmental IoT networks and devices, definitions can be made as follows: Figures 7a to 7b The connection topology is shown below. Figure 7a In this context, BS stands for Radio Access Network (RAN). An AIoT RAN refers to a node that performs specific functions for AIoT within the functional division between the RAN and the Core Network (CN). These functions include, for example, RAN node functions such as control over AIoT radio resources used by A-IoT devices. An AIoT RAN can serve one or more AIoT readers. An AIoT reader is a reader that terminates the AIoT protocol with an AIoT device. For ease of explanation, this node may be referred to as an AIoT RAN (or AIoT reader) below. This is for illustrative purposes only; it can be labeled as an AIoT RAN reader, AIoT base station, or AIoT BS reader, among other names.
[0088] In all these topologies, carrier waves can be provided to AIoT devices from other nodes inside or outside the topology. The links in each topology can be bidirectional or unidirectional. Figure 7a In this system, AIoT devices communicate directly and bidirectionally with base stations. Communication between the base station and the AIoT device can include AIoT data and / or signaling. The base station sending data to the AIoT device and the base station receiving data from the AIoT device can be the same base station or different base stations.
[0089] exist Figure 7bIn this topology, AIoT devices and the AIoT RAN communicate bidirectionally through intermediate nodes / auxiliary nodes / auxiliary terminals / auxiliary UEs. In this topology, intermediate nodes / auxiliary nodes / auxiliary terminals / auxiliary UEs can be relays, IAB (Integrated Access and Backhaul), UEs, repeaters, etc., that support AIoT functions / services. For ease of explanation, this node will be referred to as a UE reader below. This is only for illustrative purposes and can be labeled as a UE connected / associated with an AIoT-enabled RAN, an AIoT-enabled RAN / reader, an AIoT reader, an AIoT UE reader, or any other name.
[0090] Figure 8 An example of the process used for the A-IoT inventory service is shown.
[0091] Reference Figure 8 The process used for the AIoT inventory service is described below.
[0092] 1a. The A-IoT CN sends an inventory request message to the A-IoT RAN node.
[0093] 1b. A-IoT RAN node allocation and coordination of the use of A-IoT radio resources.
[0094] 2. The A-IoT RAN node sends a manifest response message to the A-IoT CN.
[0095] 3. The A-IoT RAN node performs the inventory process for A-IoT devices through the A-IoT radio interface.
[0096] 4a / 4b. After receiving the inventory results from the A-IoT device, the A-IoT RAN node may send one or more inventory reports to the A-IoT CN, including the received inventory results.
[0097] Figure 9 An example of the AS (Access Layer) process between an A-IoT device and a reader is shown.
[0098] Reference Figure 9 The following describes the overall AS (Access Layer) process between ambient IoT (A-IoT) devices and readers.
[0099] Step A: A-IoT Paging (S901)
[0100] Based on the service request, the reader sends an A-IoT paging message indicating which device(s) need to respond. Here, the A-IoT paging message can have the same meaning as the initial trigger message.
[0101] Step B: D2R (Device to Reader) (Device ID) Data Transmission (S902 to S903)
[0102] A-IoT devices triggered by paging execute the A-IoT random access procedure or, without such procedure, send their device identifier (ID) to the reader. Afterward, D2R data is sent to the reader.
[0103] Step C1: R2D (Reader to Device) data transmission (S904)
[0104] Perform possible R2D data transmission (e.g., for sending a command).
[0105] Step C2: D2R data transmission (S905)
[0106] Perform possible R2D data transmission (e.g., the corresponding response to a command).
[0107] Thus, although high-level procedures for providing inventory or command services are defined, AIoT services cannot be implemented because detailed operations between AIoT devices and AIoT RAN / readers supporting AIoT services are not provided. In particular, no specific methods are provided for handling the success and failure of AIoT services.
[0108] There is no specific approach provided for handling the success and failure of AIoT services in terms of offering AIoT technologies that are designed to support lower complexity, smaller size, reduced capabilities, and lower power consumption than existing 3GPP LPWA (Low Power Wide Area) IoT.
[0109] This specification (or disclosure), made to address these issues, proposes methods and apparatus for handling the success and / or failure of AIoT services.
[0110] The following section describes in detail the data transmission and reception methods based on 5GS (Fifth Generation System) / NR technology. However, this is for illustrative purposes only, and this specification can also be applied to any system or wireless access technology (e.g., 6G). The embodiments described in this specification can refer to the information elements and operational content specified in NR / 5GS specifications (e.g., NR MAC specification TS 38.321, NR RRC specification TS38.331, system architecture specification TS 23.501, etc.). Even if the terminal operational content related to the definition of a certain information element is not described in this specification, the corresponding content specified in the standards and specifications of known technologies may be included in this specification.
[0111] Any function described below can be defined as a separate terminal capability (UE radio capability or UE core network capability) and sent by the terminal to the base station / core network entity via appropriate signaling (e.g., AMF (Access and Mobility Management Function) / SMF (Session Management Function) / AIoTNF (Ambient IoT Network Function)). Alternatively, any function can be combined / integrated to define a corresponding terminal capability and sent by the terminal to the base station / core network entity via appropriate signaling. Here, AIoTF (Ambient IoT Function or Ambient IoT Network Function) refers to the network function that provides management and control for AIoT services and AIoT operations. This is for illustrative purposes only and can be changed to any other name. AIoTF can select an AIoT RAN node (or UE reader). AIoTF can receive AIoT service requests from the application function / application server and trigger the AIoTRAN / reader (or AIoT UE reader) to perform AIoT service operations related to the AIoT device. AIoTF can collect the AIoT service operation results from the AIoTRAN node (or AIoT UE reader) and send them to the application function / application server.
[0112] Environmental IoT devices can be categorized and defined into at least one device type / category based on at least one supported capability (or a combination of at least one capability). For example, based on energy storage capacity, they can be categorized into devices with no storage space at all, devices with a specific storage capacity (up to E1 joules), and devices with another specific storage capacity (up to E2 joules, E2>E1). As another example, devices without energy storage and without independent signal generation / amplification (e.g., backscatter transmission) (hereinafter referred to as Device A for ease of illustration), devices with energy storage devices and without independent signal generation (e.g., backscatter transmission) (hereinafter referred to as Device B for ease of illustration), the energy storage usage of Device B may include amplification of reflected signals, and devices with energy storage devices and independent signal generation (e.g., active RF components for transmission) (hereinafter referred to as Device C for ease of illustration) can be categorized. As another example, the following devices can be classified: a device with a peak power consumption of ~1 µW, energy storage, and no amplification of DL and UL within the device, whose uplink transmission is backscattered on an externally provided carrier (hereinafter referred to as device 1 for ease of explanation); a device with a peak power consumption of ≤ several hundred µW, energy storage, and amplification of both DL and UL within the device, whose uplink transmission is backscattered on an externally provided carrier (hereinafter referred to as device 2a for ease of explanation); and a device with a peak power consumption of ≤ several hundred µW, energy storage, and amplification of both DL and UL within the device, whose uplink transmission is generated internally by the device (hereinafter referred to as device 2b for ease of explanation).
[0113] The AIoT RAN / reader / base station / UE-reader or AIoTF can send / instruct / configure information / messages to the AIoT device to indicate the enable / activation / allow / support / configuration of any function or combination of functions described below. For example, this can be sent from the AIoTF to the AIoT device via an AIoT NAS message / container. Alternatively, it can be sent from the AIoT RAN / reader / base station / UE-reader to the AIoT device via a corresponding dedicated MAC PDU.
[0114] The AIoT RAN / reader / base station / UE-reader or AIoTF can send / instruct / configure information / messages to AIoT devices for disabling / deactivating / restricting / controlling any function or combination of functions described below. As an example, a prohibit / suspend / deactivate timer can be instructed for the operation of that function. This timer can be started / restarted at the same time as the function is activated, or before or after the function is activated. During the timer's operation, the device can be disabled / deactivated / restricted / controlled, preventing it from starting / executing the function.
[0115] The embodiments and functions described below can be performed independently. Alternatively, the embodiments and functions described below can be implemented in any combination / integration, which is obviously also included within the scope of this specification.
[0116] Any information described below may be traffic characteristic information obtained / calculated / derived through statistics / experience in the terminal / network (e.g., expected value / average, deviation, standard deviation, minimum, maximum, etc., any statistical / statistical quantity). Therefore, any information contained in this specification may represent at least one of the average (expected value), minimum, maximum, or standard deviation values. This is for illustrative purposes only; all information in this specification can be used as statistical information. Any information described below may be pre-configured in the device / network or provisioning information provided through OAM (Operation, Administration and Maintenance) / Application Server / Application Function / AIoT / UDM (Unified Data Management) / ADM (AIoT Data Management).
[0117] In the following text, the physical channel used for R2D (Reader to Device) data transmission is referred to as PRDCH (Physical Reader to Device CHannel), the physical channel used for D2R (Device to Reader) data transmission is referred to as PDRCH (Physical Device to Reader CHannel), and the interface / link between the reader and the device is referred to as RD interface / link (e.g., AIoT Radio interface). This is for illustrative purposes only and can be replaced with any other name. In the following text, RD / DR link resource / scheduling information may include (for RD / DR link communication) start time / subframe / timeslot / symbol / reference time / unit time of any AIoT device, (for RD / DR link communication) start time / subframe / timeslot / symbol / reference time / unit time offset of any AIoT device, (for RD / DR link communication) start time / subframe / timeslot / symbol, (for RD / DR link communication) start time / subframe / timeslot / symbol relative to a specific reference time / moment (e.g., R2D data reception, start of R2D data reception, end of R2D data reception, or specific reference time of the serving base station / cell serving the reader), and (for RD / DR link communication) start time / subframe / timeslot / The information includes at least one of the following: symbol offset, (RD / DR link communication) duration, (RD / DR link) transmission timing, (RD / DR link) transmission period, available time slots, available time slot range, maximum number of time slots, uplink / downlink start time / subframe / time slot / symbol of the associated base station / auxiliary terminal used to indicate the start time of the RD link, start time / subframe / time slot / symbol offset, RD link frequency domain information, RD link subchannel number / index, DR link frequency offset, RD / DR link MCS, RD / DR link transport block size, communication range, location information, priority, RD / DR link retransmission count, (RD / DR link communication) validity period / time, and valid reference.
[0118] Message definition for canceling / releasing AIoT service requests
[0119] To increase the likelihood of successful responses from AIoT devices, the core network (e.g., AIoTF) can select one or more AIoT RAN(s) / Reader(s) and indicate AIoT service requests through the corresponding AIoT RANs / Readers. In this scenario, if the AIoT device has successfully sent a paging message triggered by the AIoT service request from the core network and received from an AIoT RAN / Reader, if the AIoT device has successfully completed a response to the paging message triggered by the AIoT service request from the core network and received from an AIoT RAN / Reader as an AIoT service response / acknowledgment, if at least one AIoT RAN / Reader selected by the core network (e.g., AIoTF) has received an AIoT service response / acknowledgment for the AIoT service request from the AIoT device, and / or if the core network (e.g., AIoTF) has received an AIoT service response / acknowledgment for the AIoT service request from at least one of the selected AIoT RAN / Readers, then the core network (e.g., AIoTF) may provide a method to instruct the remaining / other AIoT RANs / Readers that have not received the corresponding AIoT service response / acknowledgment message to cancel the AIoT service request message.
[0120] In one embodiment, the core network (e.g., AIoTF) can receive an AIoT service request from an application function / application server and select / determine one or more AIoT RANs / Readers to execute / process the AIoT service request. The core network (e.g., AIoTF) can send a message (e.g., a manifest request message or a command request message) for the AIoT service request to the corresponding AIoT RANs / Readers. When the core network (e.g., AIoTF) receives an AIoT service response / acknowledgment message indicating success / response / acknowledgment of the AIoT service request message from the AIoT RANs / Readers executing / processing the AIoT service request (or from at least one AIoT RAN / Reader among the AIoT RANs / Readers), it can initiate / execute a procedure to release the requested / ongoing AIoT service request to the remaining / other AIoT RANs / Readers that have already sent the AIoT service request message. The release message may include at least one of the following: AIoT device identification information, core network (AIoTF / AMF) device NxAP / NGAP identification information for the AIoT device, AIoT RAN / Reader NxAP / NGAP identification information, and a corresponding reason. The release message may define information to indicate the release of all service requests requested / in progress for the AIoT device, thereby releasing all service requests for the AIoT device. The release message may include information for distinguishing / identifying the AIoT service request (information associated / identified with an AIoT service request received from the core network).
[0121] For example, the core network (e.g., AIoTF) can initiate this procedure by sending an AIoT service cancellation message to one or more of the remaining / other AIoT RANs / Readers that have not received a corresponding AIoT service response / acknowledgment message. For ease of illustration, this is labeled as an AIoT service cancellation message. This is for illustrative purposes only and can be replaced with any other name, such as AIoT cancellation message, AIoT release message, AIoT request cancellation message, etc.
[0122] In another embodiment, the core network (e.g., AIoTF) can receive an AIoT service request from an application function / application server and select / determine one or more AIoT RAN(s) / Reader(s) to execute / process the AIoT service request. The core network (e.g., AIoTF) can send a message (e.g., a manifest request message or a command request message) for the AIoT service request to the corresponding AIoT RAN(s) / Reader(s). When the core network (e.g., AIoTF) fails to receive a success / response / acknowledgment of the AIoT service request message from any AIoT RANs / Readers executing / processing the AIoT service request (or from at least one AIoT RAN / Reader among AIoT RANs / Readers), the core network (e.g., AIoTF) can initiate / execute a procedure to cancel the requested / ongoing AIoT service request to the AIoT RAN / Reader that has already sent the AIoT service request message.
[0123] In another embodiment, when an AIoT RAN / Reader is unable to accept / accommodate an AIoT service request from the core network, it can initiate / execute a procedure to indicate that the AIoT service request has failed. The core network (e.g., AIoTF) can receive the AIoT service request from the application function / application server and select / determine one or more AIoT RAN(s) / Reader(s) to execute / process the AIoT service request. If the AIoT RAN / Reader is unable to accept / accommodate the AIoT service request, the AIoT RAN / Reader can send an AIoT service request failure message containing an appropriate reason value to the core network. This failure message may include at least one of the following: AIoT device identification information, core network (AIoTF / AMF) device NxAP / NGAP identification information about the AIoT device, AIoT RAN / Reader NxAP / NGAP identification information, and a corresponding reason. The failure message may also include information for distinguishing / identifying the AIoT service request (information associated with / identified by an AIoT service request received from the core network).
[0124] As another example, when a message for canceling an AIoT service request (e.g., an AIoT service cancellation message) is received from the core network (e.g., AIoTF), the AIoT RANs / Readers that received the message can send a response / acknowledgment message to the core network (e.g., AIoTF). For ease of illustration, this is labeled an AIoT service cancellation response message. This is for illustrative purposes only and can be replaced with any other name, such as AIoT cancellation response / acknowledgment message, AIoT cancellation response / acknowledgment message, AIoT request cancellation response / acknowledgment message, etc. The response / acknowledgment message may include at least one of the following: AIoT device identification information, core network (AIoTF / AMF) device NxAP / NGAP identification information about the AIoT device, AIoT RAN / Reader NxAP / NGAP identification information, and a corresponding reason. The response / acknowledgment message may also include information for distinguishing / identifying the AIoT service request (information associated / identified with an AIoT service request received from the core network).
[0125] As another example, AIoT service cancellation messages and / or AIoT service cancellation response messages can be provided via NxAP (or service-based interface protocol between AIoTF and AIoT RAN / reader, or application protocol on top of service-based interface protocol between AIoTF and AIoT RAN) / NGAP messages.
[0126] As another example, the AIoT service cancellation message, AIoT service cancellation response message, and / or AIoT failure message may include information for identifying the corresponding AIoT service request. This information may include at least one of the following: information for identifying / distinguishing an AIoT service request / trigger requested in a core network; AIoT service type; information for distinguishing the AIoT service request; information indicating the purpose of the AIoT service; AIoT device identification information; NxAP (or service-based interface protocol between AIoTF and AIoT RAN, or application protocol on top of the service-based interface protocol between AIoTF and AIoT RAN) / NGAP identification information of the AIoT device in the AIoT RAN / reader; NxAP (or service-based interface protocol between AIoTF and AIoT RAN, or application protocol on top of the service-based interface protocol between AIoTF and AIoT RAN) / NGAP identification information of the AIoT device in the AIoTF; AIoTF identification information; and AIoT RAN / reader identification information.
[0127] As another example, AIoT service cancellation messages and / or AIoT service cancellation response messages and / or AIoT failure messages can be provided between the AIoTF and AIoT UE Reader via NAS messages.
[0128] As another example, AIoT service cancellation messages, AIoT service cancellation response messages (or information contained in such messages), and / or AIoT failure messages can be provided via NxAP (or service-based interface protocol between AIoTF and the base station / RAN of the serving UE Reader, or between AIoTF and AIoTRAN, or via an application protocol on top of the service-based interface protocol between AIoTF and RAN) or via the service-based interface protocol between AIoTF and AMF and NGAP messages between AMF and base station.
[0129] AIoT service cancellation messages, AIoT service cancellation response messages (or information contained in such messages), and / or AIoT failure messages can be sent and received between the base station serving the UE reader and the UE reader via RRC messages.
[0130] AIoT service cancellation messages, AIoT service cancellation response messages (or information contained in such messages), and / or AIoT failure messages can be sent and received via AIoT UE reader user plane data in AIoTF.
[0131] Other embodiments of this specification are described below.
[0132] Application functions / application servers can request AIoT services from AIoTF (e.g., inventory procedures or command procedures). At this time, information required to perform AIoT service operations can be included and sent. This information can be at least one of the following: AIoT service type information (e.g., inventory or command (e.g., read, write, enable, disable)), information for AIoT RAN / Reader selection, the expected / expected / estimated number of target AIoT devices for the service, and the expected / expected / estimated size of the D2R response message to the service request.
[0133] The AIoTF can determine the AIoT device identification information contained in a paging message based on information received from application functions, and this paging message is transmitted over the AIoT radio interface. The AIoTF can send an AIoT service request message (e.g., a manifest request message or a command request message) to the AIoT RAN. This AIoT service request message can be sent between the AIoTF and the AIoT RAN via the AMF. For example, it can be sent through an interface between the AIoTF and the AMF (e.g., the Nz interface) and an interface between the AMF and the AIoT RAN (e.g., the N2 / NG interface). The AIoT service request message can also be sent between the AIoT RAN and the AMF via NGAP. Alternatively, a (direct) interface (e.g., the Nx interface) can be defined between the AIoTF and the AIoT RAN, and an application protocol (e.g., NxAP) (or a service-based interface protocol between the AIoT and the AIoT RAN, or an application protocol on top of the service-based interface protocol between the AIoTF and the AIoT RAN) can be defined on that interface to send the AIoT service request message.
[0134] The AIoT RAN / Reader can execute AIoT procedures (e.g., procedures executed in the access layer between the AIoT RAN / Reader and the AIoT device) to AIoT devices via the AIoT wireless interface. To do this, the AIoT RAN / Reader can send AIoT paging messages to the AIoT device. To enable AIoT devices to effectively distinguish and process AIoT service request procedures from upper access layer layers (e.g., AIoTNAS, AIoT data / applications) and / or AIoT procedures from the access layer (e.g., access layer or PHY / MAC), the following methods can be used.
[0135] As an example, paging messages can request AIoT services from AIoT devices via downlink NAS messages.
[0136] AIoTF can generate NAS messages for AIoT service requests based on information received from application functions. These NAS messages represent NAS messages processed in the NAS layer / entity of AIoTF and AIoT devices. The NAS messages may include at least one of the following: AIoT service type information, AIoT device identification information, and security parameters.
[0137] Here, the AIoT service type information can distinguish at least one of the following: list service / operation (or distinguish at least one of list service / operation for a single device, list service / operation for a group of devices, list service / operation for multiple devices, and list service / operation for all devices), command service / operation (or distinguish at least one of command service / operation for a single device, command service / operation for a group of devices, command service / operation for multiple devices, and command service / operation for all devices) and read / write / enable / disable service / operation (or distinguish at least one of read / write / enable / disable service / operation for a single device, read / write / enable / disable service / operation for a group of devices, read / write / enable / disable service / operation for multiple devices, and read / write / enable / disable service / operation for all devices).
[0138] In one embodiment, (for the paging MAC PDU, the downlink MAC PDU, or the MAC header) 1 bit can be used to distinguish between list services / operations and command services / operations (for the AIoT service type). 2 bits can be used to distinguish between additional service types for command services / operations, such as Read / Write / Enable / Disable services / operations. When the AIoT service type is set to list, the AIoT device can ignore the information used to distinguish additional service types. Alternatively, when the AIoT service type is set to list, the information used to distinguish additional service types can be reserved for future forward compatibility.
[0139] As another example, 3 bits can be used to distinguish AIoT service types, differentiating between list / Read / Write / Enable / Disable services / operations. The remaining 3 of the 8 values can be set as reserved values to support future forward compatibility.
[0140] As another example, to support forward compatibility, 2 bits can be used to distinguish between inventory services / operations and command services / operations. 2 bits can also be used to distinguish between Read / Write / Enable / Disable services / operations, which are additional service type information for command services / operations. A reserved 1-bit (2 values) value can be used to support the future addition of AIoT services / operations. Alternatively, 1 bit can be used to distinguish the AIoT service type, and future addition of AIoT services / operations can be supported by adding a separate field to distinguish the corresponding MAC PDU version / release / format / service type version, etc.
[0141] As another example, to support forward compatibility, 2 bits can be used to distinguish between inventory services / operations and command services / operations. If the information used to distinguish the AIoT service type is set to command services / operations, the MAC header can be configured to include an additional 2 bits to distinguish Read / Write / Enable / Disable services / operations. If the information used to distinguish the AIoT service type is set to inventory services / operations, a MAC header without the 2-bit additional service type distinguishing field can be configured.
[0142] As another example, (for the paging MAC PDU or for the downlink MAC PDU or for the MAC header) to support forward compatibility, the MAC PDU (protocol) version / release / format / service type version field may be included.
[0143] As another example, (for the paging MAC PDU, or for the downlink MAC PDU, or for the MAC header) 1 bit can be used as information to distinguish between single / multiple devices (or single / multiple device identifiers). For group identifiers, the value distinguishing a single device (or single device identifier) and the value distinguishing a group of devices can be used within the value distinguishing a single device (or single device identifier). The AIoT device can check whether the terminal identification information contained in the paging message matches its own single device identifier and / or the group device identifier to which it belongs. If the AIoT device determines that the terminal identification information contained in the paging message matches one or more of its own single device identifier and the group device identifier to which it belongs, it can perform a random access procedure to the AIoT base station / reader.
[0144] As another example, if the AIoT device identification information field is included (for the paging MAC PDU, or for the downlink MAC PDU, or for the MAC header), a specific value of the AIoT device identification information (e.g., all 1s or all 0s) can be used as information to indicate that all devices within the coverage area of the AIoT RAN / reader are being paged.
[0145] As another example, (for the paging MAC PDU, or for the downlink MAC PDU, or for the MAC header) may include information / fields for indicating / distinguishing all devices paging / receiving within the coverage area of the AIoT RAN / reader. This can be provided by defining a physical channel distinct from the PRDCH, or by scrambling the information within the PRDCH with a specific identifier, or by adding the field to the MAC PDU / header, or by defining a field for distinguishing the MAC PDU / header.
[0146] As another example, the paging message (e.g., paging MAC PDU) for all devices within the coverage area of the AIoT RAN / reader and the paging message (e.g., paging MAC PDU) for a single / group of devices within the coverage area of the AIoT RAN / reader can be defined to have different formats. For example, a paging message for a single / group of AIoT devices may include an AIoT device identification information field (and / or an information field for identifying the AIoT device) within the paging MAC PDU (or the paging MAC header or the NAS message / container included in the paging message). Conversely, a paging message for all AIoT devices may not include the AIoT device identification information field (and / or the information field for identifying the AIoT device) within the paging MAC PDU (or the paging MAC header or the NAS message / container included in the paging message). The paging message format for a single / group of AIoT devices and the paging message format for all AIoT devices can be distinguished by at least one of the following: information in the MAC header used to distinguish the MAC PDU, information used to distinguish the format of the MAC PDU, specific bits in the information used to distinguish that the MAC PDU is a paging message, logical channel identification information contained in the MAC PDU, PDU type / data type identification information contained in the MAC PDU, and service type information contained in the MAC PDU.
[0147] As another example, (for the paging MAC PDU or for the downlink MAC PDU or for the MAC header) 2 bits can be used as information to distinguish at least one of a single device, multiple devices, a group of devices, and all devices within the coverage area of the AIoT RAN / reader.
[0148] As another example, for group identifiers, the information indicating a single / multiple device (or a single / multiple device identifier) can be set to a single device, and in the appropriate case, an additional field for distinguishing the group device identifier can be included. If the information indicating a single / multiple device (or a single / multiple device identifier) is set to multiple devices, a MAC header without the additional field for distinguishing the group device identifier can be configured.
[0149] As another example, if the paging MAC PDU indicates that the paging is for all devices by means of information / fields used to indicate / distinguish paging / receiving for all devices, and / or if (for the paging MAC PDU or for the downlink MAC PDU or for the MAC header) does not include an AIoT device identification information field, then the AIoT device may ignore the information used to indicate a single device or multiple devices (or a single device identifier or multiple device identifiers) (whether included).
[0150] As another example, 2 bits can be used to distinguish AIoT service types to differentiate at least one of inventory services / operations for a single device, inventory services / operations for multiple devices, command services / operations for a single device, and command services / operations for multiple devices. 2 bits can also be used as additional service type information to distinguish command services / operations to differentiate Read / Write / Enable / Disable services / operations.
[0151] As another example, 4 bits (16 values) can be used as information to distinguish AIoT service types to differentiate between list / read / write / enable / disable services / operations for a single device and list / read / write / enable / disable services / operations for multiple devices.
[0152] AIoT device identification information can be represented as AIoT device identification information contained in NxAP (or service-based interface protocol between AIoTF and AIoT RAN or application protocol on top of service-based interface protocol between AIoTF and AIoT RAN / reader) / NGAP messages, or AIoT device identification information used in the NAS (non-access stratum) layer / entity of AIoTF and AIoT devices. This information can represent at least one of the following: a full permanent Ambient IoT Device Identifier configured in an AIoT device; a part of an Ambient IoT Device Identifier; a full permanent Ambient IoT Device Identifier that has been securely processed / verified (e.g., encryption / encryption, integrity protection, message authentication code, hash function, and / or device authentication); a part of a permanent Ambient IoT Device Identifier that has been securely processed / verified; and / or a code calculated / generated / derived / determined by securely processing / verifying the AIoT device (or the full / partial permanent AIoT Device Identifier); a code associated with the AIoT device (or the full / partial permanent AIoT Device Identifier); and filtering / masking information used to determine / extract AIoT device identification information. The permanent AIoT Device Identifier can be assigned by an operator or a third party. The permanent AIoT Device Identifier may include a network identifier (e.g., MCC (Mobile Country Code) + MNC (Mobile Network Code) and / or NID (Network Identifier)) or information used to identify a third party. A permanent AIoT device identifier can be included within a network identifier (e.g., MCC+MNC and / or NID) or information used to identify third parties to distinguish different AIoT devices (e.g., EPC (Electronic Product Code) or other local / internal identification information). During any signaling process, more than one AIoT device identification information can be used for a single AIoT device. For example, a network identifier (e.g., MCC+MNC and / or NID) or information used to identify third parties can be used as the first AIoT device identification information, and information used to distinguish different AIoT devices within the network identifier (e.g., MCC+MNC and / or NID) or information used to identify third parties (e.g., EPC (Electronic Product Code) or other local / internal identification information) can be used as the second AIoT device identification information.At least one of the first AIoT device identification information and the second AIoT device identification information (or all / part of the first AIoT device identification information and at least one of all / part of the second AIoT device identification information) can be securely processed / verified and sent and received (e.g., the first AIoT device identification information (plaintext), the second AIoT device identification information (ciphertext), or vice versa).
[0153] Security parameters can represent at least one of the following information in AIoTF and / or AIoT devices: keys, key identification information, freshness values, counters, tokens, verification values, random parameters, algorithms, and device credentials / profiles used to securely process / verify complete / partial permanent AIoT device identification information (e.g., encryption / encryption, integrity protection, message authentication codes, hash functions, and / or device authentication).
[0154] AIoTF can send an NxAP / NGAP message to the AIoT RAN that includes a NAS message for requesting an AIoT service (e.g., a manifest or command). In addition to the NAS message, the (NxAP / NGAP) request message may also include at least one of the following: AIoT device identification information contained in a paging message, the expected / estimated / estimated number of target AIoT devices for the service, and the expected / estimated / estimated size of a D2R response message to the service request.
[0155] As an example, an AIoT RAN / reader can send a paging message to an AIoT device that includes a NAS message requesting AIoT services. This paging message can be sent to the AIoT device via PRDCH through a specific downlink / R2D MAC PDU (or MAC control unit or paging MAC PDU). The AIoT device can receive this MAC PDU via PRDCH. The downlink / R2D MAC PDU (or MAC control unit or paging MAC PDU) including the paging message can include explicit indication information / fields within the MAC PDU to distinguish it. Alternatively, the downlink / R2D MAC PDU (or MAC control unit or paging MAC PDU) including the paging message can be implicitly distinguished by the presence of any fields / combinations of fields contained within the MAC PDU.
[0156] For example, the inclusion of a MAC PDU can be indicated by at least one of the following: information indicating whether a NAS message / container / security / processing for an AIoT service request is included; information associated with / identified by an AIoT service request received from the core network; information indicating whether a paging message is included; information distinguishing the paging MAC PDU format; and information distinguishing the AIoT service type. The inclusion of a paging message in the MAC PDU can also be indicated by at least one of the following: AIoT service type; information indicating whether it is the first message of that AIoT service type; AIoT device identification information; AIoT RAN / reader identification information; information indicating whether a NAS message / container is included; and information indicating whether an AS ID (Access Layer Identifier) is included / applied.
[0157] As another example, a paging message sent by the AIoT RAN / reader to an AIoT device may not include NAS messages / containers received from the AIoTF. For instance, when the AIoT RAN / reader sends a paging message including indication information for contention-based random access for the AIoT device, the message may not include NAS messages / containers received from the AIoTF. NAS messages / containers received from the AIoTF may then be included in AIoT MSG2 and / or R2D data transmission. This paging message can be sent to the AIoT device via the PRDCH through a specific downlink / R2D MAC PDU (or MAC control unit or paging MAC PDU). The AIoT device can receive this MAC PDU via the PRDCH. The downlink / R2D MAC PDU (or MAC control unit or paging MAC PDU) including the paging message may include explicit indication information / fields within the MAC PDU to distinguish it. Alternatively, the downlink / R2D MAC PDU (or MAC control unit or paging MAC PDU) including the paging message may be implicitly distinguishable by the presence of any fields / combinations of fields contained within the MAC PDU. For example, the MAC PDU may indicate that it includes / represents a paging message by at least one of the following: AIoT service type, information indicating whether it is the first message of that AIoT service type, AIoT device identification information, AIoT RAN / reader identification information, and information indicating whether the AS ID is included / applied.
[0158] As another example, the AIoT RAN / reader can send paging messages to AIoT devices via a paging logical channel / MAC-PDU used for AIoT service requests. A logical channel identifier / MAC-PDU-identifier / distinguishing information can be defined to differentiate this paging logical channel / MAC-PDU. This MAC PDU (or MAC control unit or paging MAC PDU) may include this logical channel identifier / MAC-PDU-identifier / distinguishing indication information and is sent to the AIoT device via the PRDCH. The AIoT device can receive this MAC PDU via the PRDCH.
[0159] Here, the information indicating whether to include / apply the AS ID refers to information indicating whether to include / apply (at least) AS (Access Layer) identification information for D2R scheduling and R2D reception purposes. The AS ID can be a random ID contained in the first D2R message (or AIoT message 1 (MSG1)) or one of the IDs assigned to the device by the reader. This AS ID can be included in subsequent R2D messages that include this information so that the device can distinguish and use messages sent to itself using this AS ID.
[0160] Figure 10 This is a flowchart illustrating an operation method of a reader according to an embodiment of this specification.
[0161] Reference Figure 10 The reader receives a first message from the AIoTF (Internet of Things for the Environment) requesting AIoT services (S1001). Furthermore, after receiving the first message, the reader receives a second message from the AIoTF indicating the cancellation of the AIoT service (S1002), and in response to the second message, sends a third message to the AIoTF indicating that the cancellation of the AIoT service is complete (S1003).
[0162] After receiving the first message, the reader can send a fourth message for paging to the AIoT device. Here, the fourth message may be an AIoT paging MAC PDU, and the MAC PDU may include information (or fields) indicating whether security parameters are included.
[0163] In addition, the first message may further include at least one of AIoT device identification information and security parameters, and may be received via NGAP (Next Generation Application Protocol) between the AIoTF and the base station.
[0164] The AIoT device identification information may include one of the following: permanent AIoT device identification information, first securely processed identification information, and filtering information. The security parameter may be a random parameter used to generate the second securely processed identification information. Here, it can be confirmed whether the generated second securely processed identification information matches the received first securely processed identification information.
[0165] In addition, the second message may include identification information, AIoTF identification information, and reason information associated with the request for the AIoT service.
[0166] In addition, the third message may include identification information and AIoTF identification information associated with the request for the AIoT service.
[0167] Figure 11 This is a flowchart illustrating an operation method of a reader according to another embodiment of this specification.
[0168] The following is for reference Figure 11 Describe the operation method when the reader is a terminal reader.
[0169] Reference Figure 11 The terminal reader receives a first message from the base station requesting AIoT (Ambient Internet of Things) services (S1101). Furthermore, after receiving the first message, the terminal reader receives a second message from the base station indicating the cancellation of the AIoT service (S1102), and in response to the second message, sends a third message to the base station indicating that the cancellation of the AIoT service is complete (S1103).
[0170] After receiving the first message, the terminal reader can send a fourth message for paging to the AIoT device. Here, the fourth message may be an AIoT paging MAC PDU, and the MAC PDU may include information (or fields) indicating whether security parameters are included.
[0171] Furthermore, the first message may include at least one of AIoT device identification information and security parameters, and can be received via RRC (Radio Resource Control). That is, the first message can be an RRC message.
[0172] The AIoT device identification information may include one of the following: permanent AIoT device identification information, first securely processed identification information, and filtering information. The security parameter may be a random parameter used to generate the second securely processed identification information. Here, it can be confirmed whether the generated second securely processed identification information matches the received first securely processed identification information.
[0173] Furthermore, the second message may include identification information associated with the request for the AIoT service, AIoTF identification information, and reason information, and may be received via RRC (Radio Resource Control). That is, the second message may be an RRC message.
[0174] Furthermore, the third message may include identification information and AIoTF identification information associated with the request for the AIoT service, and may be sent via RRC (Radio Resource Control). That is, the third message may be an RRC message.
[0175] The disclosures described herein so far can be implemented by various means. For example, the disclosures herein can be implemented by hardware, firmware, software, or a combination thereof. Specifically, reference will be made to the following figures.
[0176] Figure 12 An apparatus according to one embodiment of this specification is shown.
[0177] Reference Figure 12 The wireless communication system may include a first device 100a and a second device 100b.
[0178] The first device 100a may be a base station, network node, transmitting terminal, receiving terminal, wireless device, wireless communication equipment, vehicle, vehicle equipped with autonomous driving function, connected car, unmanned aerial vehicle (UAV), AI (artificial intelligence) module, robot, AR (augmented reality) device, VR (virtual reality) device, MR (mixed reality) device, holographic device, public safety device, MTC device, IoT device, medical device, fintech device (or financial device), security device, climate / environment device, device related to 5G services, or other device related to the Fourth Industrial Revolution.
[0179] The second device 100b may be a base station, network node, transmitting terminal, receiving terminal, wireless device, wireless communication equipment, vehicle, vehicle equipped with autonomous driving function, connected car, unmanned aerial vehicle (UAV), AI (artificial intelligence) module, robot, AR (augmented reality) device, VR (virtual reality) device, MR (mixed reality) device, holographic device, public safety device, MTC device, IoT device, medical device, fintech device (or financial device), security device, climate / environment device, device related to 5G services, or other device related to the Fourth Industrial Revolution.
[0180] The first device 100a may include at least one processor, such as processor 1020a, at least one memory, such as memory 1010a, and at least one transceiver, such as transceiver 1031a. The processor 1020a may perform the aforementioned functions, processes, and / or methods. The processor 1020a may execute one or more protocols. For example, the processor 1020a may execute one or more layers of a wireless interface protocol. The memory 1010a is connected to the processor 1020a and may store various forms of information and / or instructions. The transceiver 1031a is connected to the processor (1020a) and may be controlled to transmit and receive wireless signals.
[0181] The second device 100b may include at least one processor, such as processor 1020b, at least one memory device, such as memory 1010b, and at least one transceiver, such as transceiver 1031b. The processor 1020b may perform the aforementioned functions, processes, and / or methods. The processor 1020b may implement one or more protocols. For example, the processor 1020b may implement one or more layers of a wireless interface protocol. The memory 1010b is connected to the processor 1020b and may store various forms of information and / or instructions. The transceiver 1031b is connected to the processor 1020b and may be controlled to transmit and receive wireless signals.
[0182] The memory 1010a and / or the memory 1010b can be connected internally or externally to the processor 1020a and / or the processor 1020b, and can also be connected to other processors via various technologies such as wired or wireless connections.
[0183] The first device 100a and / or the second device 100b may have one or more antennas. For example, antenna 1036a and / or antenna 1036b are used to transmit and receive wireless signals.
[0184] Figure 13 This is a block diagram illustrating the configuration of a terminal according to an embodiment of this specification.
[0185] In particular, Figure 13 This is to show the foregoing in more detail. Figure 12 A diagram of the device.
[0186] The device includes a memory 1010, a processor 1020, a transceiver unit 1031, a power supply unit including a power management module 1091 and a battery 1092, a display 1041, an input unit 1053, a speaker 1042 and a microphone 1052, a SIM (Subscriber Identity Module) card, and one or more antennas.
[0187] Processor 1020 is used to implement the functions, processes, and / or methods described in this specification. A layer of the radio interface protocol can be implemented in processor 1020. Processor 1020 may include an ASIC (Application-Specific Integrated Circuit), other chipsets, logic circuits, and / or data processing devices. Processor 1020 may be an AP (Application Processor). Processor 1020 may include at least one of a DSP (Digital Signal Processor), CPU (Central Processing Unit), GPU (Graphics Processing Unit), and modem (Modem; modulator and demodulator). An example of processor 1020 may be Qualcomm. SNAPDRAGON™ series processors manufactured by Samsung The EXYNOS™ series processors manufactured by Apple MediaTek's A-series processors HELIO™ series processors manufactured by Intel The manufactured ATOM™ series processors, HiSilicon The KIRINTM series processors or corresponding next-generation processors manufactured.
[0188] The power management module 1091 manages the power of the processor 1020 and / or the transceiver unit 1031. The battery 1092 supplies power to the power management module 1091. The display 1041 outputs the results processed by the processor 1020. The input unit 1053 receives inputs to be used by the processor 1020. The input unit 1053 can be displayed on the display 1041. A SIM card is an integrated circuit used to securely store the International Mobile Subscriber Identity (IMSI) and its associated keys for identifying and authenticating users in mobile phone devices such as mobile phones and computers. Many SIM cards can also store contact information.
[0189] Memory 1010 is operatively coupled to processor 1020 and stores various information for operating processor 1010. Memory 1010 may include ROM (Read-Only Memory), RAM (Random Access Memory), flash memory, memory card, storage medium, and / or other storage devices. When embodiments are implemented in software, the techniques described herein can be implemented as modules (e.g., processes, functions, etc.) that perform the functions described herein. Modules may be stored in memory 1010 and executed by processor 1020. Memory 1010 may be implemented internally to processor 1020. Alternatively, memory 1010 may be implemented externally to processor 1020 and communicatively connected to processor 1020 by various means known in the art.
[0190] Transceiver unit 1031 is operatively coupled to processor 1020 and transmits and / or receives wireless signals. Transceiver unit 1031 includes a transmitter and a receiver. Transceiver unit 1031 may include baseband circuitry for processing radio frequency signals. The transceiver unit controls one or more antennas to transmit and / or receive wireless signals. To initiate communication, processor 1020 transmits command information, such as command information for transmitting wireless signals constituting voice communication data, to transceiver unit 1031. The antennas have the function of transmitting and receiving wireless signals. When receiving wireless signals, transceiver unit 1031 can transmit the signal to processor 1020 for processing and convert the signal into baseband data. The processed signal can be converted into audible or readable information output through speaker 1042.
[0191] Speaker 1042 outputs sound-related results processed by processor 1020. Microphone 1052 receives sound-related inputs that will be used by processor 1020.
[0192] Users can input command information such as phone numbers by pressing (or touching) a button on the input unit 1053 or by activating the microphone 1052 using voice. The processor 1020 receives the command information and processes it to perform an appropriate function, such as dialing a phone number. Operational data can be retrieved from the SIM card or memory 1010. Furthermore, the processor 1020 can display the command or operational information on the display 1041 for user convenience.
[0193] Figure 14 This is a block diagram illustrating a processor configuration that implements the disclosures of this specification.
[0194] Reference Figure 14As can be seen, the processor 1020, which implements the disclosure of this specification, may include multiple circuits to implement the functions, processes, and / or methods described herein. For example, the processor 1020 may include a first circuit 1020-1, a second circuit 1020-2, and a third circuit 1020-3. Furthermore, although not shown, the processor 1020 may include more circuits. Each circuit may include multiple transistors.
[0195] The processor 1020 may be referred to as an ASIC (Application-Specific Integrated Circuit) or an AP (Application Processor), and may include at least one of a DSP (Digital Signal Processor), a CPU (Central Processing Unit), and a GPU (Graphics Processing Unit).
[0196] Figure 15 It is shown in detail Figure 12 The transceiver of the first device shown Figure 13 Block diagram of the transceiver section of the device shown.
[0197] Reference Figure 15 The transceiver unit 1031 includes a transmitter 1031-1 and a receiver 1031-2. The transmitter 1031-1 includes a DFT (Discrete Fourier Transform) unit 1031-11, a subcarrier mapper 1031-12, an IFFT unit 1031-13, a CP insertion unit 1031-14, and a wireless transmission unit 1031-15. The transmitter 1031-1 may further include a modulator. Furthermore, it may further include, for example, a scrambling unit (not shown), a modulation mapper (not shown), a layer mapper (not shown), and a layer permutation unit (not shown), and these may be arranged before the DFT unit 1031-11. That is, to prevent an increase in PAPR (Peak-to-Average Power Ratio), the transmitter 1031-1 first passes the information through the DFT 1031-11 before mapping the signal to the subcarriers. The signal extended (or precoded) by the DFT section 1031-11 is subcarrier mapped by the subcarrier mapper 1031-12 and then passes through the IFFT (Inverse Fast Fourier Transform) section 1031-13 to generate the signal on the time axis.
[0198] The DFT unit 1031-11 performs a DFT on the input symbols to output a complex-valued symbol. For example, if the input consists of Ntx symbols (where Ntx is a natural number), the DFT size is Ntx. The DFT unit 1031-11 can be referred to as a transform precoder. The subcarrier mapper 1031-12 maps the complex-valued symbol onto subcarriers in the frequency domain. The complex-valued symbol can be mapped to resource elements corresponding to resource blocks allocated for data transmission. The subcarrier mapper 1031-12 can be referred to as a resource element mapper. The IFFT unit 1031-13 performs an IFFT on the input symbols to output a baseband signal for data as a time-domain signal. The CP insertion unit 1031-14 copies a portion of the latter part of the baseband signal for data and inserts it into the former part of the baseband signal for data. By inserting the CP, ISI (inter-symbol interference) and ICI (inter-carrier interference) can be prevented, thereby maintaining orthogonality in multipath channels.
[0199] On the other hand, receiver 1031-2 includes a wireless receiving unit 1031-21, a CP removal unit 1031-22, an FFT unit 1031-23, and an equalization unit 1031-24. The wireless receiving unit 1031-21, CP removal unit 1031-22, and FFT unit 1031-23 of receiver 1031-2 perform functions opposite to those of the wireless transmitting unit 1031-15, CP insertion unit 1031-14, and IFFT unit 1031-13 in transmitter 1031-1. Receiver 1031-2 may further include a demodulator.
[0200] While preferred embodiments have been described above by way of example, the disclosure of this specification is not limited to such specific embodiments, and therefore modifications, alterations or improvements can be made in various forms within the scope of the ideas and claims of this specification.
[0201] In the exemplary system described above, the method is described based on a flowchart as a series of steps or blocks, but is not limited to the order of the described steps; some steps may occur in a different order or simultaneously. Furthermore, those skilled in the art will understand that the steps shown in the flowchart are not exclusive and may include other steps, or one or more steps in the flowchart may be deleted without affecting the scope of the claims.
[0202] The claims described in this specification can be combined in various ways. For example, the technical features of the method claims can be combined to implement an apparatus, and the technical features of the apparatus claims can be combined to implement a method. Furthermore, the technical features of the method claims and apparatus claims can be combined to implement an apparatus, and the technical features of the method claims and apparatus claims can be combined to implement a method.
Claims
1. A method for operating a reader in a wireless communication system, comprising: The steps of receiving a first message from the environmental IoT function to request environmental IoT services; After receiving the first message, the step of receiving a second message from the environmental IoT function to instruct the termination of the environmental IoT service; as well as In response to the second message, a step is taken to send a third message to the environmental IoT function to indicate that the environmental IoT service has been terminated.
2. The method according to claim 1, further comprising: The step of sending a fourth message for paging to the environmental IoT device after receiving the first message.
3. The method according to claim 1, wherein, The first message includes at least one of environmental IoT device identification information and security parameters, and is received via a next-generation application protocol between the environmental IoT function and the base station.
4. The method according to claim 3, wherein, The environmental IoT device identification information includes one of the following: permanent environmental IoT device identification information, first security-processed identification information, and filtering information. The security parameter is a random parameter used to generate the second securely processed identification information.
5. The method according to claim 2, wherein, The fourth message includes information indicating whether security parameters are included.
6. The method according to claim 1, wherein, The second message includes identification information associated with the request for the environmental IoT service, environmental IoT function identification information, and reason information.
7. The method according to claim 1, wherein, The third message includes identification information associated with the request for the environmental IoT service and environmental IoT function identification information.
8. A reader in a wireless communication system, comprising: At least one processor; as well as At least one memory that stores instructions and is operatively electrically connected to the at least one processor. The at least one processor is configured to perform the following operations: Receive the first message from the environmental IoT function to request environmental IoT services; After receiving the first message, a second message indicating the cancellation of the environmental IoT service is received from the environmental IoT function; and In response to the second message, a third message is sent to the environmental IoT function to indicate that the environmental IoT service has been terminated.
9. The reader of claim 8, wherein, When the instruction is executed by the at least one processor, the following operations are also performed: After receiving the first message, a fourth message for paging is sent to the environmental IoT device.
10. The reader according to claim 8, wherein, The first message includes at least one of environmental IoT device identification information and security parameters, and is received via a next-generation application protocol between the environmental IoT function and the base station.
11. The reader according to claim 10, wherein, The environmental IoT device identification information includes one of the following: permanent environmental IoT device identification information, first security-processed identification information, and filtering information. The security parameter is a random parameter used to generate the second securely processed identification information.
12. The reader according to claim 9, wherein, The fourth message includes information indicating whether security parameters are included.
13. The reader according to claim 8, wherein, The second message includes identification information associated with the request for the environmental IoT service, environmental IoT function identification information, and reason information.
14. The reader according to claim 8, wherein, The third message includes identification information associated with the request for the environmental IoT service and environmental IoT function identification information.