Method and apparatus for enabling / disabling ambient internet of things (AIOT) device

Abstract

The embodiments herein relate to method and apparatus for enabling / disabling Ambient Internet of Things (AIoT) device. In some embodiments, there proposes a method (400) performed by a network node (103) providing Ambient Internet of Things (AIoT) service. The method may comprise the step of transmitting (S401) a first message including a first indicator indicating that a response from an AIoT device (101) in a disabled status is required; and the step of transmitting (S403) a third message for enabling the AIoT device (101). The embodiments may allow the AIoT device in a disabled status to be enabled, by the enable requests from the application function.

Description

METHOD AND APPARATUS FOR ENABLING / DISABLING AMBIENT INTERNET OF THINGS (AIOT) DEVICETechnical Field

[0001] The embodiments herein relate generally to the field of communication, and more particularly, the embodiments herein relate to method and apparatus for enabling / disabling Ambient Internet of Things (AIoT) device.Background

[0002] Ambient Internet of Things (AIoT) , also referred as Zero-Energy IoT (ZE-IoT) , Ambient-IoT (A-IoT) , Passive-IoT, or Ambient power-enabled IoT, is recently increasingly researched. In 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 22.369 v19.3.0: “Service requirements for ambient power-enabled IoT; Stage 1 (Release 19) ” , the service requirements for enabling and disabling Ambient IoT devices are defined in section 5.2.3.

[0003] Management

[0004] The 5th Generation Mobile Communication Technology (5G) network shall support suitable management mechanisms for an Ambient IoT device or a group of Ambient IoT devices.

[0005] The 5G system shall support a mechanism to:

[0006] - disable the capability to transmit RF signals for one or more Ambient IoT device that is  / are currently able to transmit RF signals

[0007] - enable the capability to transmit RF signals for one or more Ambient IoT device that is  / are currently disabled to transmit RF signals

[0008] Based on operator policy, the 5G system shall provide a suitable mechanism to permanently disable the capability of an Ambient IoT device or a group of Ambient IoT devices to transmit RF signals.

[0009] Subject to operator policy and regulatory requirements, the 5G system shall support suitable mechanisms for the Ambient IoT device to move between one or more networks and countries.

[0010] The technical Report, 3GPP Technology Research (TR) 23.700-13 v1.0.0: “Study on Architecture support of Ambient power-enabled Internet of Thing (Release-19) ” was agreed in 3GPP SA2#164. Within the TR, solution #17 "Enable Ambient IoT Management within 5GC to support AIoT services" focused on the solution implementation for the extremely capability limited devices in Ambient IoT.

[0011] In solution #17, the AIoT Management Function (AIoTMF) sends an Inventory Start message to the targeted AIoT device (s) via an AIoT reader, if the AIoTMF receives the AIoT_Disable service operation request. Then, if an AIoT device matches the device information in the Inventory Start message, the AIoT device performs random access like procedures to establish a connection with Radio Access Network (RAN) and sends a truncated AIoT device ID in AIoT Inventory Response message. Then, after receiving the AIoT Inventory Response message, the AIoTMF constructs the corresponding AIoT Command messages (e.g., AIoT Disable Service Request message) for disabling the matched AIoT device.Summary

[0012] However, there are several problems in the solution #17. In solution#17, the command delivery towards AIoT device is implemented in an “inventory and command” way. The solution#17 is not applicable to enable a disabled AIoT device, since the disabled AIoT device shall not respond to the Inventory request, that is, the disabled AIoT device shall not perform random access like procedures or send a truncated AIoT device ID, since it is disabled. Without the response from the device, the following up command of enabling the device cannot be sent out, so that the device cannot be enabled finally.

[0013] In addition, for the Disable Service Operation in solution #17, there are no differentiation of permanent disable or temporary disable. And there are no Enable Service Operation provided.

[0014] In view of the above, the embodiments herein propose method and apparatus for enabling / disabling (temporarily disabling or permanently disabling) AIoT device (s) .

[0015] In some embodiments, there proposes a method performed by a network node providing AIoT service. The method may comprise the step of transmitting, to an AIoT reader, a first message including a first indicator indicating that a response from an AIoT device in a disabled status is required; and the step of transmitting, to the AIoT reader, a third message for enabling the AIoT device.

[0016] In some embodiments, there proposes a method performed by a network node providing AIoT service. The method may comprise the step of transmitting, to an AIoT reader, a fourth message for one of: temporarily disabling an AIoT device, permanently disabling an AIoT device, and enabling an AIoT device. Specifically, the command message may further comprise a timer indicating an AIoT device temporarily disabled is to be enabled after the timer expires.

[0017] In some embodiments, there proposes a method performed by an AIoT reader. The method may comprise the step of receiving, from a network node providing AIoT service, a first message; the step of in response to determining the first message includes an indicator indicating that a response from an AIoT device in a disabled status is required, transmitting, to the AIoT device, a first paging-like message including the indicator; the step of receiving, from the network node providing AIoT service, a third message for enabling the AIoT device; and the step of transmitting, to the AIoT device, the third message.

[0018] In some embodiments, there proposes a method performed by an AIoT reader. The method may comprise the step of receiving, from a network node providing AIoT service, a fourth message for one of: temporarily disabling the AIoT device, permanently disabling the AIoT device, and enabling the AIoT device; and the step of transmitting, to the AIoT device, the fourth message.

[0019] In some embodiments, there proposes a method performed by an AIoT device. The method may comprise the step of receiving, from an AIoT reader, a first paging-like message including a first indicator indicating that a response from an AIoT device in a disabled status is required; and the step of handling the first paging-like message.

[0020] In some embodiments, there proposes a method performed by an AIoT device. The method may comprise the step of receiving, from the AIoT reader, a fourth message for one of: temporarily disabling the AIoT device, permanently disabling the AIoT device, and enabling the AIoT device; and the step of handling the fourth message.

[0021] In some embodiments, there proposes a method performed by a network node implementing network exposure function. The method may comprise the step of receiving, from a network node implementing an application function, an AIoT service operation request message, for requesting one of an AIoT temporary disable service operation, an AIoT permanent disable service operation, and an AIoT enable service operation.

[0022] In some embodiments, there proposes a method performed by a network node implementing application function. The method may comprise the step of transmitting, to a network node implementing network exposure function, an AIoT service operation request message, for requesting one of an AIoT temporary disable service operation, an AIoT permanent disable service operation, and an AIoT enable service operation.

[0023] In some embodiments, there proposes a method performed by a network node providing AIoT service. The method may comprise the step of receiving, from a network node implementing network exposure function, an AIoT service operation request message, for requesting one of an AIoT temporary disable service operation, an AIoT permanent disable service operation, and an AIoT enable service operation.

[0024] In some embodiments, there proposes a network node providing AIoT service, implementing network exposure function, or implementing application function. The network node may comprise at least one processor; and a non-transitory computer readable medium coupled to the at least one processor. The non-transitory computer readable medium may contain instructions executable by the at least one processor, whereby the at least one processor may be configured to perform any of the above method related to the network node.

[0025] In some embodiments, there proposes an AIoT reader. The AIoT reader may comprise at least one processor; and a non-transitory computer readable medium coupled to the at least one processor. The non-transitory computer readable medium may contain instructions executable by the at least one processor, whereby the at least one processor may be configured to perform any of the above method related to the AIoT reader.

[0026] In some embodiments, there proposes an AIoT device. The AIoT device may comprise an energy harvester for harvesting energy; an energy storage for storing the harvested energy; and a digital logic for performing any of the above method related to the AIoT device. In addition, the AIoT device may further include a memory. The digital logic may comprise a controller.

[0027] In some embodiments, there proposes a communication system. The communication system may comprise one or more of the network node, the AIoT reader, and the AIoT device.

[0028] In some embodiments, there proposes a computer readable medium comprising computer readable code, which when run on an apparatus, causes the apparatus to perform any of the above method.

[0029] In some embodiments, there proposes a computer readable product comprising computer readable code, which when run on an apparatus, causes the apparatus to perform any of the above method.

[0030] The embodiments may allow the AIoT device in a disabled status to be enabled, by the enable requests from the application function.

[0031] The embodiments may provide capability for temporary disable, permanent disable and enable requests from the application function.

[0032] The embodiments may further provide an automatic enable function with a timer, so that the devices can be temporarily disabled for a period and then enabled again. In this way, the application function does not have to send enable service operation to enable those temporary disabled devices.Brief Description of the Drawings

[0033] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments of the present disclosure and, together with the description, further serve to explain the principles of the disclosure and to enable a person skilled in the pertinent art to make and use the embodiments disclosed herein. In the drawings, like reference numbers indicate identical or functionally similar elements, and in which:

[0034] Figure 1 is a schematic diagram showing an 5G architecture to support Ambient IoT, in which the embodiments herein may be implemented;

[0035] Figure 2 is a schematic diagram showing another 5G architecture to support Ambient IoT, in which the embodiments herein may be implemented;

[0036] Figure 3 is a schematic signaling chart showing the messages for enabling / disabling AIoT device (s) , according to the embodiments herein;

[0037] Figure 4 is a schematic flow chart showing an example method in the network node providing AIoT service, according to the embodiments herein;

[0038] Figure 5 is a schematic flow chart showing another example method in the network node providing AIoT service, according to the embodiments herein;

[0039] Figure 6 is a schematic flow chart showing an example method in the AIoT reader, according to the embodiments herein;

[0040] Figure 7 is a schematic flow chart showing another example method in the AIoT reader, according to the embodiments herein;

[0041] Figure 8 is a schematic flow chart showing an example method in the AIoT device, according to the embodiments herein;

[0042] Figure 9 is a schematic flow chart showing another example method in the AIoT device, according to the embodiments herein;

[0043] Figure 10 is a schematic flow chart showing an example method in the network node implementing network exposure function, according to the embodiments herein;

[0044] Figure 11 is a schematic flow chart showing an example method in the network node implementing application function, according to the embodiments herein;

[0045] Figure 12 is a schematic flow chart showing yet another example method in the network node providing AIoT service, according to the embodiments herein;

[0046] Figure 13 is a schematic block diagram showing an example network node providing AIoT service, according to the embodiments herein;

[0047] Figure 14 is a schematic block diagram showing an example AIoT reader, according to the embodiments herein;

[0048] Figure 15 is a schematic block diagram showing an example AIoT device, according to the embodiments herein;

