Apparatus in a wireless communication system and data processing method of the apparatus

Abstract

A device in a wireless communication system and a data processing method thereof are provided. The device receives a paging message containing first device identification information and confirms whether the first device identification information matches second device identification information stored in the device. Furthermore, based on the confirmation of the match, the device sends a Media Access Control (MAC) message containing upper-layer data, wherein the paging message includes a first security parameter and information indicating the presence of the first security parameter.

Description

Technical Field

[0001] This manual 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 a more advanced wireless broadband communication system 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] Among them, 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-high reliability, ultra-low latency, and ultra-high availability (e.g., V2X, emergency services, remote control); mMTC is a next-generation mobile communication scenario with characteristics such as low cost, low power consumption, short data packets, and massive connectivity (e.g., Internet of Things, IoT). Summary of the Invention

[0004] Technical issues One disclosure of this specification is intended to provide a method for providing data processing for a device with ultra-low complexity and ultra-low power consumption in a wireless communication system, and a device for performing said method.

[0005] Technical solution One embodiment of this specification provides a method in a wireless communication system in which a device receives a paging message containing first device identification information and confirms whether the first device identification information matches second device identification information stored in the device. Furthermore, based on the confirmation of the match, the device sends a Media Access Control (MAC) message containing upper-layer data, wherein the paging message includes a first security parameter and information indicating the presence of the first security parameter.

[0006] Furthermore, one embodiment of this specification provides a device in a wireless communication system, the device comprising: at least one processor; and at least one memory, the memory storing instructions and operatively electrically connected to the at least one processor, wherein the instructions are executed by the at least one processor, the operations performed including: receiving a paging message containing first device identification information, and confirming whether the first device identification information matches second device identification information stored in the device. Furthermore, based on the confirmation of the match, a Media Access Control (MAC) message containing upper-layer data is sent, wherein the paging message includes a first security parameter and information indicating the presence of the first security parameter.

[0007] The first security parameter can be used to generate a security protection identifier, wherein the security protection identifier can be generated based on a device identifier.

[0008] Furthermore, the upper-layer data may include at least one of the device identifier and a second security parameter calculated in the device, wherein the device identifier and the second security parameter may be distinguished and included as different fields within the Non-Access Stratum (NAS) message.

[0009] Furthermore, the paging message contains specific fields, and based on these specific fields, at least one of the first device identification information and the first security parameter can be transmitted to the upper layer.

[0010] Furthermore, confirming whether the first device identification information matches the second device identification information stored in the device may include an indication from the upper layer to the MAC layer (Media Access Control layer) regarding whether there is a match.

[0011] Beneficial effects Based on the disclosure in this specification, data communication for devices with ultra-low complexity and ultra-low power consumption in wireless communication systems can be effectively controlled. Attached Figure Description

[0012] Figure 1 This is a diagram illustrating a wireless communication system.

[0013] Figure 2 The structure of a radio frame used in NR is shown.

[0014] Figures 3a to 3c This is an example diagram illustrating an exemplary architecture for wireless communication services.

[0015] Figure 4 The time slot structure of an NR frame is shown.

[0016] Figure 5 This shows an example of subframe types in NR.

[0017] Figure 6 The structure of the self-contained time slot is shown.

[0018] Figures 7a to 7b An example of a connectivity topology for environmental Internet of Things (A-IoT) networks and devices is shown.

[0019] Figure 8 An example of the process used for A-IoT inventory services is shown.

[0020] Figure 9 This illustrates an example of the access layer (AS) process between an A-IoT device and a reader.

[0021] Figures 10a to 10b This illustrates an A-IoT access process for which embodiments of this specification can be applied.

[0022] Figure 11 An apparatus according to an embodiment of this specification is shown.

[0023] Figure 12 This is a block diagram illustrating the configuration of an apparatus according to an embodiment of this specification.

[0024] Figure 13 This is a block diagram illustrating a processor configuration that implements the disclosures of this specification.

[0025] Figure 14 It is shown in detail Figure 11 The transceiver of the first device shown Figure 12 Block diagram of the transceiver of the device shown. Detailed Implementation

[0026] 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 specification pertains, and should not be interpreted as having an overly broad or overly narrow meaning. Moreover, when the technical terms used in this specification are incorrect technical terms that fail to accurately express the content and ideas of this specification, those skilled in the art should replace and understand them with technical terms that can be correctly understood. Furthermore, the general terms used in this specification should be interpreted according to dictionary definitions or context, and should not be interpreted as having an overly narrow meaning.

[0027] Furthermore, the 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 constituent elements or steps described in the specification, but rather as meaning that some constituent elements or steps may be excluded, or that additional constituent elements or steps may be included.

[0028] Furthermore, the terms containing ordinal numbers (such as first, second, etc.) used in this specification may be used to describe various constituent elements, but the constituent elements should not be limited by the terms. The terms are used only for the purpose of distinguishing one constituent element from another. For example, without departing from the scope of the claims, a first constituent element may be named a second constituent element, and similarly, a second constituent element may be named a first constituent element.

[0029] When a component is referred to as being connected to or connected to another component, it may be directly connected to or connected to that other component, or there may be other intermediate components. Conversely, when a component is referred to as being directly connected to or connected to another component, it should be understood that there are no other intermediate components.

[0030] 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 assigned the same reference numerals, and repeated descriptions will be omitted. Furthermore, in describing the contents of this specification, detailed descriptions of relevant prior art will be omitted if it is determined that such detailed descriptions may obscure the key points of this specification. It should also be noted that the accompanying drawings are for illustrative purposes only and should not be construed as limiting the content and ideas of this specification. The content and ideas of this specification should be interpreted as extending to all modifications, equivalents, and substitutions other than those shown in the drawings.

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

[0032] In this specification, the forward slash ( / ) or comma 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".

[0033] 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 as equivalent to "at least one of A and B".

[0034] Furthermore, in this specification, "at least one of A, B and C" may 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" may mean "at least one of A, B and C".

[0035] Furthermore, the parentheses used in this specification may mean "for example." Specifically, when referred to as "control information (PDCCH)," examples of "physical downlink control channel (PDCCH)" may have been provided. In other words, "control information" in this specification is not limited to "PDCCH," but "PDCCH" may have been provided as an example of "control information." Moreover, even when referred to as "control information (i.e., PDCCH)," examples of "PDCCH" may have been provided as "control information."

[0036] In this specification, a technical feature described separately in a single drawing may be implemented individually or simultaneously.

[0037] While a user equipment (UE) is illustrated in the accompanying drawings, the UE may also be referred to as a terminal, mobile device (ME), or other similar terms. Furthermore, the UE may 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 equipment.

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

[0039] The term "base station" as used below generally refers to a fixed station that communicates with wireless devices, and can be used as a general term encompassing eNodeB, eNB, BTS (Base Transceiver Station), Access Point, gNB (Next Generation NodeB), RRH (Remote Radio Header), TP (Transmitter Point), RP (Receiver Point), relay, etc.

[0040] Although this specification uses LTE systems, LTE-A systems, and NR systems to illustrate embodiments, these embodiments can also be applied to any communication system that conforms to the above definitions.

[0041] Wireless Communication Systems Following the success of Long Term Evolution (LTE) / LTE-Advanced (LTE-A) for 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.

[0042] The International Telecommunication Union (ITU) defines fifth-generation mobile communication as providing data transmission rates of up to 20 Gbps and an experience transmission rate of at least 100 Mbps anywhere. Its official name is "IMT-2020".

[0043] The ITU has proposed three major use cases: enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and ultra-reliable low-latency communications (URLLC).

[0044] 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). Current 4G (LTE) latency is statistically between 21ms and 43ms (best in the top 10%), and between 33ms and 75ms (median). This is insufficient to support services requiring less than 1ms latency. Next, eMBB use cases address scenarios requiring ultra-wideband mobile technology.

[0045] In other words, fifth-generation mobile communication systems support higher capacity than current 4G LTE, increasing the density of mobile broadband users, and supporting device-to-device (D2D), high-stability, and machine-type (MTC) communication. 5G development also aims to achieve lower latency and lower battery consumption than 4G mobile communication systems, better enabling the Internet of Things (IoT). For this 5G mobile communication, a new radio access technology (New RAT or NR) can be proposed.

[0046] 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) are 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 both can be referred to as millimeter wave (mmW).

[0047] [Table 1]

[0048] The frequency range of the NR system can be varied. For example, FR1 may include a frequency band from 410 MHz to 7125 MHz as shown in Table 1. That is, FR1 may include frequency bands above 6 GHz (or 5850, 5900, 5925 MHz, etc.). For example, frequency bands above 6 GHz (or 5850, 5900, 5925 MHz, etc.) included in said FR1 may include unlicensed bands.

[0049] In addition, 3GPP-based communication standards define downlink physical channels corresponding to resource elements that carry information originating from the upper layers, and downlink physical signals corresponding to 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, while reference signals and synchronization signals are defined as downlink physical signals. Also known as the 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 the uplink physical channels corresponding to resource elements used to carry information originating from the upper layers, and the uplink physical signals corresponding to 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, while the demodulation reference signal (DMRS) used for uplink control / data signals and the sounding reference signal (SRS) used for uplink channel measurement are defined.

[0050] In this specification, the Physical Downlink Control Channel (PDCCH), Physical Control Format Indicator Channel (PCFICH), Physical Hybrid Automatic Repeat Request Indicator Channel (PHICH), and Physical Downlink Shared Channel (PDSCH) respectively refer to the set of time-frequency resources or resource elements carrying downlink control information (DCI), control format indicator (CFI), downlink acknowledgment / negative acknowledgment (ACK / NACK), and downlink data. Similarly, the Physical Uplink Control Channel (PUCCH), Physical Uplink Shared Channel (PUSCH), and Physical Random Access Channel (PRACH) respectively refer to the set of time-frequency resources or resource elements carrying uplink control information (UCI), uplink data, and random access signals.

[0051] Figure 1 This is a diagram illustrating a wireless communication system.

[0052] 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) 20a and eNodeB (or eNB) 20b. The gNB 20a supports fifth-generation mobile communication. The eNB 20b supports fourth-generation mobile communication, namely Long Term Evolution (LTE).

[0053] Each base station 20a and 20b provides communication services for a specific geographical area (usually called a cell) 20-1, 20-2, 20-3. A cell can be further divided into multiple areas (called sectors).

[0054] User equipment (UE) 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). Wireless communication systems are cellular systems, therefore, there are other cells adjacent to the serving cell. These adjacent cells are called neighboring cells. The base stations that provide communication services to neighboring cells are called neighboring base stations (BS). The serving cell and neighboring cells are determined relative to the UE.

[0055] Hereinafter, downlink refers to communication from base station 20 to UE10, and uplink refers to communication from UE10 to base station 20. In the downlink, the transmitter can be part of base station 20, and the receiver can be part of UE10. In the uplink, the transmitter can be part of UE10, and the receiver can be part of base station 20.

