Method and apparatus for communication of IoT device

Abstract

Embodiments of the present disclosure provide methods and apparatuses for communication of internet of things, IoT, device. A method (200) performed by a network node may comprise: transmitting (S202), to an ambient internet of things, AIoT, reader device, at least one request. The request is for an operation of one or more AIoT devices, and includes a transaction identifier, ID for the one or more AIoT devices. The transaction ID can be used for correlating the request from AF with inventory procedure and further with command procedure, for RAN node, AIOTF, AIOT device, UE to know they are for the same transaction.

Description

METHOD AND APPARATUS FOR COMMUNICATION OF IOT DEVICETECHNICAL FIELD

[0001] The present disclosure relates generally to the technology of wireless communication, and in particular, to a method and an apparatus for communication of internet of things, IoT, device.BACKGROUND

[0002] This section introduces aspects that may facilitate better understanding of the present disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

[0003] As the development of the IoT technology, more and more IoT devices will be produced and deployed. These IoT devices have different capabilities. For example, some devices may be very passive devices (not capable of negotiation with network, and not capable of handling persistent device identifier (ID) allocated by a core network (CN) ) , just like the radio frequency identifier (RFID) solutions. The network side will use common signalling / procedure to communicate with such devices.

[0004] However, for some other IoT devices with stronger communication capabilities, such common signalling / procedure will be not efficient.SUMMARY

[0005] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0006] Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges. Specific method and apparatus for communication of internet of things, IoT, device are provided.

[0007] A first aspect of the present disclosure provides a method performed by a network node. The method comprises transmitting, to an ambient internet of things, AIoT, reader device, at least one request. The request is for an operation of one or more AIoT devices, and includes a transaction identifier, ID for the one or more AIoT devices.

[0008] A second aspect of the present disclosure provides a method performed by an AIoT reader device. The method comprises receiving from a network node at least one request. A received request is for an operation of one or more AIoT devices, and includes a transaction identifier, ID for the one or more AIoT devices.

[0009] A third aspect of the present disclosure provides a method performed by an AIoT device. The method comprises receiving from an AIoT reader device at least one request. The request is for an operation of the AIoT device, and includes a transaction ID for the AIoT device.

[0010] A fourth aspect of the present disclosure provides an apparatus for a network node in a communication network. The apparatus comprises a processor, and a memory, the memory containing instructions executable by the processor. The apparatus for the network node is operative for transmitting, to an ambient internet of things, AIoT, reader device, at least one request. The request is for an operation of one or more AIoT devices, and includes a transaction identifier, ID for the one or more AIoT devices.

[0011] A fifth aspect of the present disclosure provides an apparatus for an AIoT reader device in a communication network. The apparatus comprises a processor, and a memory, the memory containing instructions executable by the processor. The apparatus for the AIoT reader device is operative for receiving from a network node at least one request. A received request is for an operation of one or more AIoT devices, and includes a transaction identifier, ID for the one or more AIoT devices.

[0012] A sixth aspect of the present disclosure provides an apparatus for an AIoT device in a communication network. The apparatus comprises a processor, and a memory, the memory containing instructions executable by the processor. The apparatus for the AIoT device is operative for receiving from an AIoT reader device at least one request. The request is for an operation of the AIoT device, and includes a transaction ID for the AIoT device.

[0013] A seventh aspect of the present disclosure provides a computer-readable storage medium storing instructions, which when executed by at least one processor, cause the at least one processor to perform the method according to any one of embodiments mentioned above.

[0014] Embodiments herein afford many advantages. According to embodiments of the present disclosure, when a plurality of requests has the same content, they may have the same transaction ID. Thus, the AIoT device may understand which requests are correlated to the same content.

[0015] An eighth aspect of the present disclosure provides a method performed by a network node. The method performed by a network node may comprise receiving a first request for an operation of one or more AIoT devices, determining whether the one or more AIoT devices comprise one or more registered AIoT devices and / or one or more unregistered AIoT devices, and transmitting, to at least one AIoT reader device, a second request for the operation of the one or more registered AIoT devices.

[0016] A ninth aspect of the present disclosure provides a method performed by an AIoT reader device. The method comprises receiving from a network node a second request for an operation of one or more registered AIoT devices, and transmitting to the one or more registered AIoT devices the second request including identifiers of the one or more registered AIoT devices.

[0017] A tenth aspect of the present disclosure provides a method performed by an AIoT device. The method comprises receiving from an AIoT reader device a request for an operation of the AIoT device, and transmitting to the AIoT reader device a result in response to the request. The request includes an identifier of the AIoT device.

[0018] An eleventh aspect of the present disclosure provides an apparatus for a network node in a communication network. The apparatus comprises a processor, and a memory, the memory containing instructions executable by the processor. The apparatus for the network node is operative for receiving a first request for an operation of one or more AIoT devices, determining whether the one or more AIoT devices comprise one or more registered AIoT devices and / or one or more unregistered AIoT devices, and transmitting, to at least one AIoT reader device, a second request for the operation of the one or more registered AIoT devices.

[0019] A twelfth aspect of the present disclosure provides an apparatus for an AIoT reader device in a communication network. The apparatus comprises a processor, and a memory, the memory containing instructions executable by the processor. The apparatus for the AIoT reader device is operative for receiving from a network node a second request for an operation of one or more registered AIoT devices, and transmitting to the one or more registered AIoT devices the second request including identifiers of the one or more registered AIoT devices.

[0020] A thirteenth aspect of the present disclosure provides an apparatus for an AIoT device in a communication network. The apparatus comprises a processor, and a memory, the memory containing instructions executable by the processor. The apparatus for the AIoT device is operative for receiving from an AIoT reader device a request for an operation of the AIoT device, and transmitting to the AIoT reader device a result in response to the request. The request includes an identifier of the AIoT device.

[0021] A fourteenth aspect of the present disclosure provides a computer-readable storage medium storing instructions, which when executed by at least one processor, cause the at least one processor to perform the method according to any one of embodiments mentioned above.

[0022] Embodiments herein afford many advantages. According to embodiments of the present disclosure, a manner for communication of internet of things, IoT, device may be provided. Particularly, different command may be used when the AIoT devices have different status, such as being registered or not. The efficiency of the communication may be further improved.BRIEF DESCRIPTION OF DRAWINGS

[0023] The above and other aspects, features, and benefits of various embodiments of the present disclosure will become more fully apparent, by way of example, from the following detailed description with reference to the accompanying drawings, in which like reference numerals or letters are used to designate like or equivalent elements. The drawings are illustrated for facilitating better understanding of the embodiments of the disclosure and not necessarily drawn to scale, in which:

[0024] FIG. 1 is a diagram showing a System Architecture to support AIoT Devices using AIoTF for Inventory.

[0025] FIG. 2 is a flow chart showing a method performed by a network node, according to embodiments of the present disclosure.

[0026] FIG. 3A, 3B are flow charts showing steps of a method performed by an AIoT reader device, according to embodiments of the present disclosure.

[0027] FIG. 4A, 4B are flow charts showing steps of a method performed by an AIoT device, according to embodiments of the present disclosure.

[0028] FIG. 5A is a flow chart showing a method performed by a network node, according to embodiments of the present disclosure.

[0029] FIG. 5B, FIG. 5C and FIG. 5D are flow charts showing further steps of the FIG. 5A, according to embodiments of the present disclosure.

[0030] FIG. 6A, 6B, 6C are charts showing steps of a method performed by an AIoT reader device, according to embodiments of the present disclosure.

[0031] FIG. 7A is a flow chart showing a method performed by an AIoT device, according to embodiments of the present disclosure.

[0032] FIG. 7B, FIG. 7C and FIG. 7D are flow charts showing further steps of the FIG. 7A, according to embodiments of the present disclosure.

[0033] FIG. 8 is a block diagram showing an exemplary apparatus for a network node, which is suitable for performing the method according to embodiments of the disclosure.

[0034] FIG. 9 is a block diagram showing an exemplary apparatus for an AIoT reader device, which is suitable for performing the method according to embodiments of the disclosure.

[0035] FIG. 10 is a block diagram showing an exemplary apparatus for an AIoT device, which is suitable for performing the method according to embodiments of the disclosure.

[0036] FIG. 11 is a block diagram showing an apparatus / computer readable storage medium, according to embodiments of the present disclosure.

[0037] FIG. 12 is a diagram showing a Protocol Stack for Supporting AIoT Devices using AIoTF for Topology 1, according to embodiments of the present disclosure.

[0038] FIG. 13 is a diagram showing an Inventory Procedure, according to embodiments of the present disclosure.

[0039] FIG. 14 is a diagram showing a Periodic Inventory Procedure, according to embodiments of the present disclosure.

[0040] FIG. 15 is a diagram showing a Command Procedure, according to embodiments of the present disclosure.

[0041] FIG. 16 is a diagram showing a System Architecture of Supporting AIoT Devices using AIoTF for Topology 2.

[0042] FIG. 17 is a diagram showing a Protocol Stack for Supporting AIoT Devices using AIoTF for Topology 2, according to embodiments of the present disclosure.

[0043] FIG. 18 is a diagram showing an Inventory Procedure, according to embodiments of the present disclosure.

[0044] FIG. 19A is a diagram showing a first part of Command Procedure, according to embodiments of the present disclosure.

[0045] FIG. 19B is a diagram showing a second part of Command Procedure, according to embodiments of the present disclosure.DETAILED DESCRIPTION

[0046] The embodiments of the present disclosure are described in detail with reference to the accompanying drawings. It should be understood that these embodiments are discussed only for the purpose of enabling those skilled persons in the art to better understand and thus implement the present disclosure, rather than suggesting any limitations on the scope of the present disclosure. Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present disclosure should be or are in any single embodiment of the disclosure. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Furthermore, the described features, advantages, and characteristics of the disclosure may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the disclosure.

[0047] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

[0048] As used herein, the term “network” or “communication network” refers to a network following any suitable wireless communication standards. For example, the wireless communication standards may comprise new radio (NR) , long term evolution (LTE) , LTE-Advanced, wideband code division multiple access (WCDMA) , high-speed packet access (HSPA) , Code Division Multiple Access (CDMA) , Time Division Multiple Address (TDMA) , Frequency Division Multiple Access (FDMA) , Orthogonal Frequency-Division Multiple Access (OFDMA) , Single carrier frequency division multiple access (SC-FDMA) and other wireless networks. In the following description, the terms “network” and “system” can be used interchangeably. Furthermore, the communications between two devices in the network may be performed according to any suitable communication protocols, including, but not limited to, the wireless communication protocols as defined by a standard organization such as 3rd generation partnership project (3GPP) or the wired communication protocols.

[0049] The term “network node” used herein refers to a network device or network entity or network function or any other devices (physical or virtual) in a communication network. For example, the network node in the network may include a base station (BS) , an access point (AP) , a multi-cell / multicast coordination entity (MCE) , a server node / function (such as a service capability server / application server, SCS / AS, group communication service application server, GCS AS, application function, AF) , an exposure node / function (such as a service capability exposure function, SCEF, network exposure function, NEF) , a unified data management, UDM, a home subscriber server, HSS, a session management function, SMF, an access and mobility management function, AMF, a mobility management entity, MME, a controller or any other suitable device in a wireless communication network. The BS may be, for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a next generation (NG) NodeB (gNodeB or gNB) , a remote radio unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, a low power node such as a femto, a pico, and so forth.

[0050] Yet further examples of the network node may comprise multi-standard radio (MSR) radio equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs) , base transceiver stations (BTSs) , transmission points, transmission nodes, positioning nodes and / or the like.

[0051] Further, the term “network node” , “network function” , “network entity” herein may also refer to any suitable node, function, entity which can be implemented (physically or virtually) in a communication network. For example, the 5G system (5GS) may comprise a plurality of NFs such as AMF (Access and mobility Function) , SMF (Session Management Function) , AUSF (Authentication Service Function) , UDM (Unified Data Management) , PCF (Policy Control Function) , AF (Application Function) , NEF (Network Exposure Function) , UPF (User plane Function) and NRF (Network Repository Function) , RAN (radio access network) , SCP (service communication proxy) , etc. In other embodiments, the network function may comprise different types of NFs (such as PCRF (Policy and Charging Rules Function) , etc. ) for example depending on the specific network.

[0052] The term “terminal device” refers to any end device that can access a communication network and receive services therefrom. By way of example and not limitation, the terminal device refers to a mobile terminal, user equipment (UE) , or other suitable devices. The UE may be, for example, a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, a portable computer, an image capture terminal device such as a digital camera, a gaming terminal device, a music storage and a playback appliance, a mobile phone, a cellular phone, a smart phone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet, a wearable device, a personal digital assistant (PDA) , a portable computer, a desktop computer, a wearable terminal device, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, a laptop-embedded equipment (LEE) , a laptop-mounted equipment (LME) , a USB dongle, a smart device, a wireless customer-premises equipment (CPE) and the like. In the following description, the terms “terminal device” , “terminal” , “user equipment” and “UE” may be used interchangeably. As one example, a terminal device may represent a UE configured for communication in accordance with one or more communication standards promulgated by the 3GPP, such as 3GPP’ LTE standard or NR standard. As used herein, a “user equipment” or “UE” may not necessarily have a “user” in the sense of a human user who owns and / or operates the relevant device. In some embodiments, a terminal device may be configured to transmit and / or receive information without direct human interaction. For instance, a terminal device may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the communication network. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but that may not initially be associated with a specific human user.

[0053] As yet another example, in an Internet of Things (IoT) scenario, a terminal device may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another terminal device and / or network equipment. The terminal device may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as a machine-type communication (MTC) device. As one particular example, the terminal device may be a UE implementing the 3GPP narrow band internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances, for example refrigerators, televisions, personal wearables such as watches etc. In other scenarios, a terminal device may represent a vehicle or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0054] References in the specification to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0055] It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed terms.

