Apparatus and method for suspending or resuming operation of IoT devices

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. A method performed by an ambient Internet of Things function (AIoTF) in a wireless communication system, according to the present disclosure, may comprise the steps of: receiving, from an application function (AF), a first AIoT request message comprising information about at least one device ID or device determination condition and instructing operation suspension; on the basis of the device ID or the device determination condition, determining a device to perform the operation suspension; and transmitting, to a base station corresponding to the device to perform the operation suspension, a second AIoT request message comprising a device ID for a device on which operation suspension is to be performed and a code related to the suspension.

Description

Device and method for stopping or resuming the operation of IoT devices

[0001] The present invention relates to a method and apparatus for providing services by connecting terminals or IoT devices to a wireless communication network, more specifically to 3GPP 5GS (5G System).

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in frequency bands below 6 GHz ('Sub 6 GHz'), such as 3.5 gigahertz (3.5 GHz), but also in ultra-high frequency bands called millimeter waves (mmWave), such as 28 GHz and 39 GHz ('Above 6 GHz'). In addition, for 6G mobile communication technology, which is referred to as a system beyond 5G, implementation in the terahertz band (e.g., the 3 terahertz (3 THz) band at 95 GHz) is being considered to achieve transmission speeds 50 times faster and ultra-low latency reduced to one-tenth compared to 5G mobile communication technology.

[0003] In the early stages of 5G mobile communication technology, aiming to satisfy service support and performance requirements for enhanced Mobile BroadBand (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), technologies such as beamforming and Massive MIMO to mitigate path loss and increase transmission distance in ultra-high frequency bands, support for various numerologies (such as the operation of multiple subcarrier spacings) and dynamic operation of slot formats for the efficient utilization of ultra-high frequency resources, initial access techniques to support multi-beam transmission and broadband, definition and operation of Band-Width Parts (BWP), Low Density Parity Check (LDPC) codes for high-volume data transmission, new channel coding methods such as Polar Codes for the reliable transmission of control information, and L2 pre-processing (L2 Standardization has been carried out for pre-processing, network slicing which provides a dedicated network specialized for specific services, and other methods.

[0004] Currently, discussions are underway to improve and enhance the performance of the initial 5G mobile communication technology, taking into account the services that the 5G mobile communication technology was intended to support. Additionally, standardization of the physical layer is in progress for technologies such as V2X (Vehicle-to-Everything), which helps autonomous vehicles make driving decisions and enhance user convenience based on their own location and status information transmitted by the vehicle; NR-U (New Radio Unlicensed), which aims for system operation in unlicensed bands to comply with various regulatory requirements; NR terminal low power consumption technology (UE Power Saving); Non-Terrestrial Network (NTN), which is direct terminal-satellite communication for securing coverage in areas where communication with the terrestrial network is impossible; and positioning.

[0005] In addition, standardization is underway in the field of wireless interface architecture / protocols for technologies such as the Industrial Internet of Things (IIoT) for supporting new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) which provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement including Conditional Handover and Dual Active Protocol Stack (DAPS) Handover, and 2-step Random Access (2-step RACH for NR) which simplifies random access procedures. Standardization is also underway in the field of system architecture / services for 5G baseline architectures (e.g., Service based Architecture, Service based Interface) for incorporating Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC), which provides services based on the location of the terminal.

[0006] When such 5G mobile communication systems are commercialized, connected devices, which are increasing explosively, will be connected to communication networks. Accordingly, it is expected that there will be a need to enhance the functionality and performance of 5G mobile communication systems and to integrate the operation of connected devices. To this end, new research is planned to be conducted on 5G performance improvement and complexity reduction, support for AI services, support for metaverse services, and drone communication using eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] Furthermore, the advancement of these 5G mobile communication systems encompasses multi-antenna transmission technologies such as new waveforms to guarantee coverage in the terahertz band of 6G mobile communication technology, Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas; metamaterial-based lenses and antennas to improve terahertz band signal coverage; high-dimensional spatial multiplexing technology using OAM (Orbital Angular Momentum); and Reconfigurable Intelligent Surface (RIS) technology; as well as Full Duplex technology for enhancing frequency efficiency and system networks in 6G mobile communication technology; AI-based communication technologies that realize system optimization by utilizing satellites and AI from the design stage and internalizing end-to-end AI support functions; and the realization of services of complexity exceeding the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources. It could serve as a foundation for the development of next-generation distributed computing technologies.

[0008] The objective of the present invention is to propose a method for permanently suspending, temporarily suspending, or resuming the operation of terminals or IoT devices in the process of a wireless communication network, namely 3GPP 5GS (5G System), connecting them to provide services.

[0009] According to one embodiment of the present invention, a method performed by an Ambient Internet of Things Function (AIoTF) in a wireless communication system may be disclosed, comprising: receiving a first AIoT request message from an Application Function (AF) that includes information regarding at least one device ID or device determination condition and instructs to stop operation; determining a device to stop operation based on the device ID or the device determination condition; and transmitting a second AIoT request message to a base station corresponding to the device to stop operation, the message including a device ID for the device to stop operation and a code related to the stop operation.

[0010] The above AIoTF method may further include the step of receiving an AIoT response message from the base station, the message including a device ID and a code related to interruption; and the step of performing an update on the state of a device corresponding to the device ID.

[0011] The above device determination condition may be related to the remaining service validity period of the devices.

[0012] If the first AIoT request message instructs a temporary suspension of operation for the device, the first AIoT request message and the second AIoT request message may further include idle period information resulting from the temporary suspension of operation.

[0013] The above AIoTF method may further include the steps of: receiving a third AIoT request message from the AF that, when the first AIoT request message instructs a temporary suspension of operation for a device, includes information regarding at least one device ID or device determination condition and instructs the release of the temporary suspension of operation; determining a device to perform the release of the temporary suspension of operation based on the third AIoT request message; and transmitting a fourth AIoT request message to the base station that includes a device ID for the device to which the release of the temporary suspension of operation is to be performed and a code related to the release of the temporary suspension of operation.

[0014] According to another embodiment of the present invention, a method performed by an Internet of Things (IoT) device in a wireless communication system may be disclosed, comprising: receiving an Ambient IoT (AIoT) request message from a base station including a device ID and a code related to operation suspension; determining operation suspension based on the device ID and the code related to operation suspension; transmitting an AIoT response message to the base station including the device ID and the code related to operation suspension; and suspending at least one of a radio frequency (RF) transmission function or an RF reception function based on the operation suspension determination.

[0015] The above IoT device may suspend the RF transmission function and the RF reception function if the code related to the suspension of operation indicates a permanent suspension of operation, and may suspend only the RF transmission function if the code related to the suspension of operation indicates a temporary suspension of operation.

[0016] The method of the above IoT device may further include the step of, when the code related to the operation interruption indicates a temporary operation interruption, receiving a message related to the release of the temporary interruption from the base station and determining whether to enable the RF transmission function based on the message related to the release of the temporary interruption.

[0017] According to embodiments of the present invention, when a 3GPP 5GS (5G System) connects terminals or IoT devices using a UE Reader to provide services, the Network can control the operation of the devices in a way that permanently suspends, temporarily suspends, or resumes the operation of the devices, thereby enabling efficient utilization of terminals or IoT devices.

[0018] Figure 1 illustrates the Inventory (INV) and Command (CMD) message flow used by 3GPP 5GS (5G System) to provide Ambient IoT services.

[0019] Figure 2 illustrates a message flow for permanently stopping the operation of a device that is no longer in use when 3GPP 5GS (5G System) provides Ambient IoT services.

[0020] Figure 3 illustrates a message flow including a confirmation process to permanently stop the operation of a device that is no longer in use when 3GPP 5GS (5G System) provides Ambient IoT services.

[0021] Figure 4 illustrates a message flow for temporarily suspending the operation of a device that is not in use for a while when 3GPP 5GS (5G System) provides Ambient IoT services.

[0022] Figure 5 illustrates a message flow utilizing Command Only messages to resume the operation of a device whose operation had been temporarily suspended when 3GPP 5GS (5G System) provides Ambient IoT services.

[0023] Figures 6a and 6b illustrate the message flow in which the 3GPP 5GS (5G System) utilizes Inventory and Command messages to resume the operation of a device whose operation had been temporarily suspended when providing Ambient IoT services, and the AF makes a final decision.

[0024] Figure 7 illustrates a message flow in which the 3GPP 5GS (5G System) utilizes Inventory and Command messages to resume the operation of a device whose operation had been temporarily suspended when providing Ambient IoT services, and the Reader makes a final decision.

[0025] Figure 8 illustrates the message flow in which the 3GPP 5GS (5G System) utilizes Inventory and Command messages to resume the operation of a device whose operation had been temporarily suspended when providing Ambient IoT services, and the AIOTF / NEF performs the final decision.

[0026] FIG. 9 is a drawing illustrating the structure of a device according to one embodiment of the present invention.

[0027] FIG. 10 is a drawing illustrating a network entity according to one embodiment of the present invention.

[0028] The operating principle of the present invention will be described in detail below with reference to the attached drawings. In describing the present invention below, specific descriptions of related known functions or configurations will be omitted if it is determined that such detailed descriptions would unnecessarily obscure the essence of the invention. Furthermore, the terms described below are defined considering their functions in the present invention, and these may vary depending on the intentions or conventions of the user or operator. Therefore, their definitions should be based on the content throughout this specification.

[0029] Terms used in the following description to identify connection nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, terms referring to various identification information, etc., are examples provided for the convenience of explanation. Accordingly, the present invention is not limited to the terms described below, and other terms referring to objects having equivalent technical meanings may be used.

[0030] For the convenience of the following explanation, the present invention uses terms and names defined in the 5GS and NR specifications, which are the most recent standards defined by the 3GPP (The 3rd Generation Partnership Project) among currently existing communication standards. However, the present invention is not limited by the above terms and names and can be applied in the same way to wireless communication networks conforming to other standards. In particular, the present invention can be applied to 3GPP 5GS / NR (5th generation mobile communication standard).