[0056] Furthermore, wireless communication systems can be broadly categorized into Frequency Division Duplex (FDD) and Time Division Duplex (TDD) 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 be derived from the uplink channel response, which is an advantage. Because the entire frequency band is time-divided for uplink and downlink transmissions in TDD, the base station's downlink transmission and the UE's uplink transmission cannot be performed simultaneously. In TDD systems that differentiate uplink and downlink transmissions by subframe, uplink and downlink transmissions are performed in different subframes.

[0057] Figure 2 The structure of a radio frame used in NR is shown.

[0058] In NR, uplink and downlink transmissions are composed of frames. A radio frame is 10 ms long and is defined as two 5 ms half-frames (HF). A half-frame is defined as five 1 ms subframes (SF). Subframes are divided into one or more time slots, the number of which depends on the subcarrier spacing (SCS). Each time slot includes 12 or 14 OFDM(A) symbols depending on the cyclic prefix (CP). When using normal CP, each time slot includes 14 symbols. When using extended CP, each time slot includes 12 symbols. Here, symbols may include OFDM symbols (or, CP-OFDM symbols) or SC-FDMA symbols (or, DFT-s-OFDM symbols).

[0059] Supports multiple parameter sets (numerology) In NR systems, with the development of wireless communication technology, multiple parameter sets can be provided to terminals. For example, when the SCS is 15kHz, it supports wide-area coverage in 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 bandwidth greater than 24.25GHz to overcome phase noise.

[0060] The parameter set can be defined by the cyclic prefix (CP) 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 μ, the subcarrier spacing and the corresponding CP length are shown in the table below.

[0061] [Table 2]

[0062] For a standard 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 in each subframe (N) subframe,μ slot As shown in the table below.

[0063] [Table 3]

[0064] For 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 in each subframe (N) subframe,μ slot As shown in the table below.

[0065] [Table 4]

[0066] In NR systems, OFDM(A) parameter sets (e.g., SCS, CP length, etc.) can be set differently between multiple cells merged into a single terminal. Therefore, the (absolute time) intervals of time resources (e.g., SF, time slots, or TTI) consisting of the same number of symbols (collectively referred to as Time Units (TUs) for convenience) can be set differently between the merged cells.

[0067] Figures 3a to 3c This is an example diagram illustrating an exemplary architecture for wireless communication services.

[0068] Reference Figure 3a The UE connects to both LTE / LTE-A based cells and NR based cells using dual connectivity (DC).

[0069] The NR-based cell is connected to the core network used for existing fourth-generation mobile communications, namely the Evolved Packet Core (EPC).

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

[0071] Based on the above Figure 3a and Figure 3b The service mode of the architecture shown is called non-standalone (NSA).

[0072] Reference Figure 3c The UE only connects to NR-based cells. This service mode based on this architecture is called standalone (SA).

[0073] Additionally, in the aforementioned NR, downlink subframes can be used for receiving data from the base station, while uplink subframes can be used for transmitting data to the base station. This approach can be applied to paired and unpaired spectrum. A pair of spectrums refers to two carrier spectrums comprising both downlink and uplink operations. For example, in a pair of spectrums, one carrier may include a pair of downlink and uplink frequency bands.

[0074] Figure 4 The time slot structure of an NR frame is shown.

[0075] 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. A resource block (RB) is defined in the frequency domain as multiple (e.g., 12) consecutive subcarriers. A bandwidth part (BWP) is defined in the frequency domain as multiple consecutive (physical, P) RBs and may 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 configured by the terminal can be active. In the resource grid, each element is called a resource element (RE) and can be mapped to a complex number of symbols.

[0076] Figure 5 This shows an example of subframe types in NR.

[0077] Figure 5 The transmission time interval (TTI) 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) are used for the downlink (DL) control channel, and the last few symbols are used for the uplink (UL) control channel. The remaining symbols are 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 (ACK / NACK) responses can be sent within the same subframe (or time slot).

[0078] This structure of a subframe (or time slot) can be called a self-contained subframe (or time slot).

[0079] 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 are used to transmit the UL control channel (hereinafter referred to as the UL control area). N and M are integers greater than or equal to 0. The resource area (hereinafter referred to as the data area) located between the DL control area and the UL control area can be used for either 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 control 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 control channel (PUSCH) can be transmitted in the UL data area.

[0080] Using this subframe (or time slot) structure has the advantage of reducing the time required for retransmission of data with reception errors, thereby minimizing the final data transmission latency. 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 time gaps. Therefore, in the subframe structure, some OFDM symbols during the transition from DL to UL can be set as a guard period (GP).

[0081] Figure 6 The structure of the self-contained time slot is shown.

[0082] In NR systems, frames are characterized by a self-contained structure, meaning that a single time slot can contain DL control channels, DL or UL data, and UL control channels. 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 greater than or equal to 0. The resource area located 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. For example, the following configuration can be considered. The intervals are listed in chronological order.

[0083] 1. DL configuration only 2. UL only 3. Hybrid UL-DL configuration - DL area + GP (Protection Interval) + UL Control Area - DL control area + GP + UL area DL regions: (i) DL data region, (ii) DL control region + DL data region UL Area: (i) UL Data Area, (ii) UL Data Area + UL Control Area 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. Downlink control information (DCI), such as DL data scheduling information and UL data scheduling information, can be transmitted in the PDCCH. Uplink control information (UCI), such as acknowledgment / negative acknowledgment (ACK / NACK) information for DL ​​data, channel state information (CSI) information, and scheduling requests (SR), can be transmitted in the PUCCH. GP provides time slots for base stations and terminals during transitions from transmit mode to receive mode or from receive mode to transmit mode. Certain symbols at the transition time from DL to UL within a subframe can be set to GP.

[0084] Figures 7a to 7b This illustrates an example of a connectivity topology for ambient Internet of Things (A-IoT / AIoT) networks and devices.

[0085] Ambient Internet of Things (AIoT / AIoT) devices are IoT devices powered by energy harvesting, lacking batteries or possessing only limited energy storage capabilities (e.g., using capacitors). For ease of explanation, AIoT devices will 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 waves, light, motion, heat, or other suitable power sources. Energy harvesting may be continuous (e.g., through vibration) or occur incidentally. 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., Narrowband Internet of Things (NB-IoT) / Enhanced Machine-Type Communication (eMTC) devices). AIoT devices can be designed to have a long lifespan of over 10 years without maintenance. In this way, they can replace existing 3GPP IoT devices or support various use cases (e.g., inventory, sensors, positioning, command) that are not supported by existing 3GPP IoT devices. Functions and processes supporting 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 goods (e.g., boxes, containers, packages, tools) within a specific area. When a request is sent from the network within the specific area, AIoT devices attached to these goods report identifiers associated with the goods, and additional information such as status, measurement results, and / or location can be added via the AIoT devices and / or AIoT Radio Access Network (RAN) / readers. Inventory services can discover / track AIoT devices within a certain range of a specific reader. Command services represent procedures that issue commands to AIoT devices within a specific area to execute instructions. These commands may include reading, writing, disabling, and / or enabling services as described below.

[0086] - Read: Requests information to be read from an AIoT device.

[0087] - Write: Requests information to be written to the AIoT device.

[0088] - Disable: Request to permanently or temporarily disable the radio frequency (RF) transmission capability of the AIoT device.

[0089] - Enable: Request to enable a temporarily disabled AIoT device.

[0090] 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 AIoT Radio Access Network (RAN). An AIoT RAN represents a functionally separated portion between the Radio Network (RAN) and the Core Network (CN), a node that performs AIoT-specific functions (e.g., RAN node functions: including functions such as control over AIoT radio resources directed towards A-IoT devices). An AIoT RAN can serve one or more AIoT readers. An AIoT reader is a reader that communicates with AIoT devices and terminates AIoT protocols. For ease of explanation, the node may be referred to hereinafter as an AIoT RAN (or AIoT reader). This is for illustrative purposes only and may be labeled with any other name such as AIoT RAN reader, AIoT base station, or AIoT BS reader.

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

[0092] exist Figure 7b In this topology, AIoT devices and the AIoT RAN communicate bidirectionally through intermediate nodes / auxiliary nodes / auxiliary terminals. In this topology, intermediate nodes / auxiliary nodes / auxiliary terminals can be relays, Integrated Access and Backhaul (IAB) devices, 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 for illustrative purposes only and can be labeled with any other name such as a UE connected / associated with an AIoT-enabled RAN, an AIoT-enabled RAN / reader, an AIoT reader, an AIoT UE reader, etc.

[0093] Figure 8 An example of the process used for A-IoT inventory services is shown.

[0094] Reference Figure 8 The following describes the process used for AIoT inventory services.

[0095] 1a. The A-IoT CN sends an inventory request message to the A-IoT RAN node.

[0096] 1b. A-IoT RAN nodes allocate and coordinate the use of A-IoT radio resources.

[0097] 2. The A-IoT RAN node sends an inventory response message to the A-IoT CN.

[0098] 3. The A-IoT RAN node performs an inventory process on A-IoT devices through the A-IoT wireless interface.

[0099] 4a / 4b. After receiving the inventory results from the A-IoT device, the A-IoT RAN node can send one or more inventory reports containing the received inventory results to the A-IoT CN.

[0100] Figure 9 This illustrates an example of the access layer (AS) process between an A-IoT device and a reader.

[0101] Reference Figure 9 The following describes the overall access layer (AS) process between environmental IoT (A-IoT) devices and readers.

[0102] Step A: A-IoT Paging (S901) Based on the service request, the reader sends an A-IoT paging message indicating which device needs to respond. Here, the A-IoT paging message can have the same meaning as the initial trigger message.

[0103] Step B: Device to Reader (D2R) (Device ID) Data Transmission (S902 to S903) A-IoT devices triggered by paging may perform an A-IoT random access procedure or send a device identifier (ID) to the reader without using this procedure. D2R data is then sent to the reader.

[0104] Step C1: Reader-to-Device (R2D) Data Transfer (S904) Perform possible R2D data transfers. (For example, to send commands) Step C2: D2R data transmission (S905) Perform possible D2R data transfers (e.g., responses to commands). 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, R2D / D2R data transmission and reception methods between AIoT devices and AIoT RAN / readers that take into account AIoT characteristics are not provided.

[0105] To address these issues, this specification discloses an AIoT data processing method and apparatus that supports security features.

[0106] The following describes in detail the data transmission and reception methods based on fifth-generation system (5GS) / NR technology. However, this is for illustrative purposes only, and the embodiments described in 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 explicitly defined 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 content explicitly defined in the standard specification may be included in the disclosure of this specification.

[0107] Any of the functions described below can be defined as individual terminal capabilities (UE radio capabilities or UE core network capabilities) and sent by the terminal to the base station / core network entity via corresponding signaling (e.g., Access and Mobility Management Function (AMF) / Session Management Function (SMF) / Ambient Internet of Things Network Function (AIoTNF)). Alternatively, any functions can be combined / integrated to define corresponding terminal capabilities and sent by the terminal to the base station / core network entity via corresponding signaling. Here, Ambient Internet of Things Function (AIoTF) 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 AIoT RAN / reader (or AIoT UE reader) to perform AIoT service operations with the AIoT device. AIoTF can collect the AIoT service operation results from the AIoT RAN node (or AIoT UE reader) and send them to the application function / application server.