[0056] As used herein, the phrase “at least one of A and (or) B” should be understood to mean “only A, only B, or both A and B. ” The phrase “A and / or B” should be understood to mean “only A, only B, or both A and B. ”

[0057] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0058] It is noted that these terms as used in this document are used only for ease of description and differentiation among nodes, devices or networks etc. With the development of the technology, other terms with the similar / same meanings may also be used.

[0059] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0060] A 3rd generation partnership project Technical Report (3GPP TR) 23.700-13 v0.2.0: “Study on Architecture support of Ambient power-enabled Internet of Thing (Release-19) ” was agreed in 3GPP SA2#161.

[0061] Within the TR, the architecture assumptions and requirements, 3 key issues were agreed and included. There are some solutions which are relevant with topology 2. - The following traffic types for Ambient IoT Device are to be studied: - DT: Device-terminated; and - DO-DTT: Device-originated -device-terminated triggered. - The following two connectivity topologies as defined in technical report (TR) 38.848 V18.0.0  (2023-09) are to be studied: - Topology 1: BS <--> Ambient IoT Device; - Topology 2: BS <--> intermediate node <--> Ambient IoT Device: Only a UE can act as an  intermediate node which is under the network control. The following architectural requirements are applicable to this study: - Support for AIoT Services needs to adhere to the nature of the AIoT Devices (e.g. ultra-low  complexity, power, cost and resource-constrained) . - Support of the security aspects needs to consider the nature of the AIoT Devices (e.g. ultra-low  complexity power, cost and resource-constrained) while addressing e.g. confidentiality, integrity, etc. Key Issue #1: Architecture support of Ambient IoT DevicesDescription This key issue will address the system architecture to support Ambient IoT Devices, especially on the  following aspects: - System architecture identified along with the solutions for Key Issue (KI) #2 and KI#3. - Authentication and authorization for the Ambient IoT Device; - Validation of the Ambient IoT Device identifier; Key Issue #2: Identification, Subscription, Registration and Connection management Description This Key Issue pertains to the authorization and management of Ambient IoT Devices to support  Ambient IoT services. Considering that Ambient IoT Devices are a new type of reduced capabilities devices, the existing  subscription model may not be suitable. Specifically, there is the need to study the device identification method to support Ambient IoT devices which are under operator control. Key Issue #3: Support of Ambient IoT ServicesDescription This Key Issue pertains to the AIoT services. Considering that AIoT Devices are a new type of  devices with reduced capabilities, the following need to be supported: - Inventory. - Command. The key issue will study the following aspects: - Study how to support information transfer for Ambient IoT services and related system  functionality, including the information transfer for an Ambient IoT device and for a group of Ambient IoT Devices. 6.8 Solution #8: Inventory for AIoT Devices using AIOTF 6.8.1 Description This solution addresses subscription, registration and connection management aspect of Key Issue  #2, which is based on the following system architecture. The functional entities defined in TS 23.501 V18.5.0 (2024-03) are reused with the exception for the  following additions: - Ambient IoT Function (AIOTF) : AIOTF is introduced to support AIoT services, with some  AMF's functionalities integrated, which includes: - A-Radio Access Network (RAN) (Ambient IoT RAN) connectivity. - Inventory handling and device context management. - Authentication and authorization for the access, which triggers interaction with  AUSF / UDM. - Collect charging data and interact with CHF for charging. - Routing the request from AF (via NEF) to A-RAN, for DO-DTT / DT traffic types. - Routing the response from A-RAN to AF (via NEF) for DO-DTT traffic type. - UDM: UDM is enhanced to store and manage the AIoT device information. The device  information contains the device ID, device status information (e.g. enabled / disabled / permanently disabled) , as well as CN related information (e.g. serving NF) . - NEF: NEF is enhanced to expose AIoT specific services towards AF. - Charging Function (CHF) : CHF is enhanced for the charging for AIoT services. - NRF: NRF is enhanced to support the new NF type AIOTF and the corresponding NF profile. - AUSF: AUSF is enhanced for the authentication for the access from AIoT devices. The Figure 6.8.1-1 illustrates the enhanced architecture to support AIoT devices using AIOTF for  inventory. (see FIG. 1, i.e., Figure 6.8.1-1 in 3GPP TR 23.700-13 V0.2.0 (2024-03) ) Figure 6.8.1-1: System Architecture to support AIoT Devices using AIOTF for Inventory  This solution focuses on Topology 1. The AIoT device information can be stored in UDM, which is similar as the subscription data. The  device information contains the device ID, device status information (e.g. enabled / disabled / permanently disabled) , as well as CN related information (e.g. serving NF) . For enabling registration management, the some AIoT devices are assumed not to be able to initiate  the registration on their own. However, such passive AIoT devices can respond to messages from the network, which make them discoverable by the network. The procedure that is used to make the AIoT devices discoverable can be called an inventory procedure. … 6.8.2 Procedures 6.8.2.1 Application Inventory Procedure The application inventory procedure is initiated by the AF to discover one or more AIoT devices in a  specific area. (Figure 6.8.2.1-1 in 3GPP TR 23.700-13 V0.2.0 (2024-03) )  Figure 6.8.2.1-1: Inventory Procedure … 6.8.2.2 Periodic Inventory Procedure The periodic inventory procedure is initiated by the CN or A-RAN, which follows the instructions  from the AF, (Figure 6.8.2.2-1 in 3GPP TR 23.700-13 V0.2.0 (2024-03) ) Figure 6.8.2.2-1: Periodic Inventory Procedure 6.8.3 Impacts on services, entities and interfaces …

[0062] In the solutions in TR 23.700-13 v0.2.0, solution #3, #4, #5 can only use common signaling in radio access network (RAN) for command delivery.

[0063] It works for the very passive devices (not capable of security negotiation with network, and not capable of persistent core network (CN) allocated device identifier (ID) ) , just like the radio frequency identifier (RFID) solutions.

[0064] However, the common signaling in RAN is not efficient, and requires very long time for the communication between RAN and the devices. This may cause the below issues: 1) Limited by hardware (e.g., limited energy storage and memory size) , certain devices may be  infeasible to process data / signaling in a long time period; 2) Certain devices may be limited by the current available power / energy level, which is  insufficient for the devices to process data / signaling in a long time period; 3) Devices which are involved in sessions with long time duration may block the uplink (UL)  channel, and cause high congestion.

[0065] Therefore, it is necessary to study the above issues and develop corresponding solutions.