[0031] The 3GPP 5GS (5G System) can provide services by connecting to terminals or IoT devices. To this end, devices that wirelessly connect to terminals or IoT devices are called Readers. A BS Reader, where a base station performs the Reader function, or an AIoT RAN may be used, or a UE Reader, where a wireless terminal (UE) performs the Reader role, may be utilized. If necessary, the Network may permanently stop the operation of some devices. For example, devices with a short remaining lifespan may be permanently stopped in advance to ensure stable service management. Additionally, the Network may temporarily stop the operation of some devices as needed. For instance, if service demand decreases and only some of the operating devices are required, the operation of the remaining devices may be temporarily suspended to extend their lifespan. Furthermore, if necessary, the Network may resume the operation of some of the devices whose operation was temporarily suspended. For instance, if demand increases again and more devices are required, the operation of the devices that were temporarily suspended due to decreased demand may be resumed.

[0032] The target services and devices of the present invention may include not only Ambient IoT services and devices but also all services and devices that require a disable / stop function for power saving purposes. In particular, the present invention is applicable to User Equipment (UE) based on 3GPP standards.

[0033] In the present invention, the operation of each network entity is not limited to that specific network entity. That is, another entity with a different network entity name may perform the operation of a specific network entity in place of it.

[0034] Figure 1 illustrates the Inventory (INV) and Command (CMD) message flow used by 3GPP 5GS (5G System) to provide Ambient IoT services.

[0035] In step S101, AF (100) can transmit a request for an IoT service to AIoTF (200) via NEF (300). This request may include detailed message contents such as Device IDs, UE IDs, Validity Time Condition, Location, Task ID (or Session ID, Service ID, Transaction ID), Inventory, or Command. Inventory may refer to a service that identifies the devices responsible for the service, and Command may refer to a service that requests a specific action, such as Read or Write, from the target device. Step S101 indicates the case where AF (100) requests an Inventory (INV) message to perform an inventory procedure.

[0036] In step S103, the AIOTF (200) can send an AIoT Request to the AMF / gNB (400 / 500). This AIoT Request may include detailed message contents such as Device IDs, UE IDs, Location, Task ID (or Session ID, Service ID, Transaction ID), and Inventory. At this time, the AIOTF (200) can select the necessary AMF (400) from among the multiple AMFs (400) to send the AIoT Request.

[0037] In step S105, the AMF / gNB (400 / 500) can send an AIoT Request to an AIoT Reader (AIoT RAN (600) or UE Reader (700). This AIoT Request may include detailed message content such as Device IDs, Location, Task ID (or Session ID, Service ID, Transaction ID), Inventory, etc.

[0038] In step S107, the AIoT RAN (600) or UE Reader (700) can send an AIoT Request to the Device (800) as a Paging message. This message may include detailed message contents such as Device IDs, Task ID (or Session ID, Service ID, Transaction ID), Inventory, etc.

[0039] In step S109, the Device (800) may decide to send an AIoT Response to the AIoT Reader if the Device ID included in the message received in step 4 matches its own Device ID. According to one embodiment, if the Device ID in the message of step 4 is blank, meaning all Devices, then all Devices respond; if it is an ID representing a Group, then Devices belonging to that Group respond; and if it contains specific conditions, then Devices satisfying those conditions respond.

[0040] In step S111, the Device (800) may transmit an AIoT Response to the AIoT Reader. This response may include detailed message contents such as Device IDs, Location, Task ID (or Session ID, Service ID, Transaction ID), Inventory, etc. When the AIoT Reader receives responses from multiple Devices (800), the AIoT Reader may select or aggregate the received responses. Hereinafter, aggregation in this specification may be replaced by operations such as summation, batching, compression, clustering, and data fusion.

[0041] In step S113, the AIoT RAN (600) / UE Reader (700) can send an AIoT Response to the AMF / gNB (400 / 500). This response may include detailed message contents such as Device IDs, Location, Task ID (or Session ID, Service ID, Transaction ID), Inventory, etc.

[0042] In step S115, the AMF / gNB (400 / 500) can send an AIoT Response to the AIoTF / NEF (200 / 300). This response may include detailed message contents such as Device IDs, Location, Task ID (or Session ID, Service ID, Transaction ID), and Inventory. At this time, if the AIoT Reader receives responses from multiple Devices (800), the AIoT Reader can select or aggregate the received responses.

[0043] In step S117, the AIoTF / NEF (200 / 300) can send an AIoT Response to the AF (100). This response may include detailed message contents such as Device IDs, Location, Task ID (or Session ID, Service ID, Transaction ID), and Inventory. The AF (100), having secured a list of Devices (800) available for the requested Task ID, can send additional requests to individual Devices or multiple Devices.

[0044] In step S119, AF (100) can transmit a request for an IoT service to AIoTF (200) via NEF (300). This request may include detailed message contents such as Device IDs, UE IDs, Validity Time Condition, Location, Task ID (or Session ID, Service ID, Transaction ID), Inventory, or Command. Inventory is a service that identifies the Devices (800) responsible for the service. Command is a service that requests a specific operation, such as Read or Write, from the target Device. Step S119 indicates the case where a Command (CMD) message is requested.

[0045] In step S121, the AIOTF (200) can send an AIoT Request to an AMF / gNB (400 / 500). This request may include detailed message contents such as Device IDs, UE IDs, Location, Task ID (or Session ID, Service ID, Transaction ID), and Command. At this time, the AIOTF (200) can select the necessary AMF / gNB (400 / 500) from among the multiple AMF / gNBs (400 / 500) and send the AIoT Request.

[0046] In step S123, the AMF / gNB (400 / 500) can send an AIoT Request to an AIoT Reader (AIoT RAN (600) or UE Reader (700)). This request may include detailed message content such as Device IDs, Location, Task ID (or Session ID, Service ID, Transaction ID), and Command.

[0047] In step S125, the AIoT RAN (600) or UE Reader (700) may send an AIoT Request to the Device (800) as a message targeting the individual Device. This message may include detailed message content such as Device IDs, Task ID (or Session ID, Service ID, Transaction ID), and Command.

[0048] In step S127, if the Device ID included in the message received in step S125 matches its own Device ID, the Device can execute the corresponding Command and transmit an AIoT Response to the AIoT Reader reflecting the result. According to one embodiment, if the Device ID in the message of step S125 is blank, meaning all Devices, all Devices respond; if it is an ID representing a Group, Devices belonging to that Group respond; and if it contains specific conditions, Devices satisfying those conditions respond.

[0049] In step S129, the Device (800) can send an AIoT Response to the AIoT Reader. This response may include detailed message contents such as Device IDs, Location, Task ID (or Session ID, Service ID, Transaction ID), and Command Result. When the AIoT Reader receives responses from multiple Devices (800), the AIoT Reader can select or aggregate these responses.

[0050] In step S131, the AIoT RAN (600) / UE Reader (700) can send an AIoT Response to the AMF / gNB (400 / 500). This response may include detailed message contents such as Device IDs, Location, Task ID (or Session ID, Service ID, Transaction ID), and Command result.

[0051] In step S133, the AMF / gNB (400 / 500) can send an AIoT Response to the AIoTF / NEF (200 / 300). This response may include detailed message content such as Device IDs, Location, Task ID (or Session ID, Service ID, Transaction ID), and Command results. At this time, if the AIoT Reader receives responses from multiple Devices (800), the AIoT Reader can select or aggregate these responses.

[0052] In step S135, the AIoTF / NEF (200 / 300) can send an AIoT Response to the AF (100). This response may include detailed message content such as Device IDs, Location, Task ID (or Session ID, Service ID, Transaction ID), and Command result.

[0053] Figure 2 illustrates a message flow for permanently stopping the operation of a device that is no longer in use when 3GPP 5GS (5G System) provides Ambient IoT services.

[0054] Basically, when the network sends a Command message to the Device (800) to request a permanent shutdown of the Device's operation, a code for the permanent shutdown request may be added to verify the permanent shutdown request. An AF, AIoTF, or AIoT Reader may generate or add a code for the permanent shutdown. An AF, AIoTF, or AIoT Reader may store the code for the permanent shutdown and use it in subsequent messages. Alternatively, the Device may generate a code and add it to the Disable Response. An AIoT Reader, AIoTF, or AF may check the code before removing the Device from the service list or updating the Device status to Disabled. Hereinafter, in this specification, the code may be replaced with a Token, ID, Key, reference, etc.

[0055] In step S201, AF (100) may decide to partially or permanently disable Devices (800) for a certain service. In step S203, AF (100) may send an AIoT Request to AIoTF / NEF (200 / 300). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Permanently Disable (code), Command, etc. One of the conditions for determining the Device may be the remaining service validity period. For example, 50% of the Devices among all Devices may be selected as Devices to be disabled based on the remaining service validity period, and Devices with a remaining service validity period of less than one month may be determined as Devices to be disabled.

[0056] In step S205, the AIoTF / NEF (200 / 300) can determine the target device (800) by considering the conditions, location, task ID, etc., that can determine the device ID or device (800) included in the content of the message received in step 1. For example, if 50% of all devices are received as a condition, the AIoTF / NEF (200 / 300) can select devices corresponding to 50% of the existing number based on the order of the shortest remaining service validity period. The AIoTF / NEF (200 / 300) may also generate a permanent disable code for the target device in step S205. According to one embodiment, the AIoTF / NEF (200 / 300) may decide to partially or permanently disable devices for a certain service based on a device management policy within the network without a request in step S201. For example, devices with a remaining validity period of less than one month may be determined within the network without a request from the AF (100). In step S207, the AIoTF / NEF (200 / 300) may send an AIoT Request to the gNB / AMF (500 / 400). This Request may include detailed information such as a Device ID or conditions for determining the Device, Location, Task ID, Permanently Disable (code), and Command. If the sending of the AIoT Request message fails at this stage due to reasons such as the target Device not being found or communication being impossible, the AIoTF / NEF may send an AIoT Response to the AF in step S209 to immediately notify that the request was not performed.

[0057] In step S211, the gNB / AMF (500 / 400) may send an AIoT Request to the AIoT RAN (600) or UE Reader (700). This Request may include detailed information such as a Device ID or conditions for determining the Device, Location, Task ID, Permanently Disable (code), Command, etc. The gNB / AMF (500 / 400) may also generate a Permanently Disable (code) for the target Device in this step. If the sending of the AIoT Request message fails for reasons such as the target Device not being found or communication not being established in this step, in step S215, the gNB / AMF (500 / 400) may send an AIoT Response to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) may send an AIoT Response to the AF (100) to immediately notify that the request was not performed.