[0108] Environmental IoT devices can be categorized and defined into at least one device type / category based on at least one capability (or a combination of at least one capability) they support. For example, based on energy storage capacity, they can be categorized as devices with no energy storage space, devices with energy storage capacity up to a certain value (up to E1 Journals), and devices with energy storage capacity up to another specific value (up to E2 Journals, E2>E1). Another example is a device without energy storage and unable to independently generate / amplify signals (e.g., backscatter transmission) (hereinafter referred to as Device A for ease of illustration), a device with energy storage but unable to independently generate signals (e.g., backscatter transmission) (hereinafter referred to as Device B for ease of illustration), where the use of stored energy in Device B may include amplification of reflected signals. A device with energy storage and capable of independently generating signals (e.g., active RF components for transmission) (hereinafter referred to as Device C for ease of illustration). Another example is a device with peak power consumption of approximately 1µW, energy storage, no amplification of DL and UL within the device, and whose uptransmission is backscattered on an externally provided carrier wave (hereinafter referred to as device 1 for ease of explanation); a device with peak power consumption ≤ several hundredµW, energy storage, amplification of both DL and UL within the device, and whose uptransmission is backscattered on an externally provided carrier wave (hereinafter referred to as device 2a for ease of explanation); and a device with peak power consumption ≤ several hundredµW, energy storage, amplification of both DL and UL within the device, and whose uptransmission is generated internally (hereinafter referred to as device 2b for ease of explanation).

[0109] 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, it 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.

[0110] The AIoT RAN / reader / base station / UE-reader or AIoTF can send / instruct / configure information / messages to the AIoT device for disabling / deactivating / restricting / controlling any function or any combination of functions described below. For example, a timer for disabling / pausing / deactivating the function can be instructed. The timer can be started / restarted simultaneously with, before, or after the function is started. During the timer's operation, the device can be disabled / deactivated / restricted / controlled, preventing it from starting / performing the function.

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

[0112] 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 / standard deviation values. This is for illustrative purposes only, and all information in this specification can be used as statistical information. Any information described below may be pre-configured in the device / network or provisioned information provided through Operation, Administration and Maintenance (OAM) / Application Server / Application Function / AIoT / Unified Data Management (UDM) / AIoT Data Management (ADM).

[0113] Hereinafter, the physical channel used for reader-to-device (R2D) data transmission will be labeled PRDCH, the physical channel used for device-to-reader (D2R) data transmission will be labeled PDRCH, and the interface / link between the reader and the device will be labeled RD interface / link (e.g., AIoT wireless interface). This is for illustrative purposes only and can be replaced by any other name. The 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, the start of R2D data reception, the end of R2D data reception, or the specific reference time of the serving base station / cell servicing 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.

[0114] Security handling of AIoT devices To reduce the complexity of AIoT devices, it is best to minimize their security features. However, to enable mobile network-based AIoT to support differentiated functionalities compared to Radio Frequency Identification (RFID), it is advisable to provide one of the core functions of mobile networks: partial security features. For example, it can be configured to not support access stratum (AS) security between the AIoT device and the AIoT RAN, but provide security at the non-access stratum (NAS) between the AIoT device and the AIoTF, depending on operator policy. Alternatively, registration and authentication can be supported during the AIoT device's commissioning or initial network access, after which, based on instructions from the AIoTF during this registration / authentication process, received security parameters can be selectively used to support encryption / privacy protection and / or integrity protection functions, or data can be transmitted and received without security processing.

[0115] To support a variety of security use cases, it is best to allow operators to selectively apply security features. For example, by making security features selectively configurable / applied / enabled / disabled, factors such as device type or deployment can be considered, allowing operators to choose / request / instruct / configure to support security features.

[0116] For example, it can support configuring / applying / enabling / disabling NAS security (and / or AS security) in AIoT devices. For instance, the core network can configure / set / change / apply parameters for NAS layer security processing to AIoT devices through AIoT service request procedures (e.g., inventory procedures or command procedures). The core network can enable / disable / activate / deactivate NAS layer security processing functions for AIoT devices through AIoT service request procedures (e.g., inventory procedures or command procedures).

[0117] When an AIoT device's identifier is authenticated in the core network (e.g., within the AIoTF or through authentication between the AIoTF and an authentication server), or when the AIoT device's subscription information exists in the core network (e.g., AIoT Device Management, ADM), the AIoTF can perform NAS security parameter configuration / change / application and / or NAS security function enabling / disabling / activation / deactivation for the AIoT device. For example, when the AIoT device's subscription information exists in the core network node / NF (e.g., ADM) that provides subscription information management functions, the AIoTF can receive at least one of the security parameters for authentication / security processing of the AIoT device and the AIoT device identifier for security processing / protection from the core network node / NF, and apply security functions at the NAS layer between the AIoT device and the AIoTF to perform the AIoT service process.

[0118] Alternatively, (through pre-configuration or appropriate parameter configuration / setting / change / application), when the AIoT device's identifier is authenticated in the core network (e.g., within the AIoTF or via authentication between the AIoT and the authentication server), or when the AIoT device's subscription information exists in the core network (e.g., AIoT Device Management, ADM), AIoT services can be provided to the AIoT device without NAS security (and / or AS security) processing. For example, an operator can use an unsecured plaintext AIoT device identifier (e.g., a permanent AIoT device identifier) ​​to perform AIoT service procedures at the NAS layer between the AIoT device and the AIoTF.

[0119] Another example is that when an application function / application server requests an AIoT service from the AIoTF (e.g., an inventory process or a command process), it may include an indication of whether to perform security processing / request. Upon receiving this information, the AIoTF can initiate / execute the AIoT service process by applying security protection / processing / deactivation / verification functions to the AIoT device identification information and / or NAS messages at the NAS layer. For example, the AIoTF may send an AIoT service request message (e.g., an inventory request message or a command request message) containing a securely processed / protected AIoT device identifier and / or a securely processed / protected NAS message to the AIoT RAN / reader. The AIoT service request message may include and send at least one of the following: the presence or absence of a secure / privacy-protected temporary identifier processing type / method (or whether a secure / privacy-protected temporary identifier is used), the secure / privacy-protected temporary identifier processing type / method, whether security processing is activated, a secure command request, AIoT device authentication, and random parameters (e.g., network-generated RAND) for securely processing / protecting the AIoT device identification information. This information can be included by AIoTF in an NGAP message or an AIoT NAS message and sent to the AIoT RAN / reader or AIoT device.

[0120] Another example is that the R2D MAC PDU (or MAC message / PDU containing one (or more) upper-layer data (MAC SDU) or the corresponding MAC message / PDU header / subheader) between the AIoT device and the AIoT RAN / reader may contain information / fields indicating whether upper-layer / NAS security is configured / applied / enabled / disabled (or, the MAC header / subheader contained in the MAC layer between the AIoT device and the AIoT RAN / reader may contain information / fields indicating whether upper-layer / NAS security is configured / applied / enabled / disabled / activated / deactivated). When the AIoT device receives this information, it can transmit the corresponding upper-layer data to the upper layer (NAS) for processing security functions at the upper layer.

[0121] For example, a MAC PDU (or paging MAC PDU or corresponding MAC header) used for AIoT paging or a MAC PDU containing R2D data may include information / fields indicating whether upper-layer / NAS security configuration / application / enabling / disabling is enabled or disabled. This information may include at least one of the following: information indicating whether security processing / request is performed; security parameters; an AIoT device identifier for security processing / protection; information indicating whether security processing / protection is requested; and random parameters (e.g., network-generated RAND) for AIoT device authentication and security processing / protection of AIoT device identification information. When the AIoT device receives this information, the MAC layer may indicate this information to the uplink layer (e.g., AIoTNAS, AIoT data / application).

[0122] Another example is that the AIoTF can instruct AIoT devices on the configuration / configuration parameters of arbitrary security functions via NAS signaling. For instance, command services (e.g., WRITE, Enable, or Disable) can be used to instruct security configuration information. This configuration may include information indicating whether any security function is enabled / disabled / activated / deactivated. For example, the AIoTF can generate an AIoT NAS command request and perform security processing / protection on that command request message. The AIoT service request message (e.g., inventory request message or command request message) sent by the AIoTF to the RAN / reader may contain at least one of the information regarding whether security processing and security protection are activated in the command request. This information may be included within the corresponding NGAP (Next Generation Application Protocol) message or AIoT NAS message. When this configuration is received, the AIoT device can apply it. The AIoT device can use the corresponding security function / parameter to perform AIoT service operations. For example, security verification (e.g., integrity verification) and decryption can be performed on the corresponding command request for security processing / protection. The AIoT device can generate a NAS command response and perform security processing / protection on that command response message. Another example is that when an AIoT device is instructed to disable / deactivate the AIoT device and / or its security features, if it receives parameters (e.g., on-duration / off-duration, period, and / or offset) for monitoring / receiving an enable / activation indication for the AIoT device and / or its security features, the AIoT device can store these parameters in device parameters within non-volatile memory. The AIoT device can then use these parameters to monitor the enable / activation indication.

[0123] Another example is that security processing / authentication functions / parameters can be pre-configured in AIoT devices and / or AIoTFs. AIoT service processes can be provided based on these pre-configured security processing / authentication functions / parameters. For example, AIoT devices and / or AIoTFs / core network nodes can be pre-configured with specific / arbitrary security parameters (e.g., security keys, security algorithms) for secure processing / authentication of AIoT identification information and / or NAS messages. The AIoT device can perform security processing / authentication using specific security parameters received from the AIoT / RAN / reader and another security parameter (security key) pre-configured in the AIoT device. Security verification (e.g., integrity verification) and decryption can be performed on the corresponding command request for received security processing / protection. Security processing / protection (integrity protection, encryption) can be performed on the generated NAS command response. D2R MAC messages sent by the AIoT device to the AIoT RAN / reader can contain securely processed / protected NAS messages.

[0124] Another example is that when no specific security function is supported between the AIoTF and the AIoT device (or between the AIoT RAN / Reader and the AIoT device), or when any specific security function between the AIoTF and the AIoT device (or between the AIoT RAN / Reader and the AIoT device) is set / configured / indicated to be disabled / deactivated, data can be sent and received without performing the corresponding security function processing. For example, if encryption is disabled / deactivated, the following can be done. For ease of explanation, the privacy protection / encryption of AIoT device identification information in the security functions will be described below. However, the processing methods for other arbitrary security functions (e.g., authentication, authorization, encryption / integrity protection of command messages between the AIoTF and the AIoT device) are also obviously included within the scope of this specification.