[0049] Figure 16 is a schematic block diagram showing an example network node implementing network exposure function, according to the embodiments herein;

[0050] Figure 17 is a schematic block diagram showing an example network node implementing application function, according to the embodiments herein;

[0051] Figure 18 is a schematic block diagram showing an example communication system, according to the embodiments herein; and

[0052] Figure 19 is a schematic block diagram showing an example computer-implemented apparatus, according to the embodiments herein.Detailed Description of Embodiments

[0053] Embodiments herein will be described in detail hereinafter with reference to the accompanying drawings, in which embodiments are shown. These embodiments herein may, however, be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein. The elements of the drawings are not necessarily to scale relative to each other.

[0054] Reference to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrase “in an embodiment” appearing in various places throughout the specification are not necessarily all referring to the same embodiment.

[0055] As used in the description and the appended claims, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and / or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0056] As used throughout this description, and in the claims, a list of items joined by the term “at least one of” or “one or more of” can mean any combination of the listed terms. For example, the phrase “at least one of A, B or C” can mean A; B; C; A and B; A and C; B and C; or A, B and C.

[0057] Figure 1 is a schematic diagram showing an 5G architecture to support Ambient IoT, in which the embodiments herein may be implemented. Figure 2 is a schematic diagram showing another 5G architecture to support Ambient IoT, in which the embodiments herein may be implemented.

[0058] In the architectures shown in Figures 1 and 2, the AIoT Function (AIOTF) 103 may enable / disable the AIoT device 101 via the AIoT reader 102 or 202, once a respective service operation request is received from the Application Function (AF) 105 via the Network Exposure Function (NEF) 102.

[0059] Note that, the AIOTF 103 shown in Figures 1 and 2 is an example of a network node providing AIoT service, such as executing the AIoT service request (e.g. inventory, read) in the network and handle any corresponding AIoT specific NAS messages, supporting inventory and message routing for AIoT devices 101, authorizing the AIoT service request, performing validation of the AIoT device Identifier (ID) and secure AIoT device operations if needed, collecting AIoT data and aggregating the reporting, and collecting charging information if required. The network node providing AIoT service may also be referred for example as Ambient IoT Management Function (AIoTMF) , Ambient IoT Control Function (AIoTCF) , Ambient IoT Controller, AIoTF, etc.

[0060] The Unified Data Management (UDM) 106 may manage subscription-like information for AIoT devices and service control information for third party application:

[0061] - An AIoT device ID is allocated to each AIoT device that has subscription-like information provisioned in the UDM. The AIoT device ID shall be unique within a mobile network, and it is used to locate the subscription-like information.

[0062] - The subscription-like information for an AIoT device is different from the UE subscription data. The subscription-like information contains: AIoT device ID, security materials, and device status information e.g. last serving reader node, whether the AIoT device is disabled, etc.

[0063] - As part of a provisioning process for an AIoT device, the AIoT device is provided with its AIoT device ID, security materials and security settings which control what operations on which memory regions require what levels of security to be applied.

[0064] - The service control information is used to authorize the AF's device operation request. The service control information, based on service agreements between the network operator and the 3rd party AF, may contain: AF ID, allowed service area, allowed service operations, allowed AIoT device ID information etc.

[0065] The NEF 104 may expose the 5GS AIoT capability so as to allow third party AF 105 to consume the AIoT services.

[0066] Note that, from AIoT device point of view, the interfaces with the network are the same for both Figure 1 and 2.

[0067] Note that, instead of UDM 106, Authentication Server Function (AUSF) 108 and / or the AAA server 107 which is external to 5GC, may manage subscription-like information for AIoT devices including device credentials and service control information for the third party.

[0068] Figure 3 is a schematic signaling chart showing the messages for enabling / disabling AIoT device (s) , according to the embodiments herein. Figure 3 may be applicable to the architecture in both Figure 1 and Figure 2.

[0069] In an embodiment, the signaling chart in Figure 3 may include the following messages or steps:

[0070] Step 1. the AF 105 may send AIoT service operation request to the NEF 104, carrying at least one of the AF ID, device information, and reporting control information.

[0071] The device information may include one or more of the following:

[0072] - device area information, indicating the requested area where the inventory service will be performed.

[0073] - device filter information, indicating complete or partial of third party-defined Identifier, and being used to compose the MASK used in step 5 to filter the AIoT device (s) 101 to be inventoried.

[0074] Note that, the MASK may be a full or partial AIoT device ID, which will be broadcasted by a reader in order to select a specific group of AIoT devices to perform random access and report their device IDs to the network. The AIoT device whose device ID matches the MASK will perform random access to report the device ID. This MASK can also reflect the information fully or partially of a third Party-defined Identifier as described in step 3 and step 5 of Figure 3.

[0075] The reporting control information indicates when and how to send the reports, e.g. immediate reporting of new result or progress, periodic reporting, one-time reporting at the end of the AIoT service procedure, and it can also indicate to report cached data along with the AIoT device ID etc.

[0076] The AIoT service operation may be AIoT_Inventory service operation, AIoT_Read service operation, or AIoT_Write service operation, or may be AIoT_Temporary_Disable service operation, AIoT_Permanent_Disable service operation, or AIoT_Enable service operation. If the AIoT service operation is AIoT_Read or AIoT_Write service operation. The AIoT service operation may additionally include the AIoT device operation related parameters (e.g., memory location to start, length to read / write or data to write) . If the AIoT service operation is AIoT_Temporary_Disable or AIoT_Permanent_Disable service operation, the AIoT service operation may additionally include the disable related parameters (e.g., signature and password) . The parameters for AIoT_Permanent_Disable could be more different from AIoT_Temporary_Disable. AIoT devices and network (AIOTF 103 or NEF 104) may have more restrict check if it is a permanent disable.

[0077] For AIoT_Temporary_Disable service operation, an optional timer may be provided, indicating the devices can be automatically enabled after the timer expires.

[0078] The NEF 104 may expose temporary disable service operation, permanent disable service operation and enable service operations to allow the devices to be temporarily disabled, permanent disabled and enabled.

[0079] The AIOTF 103 may expose temporary disable, permanent disable and enable service operations for temporary / permanent disabling and enabling AIoT devices.

[0080] For the service operations exposed by NEF 104 and AIOTF 103, there may be a several of forms.

[0081] In an example, the NEF or service operation can be designed as the table 1 below. Note that, the same logic applies to the AIOTF 103.

[0082] Table 1: AIoT Service provided by NEF or AIOTF

[0083] In an example, it is possible to combine temporary disable and permanent disable into one service operation and use one parameter to differentiate whether it is for temporary or permanent.

[0084] In this case, the NEF service operation can be designed as the table 2 below. In Disable service operation, there is a parameter (e.g., named as “temporaryOrPermanent” ) to differentiate it is a temporary disable request or permanent disable request from AF

[0085] Table 2: AIoT Service provided by NEF or AIOTF

[0086] In an example, it is possible to combine temporary disable, permanent disable and enable service operations into one, but use one or two parameters to differentiate (e.g., a parameter for enable or disable, another parameter for temporary disable or permanent disable in case the former parameter is set to “disable” ) .

[0087] In this case, the NEF service operation can be designed as the table below 3. The all three request is combined into an Enable_Disable service operation, there can be one parameter (e.g., named as “enableOrDisable” ) to differentiate enable or disable request, while another one (e.g., named as “temporaryOrPermanent” ) to differentiate it is a temporary operation or permanent operation.

[0088] Table 3: AIoT Service provided by NEF or AIOTF

[0089] In an example, it is possible to separate the cases as permanent service operation and temporary service operation but use one parameter to differentiate whether it is for enable or disable.

[0090] In this case, the NEF service operation can be designed as the table 4 below. TemporaryCmd and PermanentCmd service operations are provided. For those two service operations, there is a parameter (e.g., named as “enableOrDisable” ) to differentiate whether it is for enable or disable request) .

[0091] Table 4: AIoT Service provided by NEF or AIOTF

[0092] Step 2. The NEF 104 may invoke Network Repository Function (NRF) to discover and select the AIOTF (s) 103 using the AF requested device area information. The NRF may determine the target AIOTF (s) 103 based on the AF requested device area information and the AIoT information of the registered AIOTF 103.

[0093] Step 3. The NEF 104 may perform the permission control of the AIoT service operation request based on the operator policy, service agreement between the AF 105 and the operator, and the information obtained from the UDM 106, e.g., based on service area which allows the AF 105 to request the service operation, or subscribed service operation (s) that allows the AF 105 to invoke. If not authorized, the AIOTF 103 may reject the AIoT service operation request with an appropriate cause code.

[0094] Step 4. The NEF 104 may send the AIoT service operation request to each of the selected AIOTF 103. The AIOTF 103 may obtain the service control information from the UDM 106.

[0095] Step 5. The AIOTF 103 may perform the permission control of the AIoT service operation request based on the operator policy, service agreement between the AF 105 and the operator, and information obtained from the UDM 106, e.g. based on service area which allows the AF 105 to request the service operation, or subscribed service operation (s) that allows the AF 105 to invoke. If not authorized, the AIOTF 103 may reject the AIoT service operation request with an appropriate cause code.

[0096] If the AIoT service operation is AIoT_Temporary_Disable, AIoT_Permanent_Disable or AIoT_Enable service operation, the AIOTF 103 may additionally determine the AIoT devices 101 that have subscription-like information in UDM 106 / AAA 107 / AUSF 108 and match with the device information. For example, for AIoT_Temporary_Disable, it may be applied to the devices in "enabled" state. For example, for AIoT_Permanent_Disable, it may be applied when the devices are not in "permanent disabled" state. For example, for AIoT_Enable, it may be applied to the devices in "temporary disabled” state.

[0097] Step 6. The AIOTF 103 may send service operation response to the NEF 104.

[0098] Step 7. The NEF 104 may send the AIoT service operation response to the AF 105, containing the accept or reject result for the AIoT service operation request.

[0099] Step 8. The AIOTF 103 and NG-RAN may select the reader (s) 102 or 202. It can be AIOTF 103 or NG-RAN to determine; in both cases the AIOTF 103 may provide assistant information to NG-RAN to determine the (UE) reader 102 or 202, or AIOTF 103 provide candidate (UE) readers 102 or 202 and let NG-RAN to return the decided UE readers 202.