[0058] In step S217, the AIoT RAN (600) or UE Reader (700) may send an AIoT Request to the Device (800). This Request may include detailed information such as a Device ID or conditions for determining the Device, Location, Task ID, Permanently Disable (code), Command, etc. The AIoT RAN (600) or UE Reader (700) may also generate a Permanently Disable (code) for the target Device (800) in this step. If, at this stage, the AIoT Request message fails to be sent for reasons such as the target device not being found or communication not being established, then at step S219, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) can send an AIoT Response to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) can send an AIoT Response to the AF (100) to immediately notify that the request was not performed.

[0059] In step S221, the Device (800) checks for a Permanently Disable code, and if confirmed, sends an AIoT Response to the AIoT RAN or UE Reader. Alternatively, in this step, the Device (800) may generate a code and then send an AIoT Response to the AIoT RAN (600) or UE Reader (700) including the generated code. If the Code verification result is inconsistent at this stage or fails for any other reason, at step S223, the Device (800) can immediately notify that the request was not performed by sending an AIoT Response to the AIoT RAN (600) or UE Reader (700), the AIoT RAN (600) or UE Reader (700) to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) to the AF (100).

[0060] In step S225, the Device (800) can send an AIoT Response to the AIoT RAN (600) or the UE Reader (700). This Response message may include detailed information such as a Device ID, Permanently Disable Code, and CMD. Subsequently, in step S227, the Device (800) can disable both the RF TX function and the RF RX function.

[0061] At step S229, the AIoT RAN (600) or UE Reader (700) checks the Code received at step S225 and can remove the Device (800) from the service list or update the Device status to Disabled. Then, at step S231, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to the gNB / AMF (500 / 400). This Response message may include detailed information such as Device ID, Permanently Disable Code, and CMD.

[0062] In step S233, the gNB / AMF (500 / 400) can send an AIoT Response to the AIoTF / NEF (200 / 300). This Response message may include detailed information such as Device ID, Permanently Disable Code, and CMD.

[0063] In step S235, the AIoTF / NEF (200 / 300) checks the Code received in step 8 and removes the Device (800) from the service list or updates the Device status to Disabled. Then, in step S237, the AIoTF / NEF (200 / 300) can send an AIoT Response to the AF (100). This Response message may include detailed information such as the Device ID, Permanently Disable Code, and CMD.

[0064] Afterwards, at step S239, AF (100) checks the Code received at step S237 and can remove Device (800) from the service list or update the Device status to Disabled.

[0065] Figure 3 illustrates a message flow including a confirmation process to permanently stop the operation of a device that is no longer in use when 3GPP 5GS (5G System) provides Ambient IoT services.

[0066] Basically, when the network sends a command to the Device (800) to request a permanent shutdown of the Device's operation, a code for the permanent shutdown request may be added to verify the permanent shutdown request. The AF (100), AIoTF (200), or AIoT Reader may generate or add the code. The AF (100), AIoTF (200), or AIoT Reader may store the code and use it in subsequent messages. Alternatively, the Device (800) may generate the code and add it to the Disable Response. The AIoT Reader, AIoTF (200), or AF (100) may check the code before removing the Device (800) from the service list or updating the Device status to Disabled, and if verified, send a Disable confirmation message to the Device.

[0067] In step S301, AF (100) may decide to permanently disable some or all of the Devices (800) for a certain service. At this time, AF (100) may send an AIoT Request to AIoTF / NEF (200 / 300). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Permanently Disable (code), Command, etc. One of the conditions for determining the Device may be the remaining service validity period. For example, 50% of the Devices among all Devices may be selected as Devices to be disabled based on the remaining service validity period, and Devices with a remaining service validity period of less than one month may be determined as Devices to be disabled.

[0068] In step S305, the AIoTF / NEF (200 / 300) can determine the target device (800) by considering the device ID or conditions for determining the device included in the message received in step S303, such as location and task ID. For example, if 50% of all devices are received as a condition, devices corresponding to the 50% figure relative to the existing number can be selected in order of the shortest remaining service validity period. The AIoTF / NEF may also generate a Permanently Disable (code) for the target device in this step. According to one embodiment, the AIoTF / NEF may decide to partially or permanently disable devices for a certain service based on a device management policy within the network without a request in step S303. In step S307, the AIoTF / NEF (200 / 300) transmits an AIoT Request to the gNB / AMF (500 / 400). This Request may include detailed information such as a Device ID or conditions for determining the Device, Location, Task ID, Permanently Disable (code), Command, etc. If sending the AIoT Request message fails at this stage for reasons such as the target Device not being found or communication not being established, the AIoTF / NEF (200 / 300) can immediately notify AF (100) that the request was not performed by sending an AIoT Response at step S309.

[0069] In step S311, the gNB / AMF (500 / 400) may send an AIoT Request to the AIoT RAN (600) or UE Reader (700). This Request may include detailed information such as a Device ID or conditions for determining the Device, Location, Task ID, Permanently Disable (code), Command, etc. The gNB / AMF may also generate a Permanently Disable (code) for the target Device in this step. If the sending of the AIoT Request message fails for reasons such as the target Device not being found or communication not being established in this step, the gNB / AMF may immediately notify the AIoTF / NEF and the AIoTF / NEF may notify the AF in step S315 that the request was not performed.

[0070] In step S317, the AIoT RAN (600) or UE Reader (700) may send an AIoT Request to the Device (800). This Request may include detailed information such as a Device ID or conditions for determining the Device, Location, Task ID, Permanently Disable (code), Command, etc. In step S313, the AIoT RAN (600) or UE Reader (700) may also generate a Permanently Disable (code) for the target Device. If, at this stage, the AIoT Request message fails to be sent for reasons such as the target device not being found or communication not being established, then at step S319, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) can send an AIoT Response to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) can send an AIoT Response to the AF (100) to immediately notify that the request was not performed.

[0071] In step S321, the Device (800) checks for a Permanently Disable code, and if confirmed, sends an AIoT Response to the AIoT RAN (600) or UE Reader (700) in step S325. Alternatively, in this step, the Device may generate a code and then send an AIoT Response to the AIoT RAN or UE Reader including the generated code. If the Code verification result is inconsistent at this stage or fails for any other reason, at stage S323, the Device (800) can immediately notify that the request was not performed by sending an AIoT Response to the AIoT RAN (600) or UE Reader (700), the AIoT RAN (600) or UE Reader (700) to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) to the AF (100).

[0072] At step S325, the Device (800) may send an AIoT Response to the AIoT RAN (600) or the UE Reader (700). This Response message may include detailed information such as a Device ID, Permanently Disable Code, and CMD. After step S325, the Device (800) may disable both the RF TX function and the RF RX function at step S327, or disable both the RF TX function and the RF RX function at step S335, step S347, or step S351.

[0073] At step S329, the AIoT RAN (600) or UE Reader (700) checks the Code received at step S325 and can remove the Device (800) from the service list or update the Device (800) status to Disabled. Subsequently, at step S331, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to the gNB / AMF (400 / 500). This Response message may include detailed information such as Device ID, Permanently Disable Code, and CMD. At this time, as in step S333, the AIoT RAN or UE Reader can send a message confirming the Permanently Disable to the Device. Upon receiving this Permanently Disable confirmation message, the Device can stop both the RF TX function and the RF RX function.

[0074] In step S337, the gNB / AMF (400 / 500) sends an AIoT Response to the AIoTF / NEF (200 / 300). This Response message may include detailed information such as the Device ID, Permanently Disable Code, and CMD.

[0075] In step S339, the AIoTF / NEF (200 / 300) checks the Code received in step S337 and removes the Device (800) from the service list or updates the Device status to Disabled. Then, in step S341, the AIoTF / NEF (200 / 300) sends an AIoT Response to the AF (100). This Response message may include detailed information such as Device ID, Permanently Disable Code, and CMD. At this time, as in step S343, the AIoTF / NEF (200 / 300) may send a message confirming Permanently Disable to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) may send a message confirming Permanently Disable to the AIoT RAN (600) or UE Reader (700), and the AIoT RAN (600) or UE Reader (700) may send a message confirming Permanently Disable to the Device (800). A Device (800) that receives this Permanently Disable confirmation message can stop both RF TX and RF RX functions.

[0076] Subsequently, at step S345, AF (100) checks the Code received at step S341 and can remove the Device from the service list or update the Device status to Disabled. At this time, as in step S349, AF (100) can send a message confirming Permanently Disable to AIoTF / NEF (200 / 300), AIoTF / NEF (200 / 300) can send a message confirming Permanently Disable to gNB / AMF (500 / 400), gNB / AMF (500 / 400) can send a message confirming Permanently Disable to AIoT RAN (600) or UE Reader (700), and AIoT RAN (200) or UE Reader (300) can send a message confirming Permanently Disable to Device (800). Upon receiving this Permanently Disable confirmation message, Device stops both RF TX and RF RX functions.

[0077] Figure 4 illustrates a message flow for temporarily suspending the operation of a device that is not in use for a while when 3GPP 5GS (5G System) provides Ambient IoT services.

[0078] Basically, when the network sends a Command message to the Device (800) to request a temporary suspension of the Device's operation, a code for the temporary suspension request may be added to verify the request. The AF (100), AIoTF (200), or AIoT Reader may generate or add the code. The AF (100), AIoTF (200), or AIoT Reader may store the code and use it in subsequent messages. Alternatively, the Device (800) may generate the code and add it to the Disable Response. The AIoT Reader, AIoTF (200), or AF (100) may check and store the code before updating the Device status to Temporarily Disabled. Additionally, the AF (100), AIoTF (200), AIoT Reader, or Device may generate Idle Period information, and the Device may use the Idle Period information to suspend its RF Rx for a certain period of time and then temporarily operate it for the rest of the time to prepare for a situation where an Enable request is received.

[0079] In step S401, AF (100) may decide to temporarily suspend some or all of the Devices for a certain service. In step S403, AF (100) may send an AIoT Request to AIoTF / NEF (200 / 300). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Temporarily Disable (code), Command, etc. One of the conditions for determining the Device may be the remaining service validity period. For example, 50% of the Devices among all Devices may be selected as Devices to be suspended based on the remaining service validity period, and Devices with a remaining service validity period of less than one month may be determined as Devices to be suspended. Additionally, the Request message in step S403 may include Idle Period information.