[0066] In TR 23.700-13 v0.2.0, there are some solutions (e.g., solution#3 and solution#4) address the command use case in topology 1 and topology 2. In those solutions, only application layer is proposed to be used between the application function (AF) and the Ambient Internet of Things (AIOT) devices. In this case, CN and RAN are expected to be transparent towards with the command sent by the AF.

[0067] Considering that enable and disable can also be commands sent from AF to AIoT devices, CN needs to understand and update the device status stored in the network. For example, if an AIoT device is disabled successfully, the device should not be able to listen to a “read” or “write” command from the AF, execute the command and send back the result to the network. In another word, the command cannot be always transparent towards CN.

[0068] In embodiments of the present disclosure, a transaction ID may be used to identify an operation.

[0069] FIG. 2 is a flow chart showing a method performed by a network node, according to embodiments of the present disclosure.

[0070] As shown in FIG. 2, the method 200 comprises: a step S202, transmitting, to an ambient internet of things, AIoT, reader device, at least one request. The request is for an operation of one or more AIoT devices, and includes a transaction identifier, ID for the one or more AIoT devices.

[0071] According to exemplary embodiments of the present disclosure, the transaction ID can be used for correlating the request from AF with inventory procedure and further with command procedure, for RAN node, AIOTF, AIOT device, UE to know they are for the same transaction.

[0072] In exemplary embodiments of the present disclosure, the request comprises a command request or an inventory request.

[0073] In exemplary embodiments of the present disclosure, the at least one request comprises a first request including a first transaction ID, and a second request including a second transaction ID.

[0074] In exemplary embodiments of the present disclosure, optionally, the second transaction ID and first transaction ID are the same, and the second request is a repeat of the first request. Optionally, the second transaction ID and the first transaction ID are the same, and the first request is a dedicated command request for a first set of AIoT devices in the one or more AIoT devices and the second request is a common inventory request for a second set of AIoT devices in the one or more AIoT devices. Optionally, the second transaction ID and the first transaction ID are the same, and the first request is a dedicated command request for the first set of AIoT devices in the one or more AIoT devices and the second request is a dedicated command request without CN device IDs for a third set of AIoT devices in the one or more AIoT devices.

[0075] The first set of AIoT devices may be registered AIoT devices, and the second set of AIoT devices may be unregistered devices.

[0076] According to embodiments of the present disclosure, the requests for the same operation may have the same transaction ID to avoid repeated operations. The efficiency may be further improved.

[0077] In exemplary embodiments of the present disclosure, the dedicated command request for the first set of AIoT devices includes CN device IDs of the first set of AIoT devices.

[0078] In exemplary embodiments of the present disclosure, the transaction ID is correlated to the operation. The network node comprises an ambient internet of things function, AIoTF. The AIoT reader device comprises: an access network node, or an intermediate node, such as user equipment, UE.

[0079] In exemplary embodiments of the present disclosure, a transaction ID is a function of time window. A plurality of command requests or a plurality of inventory requests in a time window are allocated with the same transaction ID, when the plurality of inventory requests or the plurality of inventory requests have the same content.

[0080] According to embodiments of the present disclosure, a time window may be used. Then, the transaction ID may be reused after a certain time.

[0081] FIG. 3A, 3B are flow charts showing steps of a method performed by an AIoT reader device, according to embodiments of the present disclosure.

[0082] As shown in FIG. 3A, the method 300 comprises: a step S302, receiving, from a network node, at least one request. A received request is for an operation of one or more AIoT devices, and includes a transaction identifier, ID for the one or more AIoT devices.

[0083] As shown in FIG. 3B, the method 300 further comprises: a step S304, transmitting, to the one or more AIoT devices, one or more of the at least one request.

[0084] In exemplary embodiments of the present disclosure, the received request comprises a command request or an inventory request.

[0085] In exemplary embodiments of the present disclosure, the one or more of the at least one request comprises a first request including a first transaction ID, and a second request including a second transaction ID.

[0086] In exemplary embodiments of the present disclosure, the second transaction ID and the first transaction ID are the same, and the second request is a repeat of the first request. The second transaction ID and the first transaction ID are the same, and the first request is a dedicated command request for a first set of AIoT devices in the one or more AIoT devices and the second request is a common inventory request for a second set of AIoT devices in the one or more AIoT devices. The second transaction ID and the first transaction ID are the same, and the first request is a dedicated command request for the first set of AIoT devices in the one or more AIoT devices and the second request is a dedicated command request without CN device IDs for a third set of AIoT devices in the one or more AIoT devices.

[0087] In exemplary embodiments of the present disclosure, the dedicated command request for the first set of AIoT devices includes CN device IDs of the first set of AIoT devices.

[0088] In exemplary embodiments of the present disclosure, the transaction ID is correlated to the operation. The network node comprises an ambient internet of things function, AIoTF. The AIoT reader device comprises: an access network node, or an intermediate node.

[0089] FIG. 4A, 4B are flow charts showing steps of a method performed by an AIoT device, according to embodiments of the present disclosure.

[0090] As shown in FIG. 4A, the method 400 comprises: a step S402, receiving, from an AIoT reader device, at least one request. The request is for an operation of the AIoT device, and includes a transaction ID for the AIoT device .

[0091] In exemplary embodiments of the present disclosure, the request comprises a command request or an inventory request.

[0092] In exemplary embodiments of the present disclosure, the at least one request comprises a first request including a first transaction ID, and a second request including a second transaction ID.

[0093] As shown in FIG. 4B, the method 400 further comprises: a step S404, ignoring the second request, when the second transaction ID and the first transaction ID are the same.

[0094] Optionally, the second transaction ID and the first transaction ID are the same, and the second request is a repeat of the first request.

[0095] Optionally, the second transaction ID and the first transaction ID are the same, and the first request is a dedicated command request for a first set of AIoT devices in the one or more AIoT devices and the second request is a common inventory request for a second set of AIoT devices in the one or more AIoT devices.

[0096] Optionally, the second transaction ID and the first transaction ID are the same, and the first request is a dedicated command request for the first set of AIoT devices in the one or more AIoT devices and the second request is a dedicated command request without CN device IDs for a third set of AIoT devices in the one or more AIoT devices.

[0097] In exemplary embodiments of the present disclosure, the transaction ID is correlated to the operation.

[0098] In exemplary embodiments of the present disclosure, the AIoT reader device comprises: an access network node, or an intermediate node, such as a user equipment, UE.

[0099] FIG. 5A is a flow chart showing a method performed by a network node, according to embodiments of the present disclosure.

[0100] The method 500 performed by a network node may comprise: a step S502, receiving a first request for an operation of one or more AIoT devices; a step S504, determining whether the one or more AIoT devices comprise one or more registered AIoT devices and / or one or more unregistered AIoT devices; a step S506, transmitting, to at least one AIoT reader device, a second request for the operation of the one or more registered AIoT devices.

[0101] According to embodiments of the present disclosure, different requests may be used when the AIoT devices have different status, such as being registered or not. The efficiency of the communication may be further improved.

[0102] In exemplary embodiments of the present disclosure, the network node transmits the second request by using a dedicated signalling with CN device IDs of the one or more registered AIoT devices, when the one or more AIoT devices comprise one or more registered AIoT devices. The second request is generated based at least on the first request. The AIoT reader device comprising: an access network node and / or an intermediate node, such as a user equipment.

[0103] According to embodiments of the present disclosure, for registered AIoT devices, dedicated signalling with CN device IDs may be used, and which AIoT device is required to perform an operation is clearly indicated. Thus, the efficiency may be further improved.

[0104] FIG. 5B is a flow chart showing further steps of the FIG. 5A, according to embodiments of the present disclosure.

[0105] In exemplary embodiments of the present disclosure, the method 500 further comprises: a step S508, transmitting, to at least one AIoT reader device, an inventory request for the one or more unregistered AIoT devices, when the one or more AIoT devices comprise the one or more unregistered AIoT devices; a step S510, receiving from at least one AIoT reader device, one or more inventory responses generated by one or more responding AIoT devices. The one or more inventory responses comprise device identification information and / or device capability information associated with one or more responding AIoT devices.

[0106] According to embodiments of the present disclosure, for unregistered AIoT devices, an inventory procedure may be performed to find out whether there are some devices that can be registered or not.

[0107] FIG. 5C is a flow chart showing further steps of the FIG. 5A, according to embodiments of the present disclosure.

[0108] In exemplary embodiments of the present disclosure, the method 500 further comprises: a step S512, determining whether the one or more responding AIoT devices include a first set of AIoT devices with a capability for supporting persistence of received information, and / or a second set of AIoT devices without the capability for supporting persistence of received information, based at least on the capability information; and a step S514, registering the first set of AIoT devices in the CN, when the one or more responding AIoT devices include the first set of AIoT devices.

[0109] According to embodiments of the present disclosure, the AIoT devices with capability may be registered.

[0110] FIG. 5D is a flow chart showing further steps of the FIG. 5A, according to embodiments of the present disclosure.

[0111] In exemplary embodiments of the present disclosure, the method further comprises: a step S516, transmitting, to at least one AIoT reader devices, a third request for the operation of the first set of AIoT devices, by using a dedicated signalling including identifiers of the first set of AIoT devices; and / or a step S518, transmitting to at least one AIoT reader devices, a fourth request for the operation of the second set of AIoT devices, by using a dedicated signalling without CN device IDs.

[0112] For the first set of AIoT devices, a third request may be used to allocate CN ID, and then a fourth request may be used to perform a command. However, for the second set of AIoT devices, only a fourth request is used, and no third request.

[0113] According to embodiments of the present disclosure, the AIoT devices in different status may be requested by different kinds of signaling. The efficiency may be further improved.

[0114] In exemplary embodiments of the present disclosure, the third request, and the fourth request are generated based at least on the first request.

[0115] In exemplary embodiments of the present disclosure, the first request comprises an inventory request or a command request. The second request comprises an inventory request or a command request. The third request comprises an inventory request or a command request. The fourth request comprises an inventory request or a command request.

[0116] In exemplary embodiments of the present disclosure, the second request comprises a transaction ID. The inventory request comprises a transaction ID. The third request comprises a transaction ID. The fourth request comprises a transaction ID. The transaction ID in the second request, the transaction ID in the inventory request, the transaction ID in the third request, and the transaction ID in the fourth request are the same.

[0117] According to embodiments of the present disclosure, the same requests for the same operation may have the same transaction ID to avoid repeated operations. The efficiency may be further improved.

[0118] In exemplary embodiments of the present disclosure, the one or more registered AIoT devices are registered in the CN during an inventory procedure. Identifiers of the one or more registered AIoT devices include CN device ID.

[0119] In exemplary embodiments of the present disclosure, a transaction ID is a function of time window. A plurality of requests or a plurality of inventory requests in a time window are allocated with the same transaction ID, when the plurality of inventory requests or the plurality of inventory requests have the same content.

[0120] According to embodiments of the present disclosure, a time window may be used. Then, the transaction ID may be reused after a certain time.

[0121] In exemplary embodiments of the present disclosure, the network node comprises an ambient internet of things function, AIoTF.

[0122] FIG. 6A, 6B, 6C are charts showing steps of a method performed by an AIoT reader device, according to embodiments of the present disclosure.

[0123] As shown in FIG. 6A, the method 600 comprises: a step S602, receiving, from a network node, a second request for an operation of one or more registered AIoT devices; and a step S604, transmitting, to the one or more registered AIoT devices, the second request including identifiers of the one or more registered AIoT devices.

[0124] In exemplary embodiments of the present disclosure, the second request includes CN device IDs of the one or more registered AIoT devices. The second request is transmitted by using a dedicated signalling. The second request is generated based at least on the first request. The AIoT reader device comprising: an access network node and / or an intermediate node.

[0125] As shown in FIG. 6B, the method 600 further comprises a step S606, receiving, from the network node, an inventory request for one or more unregistered AIoT devices; a step S608, transmitting, to the one or more unregistered AIoT devices, the inventory request; a step S610, receiving one or more inventory responses from one or more responding AIoT devices; and a step S612, transmitting, to the network node, the one or more inventory responses. The one or more inventory responses comprise device identification information and / or device capability information associated with the one or more responding AIoT devices.

[0126] As shown in FIG. 6C, the method 600 further comprises a step S614, receiving, from the network node, a third request for the operation of a first set of AIoT devices with a capability for supporting persistence of received information; a step S616, transmitting, to the first set of AIoT devices, the third request, by using a dedicated signalling including identifiers of the first set of AIoT devices; a step S618, receiving, from the network node, a fourth request for the operation of a second set of AIoT devices without a capability for supporting persistence of received information; and a step S620, transmitting, to the second set of AIoT devices, the fourth request, by using a dedicated signalling without CN device IDs.

[0127] In exemplary embodiments of the present disclosure, the third request, and the fourth request are generated based at least on the first request. The first request comprises an inventory request or a command request. The second request comprises an inventory request or a command request. The third request comprises an inventory request or a command request. The fourth request comprises an inventory request or a command request.

[0128] FIG. 7A is a flow chart showing a method performed by an AIoT device, according to embodiments of the present disclosure.

[0129] As shown in FIG. 7A, the method 700 comprises: a step S702, receiving, from an AIoT reader device, a request for an operation of the AIoT device; a step S704, transmitting, to the AIoT reader device, a result, in response to the request. The request includes an identifier of the AIoT device.

[0130] In exemplary embodiments of the present disclosure, the AIoT device receives the request by using dedicated signalling. The request comprises an inventory request or a command request.

[0131] FIG. 7B is a flow chart showing further steps of the FIG. 7A, according to embodiments of the present disclosure.

[0132] In exemplary embodiments of the present disclosure, the method 700 further comprises: a step S706, performing the operation.

[0133] In exemplary embodiments of the present disclosure, the request includes a transaction ID.

[0134] FIG. 7C is a flow chart showing further steps of the FIG. 7A, according to embodiments of the present disclosure.

[0135] In exemplary embodiments of the present disclosure, the method 700 further comprises: a step S708, storing the transaction ID in the request.

[0136] FIG. 7D is a flow chart showing further steps of the FIG. 7A, according to embodiments of the present disclosure.

[0137] In exemplary embodiments of the present disclosure, the method 700 further comprises: a step S710, receiving an inventory request, wherein the inventory request includes a transaction ID; a step S712, comparing the transaction ID in the inventory request and the transaction ID in the request; and a step S714, ignoring the inventory request, when the transaction ID in the inventory request and the transaction ID in the request are the same.

[0138] In exemplary embodiments of the present disclosure, the AIoT device is registered in a core network (CN) during an inventory procedure. The identifier of the AIoT device include a CN device ID.

[0139] In exemplary embodiments of the present disclosure, a transaction ID is a function of time window. A plurality of command requests or a plurality of inventory requests in a time window are allocated with the same transaction ID, when the plurality of inventory requests or the plurality of inventory requests have the same content.

[0140] Further, the following exemplary embodiments about inventory procedure may be illustrated.

[0141] In embodiments of the present disclosure, a method performed by a network node may comprise: transmitting an inventory request for ambient internet of things, AIoT, devices, to one or more AIoT reader devices; receiving one or more inventory responses from the one or more AIoT reader devices. The one or more inventory responses comprise device identification information and / or device capability information associated with one or more AIoT devices.

[0142] Accordingly, a method performed by an AIoT reader device may comprise: receiving from a network node an inventory request for ambient internet of things, AIoT, devices; transmitting the inventory request to one or more AIoT devices; receiving one or more inventory responses from one or more AIoT devices; and transmitting the one or more inventory responses to the network node.

[0143] Accordingly, a method performed by an AIoT device may comprise: receiving, from an AIoT reader device, an inventory request for ambient internet of things, AIoT, devices; transmitting, to the AIoT reader device, an inventory response comprising device identification information and / or device capability information associated with the AIoT device.

[0144] In embodiments of the present disclosure, the device capability information indicates whether the AIoT device has a capability for supporting persistent received information. The AIoT device receives a CN device ID allocated by an AIoTF for the AIoT device, when the AIoT device has the capability.

[0145] In embodiments of the present disclosure, the method performed by the network node further comprises: performing validation of the device identification information with a core network, CN; performing authentication and authorization to the AIoT device with the CN; and determining whether an AIoT device has a capability for supporting persistence of received information, based at least on the capability information.

[0146] In embodiments of the present disclosure, when the AIoT device has the capability for supporting persistence of received information, the method performed by the network node further comprises: performing security negotiation between the AIoT device and the CN; allocating a CN device ID for the AIoT device; transmitting the CN device ID to the AIoT device; and registering the AIoT device in the CN. The security negotiation comprises: a security mode negotiation and / or security parameter exchanges.

[0147] In embodiments of the present disclosure, the inventory request comprises a transaction ID.

[0148] In embodiments of the present disclosure, the method performed by the AIoT device further comprises: comparing the received transaction ID with one or more stored transaction IDs; transmitting the inventory response, when the received transaction ID and the stored transaction ID are different, or when the received transaction ID and the stored transaction ID are the same but from different AIoT reader devices, or the AIoT device hasn’t been in communication with a network longer than a predetermined length of time; storing the received transaction ID, when the inventory response is transmitted.

[0149] In embodiments of the present disclosure, the transaction ID is a function of time window; and a plurality of inventory requests in a time window are allocated with the same transaction ID, when the plurality of inventory requests has the same content.

[0150] In embodiments of the present disclosure, the inventory request comprises at least one of: area information, device information, inventory strategy information, location required information and report aggregation information. The area information is internal geographical area information. The device information is at least one of: one or more device identifiers, one or more device group identifiers, or one or more device types. The inventory strategy information comprises an inventory frequency and inventory period that indicates whether all AIoT devices should respond, only AIoT devices that haven’t performed inventory should respond, or that both AIoT devices that haven’t performed inventory and devices that have been inventoried, but have not been in communication with a network for a predetermined length of time should respond, or that AIoT devices have performed the inventory but haven't performed the inventory to the same AIoT reader device should respond. The location required information indicates whether an application function, AF, requests the location information of the AIoT devices. The report aggregation info indicates whether reports are to be aggregated or not for a specific aggregation period, and whether the reports are needed after the aggregation period.

[0151] In embodiments of the present disclosure, the one or more inventory responses comprise location information associated with the one or more AIoT devices in response to the inventory request transmitted to the one or more AIoT reader devices comprising a location request.

[0152] In embodiments of the present disclosure, the one or more inventory responses comprise an end indicator indicating whether there will be an additional inventory response.

[0153] In embodiments of the present disclosure, the method performed by the network node further comprises: buffering device identification information from a plurality of AIoT devices; and on expiration of an aggregation period, or if buffering a sufficient long time period or buffering sufficient data within aggregation period, forwarding aggregated device identification from the plurality of AIoT devices to an application function, AF, via a network exposure function, NEF.

[0154] In embodiments of the present disclosure, the method performed by the network node further comprises: transmitting the one or more inventory responses to an AF via a NEF. The one or more inventory responses comprises reports that were not omitted based on inventory strategy information received from the AF via the NEF.

[0155] In embodiments of the present disclosure, the network node comprises an ambient internet of things function, AIoTF; and / or an AIoT reader device comprises an access network node and / or an intermediate node, such as a user equipment.

[0156] Further, exemplary embodiments about using NAS layer may be further illustrated below.

[0157] In embodiments of the present disclosure, a method performed by a network node may comprise: receiving, from a network exposure function, NEF, a request for an operation of one or more AIoT devices; generating a first request message in a first non-access stratum, NAS, layer, to include the operation in the request; generating a second request message in a second NAS layer to include the first request message; transmitting the second request message to an intermediate terminal device; and receiving a second response message in the second NAS layer from the intermediate terminal device. The first NAS layer is defined for information exchange between the network node and the one or more AIoT devices; and the request is generated by an application function, AF, and transmitted to the network node via the NEF. The second NAS layer is defined for information exchange between the network node and the intermediate terminal device (such as intermediate node, intermediate UE) . The second response message includes a first response message in the first NAS layer.

[0158] According to embodiments of the present disclosure, two NAS layers (such as AIoT device NAS layer and AIoT UE NAS layer) may be used.

[0159] The method further comprises: transmitting the first request message to an AIoT reader device; and receiving, from the AIoT reader device, a first response message in the first NAS layer.

[0160] The method, further comprises: aggregating the first response message with other response messages; transmitting the aggregated response messages to the AF via the NEF.

[0161] The method further comprises: aggregating the second response message with other response messages; transmitting the aggregated response messages to the AF via the NEF.

[0162] The network node comprises an ambient internet of things function, AIoTF.

[0163] In embodiments of the present disclosure, a method performed by an AIoT reader device may comprise: receiving from a network node, a second request message; transmitting, to one or more AIoT device, the second request; receiving from one or more AIoT device, a second response message; transmitting to the network node, the second response message in a second NAS layer. A first NAS layer is defined for information exchange between the network node and the one or more AIoT devices; and a request is generated by an application function, AF, and transmitted to the network node via the NEF. The second NAS layer is defined for information exchange between the network node and the intermediate terminal device (such as intermediate node, intermediate UE) . The second response message includes a first response message in the first NAS layer.

[0164] In embodiments of the present disclosure, a method performed by an AIoT device may comprise: receiving a signaling including a first request message in a first non-access stratum, NAS, layer, including a request for an operation of one or more AIoT devices. The first NAS layer is defined for information exchange between a network node and the one or more AIoT devices.

[0165] The method performed by the AIoT device may further comprises: performing the operation, and transmitting a signaling including a first response message in the first NAS layer.

[0166] For Command Request, the Ambient Internet of Things Function (AIoTF) , which is a CN network function (NF) , check the registered devices, and triggers command delivery to the RAN, so that RAN can apply dedicated signaling to those registered devices. For the rest of the devices (not registered) , another command delivery (initiated by inventory request) will be sent to the RAN, and the RAN will utilize common signaling to deliver.

[0167] To ensure the executed device do not execute the reporting again, Transaction ID is introduced. If the device executes the command via dedicated signaling, it records the Transaction ID, so that it can recognize the common delivery for the same command via the same Transaction ID. Based on the same Transaction ID, the device will not respond towards the inventory, so that next generation (NG) -RAN will not deliver the command to it again.

[0168] To support the case that some commands can be kept transparent towards CN, while some are not (e.g., enable / disable) , application (app) layer (between AF and AIoT devices) , AIoT Device non access stratum (NAS) layer (between AIoTF and AIoT devices) , AIoT user equipment (UE) non access stratum (NAS) layer (between AIoTF and UE reader) are proposed.

[0169] Based on solution#8, the embodiments of the present disclosure propose an optimization for the command delivery. For those devices which are capable of authentication / authorization / using CN allocated device ID, dedicated signaling in RAN would be utilized. To enable dedicated signaling, the solution needs to be adjusted: - When receiving command delivery request for some specific AIoT devices or AIoT devices  in an area, AF sends request to network exposure function (NEF) . - The NEF find the proper AIoTF based on NRF query or UDM query: ○ If area info is provided, NRF query will be used to find the AIoTF for the area. ○ If only device IDs are provided, NEF query UDM to find the serving AIoTF for those  devices. - The AIoTF checks the registered devices (the registration is assumed to be done before  downlink (DL) command delivery, for example, registration is triggered by inventory procedure) . - The AIoTF allocates Transaction ID for the command delivery. - The AIoTF sends Command Request to the RAN for the registered devices with Transaction  ID and CN allocated device ID (s) . - RAN use the CN allocated device ID (s) to perform delivery over dedicated signaling to the  devices. Dedicated signaling can target a single or multiple devices. The transaction ID is delivered to devices in the dedicated signaling. This can also be RAN implementation as RAN can use common signaling to perform delivery mechanism for specific / known / dedicated devices. For instance, if there is signaling defined like SELECT command in RFID, the RAN node utilizes the same signaling to target known or unknow devices which can include Transaction ID. - The devices execute the command and record / store the transaction ID (s) and send the  command result to the RAN. Device can include the transaction ID in the uplink (UL) message carrying command result for network to verify that expected command result is received. The RAN forwards the command result to the AIoTF. - The AIoTF triggers Inventory to the RAN for the unregistered devices targeted by the same  DL delivery, if there are any included in step 1 (such as in the inventory procedure) above e.g. if AF provided a list of AIoT devices and not all were registered and handled above. The Transaction ID is provided to the RAN. - The RAN triggers inventory with the Transaction ID. The devices which have previously  executed the command and recorded the Transaction ID will not respond the inventory. This can be subject to device capability if the device can record the ID. - Devices that provide inventory report perform registration procedure according to their  capability. This is required before continuing with DL command procedure. - After the response from the Device, the AIoTF sends the command to the RAN with a  transaction ID associated with the DL command delivery, and the RAN delivers it to the responded device. The device sends the command result to the RAN and records / stores the transaction ID. The RAN forwards the command result to the AIoTF. - The AIoTF performs aggregation of the command results for all devices and send to the NEF.  The NEF sends to the AF. - The AIoTF updates transaction ID upon completion of the DL command delivery. (Note that  the AIoTF may trigger re-attempts using the same ‘Transaction ID’ for increased service reliability) .

[0170] Note: The idea concerning Transaction ID can be generalized where if multiple command procedures and / or multiple inventory procedures are triggered which happen to indicate the same Transaction ID in their procedure’s related signaling in some time frame, then once the device has responded / reported (successfully) , then it may / must / chose to the later commands (associated with same transaction ID) within the specified time frame.

[0171] The idea above is also applicable for the solution in Topology 2 as described in Solution #X (related to 6. X…, etc. ) .

[0172] To resolve the issue some commands cannot be transparent towards CN, it is proposed to have: - AIoT Device NAS layer: The NAS protocol between AIoTF and AIoT devices. - Application (App) layer: The application layer protocol between AIoT devices and AF. - AIoT UE NAS layer for topology 2: The NAS protocol between AIoTF and UE readers.  Besides the 5th generation mobility management (5GMM) NAS and 5th generation session management (5GSM) NAS, it can be defined as a new NAS (e.g. 5GAIoT NAS) which is transmitted within the 5GMM NAS.

[0173] When deliver a command: - AF sends command to CN and includes command parameters in an app layer container; - AIoTF creates AIoT Device NAS request message containing the command.

[0174] For topology 1: AIoTF deliver AIoT Device NAS request message over NGAP to RAN reader.

[0175] For topology 2: AIoTF creates 5GAIoT NAS request message to UE including AIoT Device NAS request message and delivers to UE reader: - RAN / UE deliver AIoT Device NAS request message to the AIoT devices. - AIoT device execute the commands, including the command result in AIoT Device NAS  response message. Some application specific result can be in an app layer container. AIoT Device delivers AIoT Device NAS response message to reader.

[0176] For topology 1: RAN reader delivers AIoT Device NAS response message to AIoTF.

[0177] For topology 2: UE reader creates 5GAIoT NAS response message and includes AIoT Device NAS response message. UE deliver 5GAIoT NAS response message to AIoTF.

[0178] AIoTF get the command result from AIoT Device NAS response message. AIoTF may aggregate results and send to AF via NEF.

[0179] For command / inventory from AF, AIoTF split into two rounds: for registered devices, dedicated signaling utilized, and another round for unregistered devices (and devices who missed the dedicated signaling)

[0180] Transaction ID allocated and used in dedicated signaling and common signaling delivery to avoid the device respond for multiple times. It could be similar as session ID in RFID. However, there is no dedicated signaling delivery in RFID.

[0181] For all solutions (command related) in the previous TR, app layer (between device and AF) is assumed. But it should be AIoT Device layer (between device and AIoTF) , considering the support of enabling / disabling commands. It works for both topology 1 and topology 2.

[0182] The solutions in embodiments of the present disclosure enable dedicated signaling for the command delivery for passive Ambient IoT devices, which increase the efficiency of the delivery over the air.

[0183] A clean layered architecture is proposed, which enables some commands which are not transparent towards CN (i.e. CN needs to understand the command and take some actions accordingly) .

[0184] Some other exemplary embodiments may be also illustrated below.

[0185] In one of the embodiments, during an inventory / command procedure as described in the above clauses, area info carried by the signaling / command may comprise one or multiple areas in which the target devices are located.

[0186] In one of the options, an area is defined as a tracking area / registration area as in the legacy / previous specifications / standards.

[0187] In one of the options, an area is defined as a RAN area as in the legacy / previous specifications / standards.

[0188] In one of the options, an area (configuration) comprises at least one of the below information: ● one or multiple IDs of RAN nodes (e.g., gNB, distributed unit (DU) , central unit (CU) ) , in  this case, the area is defined as the coverage (area) where the RAN nodes have reachability. ● one or multiple IDs of intermediate nodes / UEs (e.g., UE IDs including Cell Radio Network  Temporary Identity (C-RNTI) , Inactive Radio Network Temporary Identity (I-RNTI) , resume IDs, Paging Radio Network Temporary Identity (P-RNTI) etc., to identify UEs) . ○ In this case, the area is defined as the coverage area where the intermediate UEs are  camped on / served. In other words, the area is defined as the coverage area where the intermediate nodes / UEs have reachability. ● one or multiple cells (if feasible) . Note: although a device may not be able to identify cells, at  least RAN nodes or the intermediate UEs can identify the area based on the coverage area of cells. ● One or multiple coordinates (e.g., based on Global Positioning System (GPS) , Beidou,  Compass, Galileo, GLOBAL NAVIGATION SATELLITE SYSTEM (GLONASS) , Satellite-Based Augmentation System (SBAS) or Transit etc. ) indicating boundary of the area,  ○ Alternatively, the area configuration provides a center location, and one radius / range  indicating how far the area covers the scope / area away from the center. ● One or multiple radio channel quality thresholds. ○ It is assumed that some devices may be able to measure radio channel quality in the  locations. A location / spot is deemed to be in the (coverage) area if the measured radio channel quality (transmitted by the RAN node) in terms of e.g., reference signal received power (RSRP) etc, is above the threshold. While the location / spot is deemed to be out of the (coverage) area if the measured radio channel quality is below the threshold.

[0189] In one of the embodiments, during an inventory / command procedure as described in the above, area info carried by the signaling / command may comprise one or multiple areas in which the target devices are locate, upon reception of the signaling / command (transmitted by the CN or AF) by a RAN node / an intermediate UE, the RAN node / intermediate UE may check whether itself belongs to the indicated area (s) , if the answer is yes, the RAN node / intermediate UE further forwards the signaling to the devices in the area, otherwise, the RAN node / intermediate UE ignores the received signaling without further actions. This embodiment is applicable especially when the CN / AF sends the signaling / command to RAN nodes / intermediate UEs in a groupcast or broadcast manner.

[0190] In one of the embodiment, during an inventory / command procedure as described in the above, area info carried by the signaling / command may comprise one or multiple areas in which the target devices are located, upon reception of the signaling / command by a device, the device may check whether itself belongs to the indicated area (s) , if the answer is yes, the device reads the signaling and provides a response message to the network if required, otherwise, the device ignores the received signaling without further actions. This embodiment is applicable especially when the RAN nodes / intermediate UEs sends the signaling / command in a groupcast or broadcast manner.

[0191] In one embodiment, the Transaction ID is associated with only one DL delivery. Thus, AIoTF changes / updates the value of Transaction ID every time it receives end indicator from RAN node regarding command results, i.e., all expected devices have replied to the DL command delivery (or when AIoTF itself determines all devices replied, in case RAN nodes does not keep track of applicable devices to reply to a request) . As an example, each application is with a Transaction ID is a 8-bit counter, starting from zero, increases for every DL delivery and wraps around when reaching the value of 256.

[0192] In one of the embodiments, any one of the above embodiments is applicable in case other similar info is included in the signaling / command (e.g., group info, device ID info etc) . in other words, in one case, the RAN node / intermediate UE may filter the signaling / commands received from the CN / AF by checking whether intended groups / devices are in managed by the RAN node / intermediate UE.The RAN node / intermediate UE will only forward the signaling / command to the intended devices / device groups if they are indeed under control by the RAN node / intermediate UE. In another case, the RAN node / intermediate UE may just ignore / skip a signaling / command received from the CN / AF if the intended devices / device groups are not under control by the RAN node / the intermediate UE.

[0193] FIG. 8 is a block diagram showing an exemplary apparatus for a network node, which is suitable for performing the method according to embodiments of the disclosure.

[0194] As shown in FIG. 8, an apparatus 80 for a network node in a communication network, may comprise: a processor 802; and a memory 804. The memory contains instructions executable by the processor. The apparatus 80 for the network node is operative for: transmitting, to an ambient internet of things, AIoT, reader device, at least one request. The request is for an operation of one or more AIoT devices, and includes a transaction identifier, ID for the one or more AIoT devices.

[0195] In embodiments of the present disclosure, the apparatus 80 is further operative to perform the method according to any of the above embodiments, such as these shown in FIG. 2.

[0196] Further, in other aspects, an apparatus 80 for a network node in a communication network, may comprise: a processor 802; and a memory 804. The memory contains instructions executable by the processor. The apparatus 80 for the network node is operative for: receiving a first request for an operation of one or more AIoT devices; determining whether the one or more AIoT devices comprise one or more registered AIoT devices and / or one or more unregistered AIoT devices; and transmitting, to at least one AIoT reader device, a second request for the operation of the one or more registered AIoT devices.

[0197] In embodiments of the present disclosure, the apparatus 80 is further operative to perform the method according to any of the above embodiments, such as these shown in FIG. 5A-5D.

[0198] FIG. 9 is a block diagram showing an exemplary apparatus for an AIoT reader device, which is suitable for performing the method according to embodiments of the disclosure.

[0199] As shown in FIG. 9, an apparatus 90 for an AIoT reader device in a communication network, may comprise: a processor 902; and a memory 904. The memory contains instructions executable by the processor. The apparatus 91 for an AIoT reader device is operative for: receiving, from a network node, at least one request. The request is for an operation of one or more AIoT devices, and includes a transaction identifier, ID for the one or more AIoT devices.

[0200] In embodiments of the present disclosure, the apparatus 90 is further operative to perform the method according to any of the above embodiments, such as these shown in FIG. 3A-3B.

[0201] Further, in other aspects, an apparatus 90 for an AIoT reader device in a communication network, may comprise: a processor 902; and a memory 904. The memory contains instructions executable by the processor. The apparatus 90 for an AIoT reader device is operative for: receiving, from a network node, a second request for an operation of one or more registered AIoT devices; and transmitting, to the one or more registered AIoT devices, the second request including identifiers of the one or more registered AIoT devices.

[0202] In embodiments of the present disclosure, the apparatus 90 is further operative to perform the method according to any of the above embodiments, such as these shown in FIG. 6A-6C.

[0203] FIG. 10 is a block diagram showing an exemplary apparatus for an AIoT device, which is suitable for performing the method according to embodiments of the disclosure.

[0204] As shown in FIG. 10, an apparatus 100 for an AIoT device in a communication network, may comprise: a processor 1002; and a memory 1004. The memory contains instructions executable by the processor. The apparatus 100 for an AIoT device is operative for: receiving, from an AIoT reader device, at least one request. The request is for an operation of the AIoT device, and includes a transaction ID for the AIoT device.

[0205] In embodiments of the present disclosure, the apparatus 100 is further operative to perform the method according to any of the above embodiments, such as these shown in FIG. 4A-4B.

[0206] Further, in other aspects, an apparatus 100 for an AIoT device in a communication network, may comprise: a processor 1002; and a memory 1004. The memory contains instructions executable by the processor. The apparatus 100 for an AIoT device is operative for: receiving, from an AIoT reader device, a request for an operation of the AIoT device, transmitting, to the AIoT reader device, a result in response to the request. The request includes an identifier of the AIoT device.

[0207] In embodiments of the present disclosure, the apparatus 100 is further operative to perform the method according to any of the above embodiments, such as these shown in FIG. 7A-7D.

[0208] The processors 802, 902, 1002 may be any kind of processing component, such as one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs) , special-purpose digital logic, and the like. The memories 804, 904, 1004 may be any kind of storage component, such as read-only memory (ROM) , random-access memory, cache memory, flash memory devices, optical storage devices, etc.