[0100] Step 9. For each of the selected reader, the AIOTF 103 may send the Inventory Start or Inventory Request message. For RAN reader, the message is delivered over Next Generation Application Protocol (NGAP) or another Application Protocol between RAN and Core Network (XXAP) . For UE reader 202, the message can be delivered over UE NAS message via AMF and NG-RAN, or delivered over NGAP or XXAP from AIOTF 103 to NG-RAN (possible via AMF) and then over RRC from NG-RAN to UE 202.

[0101] If the AIOTF 103 receives the AIoT_Read or AIoT_Write or AIoT_Temporary_Disable or AIoT_Permanent_Disable or AIoT_Enable service operation request, the Inventory Start or Inventory Request message may additionally include the indication that transfer of AIoT NAS Command message subsequently.

[0102] If no "command indication" is received, the reader 102 or 202 will continue to the next matched AIoT device and step 14 -step 17 are skipped.

[0103] For AIoT_Enable service operation, the AIOTF may include an indicator to indicate that a response from an AIoT device 101 in a disabled status is required. For example, a "require disabled devices" flag may be included in the Inventory Start of Inventory Request message towards UE / RAN readers 102 or 202, to inform the AIoT device 101 in a disabled status to respond.

[0104] The Inventory Start or Inventory Request message may be targeted to a specific AIoT device 101, in this case the device ID of the specific AIoT device 101 may be included in the Inventory Start or Inventory Request message. The "require disabled devices" flag may be also included in the Inventory Start or Inventory Request message to inform the specific AIoT device 101 to respond. Then, when receiving the Inventory Start or Inventory Request message, the AIoT device 101 may selectively respond, if it needs to be enabled.

[0105] Alternatively, the Inventory Start or Inventory Request message may be targeted to one or more AIoT devices 101 within a group of AIoT devices, in this case the group ID of the specific AIoT device 101 may be included in the Inventory Start or Inventory Request message. The "require disabled devices" flag may be also included in the Inventory Start or Inventory Request message to inform these AIoT device 101 to respond. Then, when receiving the Inventory Start or Inventory Request message, the AIoT device 101 may selectively respond, if it needs to be enabled. That is, the AIoT device 101 may not respond, if it is not the target for enabling command.

[0106] In an example, the "require disabled devices" flag is directed to "temporarily disabled" devices, that is only "temporarily disabled" devices need to respond.

[0107] Alternatively, the "require disabled devices" flag may be directed to both "temporarily disabled" devices and "permanent disabled" devices, that is both "temporarily disabled" devices and "permanent disabled" devices need to respond. In this case, another flag "require permanent disabled devices" may be additionally or alternatively used.

[0108] Note that, the Inventory Start or Inventory Request message, whether it includes "require disabled devices" flag may be applicable to all AIoT devices. That is, this message is not limited to "temporarily disabled" devices. The AIoT devices 101 may selectively respond to this message, let the AIOTF 103 to decide which AIoT devices 101 need to be enabled.

[0109] Step 10. Upon reception of the Inventory Start or Inventory request message, the UE / RAN reader 102 or 202 may execute inventory Task by triggering the Paging-like procedures. If "require temporary disabled devices" is received from the AIOTF 103, UE / RAN reader 102 or 202 may include the flag within the Paging-like message.

[0110] Step 11. If an AIoT device 101 matches the device information, the AIoT device 101 may perform random access like procedures to establish the AS connection with RAN. For permanent disabled devices, these devices may not perform random access like procedure and the following procedures. For temporary disabled devices, they may perform random access like procedure and the following procedures when the "require temporary disabled devices” flag received.

[0111] Step 12. The AIoT device 101 may send its AIoT device ID in AIoT Inventory Response NAS message.

[0112] The AIoT Inventory Response NAS message is encapsulated within the A-Uu message sent to UE / RAN reader 102 or 202, and the UE / RAN reader 102 or 202 may relay the AIoT Inventory Response NAS message towards the AIOTF 103.

[0113] Step 13. The AIOTF 103 may perform validation based on the device subscription-like information received from the UDM 106 / AAA 107 / AUSF 108, including device ID validation. The AIOTF 103 may trigger authentication towards the devices 101. The AIOTF 103 may update the device status for this AIoT device 101 in the UDM 106 / AAA 107 / AUSF 108, e.g. last serving node.

[0114] If the device status indicates "permanent disabled” or if the device status is "temporarily disabled" but the command is not for enabling the device, the AIOTF 103 may discard the response from the device and subsequent steps are not pursued for this AIoT device 101.

[0115] Step 14. [Conditional] If the AIoT service operation is AIoT_Read or AIoT_Write or AIoT_Temporary_Disable or AIoT_Permanent_Disable or AIoT_Enable service operation, the AIOTF 103 may construct the corresponding AIoT Command NAS messages (e.g. AIoT Read Service Request NAS message, AIoT Write Service Request NAS message, AIoT Permanent Disable Service Request NAS message, AIoT Temporary Disable Service Request NAS message, AIoT Enable Service Request NAS message) , and the AIoT device operation command related parameters are included in the AIoT Command NAS message.

[0116] For AIoT Temporary Disable Service Request NAS message, a timer may be included if AIOTF 103 has received. The timer can be omitted, if the device is not capable of handling timer.

[0117] The AIOTF 103 may send the AIoT Command NAS message to the AIoT device 101. This AIoT Command NAS message is sent to UE / RAN reader 102 or 202, and then the AIoT Command NAS message is relayed by UE / reader 102 or 202 to the AIoT device 101.

[0118] Step 15. [Conditional] If the AIoT device 101 receives an AIoT Command NAS message (e.g., Read Service Request, Write Service Request, Temporary Disable Service Request, Permanent Disable Service Request, Enable Service Request) , the AIoT device 101 may generate the results of the AIoT device operation command and send the AIoT Command Service Accept or Reject NAS message to AIOTF depending on whether the command was successful or not. The results (including appropriate cause value if failed) of the AIoT device operation command are carried as payload of the AIoT Command Service Accept or Reject NAS message. The AIoT NAS message may be sent to RAN / UE reader 102 or 202 and then the AIoT NAS message is relayed by UE / RAN reader 102 or 202 to the AIOTF 103.

[0119] If the AIoT device 101 receives the AIoT Temporary Disable Service Request NAS message or AIoT Permanent Disable Service Request NAS message, the AIoT device 101 may perform validation with the received password. For AIoT Temporary Disable Service Request NAS message, if the timer is received, the AIoT device 101 may disable itself temporarily for the timer period. After the timer expires, the AIoT device 101 may set itself to enabled again.

[0120] Step 16. [Conditional] If the AIoT service operation is AIoT_Read or AIoT_Write or AIoT_Temporary_Disable service operation or AIoT_Permanent_Disable service operation or AIoT_Enable service operation, and when the AIOTF 103 completes the device operation on the selected AIoT device, the AIOTF 103 may send the Inventory Continue message to the UE / RAN reader 102 or 202. Upon reception of this message, the UE / RAN reader 102 or 202 may continue looking for next matched AIoT device 101.

[0121] Step 17. [Conditional] If the AIoT service operation is AIoT_Temporary_Disable service operation or AIoT_Permanent_Disable service operation or AIoT_Enable service operation, and when the operation is completed successfully for one AIoT device 101, the AIOTF 103 may set the device status of this AIoT device in UDM 106 / AAA 107 / AUSF 108 to temporarily disabled, permanently disabled (or remove the device data) or enabled accordingly.

[0122] If the AIoT service operation is for AIoT_Temporary_Disable service operation and a timer has been received from the AF 105, and if the target device is not capable of running a timer, the AIOTF 103 may start the timer on behalf of the devices 101. When the timer expires, the AIOTF may trigger step 10 and construct the AIoT Enable Service Request message and deliver towards the responded devices 101, as if it receives a AIoT_Enable service operation from the AF 105. The AIOTF 103 may keep a common timer for all temporary disabled devices 101 in this service operation.

[0123] Step 18. [Conditional] If the reporting control information matches (e.g. immediate reporting of new result or progress, periodic reporting) , the AIOTF 103 may report the AIoT device ID (s) , results of the AIoT device operation command and if available to the NEF 104 by sending the AIoT_Notify message (list of device IDs, results of the AIoT device operation command) . The NEF 104 may forward the received information to the AF 105 by sending the AIoT_Notify message.

[0124] The UE / RAN reader 102 or 202 may repeat steps 11～18 if there is a next matched AIoT device 101.

[0125] Step 19. The UE / RAN reader 102 or 202 sends the Inventory Complete message (Task ID) to the AIOTF 103 in case of e.g. there is no further AIoT device 101 performing random access, or the AIOTF 103 may proactively send the Inventory Complete NGAP message (Task ID) to the RAN / reader 102 or 202 in case of e.g. all targeted AIoT device (s) have been inventoried. The UE / RAN reader 102 or 202 may confirm the Task indicated by Task ID is completed.

[0126] Alternatively, in another example, the UE / RAN reader 102 or 202 may indicate the inventory complete as a parameter in the response for the last device report, so that there is no need to have a dedicated message in the step 19 for the complete indication.

[0127] Step 20. The AIOTF 103 may complete the Task for AIoT service operation request for each selected UE / RAN reader 102 or 202. The AIOTF 103 may report the progress of the AIoT service operation request to the NEF 104 by sending the AIoT_Notify message, the NEF 104 may inform the AF 105 of the progress of the AIoT_Inventory request by sending the AIoT_Notify message.

[0128] Figure 4 is a schematic flow chart showing an example method 400 in the network node providing AIoT service, according to the embodiments herein. In an embodiment, the flow chart in Figure 4 may be implemented in the AIOTF 103.

[0129] The method 400 may begin with step S401, in which the network node providing AIoT service may transmit a first message to an AIoT reader, such as RAN reader 102 and UE reader 202, as shown in the step 9 of Figure 3. The first message may be an inventory request message. The first message may include a first indicator indicating that a response from an AIoT device in a disabled status is required.

[0130] The first message may be targeted to a specific AIoT device or one or more AIoT devices within a group of AIoT devices. When the first message is targeted to a specific AIoT device, the first message may include an AIoT device ID of the AIoT device. When the first message is targeted to one or more AIoT devices within a group of AIoT devices, the first message may include group information of the group of AIoT devices.