[0080] In step S405, the AIoTF / NEF can determine the target device (800) by considering the device ID or conditions for determining the device, location, task ID, etc., included in the content of the message received in step S403. For example, if 50% of all devices are received as a condition, devices corresponding to the 50% number relative to the existing number can be selected in order of the shortest remaining service validity period. The AIoTF / NET (200 / 300) may also generate a Temporarily Disable (code) for the target device in step S405. According to one embodiment, the AIoTF / NEF (200 / 300) may decide to temporarily suspend some or all devices for a service based on a device management policy within the network without a request in step S403. In step S407, the AIoTF / NEF (200 / 300) may transmit an AIoT Request to the gNB / AMF (500 / 400). This Request may include detailed information such as a Device ID or conditions for determining the Device, Location, Task ID, Temporarily Disable (code), Command, etc. Additionally, this message may include Idle Period information. If sending the AIoT Request message fails in step S407 for reasons such as the target Device not being found or communication not being established, the AIoTF / NEF (200 / 300) may immediately notify AF (100) that the request was not performed by sending an AIoT Response in step S409.

[0081] In step S411, the gNB / AMF (500 / 400) sends an AIoT Request to the AIoT RAN (600) or UE Reader (700). This Request may include detailed information such as a Device ID or conditions for determining the Device, Location, Task ID, Temporarily Disable (code), and Command. Additionally, this message may include Idle Period information. In this step, the gNB / AMF (500 / 400) may also generate a Temporarily Disable (code) for the target Device. If the sending of the AIoT Request message fails in step S411 for reasons such as the target Device not being found or communication not being established, in step S415, the gNB / AMF (500 / 400) may send an AIoT Response to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) may send an AIoT Response to the AF (100) to immediately notify that the request was not performed.

[0082] In step S417, the AIoT RAN (600) or UE Reader (700) may send an AIoT Request to the Device (800). This Request may include detailed information such as a Device ID or conditions for determining the Device, Location, Task ID, Temporarily Disable (code), Command, etc. Additionally, this Request message may include Idle Period information. In step S417, the AIoT RAN (600) or UE Reader (700) may also generate a Temporarily Disable (code) for the target Device. If, at this stage, the AIoT Request message fails to be sent for reasons such as the target device not being found or communication not being established, then at step S419, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) can send an AIoT Response to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) can send an AIoT Response to the AF (100) to immediately notify that the request was not performed.

[0083] In step S421, the Device (800) checks for a Temporarily Disable code; if confirmed, it stores the code and transmits an AIoT Response to the AIoT RAN (600) or UE Reader (700). Alternatively, in step S421, the Device (800) may generate a code and then transmit an AIoT Response to the AIoT RAN (600) or UE Reader (700) including the code generated in step S425. At this time, the Device (800) may store the received Idle Period information for future use or directly generate Idle Period information for future use. The Idle Period generated in this way may be included in the AIoT Response. If the AIoT Response transmission fails at step S421 due to a discrepancy in the Code check or other reasons, at step s423, the Device (800) can immediately notify the AIoT RAN (600) or UE Reader (700), the AIoT RAN (600) or UE Reader (700) can send the AIoT Response to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) can send it to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) can send it to the AF (100) to notify that the request was not performed.

[0084] In step S425, the Device (800) can send an AIoT Response to the AIoT RAN (600) or the UE Reader (700). This Response message may include detailed information such as a Device ID, Temporarily Disable Code, and CMD. Additionally, this Response message may include Idle Period information. Subsequently, in step S427, the Device (800) can stop the RF TX function and use the Idle Period information to stop the RF RX function for a certain period of time and then temporarily operate it at other times to prepare for a situation where an Enable request is received.

[0085] At step S429, the AIoT RAN (600) or UE Reader (700) can check the Code received at step S425 and update the Device status to Temporarily Disabled. The AIoT RAN (600) or UE Reader (700) can store the Code and Idle Period information. At step S431, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to the gNB / AMF (500 / 400). This Response message may include detailed information such as Device ID, Temporarily Disable Code, and CMD. Additionally, this Response message may include Idle Period information.

[0086] In step S433, the gNB / AMF (500 / 400) sends an AIoT Response to the AIoTF / NEF (200 / 300). This Response message may include detailed information such as the Device ID, Temporarily Disable Code, and CMD. Additionally, this Response message may include Idle Period information.

[0087] In step S435, the AIoTF / NEF (200 / 300) checks the Code received in step 8 and can update the Device status to Temporarily Disabled. The AIoTF / NEF (200 / 300) can store the Code and Idle Period information, and subsequently, in step S437, the AIoTF / NEF (200 / 300) can send an AIoTF Response to AF (100). This Response message may include detailed information such as Device ID, Temporarily Disable Code, and CMD. Additionally, this Response message may include Idle Period information.

[0088] In step S439, AF (100) checks the Code received in step S437 and can update the Device status to Temporarily Disabled. AF (100) can store Code and Idle Period information.

[0089] Figure 5 illustrates a message flow utilizing Command Only messages to resume the operation of a device whose operation had been temporarily suspended when 3GPP 5GS (5G System) provides Ambient IoT services.

[0090] Similar to Inventory messages, Command Only messages can be delivered by the AIoT Reader conveying an AIoT Request to the Device via Paging messages. Command Only messages may contain only control commands without a data payload. Additionally, when delivering AIoT-related messages, Code and Idle Period information previously stored in the AF, AIoTF / NEF, or AIoT Reader during a Temporarily Disable request may be utilized.

[0091] In step S501, AF (100) may decide to resume operation of some or all of the Devices (800) for a certain service. In step S503, AF (100) may send an AIoT Request to AIoTF / NEF (200 / 300). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code), Command Only, etc. Conditions for determining the Device may include the selection of 50% of the Devices in a Temporarily Disabled state, a remaining service validity period of 6 months or more, etc. The AIoT Request message may include Idle Period information. At this time, Enable Temporarily Disabled (code) is a value stored by AF that was previously set for the corresponding Device when Temporarily Disable was performed.

[0092] In step S505, the AIoTF / NEF can determine the target device by considering the device ID or conditions that can determine the device (800) included in the message received in step S503, such as location and task ID. For example, if the condition is 50% of the devices in a temporarily disabled state, the devices corresponding to 50% of the devices in a temporarily disabled state can be selected based on the one with the longest remaining service validity period. The AIoTF / NEF (200 / 300) may also decide to resume the operation of some or all of the devices (800) for a certain service based on the device management policy within the network without a request in step S503. In step S507, the AIoTF / NEF (200) sends an AIoT Request to the gNB / AMF (500 / 400). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code), and Command. Additionally, this Request message may include Idle Period information. In this case, Enable Temporarily Disabled (code) is a value stored by AF or AIoTF that was previously set for the corresponding Device during the Temporarily Disable process. If the sending of the AIoT Request message fails at step S507 for reasons such as the target Device not being found or communication not being established, the AIoTF / NEF (200 / 300) may send an AIoT Response to AF (100) at step S509 to immediately notify that the request was not performed.

[0093] In step S511, the gNB / AMF (500 / 400) can send an AIoT Request to the AIoT RAN (600) or UE Reader (700). This Request may include detailed information such as a Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code), and Command. This AIoT Request message may include Idle Period information. In this case, Enable Temporarily Disabled (code) is a value that was previously set for the Device when Temporarily Disable was performed, which is a value stored by AF (100) or AIoTF (200). If the sending of the AIoT Request message fails at this stage due to reasons such as the target device not being found or communication not being established, at step S513, the gNB / AMF (500 / 400) can immediately notify the AIoT Response to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) can immediately notify the AF (100) that the request was not performed.

[0094] In step S517, the AIoT RAN (600) or UE Reader (700) can send an AIoT Request to the Device (800). This AIoT Request may include detailed information such as the Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code), and Command. At this time, the Enable Temporarily Disabled (code) is a value that was previously set for the Device (800) during the Temporarily Disable process, and is a value stored by AF (100), a value stored by AIoTF (200), or a value stored by the AIoT Reader. The AIoT RAN (600) or UE Reader (700) can send an AIoT Request to the Device (800) at the time when the Device (800) resumes RF RX operation for a short period according to the Idle Period information. If, in step S517, the AIoT Request message fails to be sent for reasons such as the target Device (800) not being found or communication not being established, in step S519, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to gNB / AMF (500 / 400), gNB / AMF (500 / 400) can send an AIoT Response to AIoTF / NEF (200 / 300), and AIoTF / NEF (200 / 300) can send an AIoT Response to AF (100) to immediately notify that the request was not performed.

[0095] In step S521, if the Device (800) compares the Enable Temporarily Disabled code with the Temporarily Disabled Code it had stored and confirms it (for example, if it is determined that the values ​​of the Enable Temporarily Disabled code and the Temporarily Disabled code are identical or correspond), it can resume both the RF RX operation and the TX operation. In step S523, the Device (800) can transmit an AIoT Response to the AIoT RAN (600) or the UE Reader (700). Alternatively, in step S525, the Device may generate a code and then transmit an AIoT Response to the AIoT RAN or the UE Reader including the generated code. At this time, the Device (800) may store the received Idle Period information for future use or directly generate Idle Period information for future use. The Idle Period generated in this way can be included in the AIoT Response. If the Code verification result is inconsistent or fails for any other reason in step S521, then in step S523, the Device (800) can immediately notify the AIoT RAN (600) or UE Reader (700), the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) can send an AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) can send an AIoT Response to the AF (100) to notify that the request was not performed.

[0096] In step S525, the Device (800) can send an AIoT Response to the AIoT RAN (600) or the UE Reader (700). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and CMD. Additionally, this Response message may include Idle Period information.

[0097] In step S527, the AIoT RAN (600) or UE Reader (700) checks the Code received in step S525 and updates the Device status to Enabled. At this time, the Code and Idle Period information may not be stored. Subsequently, in step S529, the AIoT RAN (600) or UE Reader (700) sends an AIoT Response to the gNB / AMF (500 / 400). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and CMD. Additionally, this Response message may include Idle Period information.

[0098] In step S531, the gNB / AMF (500 / 400) sends an AIoT Response to the AIoTF / NEF (200 / 300). This Response message may include detailed information such as Device ID, Enabled / Temporarily Disabled (code), and CMD. Additionally, this Response message may include Idle Period information.