[0209] FIG. 11 is a block diagram showing an apparatus / computer readable storage medium, according to embodiments of the present disclosure.

[0210] As shown in FIG. 11, the computer-readable storage medium 110, or any other kind of product, storing instructions 1101 which when executed by at least one processor, cause the at least one processor to perform the method according to any one of the above embodiments, such as these shown in FIG. 2-7D.

[0211] In addition, the present disclosure may also provide a carrier containing the computer program / instructions as mentioned above, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium. The computer readable storage medium can be, for example, an optical compact disk or an electronic memory device like a RAM (random access memory) , a ROM (read only memory) , Flash memory, magnetic tape, CD-ROM, DVD, Blue-ray disc and the like.

[0212] The techniques described herein may be implemented by various means so that an apparatus implementing one or more functions of a corresponding apparatus described with an embodiment comprises not only prior art means, but also means for implementing the one or more functions of the corresponding apparatus described with the embodiment and it may comprise separate means for each separate function, or means that may be configured to perform two or more functions. For example, these techniques may be implemented in hardware (one or more apparatuses) , firmware (one or more apparatuses) , software (one or more modules) , or combinations thereof. For a firmware or software, implementation may be made through modules (e.g., procedures, functions, and so on) that perform the functions described herein.

[0213] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0214] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0215] The below parts include exemplary embodiments, which may be submitted to 3GPP for the purpose to replace or supplement some 3GPP technical documents. 6.8 Solution #8: Support for AIoT Devices using AIOTF for Topology 1 6.8.1 Description This solution addresses Key Issue #1, Key Issue #2, and Key Issue #3 which is based on the  following system architecture. The functional entities defined in TS 23.501 are reused with the exception for the following  additions: - Ambient IoT Function (AIOTF) : AIOTF is introduced to support AIoT services, with some  AMF's functionalities integrated, which includes: - A-RAN (Ambient IoT RAN) connectivity. - Inventory handling and device context management. - Command delivery. - Authentication and authorization for the access, which triggers interaction with  AUSF / UDM. - Collect charging data and interact with CHF for charging. - Routing the request from AF (via NEF) to A-RAN, for DO-DTT / DT traffic types. - Routing the response from A-RAN to AF (via NEF) for DO-DTT traffic type. - UDM: UDM is enhanced to store and manage the AIoT device information. The device  information contains the device ID, device group ID, device status information (e.g. enabled / disabled / permanently disabled) , optional device credentials, as well as CN related information (e.g. serving NF) . UDM also stores device capability profiles. - NEF: NEF is enhanced to expose AIoT specific services towards AF. - CHF: CHF is enhanced for the charging for AIoT services. NOTE 1: The charging aspects is to be studied by service and system aspects working group  (SA WG) 5. - NRF: NRF is enhanced to support the new NF type AIOTF and the corresponding NF profile. - AUSF: AUSF is enhanced for the authentication for the access from AIoT devices. NOTE 2: The security aspects are to be studied by SA WG3. NOTE X: Depending on service agreement between Mobile Network Operator (MNO) and  service provider, the device information can be stored in MNO or in service provider (e.g., UDM / AUSF in service provider or Authentication, Authorization, Accounting (AAA) server in service provider domain, which is similar as Standalone Non-Public Network (SNPN) ) . Editor's note: The functions of the NFs need to be aligned with A-RAN WGs, SA3 (for security) ,  SA5 (for charging) . The Figure 6.8.1-1 illustrates the enhanced architecture to support AIoT devices using AIOTF. (Figure 6.8.1-1 in 3GPP TR 23.700-13 V0.2.0 (2024-03) ) Figure 6.8.1-1: System Architecture to support AIoT Devices using AIOTF This solution focuses on Topology 1. The AIoT device information can be stored in UDM, which is similar as the subscription data. The  device information contains the device ID, device status information (e.g. enabled / disabled / permanently disabled) , as well as CN related information (e.g. serving NF) . For enabling registration management, some (AIoT) devices (limited by hardware) (e.g. device 1 and  device 2a) are assumed not to be able to initiate the registration on their own. However, those AIoT devices can respond to messages received from the network, which make them discoverable by the network. The procedure that is used to make the AIoT devices discoverable can be called an inventory procedure. The inventory procedure can be triggered by an AF sending an inventory request towards CN, and  CN sends a request to A-RAN. The AIoT devices respond to the inventory request from A-RAN and send their device IDs. Such inventory procedure triggered by an AF can be called application inventory procedure. The AF may further provide the inventory strategy information (e.g. inventory frequency info,  inventory period) to enable CN or A-RAN to perform periodic inventory to allow the newly coming AIoT devices to be discovered, without further explicit requests from the AF. For the application inventory or periodic inventory, the authentication and authorization need to be  performed, depends on device capabilities, Security Mode Command may be performed and the CN allocated device ID which is similar as 5G-Globally Unique Temporary UE Identity (GUTI) may be passed to the device. For those devices, the device contexts are stored in AIOTF, including the security contexts. When an application inventory or a periodic inventory procedure is triggered, the network may  indicate whether all targeted devices need to respond the inventory, or only those devices which haven't been "inventoried" towards this A-RAN node should respond. Alternatively, the network includes specific device IDs or device group IDs in the inventory (request) message which need to response to the inventory. When AIoT devices move to a new A-RAN node, by responding the inventory, the network can also  keep track of the AIoT devices location e.g. on a serving A-RAN node granularity, in addition, area info may be included if RAN areas are defined within the coverage area of the RAN node, so that the network can route the request effectively which is sent from the AF via the corresponding RAN nodes (instead of all RAN nodes) to one or more specific AIoT devices. NOTE 3: When AIoT devices move, the AIoT devices does not perform cell re-selection like  logic. For connection management perspective, there are no differentiation between CM-CONNECTED  and CM-IDLE states for devices. This is also due to that there is no RRC state for devices to be maintained in the (A-) RAN. However, when the device is known by the network (i.e., device context stored in AIOTF) , DL data can be delivered by the AIOTF to the service A-RAN node directly. When the detailed location of the device is unknown (i.e., device context not in AIOTF) , AIOTF needs to deliver the DL data to all A-RAN nodes in the area to look up the device and deliver the DL message accordingly. 6.8.1. X Protocol Stack The Figure 6.8.1. X-1 illustrates the protocol stack for the solution: (see FIG. 6) Figure 6.8.1. X-1: Protocol Stack for the solution Within the protocol stack: - AIOT Device NAS layer: The NAS protocol between AIOTF and AIoT devices. - AIOT AS layer (s) : The AS protocol layer (s) between RAN reader and AIoT devices, including  e.g., the physical layer, the MAC layer, the Packet Data Convergence Protocol (PDCP) layer (in case of user plane (UP) solution) , the radio resource control (RRC) layer etc. - App layer: The application layer protocol between AIoT devices and AF. 6.8.2 Procedures NOTE: The message names in the procedures below are descriptive. It is assumed that the names  are updated with corresponding SBI based names where applicable during the normative phase. 6.8.2.1 Application Inventory Procedure The application inventory procedure is initiated by the AF to discover one or more AIoT devices in a  specific area. (See FIG. 7) Figure 6.8.2.1-1: Inventory Procedure 1. The AF sends Inventory Message Request to the NEF, containing the area information, device  information, optional inventory strategy information, and optional report aggregation info. - The area information could be the external geographical area information. - The device information could be device ID, device group ID, and / or external device type. - The inventory strategy information contains, e.g. the inventory frequency info and inventory  period to guide the readers to trigger (or, perform) the inventory (e.g., periodically) . It also indicates whether all the targeted devices need to respond (full inventory) , or only those who haven't performed the inventory procedure (delta inventory) should respond or include devices IDs, device groups which need to response. - The location required indicates whether the AF requests the location information of the  AIoT devices provided. - The report aggregation info indicates whether the reports need to be aggregated or not for  a specific aggregation period, and whether the reports are needed after the aggregation period. 2. The NEF authorizes the request from the AF and perform the area translation to translate  external area information to the internal area information. Within the authorization, the NEF further check whether the AF is authorized to get the location information of the devices. The NEF map the external device type to internal device type (i.e., device 1, device 2a, device 2b, etc. ) . NOTE X: It’s up to RAN to determine whether the device type is useful or not. 3. The NEF sends NRF query with internal area information to query AIOTFs serving the area. 4. The NEF sends the Inventory Request to the AIOTFs with the internal area information, device  information and optionally inventory strategy information, optional location required information. 5. The AIOTF discovers A-RANs based on internal area information. 6. The AIOTF sends an NGAP message (Inventory Request) to each of the discovered and  applicable A-RANs with the Transaction ID, internal area information, device information and inventory strategy information, and optional location required information. 7. The A-RAN (reader) initiates inventory based on device information as well as the inventory  strategy information provided by the AF. The A-RAN may provide reader identity information (e.g. A-RAN ID) to enable the AIoT devices to understand they are read by which A-RAN node. It can also provide the Transaction ID. It may also provide the device information, which may be a group ID or a specific device ID. 8. The AIoT Device reports the concealed device ID, and optional device capability index. If the  Inventory procedure indicates only who haven't performed the inventory procedure towards this A-RAN node should respond, and if the AIoT Device has performed the inventory procedure towards this A-RAN node, it should skip the reporting. If the Inventory procedure is for one specific device, the intended AIoT Device may report an encrypted info where the info is known to the network, e.g., the info may be the (shortened) Transaction ID received from the inventory command or the (shortened) device ID or just a predefined ID. The network identifies the device based on encryption. 9. The A-RAN sends an NGAP message (Inventory Response or Inventory Notify) to the AIOTF,  containing the device ID and the optional device capability index provided by the device. The A-RAN may further provide location information (ULI) of the device, if requested from the AIOTF and allowed by local policy. The A-RAN may further provide an end indicator to inform the AIOTF whether it is the last inventory response for the inventory round. If the Inventory procedure is for one specific device, The A-RAN may include the device ID associated with the inventory command it has sent in the Inventory Response or Inventory Notify. NOTE X: It’s up to RAN3 to determine the details and enhancements of the location information. 10. The AIOTF validates the concealed device ID via interacting with AUSF and UDM. The  AIOTF may further get the device capability information from the device capability profile stored in the UDM based on the device capability index provided by the device. In case the inventory procedure is for one specific device, the AIOTF may fetch / apply the relevant security context based on the device ID received in Inventory Response or Inventory Notify. NOTE X: Depending on the service agreement between the MNO and the service provider,  the device information can be stored in the MNO or in the service provider (e.g., UDM / AUSF in service provider or AAA server in service provider domain, which is similar as SNPN) . 11. The AIOTF together with AUSF and UDM, triggers authentication and authorization  procedures (i.e., like the authentication request / response between UE and network) towards the AIoT device. Based on the device capability information from UDM, if the AIoT device is capable of persistent  received parameters, step 12 -step 13 are executed: 12. The security mode negotiation and security parameter exchanges are performed (i.e., like  the security mode command / complete between UE and network) . 12a. The AIOTF may further allocates CN device ID and sends to the AIoT device. 13. The AIOTF registers with the UDM (UECM) for the device access. 14. The AIOTF may perform aggregation for the device ID, based on the report aggregation  information provided by the AF. Within the aggregation period, the AIOTF will buffer the device IDs reported from the AIoT devices. The AIOTF may stop buffering and send report immediately, if it receives end indicator from A-RAN in step 9. When the aggregation period expires, the AIOTF sends the report. For those device ID report after the aggregation period, if it is needed by the AF, the AIOTF sends the report. Otherwise, it will be dropped. 15. The AIOTF sends Inventory Response or Notification Request towards the NEF for the  device ID or the aggregated device ID information. 16. The NEF sends Inventory Response or Notification Request towards the AF for the  device ID or the aggregated device ID information. 6.8.2.2 Periodic Inventory Procedure The periodic inventory procedure is initiated by the CN or A-RAN, which follows the instructions  from the AF, (FIG. 8) Figure 6.8.2.2-1: Periodic Inventory Procedure The AIOTF or the A-RAN may initiate the periodic inventory procedure based on the inventory  strategy information provided by the AF, to enable the AIoT devices to be discovered when they newly enter the coverage area. 0. An Inventory Procedure may have taken place resulted in inventory strategy information  stored in the AIOTF. e.g. inventory frequency. The step 1 -step 11 are similar as step 6 -step 16 in clause 6.8.2.1 (above described) , with the  following additions: 1. It will be performed only when it is AIOTF to initiate the periodic inventory. The inventory  strategy should be set to delta inventory. 2. It can be performed without step 1, if it is A-RAN who initiates the periodic inventory. The  inventory strategy could be set to delta inventory. It can include Transaction ID, and how to generate Transaction ID is specified in one of the embodiment delineated in the end. 3. The AIOT device responds if it hasn't been "inventoried" (if indicated) , i.e., only new / non- inventoried device must respond) . Using the reader identity information (e.g. A-RAN ID) over the air, AIOT device determines if it is being read by a new A-RAN node and responds the inventory. The device may provide CN allocated device ID if it received before. 6. Can be skipped if the AIOTF finds AIoT device has performed the authentication and  authorization with the network, based on CN allocated device ID. 7. Can be skipped if security mode negotiation and security parameter exchange are done 7a. Can be skipped if the AIOTF decides not to allocate a new CN allocated device ID by local  policy. 8. Can be skipped if the AIOTF has registered towards UDM. 9. The AIOTF may use the aggregation period provided by the AF, or a locally configured value  or even skip the aggregation, based on local policy. If the AIoT device responds the inventory procedure due to the A-RAN is a new reader, the device ID may not be sent to AF via NEF, unless AF requires the location information. 10. The AIOTF sends Inventory Notify Request towards the NEF for the device ID or the  aggregated device ID information. 11. The NEF sends Inventory Notify Request towards the AF for the device ID or the  aggregated device ID information. In one embodiment, corresponding to Step 2, AIoTF specify rules on generating Transaction ID by  A-IoT RAN for each periodic inventory command / procedure. If the CN sends command to specific devices (based on command procedure indicated in section 6.8.2. X (bellow described) ) , it includes transaction ID which is generated based on similar rules A-IoT RAN generates in order to have consistency. One such rule could be, e.g., Transaction ID is function of time window. For instance, if an inventory or command procedure invoked during some coherent time window, the reader or CN generates and includes the same Transaction ID in its command so that it enables device not to respond multiple times when it receives any of these commands if it has responded once in the same time window / frame. In a variant of the above embodiment, the coherent time window or a Transaction ID keeping time  may be provided to the device in e.g., the corresponding command, the device only keep the Transaction ID for a time period equal to the coherent time window or the keeping time after receiving the corresponding command or sending the response to the corresponding command or receiving positive acknowledge for the response to the corresponding command. A device does not respond multiple times when it receives a command with Transaction ID the same to (one of) the device’s stored Transaction ID, in other words, the device will respond again to a command with the same Transaction ID if the command is sent later than a time where the corresponding Transaction ID is reset in the device. 6.8.2. X Command Procedure The command procedure is initiated by the AF to request one or more specific AIoT devices or a  group of AIoT devices in an area to execute the command. The command can be read, write, enable, disable, or execution request from the AF. The command result from the devices may or may not be required. Editor's note: The command for enable / disable is to be studied by SA3, and to be aligned with  SA3. (See FIG. 9) Figure 6.8.2. X-1: Command Procedure 1. The AF sends Command Request to the NEF, containing the command to be executed, area  information, device information, optional inventory strategy information, and optional report aggregation info. - The command is to be executed in the AIoT devices. It contains the command (e.g., read,  write, execute, etc. ) together with the command parameters. The command specific parameters (e.g. what to be executed) are to be included in an app layer container between AF and AIOT devices. - The area information could be the external geographical area information. - The device information could be device ID, device group ID, and / or external device type. - The location required indicates whether the AF requests the location information of the  AIoT devices provided. - The report aggregation info indicates whether the reports need to be aggregated or not for  a specific aggregation period, and whether the reports are needed after the aggregation period. 2. The NEF authorizes the request from the AF and perform the area translation to translate  external area information to the internal area information. Within the authorization, the NEF further check whether the AF is authorized to get the location information of the device. The NEF map the external device type to internal device type (i.e., device 1, device 2a, device 2b, etc. ) . NOTE X: It’s up to RAN to determine whether the device type is useful or not. Depending on whether area information is provided, step 3a or step 3b is performed: 3a. If area information is provided, the NEF sends NRF query with internal area information  to query AIOTFs serving the area. 4b. If area information is not provided, and device ID (s) are provided, the NEF query the  serving AIOTF from UDM. 4. The NEF sends the Command Request to the AIOTFs with the command, internal area  information, device information, device type, and optional location required information. 5. The AIOTF allocates a Transaction ID for the command, which is unique per command. The  AIOTF creates the AIOT Device NAS request message for the devices, based on the command information from the AF. The AIOTF get the registered devices e.g. from device context information stored in the AIOTF, which match the device information. If no registered devices, step 6 - 12 are skipped. 6. The AIOTF sends an NGAP message (e.g., Command Request) to the A-RANs with the AIOT  Device NAS request message, CN allocated device ID for the registered devices, the Transaction ID, and optional location required information. 7. The A-RAN (reader) initiates command delivery for the AIOT Device NAS request message  based on CN allocated device IDs, using dedicated signalling. Transaction ID is also included. NOTE X: RAN signaling details is further to be studied by RAN WGs. The RAN can send group  common signaling (correspond to group of devices (associated with CN IDs) or dedicated signaling per device. 8. The AIoT Device executes the command, creates an AIOT Device NAS response message  containing the command result, and delivers the AIOT Device NAS response message if the result needs to be sent back. The application specific result can be included in an app layer container. The device records the transaction ID. The device includes Transaction ID in the UL message  for command result / reply for the network to know which DL command delivery the reply is associated with. In case of security protected UL message for command result, the Transaction ID can be protected together with the UL data, e.g., by means of NAS / AS security. 9. The A-RAN sends an NGAP message (Command Response or Command Notify) to the AIOTF,  containing AIOT Device NAS response message containing the command result from the device. The A-RAN may further provide location information (ULI) of the device, if requested from the AIOTF and allowed by local policy. The A-RAN may further provide an end indicator to inform the AIOTF whether it is the last command response. NOTE X: It’s up to RAN3 to determine the details and enhancements of the location information. 10. The AIOTF gets the command result from the AIOT Device NAS response message. The  AIOTF may perform aggregation for the device ID (or, command result) , based on the report aggregation information provided by the AF. Within the aggregation period, the AIOTF will buffer the command results reported from the AIoT devices. The AIOTF may stop buffering and send report immediately, if it receives end indicator from A-RAN in step 9. When the aggregation period expires, the AIOTF sends the report. For those command result after the aggregation period, if it is needed by the AF, the AIOTF sends the report. Otherwise, it will be dropped. 11. The AIOTF sends Command Response or Notification Request towards the NEF for the  command result or the aggregated command result information. 12. The NEF sends Command Response or Notification Request towards the AF for the  command result or the aggregated command result information. If the AIOTF determines all required devices have executed the command (e.g. when AF provide  the device ID (s) and those devices have executed the command in step 7 - 8) , the following steps are skipped. 13. For those unregistered devices (s) , the AIOTF initiates Inventory procedure as step 6 - 13  in Figure 6.8.2.1-1 (step 12 - 13 will be skipped, if the device is not able to persistent received information) . In the inventory, the Transaction ID is delivered, so that the registered devices which have executed step 7 -8 (or, the command) do not respond the inventory request from A-RAN. For the responded devices, the authentication and security parameter negotiation are performed, unless the device has registered in application inventory or period inventory procedures. 14. For each respond device, the AIOTF sends an NGAP message (Command Request) to the  A-RANs with AIOT Device NAS request message, the Transaction ID (or AIoT device ID) , and optional location required information. ¨ Alternatively, AIoTF can wait until the A-RAN notify that inventory round is ended, i.e., via an  end indicator to inform the AIOTF whether it is the last device that performs inventory and registration in response to the inventory command and then sends a Command request to A-RANs with list of newly registered device IDs. In addition, depending on the size of targeted group of devices in the DL command delivery, RAN can send one or multiple DL messages over Uu in step 15 each of which containing the Transaction ID and one or multiple device IDs. 15. The A-RAN (reader) initiate the command delivery for the AIOT Device NAS request  message to the device. 16. The AIoT Device executes the command, creates an AIOT Device NAS response message  containing the command result and delivers the AIOT Device NAS response message, if the result needs to be sent back. The application specific result can be included in an app layer container. The device includes Transaction ID in the UL message for command result / reply for the network to know which DL command delivery the reply is associated with. In case of security protected UL message, the Transaction ID can be protected together with the UL data, e.g., by means of NAS / AS security. 17. The A-RAN sends an NGAP message (Command Response or Command Notify) to the  AIOTF, including the AIOT Device NAS response message. The A-RAN may further provide location information (ULI) of the device, if requested from the AIOTF and allowed by local policy. The A-RAN may further provide an end indicator to inform the AIOTF whether it is the last command response. 18. As step 10 - 12, the AIOTF gets command result from AIOT Device NAS response  message. It may perform the aggregation and send to NEF. The NEF delivers to the AF. 6.X Solution #X: Support AIoT Devices using AIOTF for Topology 2 6.X. 1 Description This solution proposes an complementary solution to Solution #8. It enables the support of Ambient  IoT devices for topology 2, which addresses KI#1, KI#2 and KI#3. Together with Solution #8 which focus on Topology 1, the solutions can support both AIoT devices for both Topologies. In this solution, it is AIOTF who is in charge of the intermediate UE for the Ambient IoT operations, including determining intermediate UEs, sending operation commands to and receiving results from intermediate UEs. As the licensed spectrum is owned by MNO, it is proposed to let network provide the radio resource information towards the intermediate UEs about the spectrum information for the over-the-air interface between Intermediate UEs and AIoT devices. 6.X. 1.1 Reference Architecture The Figure 6. X. 1.1-1 illustrates the architecture for supporting AIoT Devices using AIOTF for  Topology 2: (See FIG. 10) Figure 6. X. 1.1-1: System Architecture of Supporting AIoT Devices using AIOTF for Topology 2 This solution focuses on Topology 2, which works together with Solution #8 addressing Topology 1. The functional entities defined in Solution #8 and TS 23.501 are reused with the exception for the  following additions: - UDM / UDR: The authorization information of Intermediate UE for AIoT is stored in UE  subscription data - AMF: Receive AIoT capability information from UE and authorize based on the subscription  data in UDM / UDR. - NG-RAN: Provide spectrum information towards authorized intermediate UE. - Intermediate UE: - Provide Ambient IoT capability information to AIOTF and receive the authorization  information - Receive the instruction from AIOTF and perform Ambient IoT operations (e.g.,  inventory, command, etc. ) on the proper spectrum. The radio resource information is received from NG-RAN 6.X. 1.2 Protocol Stack The Figure 6. X. 1.2-1 illustrates the protocol stack for AF based solution: (FIG. 11) Figure 6. X. 1.2-1: Protocol Stack for Supporting AIoT Devices using AIOTF for Topology 2 Within the protocol stack, the AIOT Device NAS layer, AIOT AS layer and App layer are defined as  Solution #8. As UE reader is used in Topology 2, which is different form the RAN reader in Topology 1, the  following layer is proposed specific in this solution: - AIOT UE NAS layer: The NAS protocol between AIOTF and UE readers. Besides the 5GMM  NAS and 5GSM NAS, it can be defined as a new NAS (e.g. 5GAIOT NAS) which is transmitted within the 5GMM NAS. 6.X. 2 Procedures NOTE: The message names in the procedures below are descriptive. It is assumed that the names  are updated with corresponding SBI based names where applicable during the normative phase. 6.X. 2.1 AIoT Service Authorization for Intermediate UE The Registration procedure for UE is performed as defined in clause 4.2.2.2 of TS 23.502 with the  following additions: - UE includes the AIoT Intermediate node capability as part of “5GMM capability” in  Registration Request message. - The AMF obtains the AIoT Subscription data as part of the user subscription data from UDM  using Nudm_SDM service - The AMF determines whether the UE is authorized to work as Intermediate UE for AIoT based  on UE’s AIoT Intermediate node capability and the AIoT Subscription data. The AMF includes the authorization information as part of UE context in NGAP message sent to NG-RAN. In Service Request procedure, N2 Handover procedure, Xn Handover procedure, and when  receiving Subscriber Data Update to AMF, the AMF includes the authorization information in NGAP message sent to NG-RAN. 6.X. 2.2 AIOTF Keep Track of Intermediate UE For authorized Intermediate UEs (Those Ambient IoT Capable UEs which have been authorized by  the AMF as described in clause 6. X. 2.1) , in Initial Registration procedure as defined in clause 4.2.2.2 of TS 23.502 [5] with the following additions: - The AMF sends Registration Request to the AIOTF for the Intermediate UE, so that the AIOTF  may select the Intermediate UE for AIoT operations. In Deregistration procedure as defined in clause 4.2.2.3 of TS 23.502 [5] , the following additions  are performed: - The AMF sends Deregistration Request to the AIOTF for the Intermediate UE, so that the  Intermediate UE will no longer be used. The AIOTF can subscribe the UE mobility event of the Intermediate UE towards the AMF to be  updated for the location information. 6.X. 2.3 Application Inventory Procedure The Inventory procedure can be initiated by the AF to discover one or more AIoT devices in a  specific area via Intermediate UEs. (See FIG. 12) Figure 6. X. 2.3-1: Inventory Procedure 1. AF sends Inventory Request to the AIOTF, which is the same as step 1 - 4 in Figure 6.8.2.1-1  in Solution #8. 2. The AIOTF determines the Intermediate UEs to be used, based on the location information for  the Intermediate UEs, as well as area information provided by the AF. 3. The AIOTF creates and sends the 5GAIOT NAS message to request the Intermediate UE to  perform the Inventory. The 5GAIOT NAS message is delivered via the AMF and the NG-RAN. 4. The Intermediate UE determines radio resource or requests NG-RAN to determine radio  resource, which is used between AIoT Devices and Intermediate UE. 5. The Intermediate UE initiates inventory based on device information as well as the inventory  strategy information provided by the AF. The Intermediate UE may provide reader identity information to enable the AIoT devices to understand they are read by which Intermediate UE. Considering the mobility of the Intermediate UE, the reader identity information can be a combination of a UE ID and the location information. Where the UE ID can be an ID allocated to the UE when authorized to act as a reader i.e. the ID would in such case not disclose any current UE ID as SUPI, GPSI etc. 6. The AIoT Device reports the device ID to the Intermediate UE. If the Inventory procedure  indicates delta inventory only, and the AIoT Device has performed the inventory procedure towards this reader, it should skip the reporting. The device capability index can be provided by AIoT device optionally. 7. The Intermediate UE creates the 5GAIOT NAS message and sends towards the AIOTF to  transmit the AIoT Device ID and optional device capability index. The Intermediate UE may further provide location information (ULI) of the device, if requested from the AIOTF and allowed by local policy. The Intermediate UE may further provide an end indicator to inform the AIOTF whether it is the last inventory response for the inventory round. NOTE X: It’s up to RAN3 to determine the details and enhancements of the location information. 8. 10. The AIOTF validates the concealed device ID via interacting with AUSF and UDM. The  AIOTF may further get the device capability information from the device capability profile stored in the UDM based on the device capability index provided by the device. 9. The AIOTF together with AUSF and UDM, triggers authentication and authorization  procedures (i.e., like the authentication request / response between UE and network) towards the AIoT device. In Topology 2, the message between the AIOTF and the AIOT device is transmitted via the Intermediate UE over 5GAIOT NAS. Based on the device capability information from UDM, if the AIoT device is capable of persistent  received parameters, step 10 -step 11 are executed: 10. The security mode negotiation and security parameter exchanges are performed (i.e., like  the security mode command / complete between UE and network) . In Topology 2, the message between the AIOTF and the AIOT device is transmitted via the Intermediate UE over 5GAIOT NAS. 11. The AIOTF may further allocates CN device ID and sends to the AIoT device. 12. The AIOTF registers with the UDM (UECM) for the device access. 13. The AIOTF may further aggregate the reported device IDs and send to AF via the NEF, as  step 14 - 16 in Figure 6.8.2.1-1. 6.X. 2.4 Periodic Inventory The periodic inventory may be requested by the AF, so that network can trigger the inventory  periodically without the request from the AF directly. Considering the movement of the Intermediate UE, and the inventory is based on area information,  the periodic inventory should be initiated by the CN (i.e., the AIOTF) , which follows the instructions from the AF. When the period expires in the AIOTF, the AIOTF determines the Intermediate UEs based on the area information from the AF and the location information for the Intermediate UEs. Step 2 - 10 in Figure 6. X. 2.3-1 are executed. 6.X. 2.5 Command Procedure The command procedure is initiated by the AF to request one or more specific AIoT devices or a  group of AIoT devices in an area to execute the command. The command can be read, write, enable, disable, or execution request from the AF. The command result from the devices may or may not be required. Editor's note: The command for enable / disable is to be studied by SA3, and to be aligned with  SA3. (See FIG. 13A, 13B) Figure 6. X. 2.5-1: Command Procedure 1. The AF sends Command Request to the NEF, containing the command to be executed, area  information, device information, optional inventory strategy information, and optional report aggregation info. - The command is to be executed in the AIoT devices. It contains the command (e.g., read,  write, execute, etc. ) together with the command parameters. The command specific parameters (e.g. what to be executed) are to be included in an app layer container between AF and AIOT devices. - The area information could be the external geographical area information. - The device information could be device ID, device group ID, and / or external device type. - The location required indicates whether the AF requests the location information of the  AIoT devices provided. - The report aggregation info indicates whether the reports need to be aggregated or not for  a specific aggregation period, and whether the reports are needed after the aggregation period. 2. The NEF authorizes the request from the AF and perform the area translation to translate  external area information to the internal area information. Within the authorization, the NEF further check whether the AF is authorized to get the location information of the device. The NEF map the external device type to internal device type (i.e., device 1, device 2a, device 2b, etc. ) . NOTE X: It’s up to RAN to determine whether the device type is useful or not. Depending on whether area information is provided, step 3a or step 3b is performed: 3a. If area information is provided, the NEF sends NRF query with internal area information  to query AIOTFs serving the area. 3b. If area information is not provided, and device ID (s) are provided, the NEF query the  serving AIOTF from UDM. 4. The NEF sends the Command Request to the AIOTFs with the command, internal area  information, device information, device type, and optional location required information. 5. The AIOTF allocates a Transaction ID for the command, which is unique per command. The  AIOTF creates the AIOT Device NAS request message for the devices, based on the command information from the AF. The AIOTF get the registered devices, which match the device information. If no registered devices, step 6 - 13 are skipped. 6. The AIOTF creates the 5GAIOT NAS request message and sends to the Intermediate UE to  deliver the Command. The 5GAIOT NAS request message contains the AIOT Device NAS message, CN allocated device IDs for the registered devices, the Transaction ID, and optional location required information. The 5GAIOT NAS message is delivered via the AMF and the NG-RAN. 7. The Intermediate UE determines radio resource or requests NG-RAN to determine radio  resource, which is used between AIoT Devices and Intermediate UE. 8. The Intermediate UE initiates command delivery for the AIOT Device NAS request message  based on CN allocated device IDs, using dedicated signalling. Transaction ID is also included. NOTE X: RAN signaling details are to be further studied by RAN WGs. 9. The AIoT Device executes the command, creates an AIOT Device NAS response message  containing the command result and delivers the AIOT Device NAS response message, if the result needs to be sent back. The application specific result can be included in an app layer container. 10. The Intermediate UE creates the 5GAIOT NAS response message, including the AIOT  Device NAS response message, and sends to the AIOTF. The Intermediate UE may further provide location information (ULI) of the device, if requested from the AIOTF and allowed by local policy. The 5GAIOT NAS message is delivered via the NG-RAN and the AMF. NOTE X: It’s up to RAN3 to determine the details and enhancements of the location information. 11. The AIOTF gets the command result from the AIOT Device NAS response message. The  AIOTF may perform aggregation for the device ID, based on the report aggregation information provided by the AF. Within the aggregation period, the AIOTF will buffer the command results reported from the AIoT devices. The AIOTF may stop buffering and send report immediately, if it receives end indicator from the Intermediate UE in step 10. When the aggregation period expires, the AIOTF sends the report. For those command result after the aggregation period, if it is needed by the AF, the AIOTF sends the report. Otherwise, it will be dropped. 12. The AIOTF sends Command Response or Notification Request towards the NEF for the  command result or the aggregated command result information. 13. The NEF sends Command Response or Notification Request towards the AF for the  command result or the aggregated command result information. If the AIOTF determines all required devices have executed the command (e.g. when AF provide  the device ID (s) and those devices have executed the command in step 7 - 8) , the following steps are skipped. 14. For those unregistered devices (s) , the AIOTF initiate Inventory procedure as step 3 - 12  in Figure 6. X. 2.3-1 (step 11 - 12 will be skipped, if the device is not able to persistent received information) . In the inventory the Transaction ID is delivered, so that the registered devices which have executed command do not respond this inventory request from the Intermediate UE. 15. The AIOTF creates the 5GAIOT NAS request message and sends to the Intermediate UE  to deliver the Command to the responded device. The 5GAIOT NAS request message contains the AIOT Device NAS request message, AIoT device ID and optional location required information. The 5GAIOT NAS request message is delivered via the AMF and the NG-RAN. 16. The Intermediate UE determines radio resource or requests NG-RAN to determine radio  resource, which is used between AIoT Devices and Intermediate UE. 17. The Intermediate UE initiates command delivery for the AIOT Device NAS request  message to the device. 18. The AIoT Device executes the command, creates an AIOT Device NAS response message  containing the command result and delivers the AIOT Device NAS response message, if the result needs to be sent back. The application specific result can be included in an app layer container. 19. The Intermediate UE creates the 5GAIOT NAS response message, including the AIoT  Device NAS response message, and sends to the AIOTF. The Intermediate UE may further provide location information (ULI) of the device, if requested from the AIOTF and allowed by local policy. The 5GAIOT NAS message is delivered via the NG-RAN and the AMF. 20. As step 11 - 13, the AIOTF get the command result from the AIOT Device NAS response  message. It may perform the aggregation and send to NEF. The NEF delivers to the AF.