[0131] The first message may be targeted to the AIoT device in a temporary disabled status or in a permanently disabled status. When the first message is targeted to the AIoT device in a permanently disabled status, the first message may further include a second indicator indicating that a response from the AIoT device in the permanently disabled status is required. In other embodiments, the first message may otherwise indicate that a response from the AIoT device in the permanently disabled status is required.

[0132] For the architecture of Figure 1, in which the AIoT reader is a Radio Access Network (RAN) reader, the first message may be transmitted over Next Generation Application Protocol (NGAP) or another Application Protocol between Radio Access Network (RAN) and Core Network.

[0133] For the architecture of Figure 2, in which the AIoT reader is a User Equipment (UE) reader, the first inventory request message may be transmitted over UE Non-Access Stratum (NAS) message via Access and Mobility Management Function (AMF) and Next Generation Radio Access Network (NG-RAN) , or delivered over NGAP or another Application Protocol between RAN and Core Network from the network node providing AIoT service to the NG-RAN and then over Radio Resource Control (RRC) from NG-RAN to UE, or delivered over NGAP or another Application Protocol between RAN and Core Network from the network node providing AIoT service to the NG-RAN via AMF and then over RRC from NG-RAN to the UE reader.

[0134] Note that, the first message may be applicable to an AIoT device in any status, and is not limited to AIoT device in temporary disabled status. For example, the AIoT device in status other than temporary disabled may not respond to this message. Otherwise, the AIoT device in status other than temporary disabled may also respond to this message, and the network node providing AIoT service (such as AIOTF 103) may perform a filter on the device (s) .

[0135] Then, the method 400 may proceed to step S402, in which the network node providing AIoT service (such as AIOTF 103) may receive a second message indicating that the AIoT device is available, from the AIoT reader 102, 202, as shown in the step 12 of Figure 3.

[0136] In an embodiment, after receiving the second message, the network node providing AIoT service (such as AIOTF 103) may checking a device status of the AIoT device, based on device information of the AIoT device as defined in a network node providing user data management (such as a Unified Data Management (UDM) 106) , and / or a network node providing Authentication and / or Authorization (such as an Authentication, Authorization, and Accounting (AAA) server 107, and / or an Authentication Server Function (AUSF) (108) ) . For example, if the device status is a temporary disabled status, the network node providing AIoT service may decide to transmit the third message.

[0137] Then, the method 400 may proceed to step S403, in which the network node providing AIoT service (such as AIOTF 103) may transmit a third message for enabling the AIoT device, to the AIoT reader, as shown in the step 14 of Figure 3. The third message may be transmitted responsive to receiving the second message. The third message may be a command message for enabling the AIoT device.

[0138] Note that, the third message is not limited to enabling the AIoT device, it may be a message aim to permanently disable the AIoT device, temporarily disable the AIoT device, or enable the AIoT device.

[0139] In addition, the network node providing AIoT service (such as AIOTF 103) may update the device status of the AIoT device in a network node providing user data management (such as the UDM 106) , and / or a network node providing Authentication and / or Authorization (such as the AAA server 107 and / or the AUSF 108) . There are two options. That is, the network node providing AIoT service (such as AIOTF 103) may update the device status of the AIoT device, after sending the third message or after receiving the response of the third message. For example, the device status of the AIoT device may be updated as "enabled" , if the response of the third message shows that the AIoT device is enabled.

[0140] The above steps are only examples, and the network node providing AIoT service may perform any related actions described with respect to Figures 1 to 3.

[0141] Figure 5 is a schematic flow chart showing another example method 500 in the network node providing AIoT service, according to the embodiments herein. In an embodiment, the flow chart in Figure 5 may be implemented in the AIOTF 103.

[0142] The method 500 may begin with step S501, in which the network node providing AIoT service (such as the AIOTF 103) may transmit, to an AIoT reader, a fourth message for one of: temporarily disabling an AIoT device, permanently disabling an AIoT device, and enabling an AIoT device, as shown in the step 14 of Figure 3.

[0143] Note that, before transmitting the fourth message, the network node providing AIoT service (such as the AIOTF 103) may transmit an Inventory request message to the targeted AIoT device (s) , and then transmit the fourth message (such as the command message) , responsive to receiving a response from the targeted AIoT device (s) .

[0144] In an embodiment, the fourth message is for temporarily disabling the AIoT device. In this case, the fourth message may further comprise a timer indicating an AIoT device temporarily disabled is to be enabled after the timer expires.

[0145] Then, the method 500 may proceed to step S502, in which the network node providing AIoT service (such as AIOTF 103) may determine whether the AIoT device is capable of running a timer.

[0146] If the AIoT device is capable of running a timer, then in step S503, the network node providing AIoT service (such as AIOTF 103) may also run the timer itself, and after the timer expires, updating a device status of the AIoT device as defined in a network node providing user data management (such as the UDM 106) , and / or a network node providing Authentication and / or Authorization (such as the AAA server 107 and / or the AUSF 108) , in response to the AIoT device is enabled.

[0147] If the AIoT device is not capable of running a timer, then in step S503, the network node providing AIoT service (such as AIOTF 103) may running the timer instead of the AIoT device 101. Then, after the timer expires, the network node providing AIoT service (such as AIOTF 103) may enable the AIoT device 101 via the flowchart in Figure 4. For example, the network node providing AIoT service (such as AIOTF 103) may transmit, to the AIoT reader, a fifth message including a first indicator indicating that a response from an AIoT device in a disabled status is required; and transmitting, to the AIoT reader, a sixth message to enable the AIoT device. Then, the network node providing AIoT service (such as AIOTF 103) may update a device status of the AIoT device as defined in a network node providing user data management (such as the UDM 106) , and / or a network node providing Authentication and / or Authorization (such as the AAA server 107 and / or the AUSF 108) , after receiving from the AIoT reader a response indicating that the AIoT device is enabled.

[0148] The above steps are only examples, and the network node providing AIoT service may perform any related actions described with respect to Figures 1 to 3.

[0149] Figure 6 is a schematic flow chart showing an example method 600 in the AIoT reader, according to the embodiments herein. In an embodiment, the flow chart in Figure 6 may be implemented in the AIoT RAN reader 102 or UE reader 202.

[0150] The method 600 may begin with step S601, in which the AIoT reader 102 or 202 may receive, from a network node providing AIoT service, a first message, as shown in the step 9 of Figure 3.

[0151] Then, the method 600 may proceed to step S602, in which the AIoT reader 102 or 202 may transmit, to the AIoT device, a first paging-like message including the indicator, in response to determining the first message includes an indicator indicating that a response from an AIoT device in a disabled status is required, as shown in the step 10 of Figure 3.

[0152] Then, the method 600 may proceed to step S603, in which the AIoT reader 102 or 202 may receive, from the network node providing AIoT service, a third message for enabling the AIoT device, as shown in the step 14 of Figure 3.

[0153] Then, the method 600 may proceed to step S604, in which the AIoT reader 102 or 202 may transmit, to the AIoT device, the third message, as also shown in the step 14 of Figure 3.

[0154] Then, the method 600 may also comprise other steps not shown, such as the AIoT reader 102 or 202 may indicate, to the network node providing AIoT service, a completion of the inventory, as also shown in the step 12 of Figure 3.

[0155] The above steps are only examples, and the AIoT reader may perform any related actions described with respect to Figures 1 to 3.

[0156] Figure 7 is a schematic flow chart showing another example method 700 in the AIoT reader, according to the embodiments herein. In an embodiment, the flow chart in Figure 7 may be implemented in the AIoT RAN reader 102 or UE reader 202.

[0157] The method 700 may begin with step S701, in which the AIoT reader 102 or 202 may receive, from a network node providing AIoT service, a fourth message for one of: temporarily disabling the AIoT device, permanently disabling the AIoT device, and enabling the AIoT device, as shown in the step 14 of Figure 3.

[0158] Then, the method 700 may proceed to step S702, in which the AIoT reader 102 or 202 may transmit, to the AIoT device, the fourth message, as also shown in the step 14 of Figure 3.

[0159] In an embodiment, the fourth message is for temporarily disabling the AIoT device. In this case, the fourth message may further comprise a timer indicating an AIoT device temporarily disabled is to be enabled after the timer expires.

[0160] In an embodiment, if the AIoT device is not capable of running a timer, then the network node providing AIoT service (such as AIOTF 103) may running the timer instead of the AIoT device 101. Then, after the timer expires, the network node providing AIoT service (such as AIOTF 103) may enable the AIoT device 101 via the flowchart in Figure 4. In this case, the AIoT reader 102 or 202 may receive, from the network node providing AIoT service, a fifth message; in response to determining the fifth message includes a first indicator indicating that a response from an AIoT device in a disabled status is required, transmit, to the AIoT device, a second paging-like message including the first indicator; receive, from the network node providing AIoT service, a sixth message for enabling the AIoT device; and transmit, to the AIoT device, the sixth message.

[0161] The above steps are only examples, and the AIoT reader may perform any related actions described with respect to Figures 1 to 3.

[0162] Figure 8 is a schematic flow chart showing an example method 800 in the AIoT device, according to the embodiments herein. In an embodiment, the flow chart in Figure 8 may be implemented in the AIoT device 101.

[0163] The method 800 may begin with step S801, in which the AIoT device 101 may receive, from an AIoT reader 102 or 202, a first paging-like message including a first indicator indicating that a response from an AIoT device in a disabled status is required, as shown in the step 10 of Figure 3.

[0164] Then, the method 800 may proceed to step S802, in which the AIoT device 101 may handle the first paging-like message accordingly. For example, the AIoT device is in temporary disabled status, the AIoT device may perform a random access like procedure, as shown in the step 11 of Figure 3; and / or send out its device ID, as shown in the step 12 of Figure 3. For example, the AIoT device may omit the first paging-like message. As an example, the AIoT device may omit the first paging-like message, if the AIoT device is permanently disabled.

[0165] The above steps are only examples, and the AIoT device may perform any related actions described with respect to Figures 1 to 3.

[0166] Figure 9 is a schematic flow chart showing another example method 900 in the AIoT device, according to the embodiments herein. In an embodiment, the flow chart in Figure 8 may be implemented in the AIoT device 101.

[0167] The method 900 may begin with step S901, in which the AIoT device 101 may receive, from the AIoT reader, a fourth message for one of: temporarily disabling the AIoT device, permanently disabling the AIoT device, and enabling the AIoT device, as shown in the step 14 of Figure 3.