[0099] In step S533, the AIoTF / NEF (200 / 300) checks the Code received in step S531 and updates the Device status to Enabled. At this time, the Code and Idle Period information may not be saved. Subsequently, in step S535, the AIoTF / NEF (200 / 300) may send an AIoT Response to the AF (100). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and CMD. Additionally, this Response message may include Idle Period information.

[0100] Subsequently, in step S537, AF (100) checks the Code received in step S535 and updates the Device status to Enabled. At this time, the Code and Idle Period information may not be saved.

[0101] Figures 6a and 6b illustrate the message flow in which the 3GPP 5GS (5G System) utilizes Inventory and Command messages to resume the operation of a device whose operation had been temporarily suspended when providing Ambient IoT services, and the AF makes a final decision.

[0102] Through an Inventory message, the Network causes the AIoT Reader to transmit an AIoT Request to the Device via a Paging message, and the Device temporarily resumes RF TX operations and sends a Response message for the Inventory back to the Network. Upon confirming this, the Network transmits an AIoT Request regarding the final decision via a Command message. Additionally, when transmitting the AIoT message, Code and Idle Period information stored in the AF, AIoTF / NEF, or AIoT Reader during the previous Temporarily Disable request may be utilized.

[0103] In step S601, AF (100) can decide to resume operation of some or all of the Devices (800) for a certain service. Then, in step S603, AF (100) can send an AIoT Request to AIoTF / NEF (200 / 300). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code) or Indication, Inventory, etc. Conditions for determining the Device may include selecting 50% of the Devices in a Temporarily Disabled state, a remaining service validity period of 6 months or more, etc. This AIoT Request message may include Idle Period information. At this time, Enable Temporarily Disabled (code) is a value stored by AF that was previously set for the corresponding Device when Temporarily Disable was performed.

[0104] In step S605, the AIoTF / NEF (200 / 300) can determine the target device by considering the device ID or conditions for determining the device, location, task ID, etc., included in the content of the message received in step S603. For example, if the condition is 50% of the devices in a temporarily disabled state, the devices corresponding to 50% of the temporarily disabled devices can be selected based on the one with the longest remaining service validity period. The AIoTF / NEF (200 / 300) may also decide to resume the operation of some or all of the devices for a certain service based on the device management policy within the network without a request in step S603. In step S607, the AIoTF / NEF (200 / 300) sends an AIoT Request to the gNB / AMF (500 / 400). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code) or Indication, Inventory, etc. Additionally, this Request message may include Idle Period information. In this case, Enable Temporarily Disabled (code) is a value stored by AF or AIoTF that was previously set for the corresponding Device during the Temporarily Disable process. If the sending of the AIoT Request message fails at step S607 for reasons such as the target Device not being found or communication not being established, the AIoTF / NEF (200 / 300) may immediately notify AF (100) that the request was not performed by sending an AIoT Response at step S609.

[0105] In step S611, the gNB / AMF (500 / 400) can send an AIoT Request to the AIoT RAN (600) or UE Reader (700). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code) or Indication, Inventory, etc. This AIoT Request message may include Idle Period information. In this case, Enable Temporarily Disabled (code) is a value that was previously set for the corresponding Device during the Temporarily Disable process, which is a value stored by AF (100) or AIoTF (200). If the sending of the AIoT Request message fails in step S611 for reasons such as the target device not being found or communication not being established, in step S613, the gNB / AMF (500 / 400) can immediately notify the AIoT Response to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) can immediately notify the AF (100) that the request was not performed.

[0106] In step S617, the AIoT RAN (600) or UE Reader (700) may send an AIoT Request to the Device (800). This AIoT Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code) or Indication, Inventory, etc. In this case, Enable Temporarily Disabled (code) is a value that was previously set for the Device during the Temporarily Disable process, a value stored by AF, a value stored by AIoTF, or a value stored by the AIoT Reader. Additionally, the AIoT RAN or UE Reader may send an AIoT Request to the Device at the time when the Device temporarily resumes RF RX operation according to the Idle Period information. If the AIoT Request message fails to be sent in step S617 for reasons such as the target device not being found or communication not being established, in step S619, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to gNB / AMF (500 / 400), gNB / AMF (500 / 400) can send an AIoT Response to AIoTF / NEF (200 / 300), and AIoTF / NEF (200 / 300) can send an AIoT Response to AF (100) to immediately notify that the request was not performed.

[0107] In step S621, if the Device (800) confirms that the Enable Temporarily Disabled code is identical to or corresponds to the Temporarily Disabled Code stored (for example, if it is determined that the values ​​of the Enable Temporarily Disabled code and the Temporarily Disabled code are identical or correspond), the RF TX operation can be resumed for a certain period. Alternatively, if the Enable Temporarily Disabled Indication exists prior to the code confirmation and the Device confirms it, the RF TX operation can be resumed for a certain period. Then, the Device (800) can transmit an AIoT Response to the AIoT RAN or UE Reader. Alternatively, at this stage, the Device (800) may generate a code and then transmit an AIoT Response containing this generated code to the AIoT RAN (600) or UE Reader (700). At this time, the Device (800) may store the received Idle Period information for future use or directly generate Idle Period information for future use. The Idle Period generated in this way can be included in the AIoT Response. If the Code verification result is inconsistent or fails for any other reason at step S621, the RF TX function may be kept suspended or the RF TX function may be temporarily reactivated to send a message once, so that at step S623, the Device (800) sends an AIoT Response to the AIoT RAN (600) or UE Reader (700), the AIoT RAN (600) or UE Reader (700) sends to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) sends to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) sends to the AF (100) to immediately notify that the request was not performed.

[0108] In step S625, the Device (800) can send an AIoT Response to the AIoT RAN (600) or the UE Reader (700). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and Inventory. Additionally, this Response message may include Idle Period information. When the AIoT Reader receives responses from multiple Devices, the AIoT Reader may select or aggregate these responses.

[0109] In step S627, the AIoT RAN (600) or UE Reader (700) can check the Code received in step S625 and update the Device status to Temporarily Enabled. The AIoT RAN or UE Reader can store the Code and Idle Period information. Subsequently, in step S629, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to the gNB / AMF (500 / 400). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and Inventory. Additionally, this Response message may include Idle Period information.

[0110] In step S631, the gNB / AMF (500 / 400) sends an AIoT Response to the AIoTF / NEF (200 / 300). This Response message may include detailed information such as Device ID, Enabled / Temporarily Disabled (code), and Inventory. Additionally, this AIoT Response message may include Idle Period information.

[0111] In step S633, the AIoTF / NEF (200 / 300) checks the Code received in step S631 and can update the Device status to Temporarily Enabled. The AIoTF / NEF (200 / 300) can store the Code and Idle Period information. Subsequently, in step S635, the AIoTF / NEF (200 / 300) can send an AIoT Response to the AF (100). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and Inventory. Additionally, this Response message may include Idle Period information. At this time, if the AIoTF / NEF (200 / 300) receives multiple responses, the AIoT Reader can select or aggregate the received responses.

[0112] In step S637, AF (100) checks the Code received in step S635 and can update the Device status to Temporarily Enabled. AF (100) can store Code and Idle Period information. After selecting the final target Device (800) from among the Temporarily Disabled Devices that sent the Inventory Response, AF (100) can decide to resume operation of some or all of these Devices (800). At this time, in step S639, AF (100) can send an AIoT Request to AIoTF / NEF (200 / 300). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code), Command, etc. Conditions for determining the Device may include selecting 50% of the Temporarily Disabled Devices, a remaining service validity period of 6 months or more, etc. This Request message may include Idle Period information. In this case, Enable Temporarily Disabled (code) is the value stored by AF, which was set for the corresponding device when the Temporarily Disable process was performed previously.

[0113] In step S641, the AIoTF / NEF (200 / 300) can determine the target device by considering the Device ID or conditions for determining the device, Location, Task ID, etc., included in the content of the message received in step S639. For example, if the condition is 50% of Temporarily Disabled Devices, the devices corresponding to 50% of the Temporarily Disabled Devices can be selected based on the device with the longest remaining service validity period. The AIoTF / NEF (200 / 300) may also decide to resume the operation of some or all of the devices for a certain service based on the device management policy within the network without the request in step 10. The AIoTF / NEF (200 / 300) can transmit an AIoT Request to the gNB / AMF (500 / 400). This Request may include detailed information such as the Device ID or conditions for determining the device, Location, Task ID, Enable Temporarily Disabled (code), Command, etc. This Request message may include Idle Period information. At this time, Enable Temporarily Disabled (code) is a value stored by AF (100) or AIoTF (200) that was previously set for the corresponding Device (800) during the Temporarily Disable process. If sending the AIoT Request message fails in step S641 for reasons such as not being able to find the target Device or confirming that communication is not possible, AIoTF / NEF (200 / 300) can send an AIoT Response to AF (100) in step S645 to immediately notify that the request was not performed.

[0114] In step S647, the gNB / AMF (500 / 400) sends an AIoT Request to the AIoT RAN (600) or UE Reader (700). This Request may include detailed information such as a Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code), and Command. This AIoT Request message may include Idle Period information. In this case, Enable Temporarily Disabled (code) is a value that was previously set for the Device when Temporarily Disable was performed, which is a value stored by AF (100) or AIoTF (200). If the sending of the AIoT Request message fails at step S647 due to reasons such as the target device not being found or communication not being established, at step S649, the gNB / AMF (500 / 400) can immediately notify the AIoT Response to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) can immediately notify the AF (100) that the request was not performed.

[0115] In step S653, the AIoT RAN (600) or UE Reader (700) sends an AIoT Request to the Device (800). This Request may include detailed information such as the Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code), and Command. At this time, the Enable Temporarily Disabled (code) is a value that was previously set for the Device during the Temporarily Disable process, and is a value stored by AF (100), a value stored by AIoTF (200), or a value stored by the AIoT Reader. The AIoT RAN (600) or UE Reader (700) may send an AIoT Request to the Device at the time when the Device temporarily resumes RF RX operation according to the Idle Period information. If, at this stage, the AIoT Request message fails to be sent for reasons such as the target Device (800) not being found or communication not being established, then at step S655, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) can send an AIoT Response to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) can send an AIoT Response to the AF (100) to immediately notify that the request was not performed.