[0216] Annexes

[0217] According to embodiments of the present disclosure, following documents may be generated and submitted to 3GPP. 3GPP SA WG2 Meeting #162 S2-240xxxx Changsha, China, April 15 - 19, 2024 Source: Ericsson Title: KI #1, #2, #3, Sol#8: Update to add Command Procedure and remove ENs Document for: Approval Agenda Item: 19.14 Work Item  / Release: FS_AmbientIoT  / Rel-19 Abstract of the contribution: The contribution includes the command procedure in soluntion#8 and  remove some editor’s notes (ENs) . 1. Introduction Solution#8 “Inventory for AIoT Devices using AIOTF” was included in the TR 23.700-13 in  SA2#161. In this solution, the system architecture and inventory procedure are described. [Proposal-1] To make the solution#8 to be a complete solution, it is proposed to include the protocol  stack and command procedure need to be included. [Proposal-2] Furthermore, the solution title can be updated to “Support AIoT Devices using  AIOTF” , and it addresses all KIs. Some restrictions (e.g., “for Inventory” ) in the description are also removed. In Solution#8, it was proposed to differentiate the passive devices into two categories: - Extremely simple devices which are not capable of authentication, only the validation of device ID (i.e.  deconcealment) is performed. - Stronger devices which can perform authentication According to SA1 requirement in TS 22.369: “The 5G system shall enable security protection  suitable for Ambient IoT, without compromising overall 5G security protection. ” There are security risks for those extremely simple devices, if there are no authentication performed. In RFID, the RFID tags can also be authenticated by the reader, and the RFID tags can move to  “Secured” state. Capability wise, it is assumed that the extremely simple devices can also be authenticated by readers in the solution. However, due to power and capability limitation, they may not be able to have sufficient power and / or non-volatile to keep received parameters, including the security parameters and CN allocated device ID, for longer period. [Proposal-3] Enable the authentication for all devices, and differentiate the devices on whether they  are capable of persistent received parameters. There is an EN regarding the clarification of the authentication and CN allocated device ID steps: Editor's note: The use of the step 11-13 is FFS. Step 11 is about authentication, which is similar as the authentication request / authorization response  between UE and CN. Regarding the Security Mode Command / Complete is not mandated for device ID reporting, it needs  to be included in step 12, which is applicable for the devices which are able to persistent received parameters. In step 12, AIOTF can also allocate CN device ID (i.e. 5G-GUTI like device ID) and send to the  device. In Step 13, AIOTF register towards UDM as the serving instance for the device. Based on step 12 –13, the device is registered towards the network and device context has been  created in AIOTF, and network could use dedicated signalling for delivery in Command Procedure. [Proposal-4] Clarify as above and resolve the EN. In Solution#8, there is an EN regarding whether the device information need to be pre-provisioned in  CN. Editor's note: It is FFS whether it can be assumed for all scenarios that the device and the CN can be pre- provisioned with CN level per device information (e.g. network layer AIoT device ID, security material) . Depending on the business agreement between service provider (AF) and MNO, there are different  scenarios in the deployment: Scenario-1: the device information is pre-provisioned in UDM in MNO, including security  credentials. Scenario-2: the device information is pre-provisioned in service provider domain, for example, in UDM or AAA for security credentials only, similar as in SNPN deployments. [Proposal-4] Clarify as above and resolve the EN. In Solution #8, there is an EN regarding different device types. Editor's note: Details of device type is FFS. In RAN1#116, there is an agreement on the classification of the device types: - Device 1: ～1 μW devices. - Device 2a: ≤few hundred μW devices requiring external carrier wave. - Device 2b: ≤few hundred μW devices with internally-generated carrier wave. It could be beneficial to provide device type information to A-RAN, so that A-RAN can optimize the  delivery based on the specific device type. AF may optional provide external device type based on MNO classification, and NEF can map the external device type to the internal device type (i.e., device 1, device 2a, device 2b, etc. ) and transmit to A-RAN. [Proposal-5] Clarify device types and the mapping in the procedure and update the EN as above.  There is another EN relevant with device types: Editor's note: It is FFS whether none of the AIoT device types can initiate registration on their own.  Device 1 and Device 2a require external carrier wave to trigger DO traffic. Device 2b can trigger DO traffic without external carrier wave. Regarding the initial registration, depending on the progress of RAN, we may have clearer view on whether device 2b can initiate registration on its own. [Proposal-6] Update device types to align with RAN classification and update the EN as above.  In Solution#8, there is an EN regarding location information check: Editor's note: Details of what location information A-RAN provides is FFS. In SA2, there are no additional requirements identified for the location information provided by A- RAN. In RAN SID (RP-234058) , there is a RAN3-led task: “Identify potential solutions for locating an Ambient IoT device with no specification impact, e.g. reusing existing user location report, or minimal specification impact to convey location information to core network. ” If RAN3 identifies some special needs, the alignment can be done. [Proposal-7] Convert the EN to a NOTE to clarify that it depends on RAN3 progress. In Solution #8, there is an EN regarding the check of device capability and device ID Editor's note: The check of the device capability information and device ID is FFS. For the device ID, it is assumed that device provide a SUCI-like device ID and network convert the  SUCI-like device ID to SUPI-like device ID by deconcealment. [Proposal-8] Clarify the check / validate of the device ID is deconcealment, and resolve the EN. For the device capability, to improve the efficiency of the transmission, as well as for flexibility, it is  proposed to store the device capability profiles in UDM, and let device transmit the device capability index. Based on device capability index, AIOTF can fetch the proper device capability profile and understand the capability of the device. Right now, the capability information identified is about whether device is capable of persistent the information received from the network (e.g., security parameters and CN allocated device ID) . [Proposal-9] Clarify as above and resolve the EN. In Solution #8, there is an EN regarding the CM state of the device: Editor's note: It is FFS whether there are needs to enable functionality enabling similar functionality as CM-IDLE  and CM-CONNECTED states enables, and whether CN (i.e. AIOTF) needs to perform different actions accordingly, when DL data need to be delivered. Without RRC states, the existing definition of CM states is not applicable. However, network can  still differentiate the handling of the devices depending on whether the device is known by the network: - If the device is known by the network (device context stored in AIOTF) , AIOTF can deliver the DL message to  the serving A-RAN directly, and A-RAN could use dedicated signalling to deliver the DL message directly. - If the device is unknown by the network (device context not stored in AIOTF) , AIOTF needs to deliver the DL  message to all A-RAN nodes in the area to look up the device and deliver the DL message accordingly. [Proposal-10] Clarify as above and resolve the EN. 2. Proposal It is proposed to agree the following changes to 3GPP TR 23.700-13 v0.2.0: (see above 6.8 part) .