[0168] Then, the method 900 may proceed to step S902, in which the AIoT device 101 may handle the fourth message accordingly. For example, the fourth message is for temporarily disabling the AIoT device, the fourth message may further include a timer, and the AIoT device is capable of running a timer. In this case, the AIoT device 101 may run the timer; and enable the AIoT device, after the timer expires. That is, the AIoT device 101 may enable itself automatically, without waiting enabling command from the AIoT reader 102, 202.

[0169] The above steps are only examples, and the AIoT device may perform any related actions described with respect to Figures 1 to 3.

[0170] Figure 10 is a schematic flow chart showing an example method 1000 in the network node implementing network exposure function, according to the embodiments herein. In an embodiment, the flow chart in Figure 10 may be implemented in the NEF 104.

[0171] The method 1000 may begin with step S1001, in which the NEF 104 may receive, from a network node implementing an application function (such as AF 105) , an AIoT service operation request message, for requesting one of an AIoT temporary disable service operation, an AIoT permanent disable service operation, and an AIoT enable service operation, as shown in the step 1 of Figure 3.

[0172] Then, the method 1000 may proceed to step S1002, in which the NEF 104 may transmit, to a network node providing AIoT service (such as the AIOTF 103) , the AIoT service operation request message.

[0173] In an embodiment, the AIoT service operation request message for requesting the AIoT temporary disable service operation may further include a timer indicating an AIoT device temporarily disabled is to be enabled after the timer expires, either for step S1001 or step S1002.

[0174] In an embodiment, the AIoT service operation request message may be one of an AIoT temporary disable service operation request message for requesting the AIoT temporary disable service operation, an AIoT permanent disable service operation request message for requesting the AIoT permanent disable service operation, and an AIoT enable service operation request message for requesting the AIoT enable service operation.

[0175] In an embodiment, the AIoT service operation request message may be one of an AIoT disable service operation request message for requesting an AIoT disable service operation and an AIoT enable service operation request message for requesting the AIoT enable service operation request. The AIoT disable service operation request message may include a third indicator indicating whether the AIoT disable service operation is the AIoT temporary disable service operation or the AIoT permanent disable service operation.

[0176] In an embodiment, the AIoT service operation request message may be an AIoT enable_disable service operation request message for requesting an AIoT enable_disable service operation. The AIoT enable_disable service operation request message may include a fourth indicator indicating whether the AIoT enable_disable service operation is the AIoT enable service operation or an AIoT disable service operation, and a fifth indicator indicating whether the AIoT disable service operation is the AIoT temporary disable service operation or the AIoT permanent disable service operation.

[0177] In an embodiment, the AIoT service operation request message may be an AIoT temporary service operation request message for requesting an AIoT temporary service operation or an AIoT permanent service operation request message for requesting an AIoT permanent service operation. The AIoT temporary service operation request message may include a sixth indicator indicating whether the AIoT temporary service operation is the AIoT enable service operation or the AIoT temporary disable service operation; and the AIoT permanent service operation request message may include a seventh indicator indicating whether the AIoT permanent service operation is the AIoT enable service operation or the AIoT permanent disable service operation.

[0178] In an embodiment, the NEF 104 may perform a permission control of the AIoT service operation request message, to decide whether to permit the requested AIoT temporary disable service operation, AIoT permanent disable service operation, or AIoT enable service operation, as shown in the step 3 of Figure 3.

[0179] The above steps are only examples, and the network node implementing network exposure function may perform any related actions described with respect to Figures 1 to 3.

[0180] Figure 11 is a schematic flow chart showing an example method 1100 in the network node implementing application function, according to the embodiments herein. In an embodiment, the flow chart in Figure 11 may be implemented in the AF 105.

[0181] The method 1100 may comprise a step S1101, in which the AF 105 may transmit, to a network node implementing network exposure function (such as NEF 104) , an AIoT service operation request message, for requesting one of an AIoT temporary disable service operation, an AIoT permanent disable service operation, and an AIoT enable service operation, as shown in the step 1 of Figure 3.

[0182] The above step is only an example, and the network node implementing application function may perform any related actions described with respect to Figures 1 to 3.

[0183] Figure 12 is a schematic flow chart showing yet another example method 1200 in the network node providing AIoT service, according to the embodiments herein. In an embodiment, the flow chart in Figure 12 may be implemented in the AIOTF 103.

[0184] The method 1200 may begin with step S1201, in which the network node providing AIoT service (such as the AIOTF 103) may receive, from a network node implementing network exposure function (such as the NEF 104) , an AIoT service operation request message, for requesting one of an AIoT temporary disable service operation, an AIoT permanent disable service operation, and an AIoT enable service operation, as shown in the step 4 of Figure 3.

[0185] Then, the method 1200 may proceed to step S1202, in which the network node providing AIoT service (such as the AIOTF 103) may determine an AIoT device targeted in the AIoT service operation request message. Note that, one or more AIoT devices may be determined.

[0186] Then, the method 1200 may proceed to step S1203, in which the network node providing AIoT service (such as the AIOTF 103) may acquire status of the AIoT device from a network node providing user data management (such as the UDM 106) , and / or a network node providing Authentication and / or Authorization (such as the AAA server 107 and / or the AUSF 108) . Then, the network node providing AIoT service (such as the AIOTF 103) may determine whether the status of the AIoT device matches the AIoT service operation request message.

[0187] Then, the method 1200 may proceed to step S1204, in which the network node providing AIoT service (such as the AIOTF 103) may transmit the AIoT service operation to an AIoT reader, if the status of the AIoT device matches the AIoT service operation request message. For example, the AIOTF 103) may transmit the AIoT service operation to an AIoT reader in an inventory and command manner, as described for the above first message and third message, and as shown in steps 9-16 of Figure 3.

[0188] For example, the status of the AIoT device matching the AIoT service operation request message further comprising: for the AIoT temporary disable service operation, the device information of the one or more AIoT devices shows that the one or more AIoT devices are in enabled state; for the AIoT permanent disable service operation, the device information of the one or more AIoT devices shows that the one or more AIoT devices are not in permanent disabled state; or for the AIoT enable service operation, the device information of the one or more AIoT devices shows that the one or more AIoT devices are in temporary disabled state.

[0189] Figure 13 is a schematic block diagram showing an example network node 1300 providing AIoT service, according to the embodiments herein. In an embodiment, the network node 1300 providing AIoT service in Figure 13 may be implemented as the AIOTF 103

[0190] In an embodiment, the network node 1300 providing AIoT service may comprise at least one processor 1301; and a non-transitory computer readable medium 1302 coupled to the at least one processor 1301. The non-transitory computer readable medium 1302 may contain instructions executable by the at least one processor 1301, whereby the at least one processor 1301 may be configured to perform any of the above methods 400, 500, 1200.

[0191] Note that, the network node 1300 providing AIoT service may be implemented as hardware, software, firmware and any combination thereof. For example, the network node 1300 providing AIoT service may include a plurality of units, logics, circuities, modules or the like, each of which may be used to perform one or more steps of the example methods 400, 500, 1200 or one or more steps shown in Figure 3 related to the network node providing AIoT service.

[0192] Figure 14 is a schematic block diagram showing an example AIoT reader 1400, according to the embodiments herein. In an embodiment, the AIoT reader 1400 in Figure 14 may be implemented as the AIoT RAN reader 102 or UE reader 202.

[0193] In an embodiment, the AIoT reader 1400 may comprise at least one processor 1401; and a non-transitory computer readable medium 1402 coupled to the at least one processor 1401. The non-transitory computer readable medium 1402 may contain instructions executable by the at least one processor 1401, whereby the at least one processor 1401 may be configured to perform any of the above methods 600, 700.

[0194] Note that, the AIoT reader 1400 may be implemented as hardware, software, firmware and any combination thereof. For example, the AIoT reader 1400 may include a plurality of units, logics, circuities, modules or the like, each of which may be used to perform one or more steps of the example methods 600, 700 or one or more steps shown in Figure 3 related to the AIoT reader.

[0195] Figure 15 is a schematic block diagram showing an example AIoT device 1500, according to the embodiments herein. In an embodiment, the AIoT device 1500 in Figure 15 may be implemented as the AIoT device 101.

[0196] In an embodiment, the AIoT device 1500 may comprise an energy harvester 1501 for harvesting energy; an energy storage 1502 for storing the harvested energy; and a digital logic 1503 for performing any of the above method related to the AIoT device.

[0197] In an embodiment, the digital logic 1503 may include functional blocks like encoder, decoder, controller, etc.

[0198] In an embodiment, the AIoT device 1500 may comprise a memory, for example the memory may include two types of memory: 1) Non-Volatile Memory (NVM) such as Electrically Erasable Programmable Read-Only Memory (EEPROM) for permanently storing device ID, etc., and 2) registers for temporarily keeping any information required for its operation while energy is available in energy storage.

[0199] In an embodiment, the AIoT device 1500 may comprise power management unit (PMU) , which manages storing energy to energy storage from energy harvester and supplying power to active component blocks which needs power supply.

[0200] In an embodiment, the AIoT device 1500 may comprise reception related blocks such as Band Pass Filter (BPF) for improving selectivity, envelope detector for converting radio frequency signal to baseband, and Low Pass Filter (LPF) for filtering out harmonics and high frequency components to improve input signal quality.

[0201] In an embodiment, the AIoT device 1500 may comprise transmission related blocks such as Backscatter modulator for switching impedance to modulate backscattered signal with transmitted signal from digital logic 1503.

[0202] Note that, the AIoT device 1500 may include a plurality of units, logics, circuities, modules or the like, each of which may be used to perform one or more steps of the example methods 700, 800 or one or more steps shown in Figure 3 related to the AIoT device; the details of the example AIoT device may be referred to 3GPP TR 38.769 V1.0.0, section 5, "Ambient IoT device architectures" .

[0203] Figure 16 is a schematic block diagram showing an example network node implementing network exposure function 1600, according to the embodiments herein. In an embodiment, the network node implementing network exposure function 1600 in Figure 16 may be implemented as the NEF 104.

[0204] In an embodiment, the network node implementing network exposure function 1600 may comprise at least one processor 1601; and a non-transitory computer readable medium 1602 coupled to the at least one processor 1601. The non-transitory computer readable medium 1602 may contain instructions executable by the at least one processor 1601, whereby the at least one processor 1601 may be configured to perform the above method 1000.