[0125] AIoTF can determine the AIoT device identification information contained in the paging message on the AIoT radio interface based on information received from the application function. If no security / privacy protection is implemented for the AIoT device identification information, the AIoT device identification information contained in the AIoT service request message (e.g., inventory request message or command request message) sent by AIoTF to the AIoT RAN / Reader can be sent without appropriate security / encryption protection / processing. Plaintext AIoT device permanent identification information can be sent. Similarly, the AIoT device identification information contained in the AIoT paging message sent by the AIoT RAN / Reader to the AIoT device can be sent without appropriate security / encryption protection / processing. Plaintext AIoT device permanent identification information can be sent. In response to this paging, the AIoT device identification information contained in the D2R message (e.g., message 1, message 3, D2R data transmission, or D2R data transmission containing NAS messages / containers) sent by the AIoT device to the AIoT RAN / Reader can be sent without appropriate security / encryption protection / processing. Plaintext AIoT device permanent identification information can be sent. The AIoT device identification information contained in AIoT service response / report messages (e.g., inventory report messages or command response messages) sent by the AIoT RAN / reader to the AIoTF can be sent without appropriate security / encryption protection / processing. Permanent AIoT device identification information in plaintext can also be sent.

[0126] Another example is that when any / specific security function is supported between the AIoTF and the AIoT device (or between the AIoT RAN / Reader and the AIoT device), or when any / specific security function between the AIoTF and the AIoT device (or between the AIoT RAN / Reader and the AIoT device) is set / configured / indicated to be enabled / activated (or when an inventory request message or command request message indicates whether a specific security function is activated), data can be sent and received by protecting / processing / de-authenticating the corresponding security function. For example, if the security / encryption protection / processing / de-authentication of the AIoT device identifier is enabled / activated, the following can be done.

[0127] AIoTF can determine the AIoT device identification information contained in the paging message on the AIoT radio interface based on information received from the application function. The AIoT device identification information contained in the AIoT service request message (e.g., inventory request message or command request message) sent by AIoTF to the AIoT RAN / reader can be sent as securely protected / encrypted AIoT device identification information. For example, it can include a temporary AIoT device identifier generated / derived through secure protection / processing. And / or the AIoT device identification information contained in the AIoT service request message (e.g., inventory request message or command request message) sent by AIoTF to the AIoT RAN / reader can be sent as plaintext AIoT device identification information. And / or the AIoT service request message (e.g., inventory request message or command request message) sent by AIoTF to the AIoT RAN / reader can send any security parameters required for secure / encrypted protection / processing and / or secure / encrypted decryption / authentication in the AIoT device, AIoT RAN / reader. For example, it may include and send security parameters (e.g., random parameters / numbers (RAND_Network) generated in the core network node (AIoT Data Management, ADM)) for generating / processing a temporary AIoT device identifier for security protection. And / or it may include at least one of the following: a security key for decrypting / verifying encrypted AIoT device identification information in the AIoT device, a freshness value (changed to prevent tracking), and a counter. And / or it may include at least one of the following: a security key used by the AIoT device for secure / encrypted protection / processing of AIoT device identification information, a freshness value (changed to prevent tracking), a counter, and a random parameter / number. And / or it may include at least one of the following: a security key used by the AIoT RAN / reader for secure / encrypted protection / decryption / verification of encrypted AIoT device identification information sent by the AIoT device, a freshness value (changed to prevent tracking), a counter, and a random parameter / number.

[0128] The AIoT device identification information included in the AIoT paging message sent by the AIoT RAN / Reader to the AIoT device can be sent as secure / encrypted AIoT device identification information. And / or the AIoT device identification information included in the AIoT paging message sent by the AIoT RAN / Reader to the AIoT device can be sent as plaintext AIoT device identification information. And / or the AIoT paging message (or any subsequent R2D message, e.g., AIoT message 2, R2D data transmission, or R2D data transmission containing NAS messages / containers) sent by the AIoT RAN / Reader to the AIoT device can send any security parameters required for security / encryption protection / processing and / or security / encryption decryption / verification within the AIoT device. For example, security parameters (e.g., security key, freshness value, counter, random parameter / number, and / or temporary AIoT device identifier for security protection, decryption, or verification) used to generate secure / encrypted AIoT device identification information for security / encryption protection / decryption / verification can be included and sent within the AIoT device. The AIoT device identification information and security parameters can be contained in the NAS message / container within the AIoT paging message or in the MAC header within the AIoT paging MAC PDU. For example, the secure / encrypted AIoT device identification information and security parameters can be provided through a NAS field within the NAS message / container within the AIoT paging message. This information can be processed at the AIoT NAS layer (distinguished by the corresponding header or field). Alternatively, the secure / encrypted AIoT device identification information and security parameters can be provided through different fields within the NAS message / container within the AIoT paging message. Alternatively, the secure / encrypted AIoT device identification information and security parameters can be provided through different fields within the MAC header within the AIoT paging MAC PDU. Alternatively, the secure / encrypted AIoT device identification information is contained within the NAS message / container, while the security parameters are contained within the MAC header within the AIoT paging MAC PDU. When the AIoT paging MAC PDU is received, the AIoT device can transmit the secure / encrypted AIoT device identification information and security parameters to the upper layer.

[0129] AIoT devices can perform security / encryption protection / decryption / verification on received secure / encrypted AIoT device identification information. In this way, they can check whether the secure / encrypted / decrypted / verified AIoT device identification information matches the AIoT device identification information received via an AIoT paging message. For example, the AIoT device can use security parameters received via a paging message to generate secure / encrypted AIoT device identification information. When the secure / encrypted AIoT device identification information generated by the AIoT device matches the secure / encrypted AIoT device identification information received via a paging message, the AIoT device considers the AIoT device selected. And / or the AIoT device can check whether the received plaintext AIoT device identification information matches the AIoT device identification information. For example, if it contains an unsecured AIoT device identifier for a single device or group identifier, the match of the AIoT device identification information can be checked using the unsecured AIoT device identifier. And / or the AIoT device can perform security / encryption protection / processing on the AIoT device identification information. For example, an AIoT device can use security parameters received via a paging message to generate secure / encrypted AIoT device identification information. In response to this paging, the AIoT device identification information contained in a D2R message (e.g., MSG1, MSG3, or D2R data transmission) sent by the AIoT device to the AIoT RAN / reader can be secure / encrypted AIoT device identification information. This / subsequent / arbitrary D2R message (e.g., MSG1, MSG3, or D2R data transmission) sent by the AIoT device to the AIoT RAN / reader can send any security parameters required for security / encryption protection / decryption / authentication. For example, at least one of the following information may be included in the AIoT RAN / reader / AIoTF for securing / encrypting / decrypting / verifying encrypted AIoT device identification information, a freshness value (changed to prevent tracking), a counter, a verification value / result value / response value (RES: Result / XRES: ExpectedResult) generated / derived in the AIoT device, and a random parameter / number (RAND_Device) generated / derived in the AIoT device.

[0130] The AIoT device identification information and security parameters can be included in a NAS message / container within a D2R message (e.g., MSG1, MSG3, or D2R data transmission) sent by the AIoT device to the AIoT RAN / reader in response to an AIoT paging, or in the MAC header within a MAC PDU of a D2R message (e.g., MSG1, MSG3, or D2R data transmission) sent by the AIoT device to the AIoT RAN / reader in response to an AIoT paging. For example, secure / encrypted AIoT device identification information and security parameters can be provided as a field within a NAS message / container sent by the AIoT device to the AIoT RAN / reader in response to an AIoT paging. This information can be processed at the AIoT NAS layer (distinguished by the corresponding header or field). Alternatively, the secure / encrypted AIoT device identification information and the security parameter can be provided through different fields within the NAS message / container included in the D2R message (e.g., MSG1, MSG3, or D2R data transmission) sent by the AIoT device to the AIoT RAN / Reader in response to an AIoT paging. Alternatively, the secure / encrypted AIoT device identification information and the security parameter can be provided through different fields within the MAC header of the D2R message (e.g., MSG1, MSG3, or D2R data transmission) MAC PDU sent by the AIoT device to the AIoT RAN / Reader in response to an AIoT paging. When the AIoT RAN / Reader receives the AIoT paging MAC PDU, the AIoT device can perform security protection / deactivation / authentication using the secure / encrypted AIoT device identification information and the security parameter. The AIoT RAN / Reader can transmit at least one of the plaintext AIoT device identification information, the secure / encrypted AIoT device identification information, and the security parameter to the AIoTF. Alternatively, only the secure / encrypted AIoT device identification information or only that security parameter can be included in the NAS message / container. Alternatively, the secure / encrypted AIoT device identification information can be included in the NAS message / container, while the security parameter is included in the MAC header of the D2R message (e.g., MSG1, MSG3, or D2R data transmission) MAC PDU sent by the AIoT device to the AIoT RAN / reader in response to an AIoT paging. When the AIoT RAN / reader receives this AIoT paging MAC PDU, it can transmit at least one of the encrypted AIoT device identification information and that security parameter (via an NGAP message) to the AIoTF.

[0131] The AIoT device identification information contained in the AIoT service response / report message (e.g., inventory report message or command response message) sent by the AIoT RAN / reader to the AIoTF can be the plaintext AIoT device identification information of that message. And / or the AIoT device identification information contained in the AIoT service response / report message (e.g., inventory report message or command response message) sent by the AIoT RAN / reader to the AIoTF can be the securely protected / encrypted AIoT device identification information of that message. The AIoT service response / report message (e.g., inventory report message or command response message) sent by the AIoT RAN / reader to the AIoTF can contain at least one of the following information in the AIoTF: a security key used for encrypting / decrypting / verifying the securely protected / encrypted AIoT device identification information, a freshness value (altered to prevent tracking), a counter, a verification value / result value / response value (RES: Result / XRES: Expected Result) generated / derived in the AIoT device, and a random parameter / number (RAND_Device) generated / derived in the AIoT device.

[0132] Another example is that paging messages can contain secure processing parameters for AIoT devices. The location of this information needs to be determined. For example, authentication of an AIoT device can be performed when authentication is triggered by the network through an inventory process and a command process. For instance, the AIoTF can receive a random number (e.g., a 128-bit RAND) generated for the AIoT device in the corresponding core network node (e.g., AIoT Data Management, ADM) and send it to the RAN / reader via an inventory request. The RAN / reader can include this random number in the paging message. Another example is that, to protect AIoT device identification information, a secure / privacy-protected temporary identifier can be used during the inventory process. The secure / privacy-protected temporary identifier can be generated based on a key (e.g., K_AIoT) shared between the AIoT device and the corresponding core network node (e.g., ADM). When using a secure / privacy-protected temporary identifier, the AIoTF can send information indicating the processing type / method of the (secure / privacy-protected) temporary identifier to the RAN / reader via an inventory request message. Information indicating the processing type / method of temporary identifiers (e.g., information indicating the secure processing type of AIoT device identification information) may indicate whether the secure / privacy-protected temporary identifier is of a protected / hidden type or a stored type. And / or information indicating the processing type / method of temporary identifiers may indicate whether the temporary identifier is of a stored temporary identifier protected / hidden type, a permanent identifier protected / hidden type, or a stored type. And / or information indicating the processing type / method of temporary identifiers may include information indicating whether the stored temporary identifier should be updated (whether the stored T-ID type shall be updated with or without a command). Paging messages may contain secure / privacy-protected temporary identifiers and information indicating the processing type of secure / privacy-protected temporary identifiers.