[0116] In step S657, the Device (800) compares the Enable Temporarily Disabled code with the Temporarily Disable Code it had stored, and if confirmed, resumes both the RX and TX operations of the RF. Then, it transmits an AIoT Response to the AIoT RAN (600) or the UE Reader (700). Alternatively, in step S657, the Device may generate a code and then transmit an AIoT Response to the AIoT RAN (600) or the UE Reader (700) in step S661, including the generated code. If the code check result at this stage is inconsistent or fails for other reasons, the Device (800) may keep the RF TX function suspended or temporarily re-enable the RF TX function to send a message once, and at step S659, the Device (800) may immediately notify the AIoT RAN (600) or UE Reader (700), the AIoT RAN (600) or UE Reader (700) may notify the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) may notify the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) may notify the AF (100) that the request was not performed.

[0117] In step S661, the Device (800) sends an AIoT Response to the AIoT RAN (600) or the UE Reader (700). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and CMD. Additionally, this AIoT Response message may include Idle Period information.

[0118] In step S663, the AIoT RAN (600) or UE Reader (700) checks the Code received in step S661 and updates the Device status to Enabled. At this time, the Code and Idle Period information may not be stored. Subsequently, in step S665, the AIoT RAN (600) or UE Reader (700) may send an AIoT Response to the gNB / AMF (500 / 400). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and CMD. Additionally, this Response message may include Idle Period information.

[0119] At step S667, the gNB / AMF (500 / 400) can send an AIoT Response to the AIoTF / NEF (200 / 300). This Response message may include detailed information such as Device ID, Enabled / Temporarily Disabled (code), and CMD. Additionally, this Response message may include Idle Period information.

[0120] In step S669, the AIoTF / NEF (200 / 300) checks the Code received in step S667 and updates the Device status to Enabled. At this time, the Code and Idle Period information may not be stored. Subsequently, in step S671, the AIoTF / NEF (200 / 300) may send an AIoT Response to the AF (100). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and CMD. Additionally, this Response message may include Idle Period information.

[0121] Subsequently, in step S673, AF (100) checks the Code received in step S671 and updates the Device status to Enabled. At this time, the Code and Idle Period information may not be saved.

[0122] Figure 7 illustrates a message flow in which the 3GPP 5GS (5G System) utilizes Inventory and Command messages to resume the operation of a device whose operation had been temporarily suspended when providing Ambient IoT services, and the Reader makes a final decision.

[0123] Through an Inventory message, the Network causes the AIoT Reader to transmit an AIoT Request to the Device via a Paging message, and the Device temporarily resumes RF TX operations and then transmits a Response message for the Inventory back to the Network. Upon confirming this, the Network transmits an AIoT Request for the final decision via a Command message. Furthermore, when transmitting the AIoT message, Code and Idle Period information stored in the AF, AIoTF / NEF, or AIoT Reader during a previous Temporarily Disable request may be utilized. In particular, in this embodiment, an AIoT Reader, such as an AIoT RAN or UE Reader, can perform the final decision.

[0124] In step S701, AF (100) can decide to resume operation of some or all of the Devices (800) for a certain service. In step S703, AF (100) can send an AIoT Request to AIoTF / NEF (200 / 300). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code) or Indication, Inventory, and Command. Conditions for determining the Device (800) may include selecting 50% of the Devices in a Temporarily Disabled state, or having a remaining service validity period of 6 months or more. This AIoT Request message may include Idle Period information. At this time, Enable Temporarily Disabled (code) is a value stored by AF (100) that was previously set for the corresponding Device when Temporarily Disable was performed.

[0125] In step S705, the AIoTF / NEF (200 / 300) can determine the target device by considering the device ID or conditions for determining the device, location, task ID, etc., included in the content of the message received in step S703. For example, if the condition is 50% of the devices in a temporarily disabled state, the devices corresponding to 50% of the devices in a temporarily disabled state can be selected based on the one with the longest remaining service validity period. The AIoTF / NEF (200 / 300) may also decide to resume the operation of some or all of the devices (800) for a certain service based on the device management policy within the network without the request in step S703. In step S707, the AIoTF / NEF (200 / 300) sends an AIoT Request to the gNB / AMF (500 / 400). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code) or Indication, Inventory, and Command. This AIoT Request message may include Idle Period information. In this case, Enable Temporarily Disabled (code) is a value stored by AF or AIoTF that was set for the corresponding Device during a previous Temporarily Disable process. If sending the AIoT Request message fails at step S707 due to reasons such as the target Device not being found or communication being impossible, AIoTF / NEF may immediately notify AF at step S709 that the request was not performed by sending an AIoT Response.

[0126] In step S711, the gNB / AMF (500 / 400) can send an AIoT Request to the AIoT RAN (600) or UE Reader (700). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code) or Indication, Inventory, and Command. This AIoT Request message may include Idle Period information. In this case, Enable Temporarily Disabled (code) is a value stored by AF or AIoTF that was previously set for the Device during the Temporarily Disable process. If the sending of the AIoT Request message fails in step S711 for reasons such as the target device not being found or communication not being established, in step S713, the gNB / AMF (500 / 400) can immediately notify the AIoT Response to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) can immediately notify the AF (100) that the request was not performed.

[0127] In step S717, the AIoT RAN (600) or the UE Reader (700) can send an AIoT Request to the Device (800). In this embodiment, the AIoT RAN or the UE Reader can make a final decision on whether to send it to the Inventory or to the CMD. In step S717, the AIoT RAN (600) or the UE Reader (700) decides to send the AIoT Request as an Inventory message. This Request may include detailed information such as the Device ID or conditions for determining the Device (800), Location, Task ID, Enable Temporarily Disabled (code) or Indication, and Inventory. At this time, the Enable Temporarily Disabled (code) is a value set for the corresponding Device when the Temporarily Disable process was previously performed, which is a value stored by the AF (100), a value stored by the AIoTF (200), or a value stored by the AIoT Reader. Additionally, the AIoT RAN (600) or UE Reader (700) may send an AIoT Request to the Device (800) at the time when the Device (800) resumes RF RX operation for a short while according to the Idle Period information. If the AIoT Request message fails to be sent at step S717 for reasons such as the target Device not being found or communication not being established, at step S719, the AIoT RAN (600) or UE Reader (700) may send an AIoT Response to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) may send an AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) may send an AIoT Response to the AF (100) to immediately notify that the request was not performed.

[0128] In step S721, if the Device (800) confirms that the Enable Temporarily Disabled code is identical to or corresponds to the Temporarily Disabled Code stored (for example, if it is determined that the values ​​of the Enable Temporarily Disabled code and the Temporarily Disabled code are identical or correspond), the RF TX operation can be resumed for a certain period. Alternatively, if the Enable Temporarily Disabled Indication exists prior to the code confirmation and the Device (800) confirms it, the RF TX operation can be resumed for a certain period. Then, the Device (800) can transmit an AIoT Response to the AIoT RAN (600) or the UE Reader (700). Alternatively, in step S721, the Device (800) may generate a code and then transmit an AIoT Response including the generated code to the AIoT RAN (600) or the UE Reader (700). At this time, the Device (800) may store the received Idle Period information for future use or directly generate Idle Period information for future use. The Idle Period generated in this way may be included in the AIoT Response. If the Code verification result is inconsistent or fails for other reasons in step S721, the RF TX function may be kept suspended, or the RF TX function may be temporarily re-enabled to send a message once, so that in step S723, the Device (800) sends an AIoT Response to the AIoT RAN (600) or UE Reader (700), the AIoT RAN (600) or UE Reader (700) sends an AIoT Response to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) sends an AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) sends an AIoT Response to the AF (100) to immediately notify that the request was not performed.

[0129] In step S725, the Device (800) can send an AIoT Response to the AIoT RAN or UE Reader. This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and Inventory. Additionally, this Response message may include Idle Period information. When the AIoT Reader receives responses from multiple Devices, the AIoT Reader can select or aggregate these responses.

[0130] In step S727, the AIoT RAN (600) or UE Reader (700) can check the Code received in step 6 and update the Device status to Temporarily Enabled. The AIoT RAN (600) or UE Reader (700) can store Code and Idle Period information. After the AIoT RAN (600) or UE Reader (700) selects the final target Device from among the Temporarily Disabled Devices that sent the Inventory Response, the AF (100) can decide to resume operation of some or all of these Devices (800). The condition for determining which Device to resume operation may be set, for example, when the response signal strength is above a threshold value. In step S729, the AIoT RAN (600) or UE Reader (700) can send an AIoT Request to the Device (800). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code), and Command. In this case, Enable Temporarily Disabled (code) is a value stored by AF, AIoTF, or AIoT Reader that was previously set for the Device during the Temporarily Disable process. Additionally, the AIoT RAN or UE Reader may send an AIoT Request to the Device at the time when the Device temporarily resumes RF RX operation based on the Idle Period information.If the AIoT Request message fails to be sent at step S727 for reasons such as the target device not being found or communication not being established, at step S731, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to gNB / AMF (500 / 400), gNB / AMF (500 / 400) can send an AIoT Response to AIoTF / NEF (200 / 300), and AIoTF / NEF (200 / 300) can send an AIoT Response to AF (100) to immediately notify that the request was not performed.

[0131] In step S733, if the Device (800) confirms that the Enable Temporarily Disabled code is the same as or corresponds to the Temporarily Disabled Code stored (for example, if it is determined that the values ​​of the Enable Temporarily Disabled code and the Temporarily Disabled code are the same or correspond), it can resume both the RF RX operation and the TX operation. Then, in step S737, the Device (800) can transmit an AIoT Response to the AIoT RAN (600) or the UE Reader (700). In step S733, the Device (800) can generate a code, and in step S737, transmit an AIoT Response including this generated code to the AIoT RAN (600) or the UE Reader (700). If the Code verification result is inconsistent or fails for any other reason at step S727, the Device may keep the RF TX function suspended or temporarily re-enable the RF TX function to send a message once, and at step S735, the Device (800) may immediately notify the AIoT RAN (600) or UE Reader (700), the AIoT RAN (600) or UE Reader (700) may notify the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) may notify the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) may notify the AF (100) that the request was not performed.