Claims

1.A method (200) performed by a network node, comprising:transmitting (S202) , to an ambient internet of things, AIoT, reader device, at least one request,wherein the request is for an operation of one or more AIoT devices, and includes a transaction identifier, ID for the one or more AIoT devices.2.The method (200) according to claim 1, wherein the request comprises a command request or an inventory request.3.The method (200) according to claim 1 or 2,wherein the at least one request comprises a first request including a first transaction ID, and a second request including a second transaction ID.4.The method (200) according to claim 3,wherein the second transaction ID and the first transaction ID are the same, and the second request is a repeat of the first request; orwherein the second transaction ID and the first transaction ID are the same, and the first request is a dedicated command request for a first set of AIoT devices in the one or more AIoT devices and the second request is a common inventory request for a second set of AIoT devices in the one or more AIoT devices; orwherein the second transaction ID and the first transaction ID are the same, and the first request is a dedicated command request for the first set of AIoT devices in the one or more AIoT devices and the second request is a dedicated command request without CN device IDs for a third set of AIoT devices in the one or more AIoT devices.5.The method (200) according to claim 4,wherein the dedicated command request for the first set of AIoT devices includes CN device IDs of the first set of AIoT devices.6.The method (200) according to any of claims 1 to 5,wherein the transaction ID is correlated to the operation;wherein the network node comprises an ambient internet of things function, AIoTF; and / orwherein the AIoT reader device comprises: an access network node, or an intermediate node.7.A method (300) performed by an ambient internet of things, AIoT, reader device, comprising:receiving (S302) , from a network node, at least one request;wherein a received request is for an operation of one or more AIoT devices, and includes a transaction identifier, ID for the one or more AIoT devices.8.The method according to claim 7, further comprising:transmitting (S304) , to the one or more AIoT devices, one or more of the at least one request.9.The method (300) according to claim 7 or 8, wherein the received request comprises a command request or an inventory request.10.The method (300) according to any of claims 7 to 9,wherein the one or more of the at least one request comprises a first request including a first transaction ID, and a second request including a second transaction ID.11.The method (300) according to claim 10,wherein the second transaction ID and the first transaction ID are the same, and the second request is a repeat of the first request; orwherein the second transaction ID and the first transaction ID are the same, and the first request is a dedicated command request for a first set of AIoT devices in the one or more AIoT devices and the second request is a common inventory request for a second set of AIoT devices in the one or more AIoT devices; orwherein the second transaction ID and the first transaction ID are the same, and the first request is a dedicated command request for the first set of AIoT devices in the one or more AIoT devices and the second request is a dedicated command request without CN device IDs for a third set of AIoT devices in the one or more AIoT devices.12.The method (300) according to claim 11,wherein the dedicated command request for the first set of AIoT devices includes CN device IDs of the first set of AIoT devices.13.The method (300) according to any of claims 7 to 12,wherein the transaction ID is correlated to the operation;wherein the network node comprises an ambient internet of things function, AIoTF; and / or wherein the AIoT reader device comprises: an access network node, or an intermediate node.14.A method (400) performed by an AIoT device, comprising:receiving (S402) , from an AIoT reader device, at least one request;wherein the request is for an operation of the AIoT device, and includes a transaction ID for the AIoT device.15.The method according to claim 14, wherein the request comprises a command request or an inventory request.16.The method (400) according to claim 14 or 15,wherein the at least one request comprises a first request including a first transaction ID, and a second request including a second transaction ID.17.The method (400) according to claim 16, further comprising:ignoring (S404) the second request, when the second transaction ID and the first transaction ID are the same.18.The method (400) according to any of claims 14 to 17,wherein the transaction ID is correlated to the operation; andwherein the AIoT reader device comprises: an access network node, or an intermediate node.19.An apparatus (80) for a network node in a communication network, comprising:a processor (802) ; anda memory (804) , the memory (804) containing instructions executable by the processor (802) , whereby the apparatus (80) for the network node is operative for:transmitting, to an ambient internet of things, AIoT, reader device, at least one request;wherein the request is for an operation of one or more AIoT devices, and includes a transaction identifier, ID for the one or more AIoT devices.20.The apparatus (80) according to claim 19, wherein the apparatus (80) is further operative to perform the method according to any of claims 2 to 6.21.An apparatus (90) for an AIoT reader device in a communication network, comprising:a processor (902) ; anda memory (904) , the memory (904) containing instructions executable by the processor (902) , whereby the apparatus (90) for the AIoT reader device is operative for:receiving, from a network node, at least one request,wherein the request is for an operation of one or more AIoT devices, and includes a transaction identifier, ID for the one or more AIoT devices.22.The apparatus (90) according to claim 21, wherein the apparatus (90) is further operative to perform the method according to any of claims 8 to 13.23.An apparatus (100) for an AIoT device in a communication network, comprising:a processor (1002) ; anda memory (1004) , the memory (1004) containing instructions executable by the processor (1002) , whereby the apparatus for the AIoT device is operative for:receiving, from an AIoT reader device, at least one request;wherein the request is for an operation of the AIoT device, and includes a transaction ID for the AIoT device.24.The apparatus (100) according to claim 23, wherein the apparatus (100) is further operative to perform the method according to any of claims 15 to 18.25.A computer-readable storage medium (110) storing instructions (1101) , which when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 18.26.A method (500) performed by a network node, comprising:receiving (S502) a first request for an operation of one or more AIoT devices;determining (S504) whether the one or more AIoT devices comprise one or more registered AIoT devices and / or one or more unregistered AIoT devices; andtransmitting (S506) , to at least one AIoT reader device, a second request for the operation of the one or more registered AIoT devices.27.The method (500) according to claim 26,wherein the network node transmits the second request by using a dedicated signalling with CN device IDs of the one or more registered AIoT devices, when the one or more AIoT devices comprise the one or more registered AIoT devices;wherein the second request is generated based at least on the first request; andwherein the AIoT reader comprises: an access network node and / or an intermediate node.28.The method (500) according to claim 26 or 27, further comprising:transmitting (S508) , to at least one AIoT reader device, an inventory request for the one or more unregistered AIoT devices, when the one or more AIoT devices comprise the one or more unregistered AIoT devices; andreceiving (S510) , from at least one AIoT reader device, one or more inventory responses generated by one or more responding AIoT devices;wherein the one or more inventory responses comprise device identification information and / or device capability information associated with the one or more responding AIoT devices.29.The method (500) according to claim 28, further comprising:determining (S512) whether the one or more responding AIoT devices include a first set of AIoT devices with a capability for supporting persistence of received information, and / or a second set of AIoT devices without the capability for supporting persistence of received information, based at least on the device capability information; andregistering (S514) the first set of AIoT devices in the CN, when the one or more responding AIoT devices include the first set of AIoT devices.30.The method (500) according to claim 29, further comprising:transmitting (S516) , to at least one AIoT reader devices, a third request for the operation of the first set of AIoT devices, by using a dedicated signalling including identifiers of the first set of AIoT devices; and / ortransmitting (S518) , to at least one AIoT reader devices, a fourth request for the operation of the second set of AIoT devices, by using a dedicated signalling without CN device IDs.31.The method (500) according to any of claims 26 to 30,wherein the third request, and the fourth request are generated based at least on the first request;wherein the first request comprises an inventory request or a command request;wherein the second request comprises an inventory request or a command request;wherein the third request comprises an inventory request or a command request; and / or wherein the fourth request comprises an inventory request or a command request.32.A method (600) performed by an AIoT reader device, comprising:receiving (S602) , from a network node, a second request for an operation of one or more registered AIoT devices; andtransmitting (S604) , to the one or more registered AIoT devices, the second request including identifiers of the one or more registered AIoT devices.33.The method (600) according to claim 32,wherein the second request includes CN device IDs of the one or more registered AIoT devices;wherein the second request is transmitted by using a dedicated signalling;wherein the second request is generated based at least on the first request; andwherein the AIoT reader device comprising: an access network node and / or an intermediate node.34.The method (600) according to claim 32 or 33, further comprising:receiving (S606) , from the network node, an inventory request for one or more unregistered AIoT devices;transmitting (S608) , to the one or more unregistered AIoT devices, the inventory request;receiving (S610) one or more inventory responses from one or more responding AIoT devices; andtransmitting (S612) , to the network node, the one or more inventory responses;wherein the one or more inventory responses comprise device identification information and / or device capability information associated with the one or more responding AIoT devices.35.The method (600) according to claim 34, further comprising:receiving (S614) , from the network node, a third request for the operation of a first set of AIoT devices with a capability for supporting persistence of received information;transmitting (S616) , to the first set of AIoT devices, the third request, by using a dedicated signalling including identifiers of the first set of AIoT devices;receiving (S618) , from the network node, a fourth request for the operation of a second set of AIoT devices without a capability for supporting persistence of received information; andtransmitting (S620) , to the second set of AIoT devices, the fourth request, by using a dedicated signalling without CN device IDs.36.The method (600) according to any of claims 32 to 35,wherein the third request, and the fourth request are generated based at least on the first request;wherein the first request comprises an inventory request or a command request;wherein the second request comprises an inventory request or a command request;wherein the third request comprises an inventory request or a command request; and / or wherein the fourth request comprises an inventory request or a command request.37.A method (700) performed by an AIoT device, comprising:receiving (S702) , from an AIoT reader device, a request for an operation of the AIoT device; andtransmitting (S704) , to the AIoT reader device, a result in response to the request;wherein the request includes an identifier of the AIoT device.38.The method (700) according to claim 37,wherein the AIoT device is registered in a CN during an inventory procedure;wherein the identifier of the AIoT device includes a CN device ID;wherein the AIoT device receives the request by using a dedicated signalling; and / or wherein the request comprises an inventory request or a command request.39.An apparatus (80) for a network node in a communication network, comprising:a processor (802) ; anda memory (804) , the memory (804) containing instructions executable by the processor (802) , whereby the apparatus (80) for the network node is operative for:receiving a first request for an operation of one or more AIoT devices;determining whether the one or more AIoT devices comprise one or more registered AIoT devices and / or one or more unregistered AIoT devices; andtransmitting, to at least one AIoT reader device, a second request for the operation of the one or more registered AIoT devices.40.The apparatus (80) according to claim 39, wherein the apparatus (80) is further operative to perform the method according to any of claims 27 to 31.41.An apparatus (90) for a AIoT reader device in a communication network, comprising:a processor (902) ; anda memory (904) , the memory (904) containing instructions executable by the processor (902) ,whereby the apparatus (90) for theAIoT reader device is operative for:receiving, from a network node, a second request for an operation of one or more registered AIoT devices; andtransmitting, to the one or more registered AIoT devices, the second request including identifiers of the one or more registered AIoT devices.42.The apparatus (90) according to claim 41, wherein the apparatus (90) is further operative to perform the method according to any of claims 33 to 36.43.An apparatus (100) for an AIoT device in a communication network, comprising:a processor (1002) ; anda memory (1002) , the memory (1004) containing instructions executable by the processor (1002) , whereby the apparatus (100) for the AIoT device is operative for:receiving, from an AIoT reader device, a request for an operation of the AIoT device;transmitting, to the AIoT reader device, a result in response to the request;wherein the request includes an identifier of the AIoT device.44.The apparatus (100) according to claim 43, wherein the apparatus (100) is further operative to perform the method according to claim 38.45.A computer-readable storage medium (110) storing instructions (1101) , which when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 26 to 38.

Images