[0133] For ultra-low complexity AIoT devices, it is best to minimize the number of bits included in the paging message. The number of bits required for security parameters needs to be defined efficiently. In one embodiment, by making authentication mandatory for all inventory processes, the field indicating the presence (or authentication status) of security parameters required for authentication (e.g., a random number (e.g., a 128-bit RAND)) can be omitted from the R2D paging message. The paging message can always include security parameters for authentication (e.g., a random number (e.g., a 128-bit RAND)).

[0134] In another embodiment, authentication of AIoT devices can be performed selectively triggered by the network. The paging message may include a field (e.g., 1 bit) indicating whether a security parameter required for authentication (e.g., a random number (e.g., a 128-bit RAND)) is present (or whether authentication is required). If the security parameter for authentication is present, the field may be set to a specific value (e.g., 1 for present, 0 for absent, or 0 for present, 1 for absent), and the security parameter information for authentication may be included in subsequent fields.

[0135] Another example is that the protection / security processing of AIoT device identification information can be selectively performed. The paging message may contain a field (e.g., 1 bit) indicating the presence or absence of a security / privacy-protected temporary identifier processing type / method (or whether a security / privacy-protected temporary identifier is used). If protection / security processing is applied / performed on the AIoT device identifier (or if security / privacy-protected temporary identifier processing type / method information exists), this field can be set to a specific value (e.g., 1 for presence, 0 for absence, or 0 for presence, 1 for absence), and the security / privacy-protected temporary identifier processing type / method can be included in subsequent fields. The security / privacy-protected temporary identifier processing type / method can be indicated by 2 bits whether the temporary identifier is protected / hidden by a stored temporary identifier (e.g., generating a temporary identifier using a stored temporary identifier as P0 input), protected / hidden by a permanent identifier (e.g., generating a temporary identifier using an AIoT permanent identifier as P0 input), or stored. The type / method for handling temporary identifiers with and / or with security / privacy protection may include an additional 1 bit to indicate whether the stored temporary identifier should be updated with or without a command.

[0136] Another example is that security parameters in the paging message used for authentication (or AIoT identifier security / privacy protection) (e.g., fields indicating the presence or absence of a random number (or whether authentication is performed), security parameters used for authentication (or AIoT identifier security / privacy protection), fields indicating the presence or absence of a security / privacy protection temporary identifier processing type / method (or whether a security / privacy protection temporary identifier is used), and / or a security / privacy protection temporary identifier processing type / method field) are used to match AIoT device identification information in the NAS layer, which determines whether to respond based on the AIoT device identification information, or, when deciding to respond, derive another security parameter (e.g., result value / response value / verification value (RES) or expected result value / expected response value / expected verification value (XRES)) as a response to this. Therefore, since the matching of AIoT device identification information needs to be processed first, the system may include AIoT device identification information (Paging ID) and / or information indicating the presence or absence of the Paging ID length, Paging ID length (8 bits), a field following the AIoT device identification information (Paging ID) indicating the presence or absence of a security / privacy-protected temporary identifier processing type / method (or whether a security / privacy-protected temporary identifier is used), and a security / privacy-protected temporary identifier processing type / method field. Alternatively, this field may be included in the following order: AIoT device identification information (Paging ID) and / or information indicating the presence or absence of the Paging ID length, Paging ID length (8 bits), a field indicating the presence or absence of a security / privacy-protected temporary identifier processing type / method (or whether a security / privacy-protected temporary identifier is used), a security / privacy-protected temporary identifier processing type / method field, and the AIoT device identification information (Paging ID).

[0137] Another example is that, since security processing for authentication can be performed after determining whether the AIoT device identification information matches, it needs to be processed first. Therefore, the field can be included in the following order: AIoT device identification information (paging ID) and / or information indicating whether the paging ID length exists, paging ID length (8 bits), AIoT device identification information (paging ID), field indicating whether the security / privacy protection temporary identifier processing type / method exists (or whether a security / privacy protection temporary identifier is used), security / privacy protection temporary identifier processing type / method field, security parameters for authentication (e.g., field indicating whether a random number exists (or whether authentication is performed)), and security parameters for authentication. Alternatively, the field may be included in the following order: AIoT device identification information (Paging ID) and / or information indicating the presence or absence of the Paging ID length, Paging ID length (8 bits), field indicating the presence or absence of a security / privacy-protected temporary identifier processing type / method (or whether a security / privacy-protected temporary identifier is used), security / privacy-protected temporary identifier processing type / method field, AIoT device identification information (Paging ID), security parameters for authentication (e.g., a field indicating the presence or absence of a random number (or whether authentication is performed)), and security parameters for authentication.

[0138] Another example is that the paging message used when indicating contention-free access (CFA) to an AIoT device may include the following fields in the order of Paging ID length, AIoT device identification information (Paging ID), field indicating the presence or absence of a security / privacy-protected temporary identifier processing type / method (or whether a security / privacy-protected temporary identifier is used), security / privacy-protected temporary identifier processing type / method, security parameters for authentication (e.g., field indicating the presence or absence of a random number (or whether authentication is performed)), and security parameter field for authentication. Alternatively, the field may be included in the following order: Paging ID length, field indicating the presence or absence of a security / privacy-protected temporary identifier processing type / method (or whether a security / privacy-protected temporary identifier is used), security / privacy-protected temporary identifier processing type / method field, AIoT device identification information (Paging ID), security parameters for authentication (e.g., field indicating the presence or absence of a random number (or whether authentication is performed)), and security parameters for authentication.

[0139] The following describes another embodiment of this specification.

[0140] One example is that the MAC header (or MAC subheader if MAC multiplexing is supported) included in the MAC PDU of the access layer (AS) AIoT service procedure between the AIoT device and the AIoT RAN / reader may not include an explicit AIoT device identification information field containing AIoT device identification information.

[0141] If the MAC header / subheader does not contain AIoT device identification information, the AIoT device's MAC layer / entity cannot (via the corresponding MAC PDU header) check whether the AIoT MAC PDU requires a response from the AIoT device. For example, it cannot (via the corresponding MAC PDU header) check whether the corresponding AIoT device identification information matches. If the MAC header / subheader does not contain AIoT device identification information, the AIoT device's MAC layer / entity cannot (via the corresponding MAC PDU header) decide whether to transmit the corresponding MAC SDU to the upper layer.

[0142] An AIoT device (or MAC layer / entity) can determine the MAC PDU to be transmitted to the upper layer based on specific / arbitrary MAC header / subheader information / fields other than AIoT device identification information, and transmit the corresponding MAC SDU (or NAS message or AIoT service request data for AIoT service requests) to the upper layer (AIoT NAS layer or AIoT data / application layer). Alternatively, the AIoT device (or MAC layer / entity) can transmit a MAC SDU (or such information) containing information from a paging message / MAC-PDU / MAC-SDU (or a paging message or NAS message / container containing NAS messages / containers) to the upper layer. For example, at least one of the following information can be transmitted to the upper layer: AIoT device identification information, security parameters, and any information / fields / parameters contained in the MAC header.

[0143] NAS messages / containers may contain at least one of the following: AIoT device identification information and security parameters. MAC PDUs may contain at least one of the following: a field indicating whether a NAS message / container is included, a NAS message / container field, a field indicating whether a paging message is included, a paging message / container field, a field indicating whether security processing is performed, and security parameters. If at least one of these information / fields is included / set in the MAC header / subheader (or according to pre-configured baselines / rules / configurations), the corresponding MAC SDU (and / or any / specific information (e.g., AIoT service type) contained in the MAC PDU / header / subheader) can be transmitted to the upper layer.

[0144] If the AIoT device identification information (or the AIoT device identification information that has been securely processed) within the MAC SDU (or NAS message / container) received by the AIoT device (or NAS layer / entity) matches (or is the same as) the AIoT device identification information of the AIoT device, then at least one of the following operations can be performed (or, if the AIoT device (or NAS layer / entity) receives a NAS message / container (or AIoT device identification information, security parameters), then at least one of the following operations can be performed). The order of the following operations is for illustrative purposes only and can be performed in any order different from the following order.

[0145] The security decryption / verification / processing of the AIoT device identification information can be performed using the AIoT device identification information and / or security parameters and / or NAS messages / payload information within the container and / or any field information contained in the NAS messages.

[0146] If the AIoT device identification information after security clearance matches (or is the same as) the AIoT device identification information of the AIoT device, then this information can be indicated to the lower layer (MAC) / upper layer (AIoT data / application layer).

[0147] The payload information within the NAS message / container (and / or any field information contained within the NAS message and / or any field information contained within the NAS message / container, as well as the information after it has been securely decrypted) can be indicated to the upper layer (AIoT data / application layer).

[0148] At least one of the following information can be stored as a device variable: information received from the MAC layer and / or payload information within the NAS message / container (and / or any field information contained in the NAS message and / or any field information contained in the NAS message / container (or information after being securely decrypted)).

[0149] It can generate / build a NAS response message for the NAS request message.

[0150] It can generate / build NAS response messages for the AIoT service request.

[0151] The processing result indication information can be sent from the AIoT device (or NAS layer / entity) to the lower layer (MAC layer). For example, this can be indicated to initiate an AIoT random access procedure. Alternatively, it can be used to initiate an AIoT random access procedure.

[0152] The payload information (and / or any field information contained in the NAS message / container) can be directed to the lower layer (MAC data / application layer).

[0153] You can receive a response message for the service request from the (AIoT data / application layer).

[0154] Based on the instructions / requests of the lower layer, a response message for the request can be sent to the lower layer.

[0155] If the information used to identify the AIoT device in the MAC SDU (or NAS message / container) received by the AIoT device (or NAS layer / entity) does not match the information used by the AIoT device to identify itself, the MAC-SDU / NAS message / container can be discarded / abandoned / deleted / removed. The AIoT device (or NAS layer / entity) can instruct the lower layer whether the AIoT device identification information matches and / or whether to discard / abandon / delete / remove the MAC-SDU / NAS message / container.

[0156] To verify whether the information used to identify the AIoT device within the MAC SDU (or NAS message / container) received by the AIoT device (or NAS layer / entity) matches the information used to identify the AIoT device, security decryption (e.g., decryption, integrity verification, message authentication code verification, hash function) can be performed on the NAS message / container (or specific fields contained within the NAS message / container, or AIoT device identification information contained within the NAS message / container). For this purpose, security parameters contained within the NAS message / container can be utilized.