[0132] In step S737, the Device (800) can send an AIoT Response to the AIoT RAN (600) or the UE Reader (700). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and CMD. Additionally, this AIoT Response message may include Idle Period information.

[0133] At step S739, the AIoT RAN (600) or UE Reader (700) can check the Code received at step S737 and update the Device status to Enabled. At this time, the Code and Idle Period information may not be stored. Subsequently, at step S741, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to the gNB / AMF (500 / 400). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and CMD. Additionally, this Response message may include Idle Period information.

[0134] In step S743, the gNB / AMF (500 / 400) can send an AIoT Response to the AIoTF / NEF (200 / 300). This Response message may include detailed information such as Device ID, Enabled / Temporarily Disabled (code), and CMD. Additionally, this Response message may include Idle Period information.

[0135] In step S745, the AIoTF / NEF (200 / 300) checks the Code received in step S741 and can update the Device status to Enabled. At this time, the Code and Idle Period information may not be stored. Subsequently, in step S747, the AIoTF / NEF (200 / 300) can send an AIoT Response to the AF (100). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and CMD. Additionally, this Response message may include Idle Period information.

[0136] Afterwards, in step S749, AF (100) can check the Code received in step 12 and update the Device status to Enabled. At this time, the Code and Idle Period information may not be saved.

[0137] Figure 8 illustrates the message flow in which the 3GPP 5GS (5G System) utilizes Inventory and Command messages to resume the operation of a device whose operation had been temporarily suspended when providing Ambient IoT services, and the AIOTF / NEF performs the final decision.

[0138] The Network, through an Inventory message, causes the AIoT Reader to transmit an AIoT Request to the Device via a Paging message, and the Device temporarily resumes RF TX operations and then transmits a Response message for the Inventory back to the Network. Upon confirming this, the Network transmits an AIoT Request for the final decision via a Command message. Furthermore, when transmitting the AIoT message, the Code and Idle Period information stored in the AF, AIoTF / NEF, or AIoT Reader during the previous Temporarily Disable request may be utilized. In particular, in this embodiment, the AIoTF / NEF may perform the final decision.

[0139] In step S801, AF (100) may decide to resume operation of some or all of the Devices (800) for a certain service. In step S803, AF (100) may send an AIoT Request to AIoTF / NEF (200 / 300). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code) or Indication, Inventory, and Command. Conditions for determining the Device may include selecting 50% of the Devices in a Temporarily Disabled state, or having a remaining service validity period of 6 months or more. This AIoT Request message may include Idle Period information. At this time, Enable Temporarily Disabled (code) is a value stored by AF that was previously set for the corresponding Device when Temporarily Disable was performed.

[0140] In step S805, the AIoTF / NEF (200 / 300) can determine the target device by considering the device ID or conditions for determining the device, location, task ID, etc., included in the content of the message received in step S803. For example, if the condition is 50% of the devices in a temporarily disabled state, the devices corresponding to 50% of the temporarily disabled devices can be selected based on the one with the longest remaining service validity period. The AIoTF / NEF may also decide to resume the operation of some or all of the devices for a certain service based on the device management policy within the network without a request in step S703. In step S807, the AIoTF / NEF (200 / 300) transmits an AIoT Request to the gNB / AMF (500 / 400). In this embodiment, the AIoTF (200) can make a final decision on whether to send it to the Inventory or to the CMD. At this stage, the AIoT RAN (600) or UE Reader (700) decides to send it to the Inventory. This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code) or Indication, and Inventory. Additionally, this Request message may include Idle Period information. In this case, Enable Temporarily Disabled (code) is a value stored by AF or AIoTF that was previously set for the Device during the Temporarily Disable process.If sending the AIoT Request message fails at this stage due to reasons such as the target device not being found or communication not being established, the AIoTF / NEF (200 / 300) can immediately notify AF (100) that the request was not performed by sending an AIoT Response at stage S808.

[0141] In step S809, the gNB / AMF (500 / 400) can send an AIoT Request to the AIoT RAN (600) or UE Reader (700). This Request may include detailed information such as Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code) or Indication, Inventory, etc. This AIoT Request message may include Idle Period information. In this case, Enable Temporarily Disabled (code) is a value that was previously set for the corresponding Device (800) during the Temporarily Disable process, and is a value stored by AF (100) or AIoTF (200). If, at this stage, the sending of the AIoT Request message fails for reasons such as the target Device (800) not being found or communication not being established, then at step S810, the gNB / AMF (500 / 400) can immediately notify the AIoT Response to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) can immediately notify the AF (100) that the request was not performed.

[0142] In step S813, the AIoT RAN (600) or UE Reader (700) may send an AIoT Request to the Device (800). This Request may include detailed information such as the Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code) or Indication, Inventory, etc. At this time, the Enable Temporarily Disabled (code) is a value set for the Device (800) when the Temporarily Disable was previously performed, and is a value stored by AF (100), a value stored by AIoTF (200), or a value stored by the AIoT Reader. Additionally, the AIoT RAN (600) or UE Reader (700) may send an AIoT Request to the Device at the time when the Device (800) temporarily resumes RF RX operation according to the Idle Period information. If, at this stage, the AIoT Request message fails to be sent for reasons such as the target Device (800) not being found or communication not being established, then at step S814, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) can send an AIoT Response to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) can send an AIoT Response to the AF (100) to immediately notify that the request was not performed.

[0143] In step S815, if the Device (800) confirms that the Enable Temporarily Disabled code is identical to or corresponds to the Temporarily Disabled code stored (for example, if it is determined that the values ​​of the Enable Temporarily Disabled code and the Temporarily Disabled code are identical or correspond), the RF TX operation can be resumed for a certain period. Alternatively, if the Enable Temporarily Disabled Indication exists prior to the code confirmation and the Device confirms it, the RF TX operation can be resumed for a certain period. Then, in step S817, the Device (800) transmits an AIoT Response to the AIoT RAN (600) or the UE Reader (700). Alternatively, in step S815, the Device (800) may generate a code and then transmit an AIoT Response including the generated code to the AIoT RAN (600) or the UE Reader (700). At this time, the Device (800) may store the received Idle Period information for future use or directly generate Idle Period information for future use. The Idle Period generated in this way can be included in the AIoT Response. If the Code verification result is inconsistent or fails for other reasons in step S815, the RF TX function may be kept suspended or the RF TX function may be temporarily reactivated to send a message once, so that in step S816, the Device (800) sends an AIoT Response to the AIoT RAN (600) or UE Reader (700), the AIoT RAN (600) or UE Reader (700) sends an AIoT Response to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) sends an AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) sends an AIoT Response to the AF (100) to immediately notify that the request was not performed.

[0144] In step S817, the Device (800) can send an AIoT Response to the AIoT RAN or UE Reader. This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and Inventory. Additionally, this Response message may include Idle Period information. When the AIoT Reader receives responses from multiple Devices, the AIoT Reader may select or aggregate these responses.

[0145] In step S819, the AIoT RAN (600) or UE Reader (700) checks the Code received in step S817 and can update the Device status to Temporarily Enabled. The AIoT RAN (600) or UE Reader (700) can store the Code and Idle Period information. Subsequently, in step S821, the AIoT RAN (600) or UE Reader (700) sends an AIoT Response to the gNB / AMF. This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and Inventory. Additionally, this Response message may include Idle Period information.

[0146] In step S823, the gNB / AMF (500 / 400) sends an AIoT Response to the AIoTF / NEF (200 / 300). This Response message may include detailed information such as Device ID, Enabled / Temporarily Disabled (code), and Inventory. Additionally, this Response message may include Idle Period information.

[0147] In step S825, the AIoTF / NEF (200 / 300) checks the Code received in step S823 and can update the Device status to Temporarily Enabled. The AIoTF / NEF (200 / 300) can store Code and Idle Period information. At this time, if the AIoTF / NEF (200 / 300) receives multiple responses, the AIoT Reader can select or aggregate these responses. After selecting the final target Device (800) from among the Temporarily Disabled Devices that sent the Inventory Response, the AIoTF / NEF (200 / 300) can decide to resume operation of some or all of these Devices. The condition for determining the Device (800) may be configured to maintain the number of Enabled Devices per AIoT Reader as evenly as possible. In step S827, the AIoTF / NEF (200 / 300) can send an AIoT Request to the gNB / AMF. This Request may include detailed information such as a Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code), and Command. Additionally, this Request message may include Idle Period information. In this case, the Enable Temporarily Disabled (code) is a value stored by AF (100) or AIoTF (200) that was previously set for the corresponding Device during a Temporarily Disable process.If the AIoT Request message fails to be sent at this stage for reasons such as the target Device (800) not being found or communication not being established, the AIoTF / NEF (200 / 300) can immediately notify AF (100) that the request was not performed by sending an AIoT Response at step S828.

[0148] In step S829, the gNB / AMF (500 / 400) can send an AIoT Request to the AIoT RAN (600) or UE Reader (700). This Request may include detailed information such as a Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code), and Command. Additionally, this Request message may include Idle Period information. In this case, Enable Temporarily Disabled (code) is a value stored by AF (100) or AIoTF (200) that was previously set for the Device during the Temporarily Disable process. If, at this stage, the sending of the AIoT Request message fails for reasons such as the target Device (800) not being found or communication not being established, then at step S830, the gNB / AMF (500 / 400) sends an AIoT Response to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) sends an AIoT Response to the AF (100) to immediately notify that the request was not performed.

[0149] In step S833, the AIoT RAN (600) or UE Reader (700) may send an AIoT Request to the Device (800). This Request may include detailed information such as the Device ID or conditions for determining the Device, Location, Task ID, Enable Temporarily Disabled (code), and Command. In this case, Enable Temporarily Disabled (code) is a value that was previously set for the Device during the Temporarily Disable process, and is a value stored by AF, a value stored by AIoTF, or a value stored by the AIoT Reader. Additionally, the AIoT RAN or UE Reader may send an AIoT Request to the Device at the time when the Device temporarily resumes RF RX operation according to the Idle Period information. If the AIoT Request message fails to be sent at this stage for reasons such as the target device not being found or communication not being established, then at step S834, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) can send an AIoT Response to the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) can send an AIoT Response to the AF (100) to immediately notify that the request was not performed.