[0205] Note that, the network node implementing network exposure function 1600 may be implemented as hardware, software, firmware and any combination thereof. For example, the network node implementing network exposure function 1600 may include a plurality of units, logics, circuities, modules or the like, each of which may be used to perform one or more steps of the example method 1000 or one or more steps shown in Figure 3 related to the network node implementing network exposure function.

[0206] Figure 17 is a schematic block diagram showing an example network node implementing application function 1700, according to the embodiments herein. In an embodiment, the network node implementing application function 1700 in Figure 17 may be implemented as the AF 105.

[0207] In an embodiment, the network node implementing application function 1700 may comprise at least one processor 1701; and a non-transitory computer readable medium 1702 coupled to the at least one processor 1701. The non-transitory computer readable medium 1702 may contain instructions executable by the at least one processor 1701, whereby the at least one processor 1701 may be configured to perform the above method 1100.

[0208] Note that, the network node implementing application function 1700 may be implemented as hardware, software, firmware and any combination thereof. For example, the network node implementing application function 1700 may include a plurality of units, logics, circuities, modules or the like, each of which may be used to perform one or more steps of the example method 1100 or one or more steps shown in Figure 3 related to the network node implementing application function.

[0209] Figure 18 is a schematic block diagram showing an example communication system 1800, according to the embodiments herein.

[0210] In an embodiment, the communication system 1800 may comprise the example network node 1300 providing AIoT service, the example AIoT reader 1400, the example AIoT device 1500. In an embodiment, the communication system 900 may further comprise the network node implementing network exposure function 1600, and the network node implementing application function 1700.

[0211] In an embodiment, the communication system 1800 may be configured in an OTT scenario. The OTT connection may be transparent in the sense that the participating communication devices through which the OTT connection passes are unaware of routing of uplink and downlink communications.

[0212] It should also be understood that, a network element (such as the example network node 1300 providing AIoT service, the network node implementing network exposure function 1600, and the network node implementing application function 1700, the RAN reader 102) can be implemented either as a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., on a cloud infrastructure.

[0213] Figure 19 is a schematic block diagram showing an example computer-implemented apparatus 1900, according to the embodiments herein. In an embodiment, the apparatus 1900 may be configured as the above mentioned apparatus, such as the AIoT device 101, the AIoT reader 102, 202, the AIOTF 103, the NEF 104, and / or the AF 105.

[0214] In an embodiment, the apparatus 1900 may include but not limited to at least one processor such as Central Processing Unit (CPU) 1901, a computer-readable medium 1902, and a memory 1903. The memory 1903 may comprise a volatile (e.g., Random Access Memory, RAM) and / or non-volatile memory (e.g., a hard disk or flash memory) . In an embodiment, the computer-readable medium 1902 may be configured to store a computer program and / or instructions, which, when executed by the processor 1901, causes the processor 1901 to carry out any of the above mentioned methods.

[0215] In an embodiment, the computer-readable medium 1902 (such as non-transitory computer readable medium) may be stored in the memory 1903. In another embodiment, the computer program may be stored in a remote location for example computer program product 1904 (also may be embodied as computer-readable medium) , and accessible by the processor 1901 via for example carrier 1905.

[0216] The computer-readable medium 1902 and / or the computer program product 1904 may be distributed and / or stored on a removable computer-readable medium, e.g. diskette, CD (Compact Disk) , DVD (Digital Video Disk) , flash or similar removable memory media (e.g. compact flash, SD (secure digital) , memory stick, mini SD card, MMC multimedia card, smart media) , HD-DVD (High Definition DVD) , or Blu-ray DVD, USB (Universal Serial Bus) based removable memory media, magnetic tape media, optical storage media, magneto-optical media, bubble memory, or distributed as a propagated signal via a network (e.g. Ethernet, ATM, ISDN, PSTN, X. 25, Internet, Local Area Network (LAN) , or similar networks capable of transporting data packets to the infrastructure node) .

[0217] This disclosure also proposes the following embodiments / implements on FS_AmbientIoT. There proposes the conclusion on Key Issue #3 for Ambient IoT.

[0218] 1. Introduction

[0219] According to RAN SID (RP-240826) , there are type 1 and type 2 devices to be studied in Rel-19:

[0220] A. The overall objective shall be to study a harmonized air interface design with minimized differences (where necessary) for Ambient IoT to enable the following devices:

[0221] i. ～1 μW peak power consumption, has energy storage, initial sampling frequency offset (SFO) up to 10X ppm, neither DL nor UL amplification in the device. The device’s UL transmission is backscattered on a carrier wave provided externally.

[0222] ii. ≤ a few hundred μW peak power consumption1, has energy storage, initial sampling frequency offset (SFO) up to 10X ppm, DL and / or UL amplification in the device. The device’s UL transmission may be generated internally by the device, or be backscattered on a carrier wave provided externally.

[0223] [Observation-1] Type 1 devices are very power limited. Compared with type 1 devices, type 2 devices have much higher power.

[0224] In TSG RAN#105, there was some discussion regarding harmonized air interface design, the discussion conclusion is included in RP-242360:

[0225] Conclusion: RAN reiterates that “study a harmonized framework with minimized differences (where necessary) ” includes studying minimized differences (where necessary) between devices, e.g. for frequency synchronization between device 1 / 2a and device 2b, etc.

[0226] [Observation-2] TSG RAN clarifies the harmonized framework allow some differences between devices.

[0227] [Proposal-1] Based on [Observation-1] and [Observation-2] , in SA2, the solution framework also allow some differences between type 1 and type 2 devices. Studying actual differences in terms of system architecture and system functions needs cooperation with RAN WGs.

[0228] In TR 38.769, RAN2 is studying three use cases:

[0229] - Inventory-only;

[0230] - Inventory and Command;

[0231] - Command-only;

[0232] In our view, the three use cases in RAN2 can be mapped to the two procdeures (i.e., inventory, command) in SA2:

[0233] - Inventory-only: it is used in inventory procedure for all AIoT devices.

[0234] ○ For type 1 devices, the devices simply respond the inventory request with their device IDs.

[0235] ○ It is expected that there are no obstacles for type 2 devices to perform registration with the network, after responding with their device IDs. That is, there can be authentication and security parameter exchanges between the network and the devices, so that the network can allocate a CN Temp ID (similar as 5G-GUTI for UEs) towards the device. The type 2 device stores the security parameters and the CN Temp ID.

[0236] - Inventory and Command: according to TR 38.769, this is the baseline for device types 1 and 2, i.e. a concatenation of inventory and subsequent exchange of data between the AIoT device and the network. It is expected that type 1 devices are not able to optimise respective signalling on the AIoT air interface..

[0237] - Command-only: it is expected that there are no obstacles for type 2 devices to perform command-only procedures, omitting some steps as compared to “Inventory and Command” , see TR 38.769. The network use the allocated CN Temp ID to page the device and deliver the command to the device directly.

[0238] To support Command-only use case in RAN2, the network and the devices need to authenticate each other, exchange security parameters, and the network need to allocate a CN Temp ID towards the device. It is similar as the initial registration for the UEs, but can only be passively triggered by the network, as some type 2 devices (i.e., type 2a devices) are passive devices. Such “passive registration” can ensure the following command delivery to be executed in an efficient and secure way. However, it requires the “registered” devices to be able to write the received information (i.e., security parameters and CN Temp ID) into their NVMs.

[0239] [Proposal-2] It is proposed to differentiate the solutions for type 1 and type 2 devices. For type 1 devices, without being registered towards the network, the command delivery can only be achieved in an “inventory and command” manner. For type 2 devices, they can be registered towards the network in inventory, and thus the command delivery can be achieved in a “command-only” manner.

[0240] SA2 receives reply LS from RAN1 (R1-2407364) , RAN1 answered the question from SA2 about whether Ambient IoT device can update is NVM:

[0241] - An Ambient IoT device will be able to update its non-volatile memory at some point after receiving a trigger from the Reader. Writing may not always be possible at all times.

[0242] - The power consumption during writing to the NVM is higher than during reading.

[0243] - RAN1 thinks that frequent or recurring writing to NVM should be avoided.

[0244] - RAN1 has not discussed energy status and energy storage capabilities in relation to an Ambient IoT device ability to update its non-volatile memory.

[0245] [Observation-3] Based on the answer from RAN1, the ability of writing to a NVM is possible, RAN1 has not studied the cost in terms of necessary energy for such operation.

[0246] SA2 also receives a reply LS from SA1 (S1-242527) to further clarify the security and privacy requirements for AIoT devices:

[0247] Question 2: Do the requirements listed in clause 5.2.6 of TS 22.369 for privacy protection apply to any Ambient IoT device that need to be supported in Rel-19? If these requirements do not apply to all Ambient IoT devices, does this imply that such devices would be restricted to certain deployment scenarios?

[0248] Answer 2: All functional service requirements in chapter 5 in TS 22.369 are valid for all categories.

[0249] Question 3: Does command  / inventory response signaling, e.g. for sensor data collection or actuator control in TS 22.369 clause 4.3, need to generally be security protected (privacy, integrity and confidentiality protection) ?

[0250] Answer 3: All functional service requirement in chapter 5 in TS 22.369, including the security and privacy requirements in chapter 5.2.6 are valid for all categories regardless of use case.

[0251] [Observation-4] All the security and privacy requirements are valid for all type of devices, regardless the use case and the deployment.

[0252] Based on [Proposal-2] , [Observation-3] and [Observation-4] , in our view:

[0253] - For the type 1 devices, the extreme low power consumption restrict their functionalities. They may not be able to write to their NVMs during the procedure. And thus, the “registration” towards the network is unlikely to take place. Given such preliminary feedback from RAN1, SA1 requirements on security and yet to be awaited feedback from SA3, type 1 devices with low energy storage capabilities and high cost restrictions might not be able to fulfill basic requirements for operation within a 5G system.

[0254] -For type 2 devices, with much higher power consumption, they can be registered towards the network passively, and store the security parameters and CN Temp ID into their NVMs.

[0255] [Proposal-3] It is proposed to capture the dependency with SA3 about the discussion above

[0256] Inventory Procedure:

[0257] In inventory procedure, after the AIOTF receives inventory request from the AF (optionally via NEF) , it needs to distribute the request towards the proper readers. In topology 1, it needs to distribute towards proper A-IoT RAN nodes, and in topology 2, it needs to distribute towards proper NG-RAN nodes and further towards UE readers. The RAN reader and UE reader selection mechanism needs to be decided by SA2 and RAN3 jointly.