[0157] Matching AIoT device identification information is as follows: If an AIoT paging message contains an identifier for a single AIoT device, then the AIoT device is considered a match if the AIoT device identifier contained in the AIoT paging message is the same as the single AIoT device identifier configured / stored / computed / generated / derived / determined in that AIoT device. And / or, the AIoT device is considered a match if the AIoT device identifier contained in the AIoT paging message is the same as the group AIoT identifier mapped to that AIoT device. And / or, if the paging MAC PDU or downlink MAC PDU or the corresponding MAC header contains information / fields indicating that all devices within the coverage area of ​​the AIoT RAN / reader are being paged / received, and these fields are set; or if the AIoT paging message does not contain an AIoT device identification information field, or the AIoT device identification information field is set to a specific value (e.g., all 1s or all 0s), then all AIoT devices receiving the AIoT paging message are considered to need to respond, thus constituting a match.

[0158] To support ultra-low complexity, AIoT devices should be implemented with the lowest possible specifications. The memory included in an AIoT device can be of two types. First, non-volatile memory can be supported for storing permanent information. Next, a register can be supported for temporarily storing information required by the AIoT device to perform any service / operation while energy is available in the energy storage (e.g., a capacitor). The non-volatile memory can store / configure one or more of the AIoT device's device ID, pre-configured radio resource configuration parameters, and pre-configured default parameters. The register (or volatile memory or temporary memory used by the device when the AIoT device is available) can store / configure at least one of the temporary radio resource configuration parameters, device variables, state variables, counters, and timers required by the AIoT device to perform specific AIoT service operations.

[0159] For example, when an AIoT device is available (e.g., data transmission and reception are available / possible, actions for any / specific AIoT service / operation are available / possible, energy stored / collected / charged in the AIoT device exceeds a certain level), at least one of the following can be instructed / set / applied / changed / configured / stored / started / executed / stopped / expired / added / initialized / maintained pre-configured radio resource configuration parameters, temporary radio resource configuration parameters, device variables, status variables, counters, and timers. For example, the AIoT device can receive radio resource configuration / setting information / configuration files via NAS messages / containers from the AIoTF to set / apply / change / configure / store the radio resource configuration parameters. Alternatively, when the AIoT device receives a specific MAC PDU from the AIoT RAN / reader, it can store / update / initialize / add / start / stop the relevant device variables / status variables / counters / timers.

[0160] Another example is that when an AIoT device becomes unavailable / deactivated / disabled (e.g., data transmission is unavailable / impossible / deactivated, actions for any / specific AIoT service / operation are unavailable / impossible / deactivated, or the energy stored / collected / charged in the AIoT device is below a certain level), at least one of the aforementioned temporary wireless resource configuration parameters, device variables, state variables, counters, and timers can be initialized / released / deleted / removed / disappeared / discarded / converted to default values.

[0161] Another example is that when an AIoT device receives an R2D message / data, based on at least one of the following information in the header of the R2D message / data MAC PDU (or the MAC PDU / CE containing the R2D message / data) and the header of the NAS message / container contained in the R2D message MAC PDU (or any / specific field / information contained in the NAS message / container), at the MAC layer / entity and / or the NAS layer / entity, at least one of the following can be indicated / set / applied / changed / configured / stored / started / executed / stopped / expired / added / initialized pre-configured radio resource configuration parameters, temporary radio resource configuration parameters, device variables, status variables, counters, and timers.

[0162] One of the representative use cases of AIoT is that the inventory process can be based on... Figure 9 Steps A and B are provided. The AIoT device can perform D2R data transmission after receiving the AIoT paging message in step A, after receiving the AIoT MSG2 in step B, or after the AIoT random access procedure in step B.

[0163] The command process can be provided based on steps A, B, C1, and C2. The AIoT device can perform D2R data transmission after receiving the AIoT paging message in step A, after receiving the AIoT MSG2 in step B, or after the AIoT random access process in step B, and after the R2D data transmission in step C1.

[0164] In this D2R data transmission, the AIoT device can send D2R messages / data based on the scheduling information contained in the (most recent / previous) R2D messages received from the reader (e.g., access timing, frequency band / subband / resource / resource set, transport block size, modulation, coding, etc.) and / or based on the scheduling information determined in the MAC layer of the AIoT device.

[0165] This D2R data can be provided together with the AIoT MSG1.

[0166] In one embodiment, the AIoT MSG1 MAC PDU may contain D2R data (MAC SDU). The AIoT MSG1 MAC PDU may include a corresponding MAC header and a MAC SDU.

[0167] Another example is that the AIoT MSG1 and the D2R data can be sent separately via their respective MAC sub-PDUs. A corresponding MAC PDU may include an AIoT MSG1 MAC sub-PDU and a D2R data MAC sub-PDU. The AIoT MSG1 MAC sub-PDU may include a corresponding MAC sub-header and a MAC MSG1 CE. Alternatively, the AIoT MSG1 MAC sub-PDU may consist only of a corresponding MAC sub-header.

[0168] If no upper-layer data is to be sent when transmitting AIoT MSG1, the AIoT MSG1 MAC PDU may consist of a corresponding MAC header and a MAC MSG1 CE. Alternatively, the AIoT MSG1 MAC PDU may consist of only a corresponding MAC header.

[0169] On the D2R link (or R2D link) between the AIoT device and the AIoT RAN / reader, the MAC layer / entity can support segmentation. When triggered / indicated by an AIoT service request (and / or by the AIoT RAN / reader), and the size of a single MAC PDU containing D2R data to be transmitted by the AIoT device is greater than the size of the scheduling resources / transmission blocks received / determined by the AIoT device, the AIoT device can support segmentation at the MAC layer / entity.

[0170] One example is that when the size of a single MAC SDU containing upper-layer data, plus the MAC header, is greater than the size of the received / determined scheduling resource / transport block in the AIoT device, the data / bit stream / byte / bit (or a portion of the upper-layer data) that fits the size of the received / determined scheduling resource / transport block (e.g., the upper-layer data portion included in the segment plus the MAC header is equal to (or less than or equal to) the size of the scheduling resource / transport block) before the data / bit stream / byte / bit (or a portion of the upper-layer data) is contained in a segment. This segment may include a corresponding MAC header and a single MAC PDU consisting of a MAC SDU composed of / provided by the upper-layer data portion.

[0171] Another example is when the size of one or more MAC SDUs containing one or more upper-layer data (e.g., one or more AIoTNAS messages, one or more AIoT data) plus their respective MAC subheadings is greater than the size of the received / determined scheduling resource / transmission block in the AIoT device, the cumulative value of the respective upper-layer data plus their respective MAC subheadings can be fitted to the received / determined scheduling resource / transmission block size (e.g., the last upper-layer data portion whose respective upper-layer data plus their respective MAC subheadings are equal to (or less than or equal to) the scheduling resource / transmission block size) before the data / bit stream / byte / bit (or all / part of the MAC subheading and the upper-layer data, e.g., if it consists of two upper-layer data, and only the entire first upper-layer data and a portion of the second upper-layer data can be sent) contained in a segment. This segment can be composed of a single MAC PDU consisting of one or more corresponding MAC subheadings and a MAC SDU composed of / provided the entire / part of the corresponding one or more upper-layer data.

[0172] The bit order of the parameters within a single MAC PDU can be represented as the first and most important bit being the leftmost bit, and the last and least important bit being the rightmost bit.

[0173] To support segmentation, AIoT devices can store the corresponding segment information in registers (or volatile memory or temporary memory when the AIoT device is available).

[0174] One example is that segment information can be buffered / stored at the AS layer (MAC layer). AIoT devices can, at the MAC layer, indicate information generated from processing the MAC header within the MAC PDU received from the AIoT RAN / reader, and / or fields / information within that MAC header, and / or upper-layer data (e.g., AIoT NAS messages / containers, AIoT (application) data) contained within that MAC PDU, to the upper layer (AIoT NAS, AIoT data / application). AIoT devices can also receive indication information and / or upper-layer data (e.g., AIoT NAS messages / containers, AIoT (application) data) generated from upper-layer processing.