[0150] In step S835, if the Device (800) confirms that the Enable Temporarily Disabled code is the same as or corresponds to the Temporarily Disabled Code stored (for example, if it is determined that the values ​​of the Enable Temporarily Disabled code and the Temporarily Disabled code are the same or correspond), it can resume both the RX and TX operations of the RF. Then, the Device (800) transmits an AIoT Response to the AIoT RAN (600) or the UE Reader (700). In step S835, the Device (800) may generate a code and then transmit an AIoT Response to the AIoT RAN or the UE Reader in step S837, including the generated code. If the Code verification result is inconsistent or fails for any other reason at step S835, the Device (800) may keep the RF TX function suspended or temporarily reactivate the RF TX function to send a message once, and at step S836, the Device (800) may immediately notify the AIoT RAN (600) or UE Reader (700), the AIoT RAN (600) or UE Reader (700) may notify the gNB / AMF (500 / 400), the gNB / AMF (500 / 400) may notify the AIoTF / NEF (200 / 300), and the AIoTF / NEF (200 / 300) may notify the AF (100) that the request was not performed.

[0151] In step S837, the Device (800) can send an AIoT Response to the AIoT RAN (600) or the UE Reader (700). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and CMD. Additionally, this AIoT Response message may include Idle Period information.

[0152] At step S839, the AIoT RAN (600) or UE Reader (700) can check the Code received at step S837 and update the Device status to Enabled. At this time, the Code and Idle Period information may not be stored. Subsequently, at step S841, the AIoT RAN (600) or UE Reader (700) can send an AIoT Response to the gNB / AMF (500 / 400). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and CMD. Additionally, this Response message may include Idle Period information.

[0153] At step S843, the gNB / AMF (500 / 400) can send an AIoT Response to the AIoTF / NEF (200 / 300). This Response message may include detailed information such as Device ID, Enabled / Temporarily Disabled (code), and CMD. Additionally, this Response message may include Idle Period information.

[0154] In step S845, the AIoTF / NEF (200 / 300) checks the Code received in step S843 and can update the Device status to Enabled. At this time, the Code and Idle Period information may not be stored. Subsequently, the AIoTF / NEF (200 / 300) can send an AIoT Response to the AF (100). This Response message may include detailed information such as Device ID, Enabled, Temporarily Disabled (code), and CMD. Additionally, this Response message may include Idle Period information.

[0155] Afterward, AF (100) can check the Code received in step S847 and update the Device status to Enabled. At this time, the Code and Idle Period information may not be saved.

[0156] FIG. 9 is a drawing illustrating the structure of a device according to one embodiment of the present invention.

[0157] Referring to FIG. 9, the device may include a transceiver (910), a control unit (920), and a storage unit (930). In the present invention, the control unit may be defined as a circuit or an application-specific integrated circuit or at least one processor.

[0158] The transceiver (910) can transmit and receive signals with other network entities. The transceiver (910) can receive paging messages from, for example, an AIoT RAN or a UE Reader.

[0159] The control unit (920) can control the overall operation of the user terminal according to the embodiment proposed in the present invention. For example, the control unit (920) can control the operation of the device receiving an AIoT device and generating and transmitting a response thereto.

[0160] The storage unit (930) can store at least one of the information transmitted and received through the transmission and reception unit (910) and the information generated through the control unit (920).

[0161] FIG. 10 is a drawing illustrating a network entity according to one embodiment of the present invention.

[0162] The network entity illustrated in FIG. 10 may be composed of one of the various types of network entities disclosed in the present invention, for example, AIoT RAN, AMF, gnB, AIoTF, NEF, AF, etc.

[0163] Referring to FIG. 10, a network entity may include a transceiver (1010), a control unit (1020), and a storage unit (1030). In the present invention, the control unit may be defined as a circuit or an application-specific integrated circuit or at least one processor.

[0164] The transmitting and receiving unit (1010) can transmit and receive signals with other network entities. The transmitting and receiving unit (1010) can receive, for example, request messages for various information from a device, user terminal, base station, or other network entities.

[0165] The control unit (1020) can control the overall operation of the network entity according to the embodiment proposed in the present invention.

[0166] The storage unit (1030) can store at least one of the information transmitted and received through the transmission and reception unit (1010) and the information generated through the control unit (1020).

[0167] Methods according to the embodiments described in the claims or specification of the present invention may be implemented in the form of hardware, software, or a combination of hardware and software.

[0168] When implemented in software, a computer-readable storage medium may be provided for storing one or more programs (software modules). One or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. One or more programs include instructions that cause the electronic device to execute methods according to embodiments described in the claims or specification of the present invention.

[0169] Such programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, ROM (Read Only Memory), Electrically Erasable Programmable Read Only Memory (EEPROM), magnetic disc storage devices, Compact Disc-ROM (CD-ROM), Digital Versatile Discs (DVDs), or other forms of optical storage devices, magnetic cassettes. Alternatively, they may be stored in memory composed of some or all of these. Additionally, each constituent memory may include multiple units.

[0170] In addition, the above program may be stored on an attachable storage device that can be accessed via a communication network such as the Internet, Intranet, Local Area Network (LAN), Wide LAN (WLAN), or Storage Area Network (SAN), or a combination thereof. Such a storage device may be connected to a device performing an embodiment of the present invention through an external port. Additionally, a separate storage device on a communication network may be connected to a device performing an embodiment of the present invention.

[0171] In the specific embodiments of the present invention described above, the components included in the invention are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present invention is not limited to singular or plural components; even if a component is expressed in the plural form, it may be composed in the singular form, or even if a component is expressed in the singular form, it may be composed in the plural form.

[0172] Meanwhile, although specific embodiments have been described in the detailed description of the present invention, it is understood that various modifications are possible within the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof.

Claims

1. A method performed by an Ambient Internet of Things Function (AIoTF) in a wireless communication system, A step of receiving a first AIoT request message from an AF (Application Function) that includes information on at least one device ID or device determination condition and instructs to stop operation; A step of determining a device to perform an operation interruption based on the above device ID or the above device determination condition; and A method comprising the step of transmitting a second AIoT request message to a base station corresponding to a device to be deactivated, the message including a device ID for the device to be deactivated and a code related to the deactivation.

2. In Paragraph 1, A step of receiving an AIoT response message from the base station, the message including a device ID and a code related to interruption; and A method further comprising the step of performing an update on the state of a device corresponding to the above device ID.

3. In Paragraph 1, The above device determination condition is a method related to the remaining service validity period of the devices.

4. In Paragraph 1, A method in which, when the first AIoT request message instructs a temporary suspension of operation for a device, the first AIoT request message and the second AIoT request message further include idle period information corresponding to the temporary suspension of operation.

5. In Paragraph 1, If the above first AIoT request message instructs a temporary suspension of operation for the device, A step of receiving a third AIoT request message from the above AF, which includes information on at least one device ID or device determination condition and instructs the release of a temporary suspension of operation; A step of determining a device to perform release of temporary operation suspension based on the above third AIoT request message; and A method further comprising the step of transmitting a fourth AIoT request message to the base station, the message including a device ID for the device on which the release of the temporary suspension of operation is to be performed and a code related to the release of the temporary suspension of operation.

6. A method performed by an IoT (Internet of Things) device in a wireless communication system, A step of receiving an AIoT (Ambient IoT) request message from a base station containing a device ID and a code related to operation interruption; A step of determining a suspension of operation based on the above device ID and the code associated with the suspension of operation; A step of transmitting an AIoT response message to the base station, the message including the device ID and a code related to the suspension of operation; and A method comprising the step of suspending at least one of an RF (radio frequency) transmission function or an RF reception function based on the above decision to suspend operation.

7. In Paragraph 6, If the code related to the above operation suspension indicates a permanent operation suspension, the RF transmission function and the RF reception function are suspended, and A method for suspending only the RF transmission function when the code related to the above-mentioned suspension of operation indicates a temporary suspension of operation.

8. In Paragraph 6, If the code related to the above operation suspension indicates a temporary operation suspension, A method further comprising the step of receiving a message related to lifting a temporary suspension from the base station and determining whether to enable an RF transmission function based on the message related to lifting the temporary suspension.

9. In the Ambient Internet of Things Function (AIoTF) in wireless communication systems, Transmitter / receiver; and It includes a control unit, The above control unit is, Receive a first AIoT request message from an AF (Application Function) that includes information on at least one device ID or device determination condition and instructs to stop operation, and Based on the above device ID or the above device determination condition, the device to perform operation interruption is determined, and AIoTF configured to transmit a second AIoT request message to a base station corresponding to a device to be deactivated, the request message including a device ID for the device to be deactivated and a code related to the deactivation.

10. In Paragraph 9, The above control unit is, Receive an AIoT response message from the above base station including a device ID and a code related to interruption, and AIoTF further configured to perform updates to the state of the device corresponding to the above device ID.

11. In Paragraph 9, The above device determination condition is related to the remaining service validity period of the devices, AIoTF.

12. In Paragraph 9, When the first AIoT request message instructs a temporary suspension of operation for the device, the first AIoT request message and the second AIoT request message further include idle period information for the temporary suspension of operation, AIoTF.

13. In Paragraph 9, If the above first AIoT request message instructs a temporary suspension of operation for the device, The above control unit is, From the above AF, a third AIoT request message is received that includes information on at least one device ID or device determination condition and instructs the release of a temporary suspension of operation, and Based on the above third AIoT request message, a device to perform release of temporary operation suspension is determined, and AIoTF further configured to transmit to the base station a fourth AIoT request message including a device ID for a device on which the release of a temporary suspension of operation is to be performed and a code related to the release of the temporary suspension of operation.

14. In IoT (Internet of Things) devices in wireless communication systems, Transmitter / receiver; and It includes a control unit, The above control unit is, Receive an AIoT (Ambient IoT) request message from a base station containing a device ID and a code related to the suspension of operation, and Based on the above device ID and the code related to the above operation interruption, the operation interruption is determined, and Transmit an AIoT response message to the base station, the device ID and a code related to the suspension of operation, and An IoT device configured to stop at least one of an RF (radio frequency) transmission function or an RF reception function based on the above decision to stop operation.

15. In Paragraph 14, The above control unit is, If the code related to the above operation suspension indicates a permanent operation suspension, the RF transmission function and the RF reception function are suspended, and An IoT device configured to stop only the RF transmission function when the code related to the above-mentioned operation interruption indicates a temporary operation interruption.

Images