[0258] [Proposal-4] It is proposed to capture the RAN3 dependency in the EN.

[0259] For A-IoT paging for a group of devices, there are two options in TR 23.700-13 for the ID used:

[0260] - Option-1: Group ID

[0261] - Option-2: Device ID MASK information (including EPC with MASK) .Group ID requires additional information stored in NVM of the devices, besides the individual device ID. Device ID MASK information allows the network to reach a group of devices by masking some bits in the device ID, so that only the Device ID needs to be stored in the NVM of the devices. For type 1 devices, the less storage requirement would be more important. That is, Option-2 is recommended for type 1 devices.

[0262] On the other hand, the group ID bring more flexibility than the MASK. Using the MASK, the group size needs to be pre-determined. For example, if the AF uses the last 4 bits for a group of devices in the planning phase. In Device ID MASK information, the last 4 bits are masked. But after running for a period, there need to be the 17th device to be deployed, the MASK adjustment (e.g., needs to mask the last 5 bits) of this group may cause conflicts (e.g., some unintended devices respond the A-IoT paging due to the new MASK) . For flexibility consideration, Option-1 is recommended for type 2 devices.

[0263] And for both options, it is also up to SA3 to determine whether it will cause security / privacy concerns using Group ID and / or Device ID MASK information.

[0264] [Proposal-5] It is proposed to conclude the solutions discussed above, and capture the SA3 dependency in the EN.

[0265] In inventory procedure, after the reader triggers A-IoT paging, the devices need to respond their device IDs or truncated device IDs, if they are within the group or match the device MASK

[0266] information. Following the existing solutions in 5GS, the device ID needs to be concealed when there’s no mutual authentication between the network and the device. Are Ambient IoT devices able to perform the concealment, especially for type 1 devices? If not, is there a secured way to report the device ID towards the network? It is up to SA3 to determine.

[0267] [Proposal-6] It is proposed to capture the SA3 dependency in the EN.

[0268] Command Procedure:

[0269] For command procedure, AF request network to deliver the command to one or multiple devices (in an area) .

[0270] As discussed above, if the device can be registered to the network, the CN Temp ID can be used to reach the device and have the command delivery in “command-only” manner. There is no specific security / privacy conern.

[0271] Otherwise, the device ID needs to be used to reach the device and have the comment delivery in “inventory-command” manner. Different from inventory, the individual device ID is used directly without MASK information this time. There could be stronger security / privacy conern in this case. It is possible that AIOTF add several-bit MASK intendedly to reduce the security / privacy concern. Anyway, it is up to SA3 to determine.

[0272] [Proposal-7] It is proposed to capture the SA3 dependency in the EN.

[0273] In clause 5.2.3 of TS 22.369, SA1 put clear requirements on (temporary) disable, enable and permanent disable as a part of the management requirements:

[0274] The 5G system shall support a mechanism to:

[0275] - disable the capability to transmit RF signals for one or more Ambient IoT device that is  / are currently able to transmit RF signals

[0276] - enable the capability to transmit RF signals for one or more Ambient IoT device that is  / are currently disabled to transmit RF signals

[0277] Based on operator policy, the 5G system shall provide a suitable mechanism to permanently disable the capability of an Ambient IoT device or a group of Ambient IoT devices to transmit RF signals. Subject to operator policy and regulatory requirements, the 5G system shall support suitable mechanisms for the Ambient IoT device to move between one or more networks and countries.

[0278] So far, no solutions in TR 23.700-13 have addressed such aspect very well. There are some solutions discussed the disable from network point of view (i.e., network should not accept the information from the device if the device is disabled) . There are no complete solution to clarify the handling for enable /  (temporary) disable / permanent disable.

[0279] [Proposal-8] It is FFS about the solution of enable /  (temporary) disable / permanent disable AIoT devices.

[0280] 2. Proposal

[0281] It is proposed to agree the following changes to 3GPP TR 23.700-13 v1.0.0:

[0282] 8. X Conclusion on Key Issue #3

[0283] Editor's note: For type 1 devices, it is up to SA3 to determine whether they can fulfill security and privacy requirements defined by SA1. SA2 will make alignment with SA3 decisions if needed.

[0284] The following aspects and principles for Ambient IoT services are agreed for the conclusion on the support of Ambient IoT Services, which apply to both topology 1 and topology 2:

[0285] - Inventory and Command are supported.

[0286] - For inventory, AIoT devices respond their device IDs towards the network. For type 2 devices, they can be registered towards the network. During registration, CN Temp ID of the device can be allocated by the network.

[0287] Editor's note: It is up to SA3 to determine whether the devices send concealed device IDs. And if not, it is up to SA3 do determine whether and how the privacy concerns can be resolved.

[0288] - For reader selection, it is performed by both CN and RAN (A-IoT RAN and NG-RAN) together.

[0289] Editor's note: It requires colaboration with RAN3 to determine how the readers are selected for both Topology 1 and Topology 2.

[0290] - For A-IoT paging for inventory, to reach a group of AIoT devices, device ID MASK information is used for type 1 devices, and Group ID is used for type 2 devices.

[0291] Editor's note: It is up to SA3 to determine whether there are security / privacy concerns when using the device ID MASK information and Group ID in A-IoT paging. And if there are, it’s up to SA3 to determine how to resolve them.

[0292] - For command, AIoT devices execute the command and respond the results towards the network. For type 1 devices, the command delivery is performed in "Inventory and Command" manner. For type 2 devices, the command delivery can be optimized to "Command-only" manner.

[0293] - For A-IoT paging, to reach one or more specific AIoT devices. For type 1 devices, device IDs are used. For type 2 devices, the allocated CN Temp IDs of the devices are used.

[0294] Editor's note: It is up to SA3 to determine whether there are security / privacy concerns when using the device IDs in A-IoT paging for type 1 devices. And if there are, it’s up to SA3 to determine how to resolve them.

[0295] Editor's note: It is FFS about the solution of enable /  (temporary) disable / permanent disable AIoT devices.

Claims

1. A method (400) performed by a network node (103) providing Ambient Internet of Things (AIoT) service, comprising:- transmitting (S401) , to an AIoT reader (102, 202) , a first message including a first indicator indicating that a response from an AIoT device (101) in a disabled status is required; and- transmitting (S403) , to the AIoT reader (102, 202) , a third message for enabling the AIoT device (101) .2.the method (400) according to claim 1, further comprising:after transmitting (S401) the first message,- receiving (S402) , from the AIoT reader (102, 202) , a second message indicating that the AIoT device (101) is available;wherein transmitting (S403) the third message further comprises: responsive to receiving (S402) the second message, transmitting (S403) the third message.3.the method (400) of claim 1 or 2, wherein the first message is targeted to the AIoT device (101) in a temporary disabled status or in a permanently disabled status.4.the method (400) of any one of claims 1 to 3, wherein the first message is an inventory request message; andwherein the third message is a command message for enabling the AIoT device (101) .5.the method (400) of any one of claims 1 to 4,wherein the first message is targeted to a specific AIoT device (101) , and the first message includes an AIoT device ID of the AIoT device (101) , orwherein the first message is targeted to one or more AIoT devices (101) within a group of AIoT devices (101) , and the first message includes group information of the group of AIoT devices (101) .6.the method (400) of claim 3, wherein the first message is targeted to the AIoT device (101) in a permanently disabled status, andwherein the first message further includes a second indicator indicating that a response from the AIoT device (101) in the permanently disabled status is required.7.the method (400) of any one of claims 1 to 6, wherein the AIoT reader (102, 202) is a Radio Access Network (RAN) reader (102) , andwherein the first message is transmitted (S401) over Next Generation Application Protocol (NGAP) or another Application Protocol between Radio Access Network (RAN) and Core Network.8.the method (400) of any one of claims 1 to 6, wherein the AIoT reader (102, 202) is a User Equipment (UE) reader (202) , andwherein the first inventory request message is transmitted (S401) over UE Non-Access Stratum (NAS) message via Access and Mobility Management Function (AMF) and Next Generation Radio Access Network (NG-RAN) , or delivered over NGAP or another Application Protocol between RAN and Core Network from the network node providing AIoT service to the NG-RAN and then over Radio Resource Control (RRC) from NG-RAN to UE, or delivered over NGAP or another Application Protocol between RAN and Core Network from the network node providing AIoT service to the NG-RAN via AMF and then over RRC from NG-RAN to the UE reader.9.the method (400) of claim 2, further comprising:after receiving (S402) the second message,- checking a device status of the AIoT device (101) , based on device information of the AIoT device (101) in a network node (106) providing user data management, and / or a network node (107, 108) providing Authentication and / or Authorization;wherein the third message is transmitted (S401) , if the device status is a temporary disabled status.

10. the method (400) of claim 9, further comprising:- updating the device status of the AIoT device (101) in the network node (106) providing user data management, and / or the network node (107, 108) providing Authentication and / or Authorization, after transmitting the third message or after receiving the response of the third message.

11. the method (400) according to any of claims 1 to 10, wherein the third message is to permanently disable the AIoT device (101) , temporarily disable the AIoT device (101) , or enable the AIoT device (101) ; and / orwherein the first message is applicable to an AIoT device (101) in any status.12.A method (500) performed by a network node (103) providing Ambient Internet of Things (AIoT) service, comprising:- transmitting (S501) , to an AIoT reader (102, 202) , a fourth message for one of: temporarily disabling an AIoT device (101) , permanently disabling an AIoT device (101) , and enabling an AIoT device (101) .13.the method (500) of claim 12, wherein the fourth message is for temporarily disabling the AIoT device (101) , andwherein the fourth message further comprises a timer indicating an AIoT device (101) temporarily disabled is to be enabled after the timer expires.14.the method (500) of claim 13, further comprising:- determining (S502) whether the AIoT device (101) is capable of running a timer;- if the AIoT device (101) is capable of running a timer,- running (S503) the timer;- after the timer expires,- updating a device status of the AIoT device (101) as enabled in a network node (106) providing user data management, and / or a network node (107, 108) providing Authentication and / or Authorization, in response to the AIoT device (101) is enabled.15.the method (500) of claim 13, further comprising:- determining (S502) whether the AIoT device (101) is capable of running a timer;- if the AIoT device (101) is not capable of running a timer,- running (S503) the timer;- after the timer expires,- transmitting, to the AIoT reader (102, 202) , a fifth message including a first indicator indicating that a response from an AIoT device (101) in a disabled status is required;- transmitting, to the AIoT reader (102, 202) , a sixth message to enable the AIoT device (101) ; and- updating a device status of the AIoT device (101) as defined in a network node (106) providing user data management, and / or a network node (107, 108) providing Authentication and / or Authorization, after receiving from the AIoT reader (102, 202) a response indicating that the AIoT device (101) is enabled.16.A method (600) performed by an Ambient Internet of Things (AIoT) reader (102, 202) , comprising:- receiving (S601) , from a network node (103) providing Ambient Internet of Things (AIoT) service, a first message;- in response to determining the first message includes an indicator indicating that a response from an AIoT device (101) in a disabled status is required, transmitting (S602) , to the AIoT device (101) , a first paging-like message including the indicator;- receiving (S603) , from the network node (103) providing AIoT service, a third message for enabling the AIoT device (101) ; and- transmitting (S604) , to the AIoT device (101) , the third message.