[0175] Upper-layer data can be associated with a MAC SDU containing the upper-layer header. One or more upper-layer data can be processed within a single MAC SDU. Alternatively, each upper-layer data can be processed as its own MAC SDU. (Another approach is that the upper-layer data can be the upper-layer payload information without the upper-layer header.) The AIoT device can store the upper-layer data at the MAC layer. The AIoT device can generate a MAC PDU to be sent at the MAC layer based on scheduling information received from the AIoT RAN / reader (and / or scheduling information determined in the AIoT device's MAC layer). If segmentation is performed for any reason (the size of the MAC PDU included in the upper-layer data plus the MAC header exceeds the received scheduling resources), the AIoT device can store the segment information at the MAC layer. The AIoT device can then send the MAC PDU or the segment to the AIoT RAN / reader. When the AIoT device receives a retransmission instruction for the MAC PDU or the segment from the AIoT RAN / reader, it can also send the MAC PDU or the segment to the AIoT RAN / reader.

[0176] Segment information can indicate the location of the MAC SDU segment within the original MAC SDU (in bytes / bits). (Alternatively, segment information can indicate the location of the MAC PDU segment within the original MAC PDU (in bytes / bits).) Segment information can indicate the start / first byte / bit of the MAC SDU / PDU segment within the original MAC SDU / PDU (in bytes / bits). And / or, segment information can indicate the end / last byte / bit of the MAC SDU / PDU segment within the original MAC SDU / PDU (in bytes / bits). And / or, segment information can indicate the start / first byte / bit of the MAC SDU / PDU segment to be transmitted within the original MAC SDU / PDU (in bytes / bits). For example, it could indicate the end / last byte / bit + 1 of a previously transmitted MAC SDU / PDU segment successfully received by the reader. And / or, segment information can indicate the end / last byte / bit (in bytes / bits) of a previously transmitted MAC SDU / PDU segment within the original MAC SDU / PDU. For example, it can indicate the end / last byte / bit of a previously transmitted MAC SDU / PDU segment successfully received by the reader. And / or, segment information can be associated with the MAC SDU / PDU as a device variable. For ease of illustration, an example is given. This is for illustrative purposes only, and the disclosure in this specification is not limited to this example. If the MAC SDU received from the upper layer is 100 bytes, and the first D2R schedule determines to send 30 bytes (excluding the MAC header) (or 45 bytes including the MAC header), and the second D2R schedule determines to send 70 bytes (excluding the MAC header) (or 85 bytes including the MAC header), then the start position of the segment sent according to the first D2R schedule can be 0, and the end position can be 30. The start position of the segment sent according to the second D2R schedule can be 30+1, and the end position can be 100. Alternatively, the start position of the segment sent according to the first D2R scheduling can be 0, and the end position can be 45. The start position of the segment sent according to the second D2R scheduling can be 45+1, and the end position can be 130.

[0177] Another example is that this information can be included within the D2R / R2D MAC PDU (or MAC PDU header).

[0178] Another example is that the information sent by the AIoT RAN / reader to the AIoT device to indicate the success / failure of a segment transmission may include segment information or segment information included in subsequent / next / following transmissions. For instance, an AIoT RAN / reader that successfully receives a segment sent by an AIoT device may indicate the end / last byte / bit of the successfully received MAC SDU / PDU segment. Alternatively, an AIoT RAN / reader that successfully receives a segment sent by an AIoT device may include the start / first byte / bit of the beginning segment of the raw upper-layer data to be transmitted after the successfully received MAC SDU / PDU segment.

[0179] Another example is that when an AIoT device sends a segment to the AIoT RAN / reader, the AIoT device can store that segment information as a device variable. If the segment information stored in that device variable is different from the segment information of the currently sent segment, then that segment information (of the device variable) can be updated / modified / changed.

[0180] Another example is that when an AIoT device sends a MAC PDU or segment to an AIoT RAN / reader and receives an indication from the AIoT RAN / reader that the MAC PDU or segment was successfully sent, the segment information (of the device variable) can be updated / discarded / removed.

[0181] Another example is that segment information can be buffered / stored at higher layers (AIoT NAS layer, AIoT data / application layer). The AIoT device can indicate to the higher layer (e.g., AIoT NAS or AIoT data / application) information generated from processing the MAC header within the MAC PDU received from the AIoT RAN / reader in the MAC layer, and / or fields / information within that MAC header, and / or upper-layer data (e.g., AIoT NAS messages / containers, AIoT (application) data) contained within that MAC PDU. The information indicating to the higher layer can include information instructing the AIoT device on the size / volume / data amount of upper-layer data to be included in the MAC PDU for generating the MAC PDU to be sent, based on scheduling information received from the AIoT RAN / reader in the MAC layer (and / or scheduling information determined in the AIoT device's MAC layer). This upper-layer data can represent data including the upper-layer header. Alternatively, the upper-layer data can represent the upper-layer payload data without the upper-layer header.

[0182] The information sent to the upper layer may include segment transmission indication information or retransmission indication information for previously sent segments.

[0183] The upper layer of an AIoT device (e.g., the AIoT NAS layer or the AIoT data / application layer) can generate a MAC SDU (or upper layer data, AIoT NAS PDU, AIoT data / application PDU) to be instructed / submitted / transmitted to the MAC layer based on the received information.

[0184] AIoT devices can store the upper-layer data in the upper layer (e.g., at least one of the AIoT NAS layer and the AIoT data / application layer). Alternatively, AIoT devices can store the upper-layer data in the AIoT NAS layer.

[0185] The AIoT device can decide whether to perform segmentation based on information received from the MAC layer at the upper / AIoT-NAS layer. Alternatively, the AIoT device can decide whether to perform segmentation at the MAC layer and indicate / transmit the indication to the upper / AIoT-NAS layer.

[0186] If segmentation is performed, for example, when the size of the upper-layer data (e.g., an AIoT NAS PDU or AIoT data / application PDU) is greater than the data size based on the information received from the MAC layer (e.g., the size / volume / data amount of the upper-layer data to be included in the MAC PDU), and / or when segmentation-related information is received from the MAC layer, the AIoT device may store the segment information in the upper-layer / AIoT-NAS layer. The AIoT device may transmit / submit / indicate the segment (or MAC SDU) to the MAC layer from the upper-layer / AIoT-NAS layer. The AIoT device may indicate / transmit the indication information and / or the segment information generated by the upper-layer processing to the MAC layer from the upper-layer / AIoT-NAS layer. The AIoT device may send the MAC PDU or the segment to the AIoT RAN / reader in the MAC layer. When the AIoT device receives a retransmission indication for the MAC PDU or the segment from the AIoT RAN / reader, the AIoT device's MAC layer may indicate the indication information to the upper layer. The AIoT device can transmit / submit / indicate the MAC PDU or segment (or MAC SDU) to the MAC layer from the upper layer / AIoT-NAS layer. The AIoT device can then send the MAC PDU or segment to the AIoT RAN / reader from the MAC layer.

[0187] Segment information can indicate the location (in bytes / bits) of the MAC SDU segment within the original MAC SDU. Alternatively, segment information can indicate the location (in bytes / bits) of the MAC PDU segment within the original MAC PDU. Segment information can indicate the start / first byte / bit (in bytes / bits) of the MAC SDU / PDU segment within the original MAC SDU / PDU. And / or, segment information can indicate the end / last byte / bit (in bytes / bits) of the MAC SDU / PDU segment within the original MAC SDU / PDU. And / or, segment information can indicate the start / first byte / bit (in bytes / bits) of the MAC SDU / PDU segment to be transmitted within the original MAC SDU / PDU. For example, it can indicate the end / last byte / bit + 1 of a previously transmitted MAC SDU / PDU segment successfully received by the reader. And / or, segment information can indicate the end / last byte / bit (in bytes / bits) of a previously transmitted MAC SDU / PDU segment within the original MAC SDU / PDU. For example, it can indicate the end / last byte / bit of a previously transmitted MAC SDU / PDU segment successfully received by the reader. Segment information can be associated with the MAC SDU / PDU as a device variable.

[0188] Segment information can indicate the location (in bytes / bits) of the NAS / data PDU segment within the original NAS / data PDU. Segment information can indicate the start / first byte / bit (in bytes / bits) of the NAS / data PDU segment within the original NAS / data PDU. And / or, segment information can indicate the end / last byte / bit (in bytes / bits) of the NAS / data PDU segment within the original NAS / data PDU. And / or, segment information can indicate the start / first byte / bit (in bytes / bits) of the NAS / data PDU segment to be transmitted within the original NAS / data PDU. For example, the end / last byte of a previously transmitted MAC SDU / PDU segment successfully received by the reader, and / or segment information can indicate the end / last byte / bit (in bytes / bits) of a previously transmitted NAS / data PDU segment within the original NAS / data PDU. For example, it can indicate the end / last byte / bit of a previously transmitted MAC SDU / PDU segment successfully received by the reader. And / or, segment information can be associated with the NAS / data PDU as a device variable.

[0189] Another example is that this segment information can be included within the NAS PDU (or NAS PDU header) or MAC PDU (or MACPDU header). For instance, an AIoT RAN / reader that successfully receives a segment from an AIoT device can indicate the end / last byte / bit of the successfully received MAC SDU / PDU segment. Alternatively, an AIoT RAN / reader that successfully receives a segment from an AIoT device can include the start / first byte / bit of the beginning segment of the raw upper-layer data to be transmitted after the successfully received MAC SDU / PDU segment.

[0190] Another example is that the information sent by the AIoT RAN / reader to the AIoT device to indicate the success / failure of a transmission segment may include segment information or segment information included in subsequent / next / following transmissions. For instance, the AIoT RAN / reader may indicate the size of a previously transmitted NAS SDU / PDU received by the reader, causing the AIoT device receiving the indication to include the segment starting from the size of the original NAS data SDU / PDU plus 1 byte / bit.

[0191] Another example is that when an AIoT device transmits / submits / indicates a segment (or MAC SDU) to the MAC layer in the upper layer / AIoT-NAS layer, the AIoT device can store the segment information as a device variable. If the device variable stores information different from the segment information of the currently transmitted segment, the segment information can be updated / modified / changed.

[0192] Another example is that when an AIoT device transmits / submits / indicates a segment (or MAC SDU) to the MAC layer in the upper layer / AIoT-NAS layer, and receives an indication message from the MAC layer indicating that the segment (or MAC SDU) was successfully transmitted, the segment information (of the device variable) can be updated / discarded / removed.

[0193] Additionally, AIoT device identification information can represent AIoT device identification information contained in NxAP (or service-based interface protocol between AIoTF and AIoTRAN, or application protocol above the service-based interface protocol between AIoTF and AIoTRAN / reader) / NGAP messages, or AIoT device identification information used in the non-access stratum (NAS) layer / entity of AIoTF and AIoT devices. This information can represent at least one of the following: a complete permanent AIoT device identifier configured in the AIoT device; a portion of a permanent AIoT device identifier; a complete permanent AIoT device identifier that has undergone security processing / verification (e.g., encryption, integrity protection, message authentication code, hash function, and / or device authentication); a portion of a securely processed / verified permanent AIoT device identifier; a code calculated / generated / derived / determined for secure processing / verification of the AIoT device (or complete / partial permanent AIoT device identifier); a code associated with the AIoT device (or complete / 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 the operator or a third party. A permanent AIoT device identifier may include either a network identifier (e.g., Mobile Country Code (MCC) + Mobile Network Code (MNC) and / or Network Identifier (NID)) or information used to identify third parties. A permanent AIoT device identifier may also include information used to distinguish different AIoT devices (e.g., Electronic Product Code (EPC) or other local / internal identification information) within the network identifier (e.g., MCC + MNC and / or NID) or information used to identify third parties. During any signaling process, more than one AIoT device identification information may be used for one AIoT device. For example, a network identifier (e.g., MCC + MNC and / or NID) or information used to identify third parties may be used as the first AIoT device identification information, and information used to distinguish different AIoT devices (e.g., Electronic Product Code (EPC) or other local / internal identification information) within the network identifier (e.g., MCC + MNC and / or NID) or information used to identify third parties may 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 sent and received after secure processing / verification. (For example, the first AIoT device identification information (plaintext), the second AIoT device identification information (ciphertext), or vice versa) Security parameters may represent at least one of the following information used in the secure processing / verification of the complete / partial permanent AIoT device identifier in AIoTF and / or AIoT devices: key, key identification information, freshness value, counter, token, verification value, random parameters (e.g., random parameters generated by the core network or random parameters generated by the device), algorithm, and device credentials / profile.

[0194] Figures 10a to 10b This document illustrates the A-IoT access process for embodiments to which this specification applies.

[0195] The main services and functions of the A-IoT MAC layer are as follows: - Paging; - Access; - Upper-layer data transmission - Construct a MAC PDU to map to a D2R transport block and transmit it to the physical layer. - MAC padding; - D2R segmentation; - Process MAC PDUs in R2D transport blocks transmitted from the physical layer - Fault detection A-IoT paging A-IoT paging enables A-IoT readers to trigger one, multiple, or all A-IoT devices to perform A-IoT CBRA or A-IoT CFA. A-IoT paging messages are sent in the PRDCH. A-IoT paging messages can contain 0 or 1 paging identifiers. Here, the paging identifier can be a permanent identifier for the A-IoT device or filtering information. When a paging identifier is included, the paging message is sent to one A-IoT device or a group of A-IoT devices. If no paging identifier is included, the paging message is sent to all A-IoT devices. Furthermore, A-IoT paging messages provide configuration for the A-IoT access procedure.

[0196] A-IoT Access Process For A-IoT access, both the A-IoT Contention-Based Random Access (CBRA) procedure and the A-IoT Contention-Free Access (CFA) procedure are supported. When an A-IoT device is paged, either A-IoT CBRA or A-IoT CFA is initiated based on the explicit instructions contained in the A-IoT paging message.

[0197] In the case of CBRA ( Figure 10aThe device randomly selects an access opportunity from those configured in the A-IoT paging message. To determine the start of the selected access opportunity, it can monitor access trigger messages and send A-IoTMSG1 (Access Random ID Message) at that access opportunity. The start of the first A-IoT MSG1 resource set is indicated directly in the A-IoT paging message, not through the access trigger message. After sending A-IoT MSG1, the device monitors A-IoT MSG2 (Random ID Response Message) until it receives the configured number of access trigger messages or subsequent A-IoT paging messages. That is, subsequent A-IoT MSG2 messages are not processed. If the frequency index (if present) contained in A-IoT MSG2 matches the frequency index used in MSG1, and the contained random ID is the same as the random ID sent in MSG1, the device considers contention resolution successful. Otherwise, contention resolution is considered unsuccessful. If contention resolution is successful, the device sends a D2R upper-layer data transmission message on the resources provided in A-IoT MSG2. If contention resolution fails, the device must perform re-access when receiving an A-IoT paging message with the same transaction ID.

[0198] In the case of CFA ( Figure 10b A-IoT devices use dedicated resources provided in the A-IoT paging message to send D2R upper-layer data transmission messages. In this case, monitoring access trigger messages is not required.

[0199] According to one embodiment of this specification, a device in a wireless communication system receives a paging message containing first device identification information and confirms whether the first device identification information matches second device identification information stored in the device. Furthermore, based on the confirmation of the match, the device sends a Media Access Control (MAC) message containing upper-layer data, wherein the paging message may include a first security parameter and information indicating the presence of the first security parameter.

[0200] The first security parameter can be used to generate a security protection identifier. Furthermore, the security protection identifier can be generated based on a device identifier.

[0201] Additionally, the upper-layer data may include at least one of the device identifier and a second security parameter calculated in the device. Here, the device identifier and the second security parameter may be distinguished and included as different fields within the Non-Access Stratum (NAS) message.

[0202] Furthermore, the paging message contains specific fields, and based on these specific fields, at least one of the first device identification information and the first security parameter can be transmitted to the upper layer.

[0203] Furthermore, confirming whether the first device identification information matches the second device identification information stored in the device may include an indication from the upper layer to the MAC layer regarding whether or not there is a match.

[0204] The disclosures described herein can be implemented by various means. For example, the disclosures can be implemented by hardware, firmware, software, or a combination thereof. Specifically, the following figures will be used for illustration.

[0205] Figure 11 An apparatus according to an embodiment of this specification is shown.

[0206] Reference Figure 11 The wireless communication system may include a first device 100a and a second device 100b.

[0207] 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), artificial intelligence (AI) module, robot, augmented reality (AR) device, virtual reality (VR) device, mixed reality (MR) 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.

[0208] 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), artificial intelligence (AI) module, robot, augmented reality (AR) device, virtual reality (VR) device, mixed reality (MR) 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.

[0209] 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 information and / or instructions of various forms. The transceiver 1031a is connected to the processor 1020a and may be controlled to transmit and receive wireless signals.

[0210] 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 information and / or instructions of various forms. The transceiver 1031b is connected to the processor 1020b and may be controlled to transmit and receive wireless signals.

[0211] The memory 1010a and / or the memory 1010b may be connected internally or externally to the processor 1020a and / or the processor 1020b, or may be connected to other processors via various technologies such as wired or wireless connections.

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

[0213] Figure 12 This is a block diagram illustrating the configuration of a terminal according to an embodiment of this specification.

[0214] In particular, Figure 12 This is to show the foregoing in more detail. Figure 11 A diagram of the device.

[0215] The device includes a memory 1010, a processor 1020, a transceiver 1031, a power management module 1091, a battery 1092, a display 1041, an input unit 1053, a speaker 1042 and a microphone 1052, a user identification module (SIM card), and one or more antennas.

[0216] Processor 1020 is programmed to implement the functions, processes, and / or methods described herein. The various layers of the wireless interface protocol may be implemented in processor 1020. Processor 1020 may include application-specific integrated circuits (ASICs), other chipsets, logic circuits, and / or data processing devices. Processor 1020 may be an application processor (AP). Processor 1020 may include at least one of a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modem. An example of processor 1020 may be a Qualcomm processor. ® The SNAPDRAGON™ series processors manufactured by Samsung ® The EXYNOS™ series processors manufactured by Apple ® A-series processors manufactured by MediaTek ® The manufactured HELIO™ series processors, Intel ® The manufactured ATOM™ series processors, HiSilicon ® The KIRINTM series processors or corresponding next-generation processors manufactured.

[0217] Power management module 1091 manages the power supplied to processor 1020 and / or transceiver 1031. Battery 1092 supplies power to power management module 1091. Display 1041 outputs the results processed by processor 1020. Input unit 1053 receives inputs to be used by processor 1020. Input unit 1053 can be displayed on 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.

[0218] Memory 1010 is operatively coupled to processor 1020 and stores various information for operating processor 1020. Memory 1010 may include read-only memory (ROM), random access memory (RAM), 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 may be communicatively connected to processor 1020 by various means known in the art.

[0219] Transceiver 1031 is operatively coupled to processor 1020 and transmits and / or receives wireless signals. Transceiver 1031 includes a transmitter and a receiver. Transceiver 1031 may include baseband circuitry for processing radio frequency signals. The transceiver controls one or more antennas to transmit and / or receive wireless signals. To initiate communication, processor 1020 transmits instruction information of wireless signals constituting voice communication data to transceiver 1031. The antennas have the function of transmitting and receiving wireless signals. When receiving wireless signals, transceiver 1031 may transmit the signals to processor 1020 for processing and convert the signals to baseband. The processed signals may be converted into audible or readable information output through speaker 1042.

[0220] Speaker 1042 outputs sound-related results processed by processor 1020. Microphone 1052 receives sound-related inputs that will be used by processor 1020.

[0221] 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 these command information and processes them to perform appropriate functions, 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 information or operational information on the display 1041 for user identification and convenience.

[0222] Figure 13 This is a block diagram illustrating a processor configuration that implements the disclosures of this specification.

[0223] Reference Figure 13 As 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.

[0224] The processor 1020 may be referred to as an application-specific integrated circuit (ASIC) or an application processor (AP), and may include at least one of a digital signal processor (DSP), a central processing unit (CPU), and a graphics processing unit (GPU).

[0225] Figure 14 It is shown in detail Figure 11 The transceiver of the first device shown Figure 12 Block diagram of the transceiver of the device shown.

[0226] Reference Figure 14The transceiver 1031 includes a transmitter 1031-1 and a receiver 1031-2. The transmitter 1031-1 includes a Discrete Fourier Transform (DFT) section 1031-11, a subcarrier mapper 1031-12, an Inverse Fast Fourier Transform (IFFT) section 1031-13, a Cyclic Prefix (CP) insertion section 1031-14, and a wireless transmission section 1031-15. The transmitter 1031-1 may further include a modulator. Furthermore, for example, it may further include a scrambling unit (not shown), a modulation mapper (not shown), a layer mapper (not shown), and a layer permuter (not shown), which may be arranged before the DFT section 1031-11. That is, to prevent an increase in the peak-to-average power ratio (PAPR), the transmitter 1031-1 first passes the information through the DFT 1031-11 before mapping the signal to the subcarriers. The signal spread by the DFT unit 1031-11 (or synonym precoding) is subcarrier mapped by the subcarrier mapper 1031-12, and then the signal on the time axis is generated by the inverse fast Fourier transform (IFFT) unit 1031-13.

[0227] The DFT unit 1031-11 performs a DFT on the input symbols to output complex-valued symbols. For example, if Ntx symbols are input (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 symbols to subcarriers in the frequency domain. The complex symbols 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, inter-symbol interference (ISI) and inter-carrier interference (ICI) can be prevented, thereby maintaining orthogonality in multipath channels.

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

[0229] The preferred embodiments have been illustrated above, but the disclosure of this specification is not limited to these specific embodiments. Therefore, modifications, alterations or improvements can be made in various forms within the spirit and scope of the claims.

[0230] In the exemplary system described above, although the method is illustrated based on a flowchart as a series of steps or blocks, it is not limited to the order of the illustrated steps. Some steps may occur in different orders 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.

[0231] The claims described in this specification can be combined in various ways. For example, the technical features of the method claims in this specification can be combined to implement an apparatus, and the technical features of the apparatus claims in this specification can be combined to implement a method. Furthermore, the technical features of the method claims and the apparatus claims in this specification can be combined to implement an apparatus, and the technical features of the method claims and the apparatus claims in this specification can be combined to implement a method.

Claims

1. A data processing method of a device in a wireless communication system, the method comprising: Includes the following steps: Receive a paging message containing first device identification information; Confirm whether the first device identification information matches the second device identification information stored in the device; and Based on the confirmation of whether a match has been found, a media access control message containing upper-layer data is sent. The paging message includes a first security parameter and information indicating the presence of the first security parameter.

2. The data processing method for a device in a wireless communication system according to claim 1, characterized in that, The first security parameter is used to generate the identifier for security protection.

3. The data processing method for a device in a wireless communication system according to claim 2, characterized in that, The identifier for the security protection is generated based on the device identifier.

4. The data processing method for a device in a wireless communication system according to claim 3, characterized in that, The upper-layer data includes at least one of the device identifier and a second security parameter calculated in the device.

5. The data processing method for a device in a wireless communication system according to claim 4, characterized in that, The device identifier and the second security parameter are contained in different fields within the non-access stratum message.

6. The data processing method for a device in a wireless communication system according to claim 1, characterized in that, The paging message contains specific fields, and based on these specific fields, at least one of the first device identification information and the first security parameter is transmitted to the upper layer.

7. The data processing method for a device in a wireless communication system according to claim 1, characterized in that, The step of confirming whether a match exists includes a step whereby the upper layer indicates to the media access control layer whether a match exists.

8. An apparatus in a wireless communication system, the apparatus comprising: include: At least one processor; as well as At least one memory, the memory storing instructions and operably electrically connected to the at least one processor, wherein the at least one processor executes based on the instructions, and the operations performed include: Receive a paging message containing first device identification information; Confirm whether the first device identification information matches the second device identification information stored in the device; and Based on the confirmation of whether a match has been found, a media access control message containing upper-layer data is sent. The paging message includes a first security parameter and information indicating the presence of the first security parameter.

9. The device in the wireless communication system according to claim 8, characterized in that, The first security parameter is used to generate the identifier for security protection.

10. The device in the wireless communication system according to claim 9, characterized in that, The identifier for the security protection is generated based on the device identifier.

11. The device in the wireless communication system according to claim 10, characterized in that, The upper-layer data includes at least one of the device identifier and a second security parameter calculated in the device.

12. The device in the wireless communication system according to claim 11, characterized in that, The device identifier and the second security parameter are contained in different fields within the non-access stratum message.

13. The device in the wireless communication system according to claim 8, characterized in that, The paging message contains specific fields, and based on these specific fields, at least one of the first device identification information and the first security parameter is transmitted to the upper layer.

14. The device in the wireless communication system according to claim 8, characterized in that, The step of confirming whether a match exists includes a step whereby the upper layer indicates to the media access control layer whether a match exists.

Images