17. the method (600) of claim 16, wherein the AIoT reader (102, 202) is a Radio Access Network (RAN) reader (102) or a User Equipment (UE) reader (202) .

18. the method (600) of claim 16 or 17, wherein the first message is an inventory request message, andwherein the method (600) further comprising:- indicating, to the network node (103) providing AIoT service, a completion of the inventory.19.A method (700) performed by an Ambient Internet of Things (AIoT) reader (102, 202) , comprising:- receiving (S701) , from a network node (103) providing Ambient Internet of Things (AIoT) service, a fourth message for one of: temporarily disabling the AIoT device (101) , permanently disabling the AIoT device (101) , and enabling the AIoT device (101) ; and- transmitting (S702) , to the AIoT device (101) , the fourth message.20.the method (700) of claim 19, wherein the fourth message is for temporarily disabling the AIoT device (101) ; andwherein the command message further comprises a timer indicating an AIoT device (101) temporarily disabled is to be enabled after the timer expires.21.the method (700) of claim 20, further comprising:- receiving, from the network node (103) providing AIoT service, a fifth message;- in response to determining the fifth message includes a first indicator indicating that a response from an AIoT device (101) in a disabled status is required, transmitting, to the AIoT device (101) , a second paging-like message including the first indicator;- receiving, from the network node (103) providing AIoT service, a sixth message for enabling the AIoT device (101) ; and- transmitting, to the AIoT device (101) , the sixth message.22.A method (800) performed by an Ambient Internet of Things (AIoT) device (101) , comprising:- receiving (S801) , from an AIoT reader (102, 202) , a first paging-like message including a first indicator indicating that a response from an AIoT device (101) in a disabled status is required; and- handling (S802) the first paging-like message.23.the method (800) of claim 22, wherein handling (S802) the first paging-like message comprises performing a random access like procedure; and / orhandling (S802) the first paging-like message comprises transmitting the device ID of the AIoT device.24.the method (800) of claim 22, wherein handling (S802) the first paging-like message comprises omitting the first paging-like message.25.A method (900) performed by an Ambient Internet of Things (AIoT) device (101) , comprising:- receiving (S901) , from the AIoT reader (102, 202) , a fourth message for one of: temporarily disabling the AIoT device (101) , permanently disabling the AIoT device (101) , and enabling the AIoT device (101) ; and- handling (S902) the fourth message.26.the method (900) of claim 25, wherein the fourth message is for temporarily disabling the AIoT device (101) ;wherein the fourth message further includes a timer; andwherein the method (900) further comprising:- running the timer;- enabling the AIoT device (101) , after the timer expires.27.A method (1000) performed by a network node (104) implementing network exposure function, comprising:- receiving (S1001) , from a network node (105) implementing an application function, an Ambient Internet of Things (AIoT) service operation request message, for requesting one of an AIoT temporary disable service operation, an AIoT permanent disable service operation, and an AIoT enable service operation.28.the method (1000) of claim 27, further comprising:- transmitting (S1002) , to a network node (103) providing Ambient Internet of Things (AIoT) service, the AIoT service operation request message.29.the method (1000) of claim 27 or 28, wherein the AIoT service operation request message for requesting the AIoT temporary disable service operation further includes a timer indicating an AIoT device (101) temporarily disabled is to be enabled after the timer expires.30.the method (1000) of any one of claims 27 to 29, wherein the AIoT service operation request message is one of an AIoT temporary disable service operation request message for requesting the AIoT temporary disable service operation, an AIoT permanent disable service operation request message for requesting the AIoT permanent disable service operation, and an AIoT enable service operation request message for requesting the AIoT enable service operation.31.the method (1000) of any one of claims 27 to 29, wherein the AIoT service operation request message is one of an AIoT disable service operation request message for requesting an AIoT disable service operation and an AIoT enable service operation request message for requesting the AIoT enable service operation request; andwherein the AIoT disable service operation request message includes a third indicator indicating whether the AIoT disable service operation is the AIoT temporary disable service operation or the AIoT permanent disable service operation.32.the method (1000) of any one of claims 27 to 29, wherein the AIoT service operation request message is an AIoT enable_disable service operation request message for requesting an AIoT enable_disable service operation; andwherein the AIoT enable_disable service operation request message includes a fourth indicator indicating whether the AIoT enable_disable service operation is the AIoT enable service operation or an AIoT disable service operation, and a fifth indicator indicating whether the AIoT disable service operation is the AIoT temporary disable service operation or the AIoT permanent disable service operation.33.the method (1000) of any one of claims 27 to 29, wherein the AIoT service operation request message is an AIoT temporary service operation request message for requesting an AIoT temporary service operation or an AIoT permanent service operation request message for requesting an AIoT permanent service operation;wherein the AIoT temporary service operation request message includes a sixth indicator indicating whether the AIoT temporary service operation is the AIoT enable service operation or the AIoT temporary disable service operation; andwherein the AIoT permanent service operation request message includes a seventh indicator indicating whether the AIoT permanent service operation is the AIoT enable service operation or the AIoT permanent disable service operation.34.the method (1000) of any one of claims 27 to 29, further comprising:- performing a permission control of the AIoT service operation request message, to decide whether to permit the requested AIoT temporary disable service operation, AIoT permanent disable service operation, or AIoT enable service operation.35.A method (1100) performed by a network node (105) implementing application function, comprising:- transmitting (S1101) , to a network node (104) implementing network exposure function, an Ambient Internet of Things (AIoT) service operation request message, for requesting one of an AIoT temporary disable service operation, an AIoT permanent disable service operation, and an AIoT enable service operation.36.A method (1200) performed by a network node (103) providing Ambient Internet of Things (AIoT) service, comprising:- receiving (S1201) , from a network node (104) implementing network exposure function, an AIoT service operation request message, for requesting one of an AIoT temporary disable service operation, an AIoT permanent disable service operation, and an AIoT enable service operation.37.the method (1200) of claim 36, further comprising:- determining (S1202) an AIoT device (101) targeted in the AIoT service operation request message;- acquiring status of the AIoT device (101) from a network node (106) providing user data management, and / or a network node (107, 108) providing Authentication and / or Authorization;- determining (S1203) whether the status of the AIoT device (101) matches the AIoT service operation request message;- if matched, transmitting (S1204) the AIoT service operation to an AIoT reader (102, 202) .38.the method (1200) of claim 36 or 37, wherein the status of the AIoT device (101) matching the AIoT service operation request message further comprising:- for the AIoT temporary disable service operation, the device information of the AIoT device (101) shows that the AIoT device (101) is in enabled state;- for the AIoT permanent disable service operation, the device information of the AIoT device (101) shows that the AIoT device (101) is not in permanent disabled state; or- for the AIoT enable service operation, the device information of the AIoT device(101) shows that the AIoT device (101) is in temporary disabled state.39.A network node (1300) providing Ambient Internet of Things (AIoT) service, comprising:- at least one processor (1301) ; and- a non-transitory computer readable medium (1302) coupled to the at least one processor (1301) , the non-transitory computer readable medium (1302) contains instructions executable by the at least one processor (1302) , whereby the at least one processor (1301) is configured to perform the method (400, 500, 1200) according to any one of claims 1-15 and 36-38.40.An Ambient Internet of Things (AIoT) reader (1400) , comprising:- at least one processor (1401) ; and- a non-transitory computer readable medium (1402) coupled to the at least one processor (1401) , the non-transitory computer readable medium (1402) contains instructions executable by the at least one processor (1402) , whereby the at least one processor (1401) is configured to perform the method (600, 700) according to any one of claims 16-21.41.An Ambient Internet of Things (AIoT) device (1500) , comprising:- an energy harvester (1501) , for harvesting energy;- an energy storage (1502) , for storing the harvested energy; and- a digital logic (1503) , for performing the method (800, 900) according to any one of claims 22-26.42.A network node (1600) implementing network exposure function, comprising:- at least one processor (1601) ; and- a non-transitory computer readable medium (1602) coupled to the at least one processor (1601) , the non-transitory computer readable medium (1602) contains instructions executable by the at least one processor (1602) , whereby the at least one processor (1601) is configured to perform the method (1000) according to any one of claims 27-34.43.A network node (1700) implementing application function, comprising:- at least one processor (1701) ; and- a non-transitory computer readable medium (1702) coupled to the at least one processor (1701) , the non-transitory computer readable medium (1702) contains instructions executable by the at least one processor (1702) , whereby the at least one processor (1701) is configured to perform the method (1100) according to claim 35.44.A communication system (1800) , comprising:- the network node (1300) providing Ambient Internet of Things (AIoT) service according to claim 39;- the AIoT reader according to claim 40; and- the AIoT device according to claim 41.45.The communication system (1800) of claim 44, further comprising:- the network node (1600) implementing network exposure function according to claim 42; and- the network node (1700) implementing application function according to claim 43.46.A computer readable medium (2302) comprising computer readable code, which when run on an apparatus (2300) , causes the apparatus (2300) to perform the method (500, 600, 700, 800, 900, 1000, 1100, 1200) according to any one of claims 1-38.47.A computer readable product (2304) comprising computer readable code, which when run on an apparatus (2300) , causes the apparatus (2300) to perform the method (500, 600, 700, 800, 900, 1000, 1100, 1200) according to any one of claims 1-38.

Images