Ambient IoT - inventory procedure

Abstract

Various embodiments provide for a method for performing inventory of Ambient Internet of Things (AIoT) devices where an AIoT function (AIoTF) can receive an inventory request from an Application Function (AF) and then determine the relevant Radio Access Network (RAN) nodes based on information in the inventory request, forward the inventory request to the RAN nodes, then receive the inventory response. The inventory request message can specify whether AIoT devices that have already been inventoried within a predefined time period should respond. The inventory request can also include instructions for the AIoTF to aggregate the inventory responses before reporting them back to the AF via a Network Exposure Function (NEF) in order to minimize signaling in the network.

Description

AMBIENT loT - INVENTORY PROCEDURERelated Applications

[0001] This application claims the benefit of international patent application serial number PCT / CN2024 / 077220, filed February 15, 2024, the disclosure of which is hereby incorporated herein by reference in its entirety.Technical Field

[0002] The present disclosure relates to a method and network nodes that can perform Ambient Internet of Things (AIoT) device inventory in a wireless communication system.Background

[0003] Third Generation Partnership Program (3GPP) Technical Report (TR) 23.700- 13 vO.l.O: "Study on Architecture support of Ambient power-enabled Internet of Thing (IOT) (Release-19)" was agreed in 3GPP SA2#160AHE. Within the TR, the architecture assumptions and requirements, as well as 3 key issues were agreed and included.

[0004] Architectural Assumptions• The following traffic types for Ambient loT Device are to be studied:• DT: Device-terminated; and• DO-DTT: Device-originated - device-terminated triggered.

[0005] NOTE 1: The final decision for including DO-A (Device-originated - autonomous) in the study depends on RAN decision.

[0006] - The following two connectivity topologies as defined in TR 38.848 [7] are to be studied:• Topology 1: Base station (BS) <-> Ambient loT (AIoT) Device;• Topology 2: BS <--> intermediate node <-> Ambient loT Device: Only a User Equipment (UE) can act as an intermediate node which is under the network control.• The communication spectrum is assumed to be licensed.• Handover is not supported.• RRC states are not supported by AIoT Devices (see RP-234058 [3])• No mobility (i.e. at least no cell selection / re-selection-like function) supported by AIoT Devices (see RP-234058 [3])

[0007] Architectural Requirements

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

[0009] Key Issue #1: Architecture support of Ambient loT Devices

[0010] Description

[0011] This key issue will address the system architecture to support Ambient loT Devices, especially on the following aspects:• - System architecture identified along with the solutions for KI#2 and KI#3.• - Authentication and authorization for the Ambient loT Device;• - Validation of the Ambient loT Device identifier;

[0012] NOTE 1: Format of the Ambient loT Device identifier is addressed in KI#2.• - Whether and how to secure device operations and services for an Ambient loT Device or a group of Ambient loT Devices;

[0013] NOTE 2: This key issue will take into account the outcome of RAN study in RP-234508 [3].

[0014] Key Issue #2: Identification, Subscription, Registration and Connection Management

[0015] This Key Issue pertains to the authorization and management of Ambient loT Devices to support Ambient loT services.

[0016] Considering that Ambient loT 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 loT devices which are under operator control.

[0017] Based on the above consideration, the aspects to be studied in this key issue include:Study whether subscription management, registration management and / or connection management are necessary for an Ambient loT Device or a group ofAmbient loT Devices and, if so, identify the necessary state machine(s), procedures and functionality considering the Ambient loT Devices capability and characteristics.• Study whether and how reachability and paging apply to Ambient loT Device(s) considering the Ambient loT devices capability and characteristics, and if so, what are the impacts.• Study how to identify Ambient loT Device or group of devices and how to format the identifier.

[0018] Key Issue #3: Support of Ambient loT

[0019] This Key Issue pertains to the AIoT services. Considering that AIoT Devices are a new type of reduced capabilities devices, the services / use cases to be supported include:• Inventory.• Command.

[0020] The key issue will study the following aspects:• Study how to support information transfer for Ambient loT services and related system functionality, including the information transfer for an Ambient loT device and for a group of Ambient loT Devices.

[0021] NOTE: Including whether there is a need to support session based transfer between Ambient loT Device and the network considering the device types and capabilities.• Study which of the enabled Ambient loT services are exposed to AF and how, e.g. for the case AF requests Ambient loT service for an Ambient loT Device and for a group of Ambient loT Devices.

[0022] A 3GPP proposal (S2-2401057) includes proposed changes to TR 23.700-13

[0023] The following excerpt is the proposed text from S2-2401057START OF CHANGES6.X Solution #X: Enable Ambient loT Management within 5GC to support AIoT services6.X.1 Key Issue mappingThis solution addresses the key issues in terms of architecture enhancements, AIoT Device management and Ambient loT services, i.e. for Kl#1 , Kl#2 and Kl#3.6.X.2 DescriptionThis solution proposes to introduce enhancements in the 5GS to support AloT Device management and Ambient loT services. In particular,Ambient loT specific NAS , to support transfer of Ambient loT data (operation commands or feedbacks) between AloT Device and 5GC directly, or via a UE acting as readerAmbient loT Management Function (AloTMF), responsible for the logic for handling of Ambient loT services including: execute the Ambient loT service request (e.g. inventory, read) in the network and handle any corresponding Ambient loT specific NAS, support inventory and message routing for AloT Devices, and if needed, securing device operations, authorize the Ambient loT service request, collect Ambient loT data and aggregate the reporting, collect charging data (if required).UDM enhancements to manage device subscription for AloT Devices. The device subscription contains Device ID information and device’s status information, e.g. the last serving node, indication whether the device’s ID is validated, indication whether the device is permanently disabled etc. This device subscription data is different from the UE subscription data.NEF enhancements to expose the 5GS Ambient loT capability so as to allow 3rdparty application to consume the Ambient loT services.Figure 6.X.2.1 -1 illustrates the enhancements to the 5GC to support AloT Device management and Ambient loT services.Editor's Note: It is FFS whether AMF is needed6.X.3 ProceduresThe following services are provided to support Ambient loT:- Inventory Service- Read Data ServiceEditor's Note: It is FFS how to support more Ambient loT services.6.x.3.1 Inventory ServiceThis clause provides end to end information flow for support of inventory service over 5GS.Figure 6.X.3.1-1 : Inventory Service Flow (See Figure 1)1 . AF seAnds Inventory Request carrying the area information and device inventory information2. NEF discovers one or more AloTMF(s) via NRF or local configuration using device inventory information.3. NEF forwards the Inventory Request to each of the selected AloTMF.4. AloTMF performs the permission control on the AF request. If authorised, the AloTMF selects the Ambient loT capable RANs.5. For each of the selected RAN, the AloTMF requests Inventory with the device inventory information.6. RAN / Reader executes the inventory operation towards the AloT Devices.7. If an AloT Device is selected in RAN, the AloT device sends its Device ID.8. AloTMF performs access control based on the device subscription received from the UDM, including Device ID validation.9. AloTMF reports the Device ID to the AF. Alternatively, the AloTMF combines multiple Device IDs into a single report in step 11 / 12.Steps 7~9 are repeated for each AloT Device.10 / 11 / 12. AloTMF collected the Inventory Complete message from each RAN, and informs the AF of the progress / completion of the inventory procedure.6.X.3.2 Read Data ServiceThis clause provides end to end information flow for support of Ambient loT Read Data Service.Figure 6.X.3.2-1 : Read Information Flow (See Figure 2)Key different steps compared to Figure 6.X.3.1 -1 :1 . AF sends Read Request, including the target Device ID information and Read command information.5. For each of the selected RAN, AloTMF sends a request with the Device ID information and NAS Read Command message.7. If an AloT Device is selected, the NAS Read Command is sent and NAS Read result is returned to the Reader / RAN and forwarded to the network.9. AloTMF reports the Device ID and Read results to the AF. Alternatively, the AloTMF combines multiple results into a single report in step 11 / 12.6.X.4 Impacts on services, entities and interfacesEditor's Note: It is FFS the impacts on services, entities and interfaces.END OF CHANGES

[0024] A second item, S2-2401058, includes proposed changes to TR 23.700-13

[0025] The following excerpt is the proposed text from S2-2401058:START OF CHANGES6.X Solution #X: AloT Device Function and Services6.X.1 Key Issue mappingThis solution provides an architecture overview, service overview and core AloT Device operation. It is a solution for Kl#1 , Kl#2 and Kl#3.6.X.2 DescriptionAloT Devices have reduced functionality compared to other types of UE (e.g. NR, eMTC or NB-loT). The AloT Device does not initiate connections to the network, any type of device originated services (e.g. message, communication services), and neither streaming of data to / from the network.An AloT Device is more akin to a memory device (for example a flash memory card) that supports basic operations of identification (for inventory operations) and reading andwriting data. The inventory, read and writing operations may be configured in the AloT Device to require authentication before they can be completed successfully.In order to ensure basic interoperability between AloT Devices, networks and applications, the information on the AloT Device can be partitioned into 2 types:- 3GPP Information, and- Application Information.The 3GPP Information is information that is known to and used by the 3GPP system, and can contain e.g. the following types of information:- Home Network Information: Home network of the AloT Device.- Device Network Identity: Identity provisioned to the AloT Device by the 3GPP network. When combined with the Home Network Information this allows unique identification of the individual AloT Device The 3GPP Information are expected to be used as parameters in e.g. in service operations from the AF or with other NFs, for example device identities in inventory responses etc., which is why the 3GPP system needs to be aware of them explicitly.The information about the owner is also stored in the Ambient loT device.The format and contents of the Application Information will depend upon the application and is optional to use. Examples of use of the Application Information include the device having a fixed application defined memory format, where certain locations in the memory are known to contain information read / written by the application, sensor reading(s) or it can be used for more complex message passing techniques, e.g. being used as a mailbox. The contents and use of the Application Information is not expected to be defined by 3GPP, however 3GPP needs to define the operation primitives that allow reading, writing etc. of the memory without detailed knowledge of its contents. The mapping of information / fields and their contents into physical memory is to be defined by Stage 3, including whether it is a flat continuous memory layout, split into memory pages (e.g. page 1 contains 3GPP Information region, and subsequent page(s) contain Application Information, etc.).As part of the provisioning process for an AloT Device to join a network, the AloT Device is provided with security materials and security settings which control what operations on which memory regions require what levels of security to be applied.6.X.3 Procedures6.x.3.1 OverviewThe following base operations are supported for AloT Devices:- Inventory: to discover the AloT device(s) in a specific area.- Read Data: Read application data from the memory of an AloT Device.- Write Data: Write application data to the memory of the AloT Device.- Disable Device: Disable the capability of an AloT Device to transmit RF signalsAll of the base operations follow the same core flow. The main difference between them are the parameters from the AF (e.g. for writing the call will contain the data to write, for reading a description of the data to be read etc.).The service operations to support the AloT Device operations use "Request-response" and "Subscribe-Notify" (including implicit-subscription) as described in TS 23.501 [x] clause 7.1 .2. The AF interacts with the NEF to request the 3GPP to perform the basicoperations. Depending on the request, the AF could be implicitly subscribed to receive notifications for its requests.6.x.3.2 NEF Services6.x.3.2.1 OverviewThe NEF supports a new Nnef_AloT service with the operations described.NOTE: The defined service operation inputs and outputs are example, with the final details expected to be defined by more detailed solutions.6.X.3.2.2 Inventory Operation6.X.3.2.2.1 OverviewThe inventory operations for the Nnef_AloT service has a request, response and inventory report service operations:6.x.3.2.2.2 Nnef_AloT_lnventory service operationService operation name: Nnef_AloT_lnventoryDescription: Request to perform an inventory operation.Inputs, Required: None.Inputs, Optional: For example, device filtering information, duration, etc.Outputs, Required: Status.Outputs, Optional: Correlation Information.6.x.3.2.2.3 Nnef_AloT_lnventory_Cancel service operationService operation name: Nnef_AloT_lnventory_CancelDescription: Request to cancel a requested inventory operation.Inputs, Required: Correlation Information.Outputs, Required: Status.6.x.3.2.2.4 Nnef_AloT_lnventory_Notify service operationService operation name: Nnef_AloT_lnventory_NotifyDescription: Inventory results from a requested inventory operation.Inputs, Required: Correlation Information.Outputs, Required: Correlation Information, Status, List of AloT Devices (e.g. Device Network Identity, etc.).6.X.3.3.3 Read Operation6.x.3.3.3.1 OverviewThe read operations for the Nnef_AloT service has a request, response and read data report service operations:6.x.3.3.3.2 Nnef_AloT_Device_Read service operationService operation name: Nnef_AloT_Device_ReadDescription: Request to perform a read operation.Inputs, Required: AloT Device identity to read (e.g. Device Network Identity, etc.), memory and length to read.Inputs, Optional: For example, timeout in case AloT Device is not located, etc.Outputs, Required: Status.Outputs, Optional: Correlation Information.6.x.3.3.3.3 Nnef_AloT_Device_Read_Cancel service operationService operation name: Nnef_AloT_Device_Read_CancelDescription: Request to cancel a requested read operation.Inputs, Required: Correlation Information.Outputs, Required: Status.6.x.3.3.3.4 Nnef_AloT_Device_Read_Notify service operationService operation name: Nnef_AloT_Device_Read_NotityDescription: Return information read.Inputs, Required: Correlation Information, Status.Inputs, Optional: Data read. Outputs, Required: None.6.X.3.3.4 Write Operation6.x.3.3.4.1 OverviewThe write operations for the Nnef_AloT service has a request, response and write status report service operations:6.x.3.3.4.2 Nnef_AloT_Device_Write service operationService operation name: Nnef_AloT_Device_WriteDescription: Request to perform a write operation.Inputs, Required: AloT Device identity to write, memory location and length to write, data to write.Inputs, Optional: For example, timeout in case the AloT Device is not located, etc.Outputs, Required: Status.Outputs, Optional: Correlation Information.6.x.3.3.4.3 Nnef_AloT_Device_Write_Cancel service operationService operation name: Nnef_AloT_Device_Write_CancelDescription: Request to cancel a requested write operation.Inputs, Required: Correlation Information.Outputs, Required: Status.6.x.3.3.4.4 Nnef_AloT_Device_Write_Notify service operationService operation name: Nnef_AloT_Device_Write_NotifyDescription: Return status of write to an AloT device.Inputs, Required: Correlation Information, Status.Inputs, Optional: None.Outputs, Required: None.6.x.3.4.5 Disable AloT Device Operation6.x.3.3.5.1 OverviewThe disable operations for the Nnef_AloT service has a request, response and notify report service operations. If the AloT Device is disabled permanently then the network may also discard any stored state for the AloT Device and no further operations for that AloT Device will succeed.6.x.3.3.5.2 Nnef_AloT_Device_Disable service operationService operation name: Nnef_AloT_Disable_DeviceDescription: Request to disable RF transmission from an AloT Device.Inputs, Required: AloT Device identity to disable (e.g. Device Network Identity, etc.), duration AloT Device should disable or permeant.Inputs, Optional: For example, timeout in case AloT Device is not located, etc.Outputs, Required: Status.Outputs, Optional: Correlation Information.6.x.3.3.5.3 Nnef_AloT_Device_Disable_Cancel service operationService operation name: Nnef_AloT_Device_Disable_Cancel Description: Request to cancel a requested disable operation.Inputs, Required: Correlation Information.Outputs, Required: Status.6.x.3.3.5.4 Nnef_AloT_Device_Disable_Notity service operationService operation name: Nnef_AloT_Disable_Disable_NotifyDescription: Return status of disable AloT Device.Inputs, Required: Correlation Information, Status.Inputs, Optional: None.Outputs, Required: None.6.X.4 Impacts on services, entities and interfacesAloT Device:- An AloT Device supports the operations and functionalities described.NEF:- Supports the new service operations for AloT Devices.RAN:- Support of inventory, reading and writing NAS messages to / from an AloT Device.CN:- Other NFs (new or existing) will be impacted to support the AloT Device operations. The details of those impacts will be defined by other solutions.END OF CHANGESSummary

[0026] Various embodiments provide for a method for performing inventory of Ambient Internet of Things (AloT) devices where an AloT function (AIoTF) can receive an inventory request from an Application Function (AF) and then determine the relevant Radio Access Network (RAN) nodes based on information in the inventory request, forward the inventory request to the RAN nodes, then receive the inventory response. The inventory request message can specify whether AloT devices that have already been inventoried within a predefined time period should respond. The inventory request can also include instructions for the AIoTF to aggregate the inventory responses before reporting them back to the AF via a Network Exposure Function (NEF) in order to minimize signaling in the network.

[0027] In an embodiment, a method of performing AloT device inventory performed by an AIoTF includes receiving an inventory request, originating from an AF comprising area information, device information, inventory strategy information, location required information and report aggregation information, discovering one or more radio access networks based on the area information, and forwarding the inventory request to one or more radio access network nodes associated with the one or more radio access networks. The method also includes receiving one or more inventory responses from the one or more radio access network nodes, wherein the one or more inventory responses comprise device identification information associated with one or more AloT devices and forwarding the one or more inventory responses toward the AF via a NEF.

[0028] In an embodiment, the one or more inventory responses comprise location information associated with the one or more AIoT devices in response to the inventory request forwarded to the one or more radio access network nodes comprising a location request.

[0029] In an embodiment, the one or more inventory responses comprise an end indicator indicating whether there will be an additional inventory response.

[0030] In an embodiment, in response to information received in response to the validation indicating that an AIoT device is capable of handling authentication and authorization, the method further comprises triggering authentication and authorization towards the AIoT device via a radio access network node of the one or more radio access network nodes associated with the AIoT device and registering the AIoT device with a network function by recording a serving AIOTF for the AIoT device in the network function.

[0031] In an embodiment, the method further comprises providing a core network device identifier to the AIoT device.

[0032] In an embodiment, the network function is a Unified Data Management Function.

[0033] In an embodiment, the method further comprises based on the report aggregation information, buffering the device identification information from a plurality of AIoT devices and on expiration of an aggregation period, forwarding aggregated device identification from the plurality of AIoT devices to the NEF.

[0034] In an embodiment, the one or more inventory responses to the NEF comprise reports that were not omitted based on the inventory strategy information received from the NEF.

[0035] In an embodiment, the area information is internal geographical area information, the device information is at least one of a device identifier, a device group identifier, or a device type, the inventory strategy information comprises an inventory frequency, inventory period and an indicator 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, the location required information indicates whether an AF, requests the location information of the AIoT devices or the report aggregationinformation indicates whether reports are to be aggregated or not for a specific aggregation period, and whether the reports are needed after the aggregation period.

[0036] In an embodiment, the method further includes facilitating validation of the device identification information with an Authentication Server Function (AUSF) and the UDM and confirming device capability information with the UDM.

[0037] In an embodiment, a network node can be provided to perform the embodiments of the AIoTF described above.

[0038] In an embodiment, a method for performing AIoT device inventory performed by a NEF is provided. The method includes receiving, from an AF, an inventory request comprising external area information, device information, inventory strategy information, location required information and report aggregation information, providing, to an AIoTF an inventory request comprising internal area information, the device information, the inventory strategy information, the location required information and the report aggregation information, and receiving, from the AIoTF, one or more inventory responses, wherein the inventory responses comprise device identification information associated with one or more AIoT devices.

[0039] In an embodiment, the method further includes discovering the AIoTF based on a query to a Network Repository Function (NRF).

[0040] In an embodiment, the device information is at least one of a device identifier, a device group identifier, or a device type, the inventory strategy information comprises an inventory frequency, inventory period and an indicator 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, the location required information indicates whether the AF requests the location information of the AIoT devices, and the report aggregation information indicates whether reports are to be aggregated or not for a specific aggregation period, and whether the reports are needed after the aggregation period.

[0041] In an embodiment, the method further includes forwarding the one or more inventory responses to the AF.

[0042] In an embodiment, the method further includes determining that the AF is authorized to receive device location information, and translating the external area information to the internal area information

[0043] In an embodiment, a network node that performs the method performed by the NEF as described above is provided.

[0044] In an embodiment, a method of performing AIoT device inventory performed by a Radio Access Network (RAN) node is provided. The method includes performing an inventory procedure based on AIoT device information and inventory strategy information received from an AIoTF, receiving from one or more AIoT devices, device identification information and device capability information, and forwarding one or more inventory responses to the AIoTF comprising the device identification information and device capability information of the one or more AIoT devices.

[0045] In an embodiment, the one or more inventory responses comprise location information associated with the one or more AIoT devices in response to an inventory request received from the AIoTF comprising a location request.

[0046] In an embodiment, the method further comprises receiving an inventory request from the AIoTF.

[0047] In an embodiment, the inventory strategy information requests AIoT devices that haven't performed an inventory procedure or have performed the inventory procedure within a predetermined period of time.

[0048] In an embodiment, a RAN node is provided that performs the method described above.Brief Description of the Drawings

[0049] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0050] Figure 1 illustrates an exemplary message sequence chart of an existing inventory service flow according to one or more embodiments of the present disclosure;

[0051] Figure 2 illustrates an exemplary message sequence chart of an existing read information flow according to one or more embodiments of the present disclosure;

[0052] Figure 3 illustrates one example of a cellular communications system in which embodiments of the present disclosure may be implemented;

[0053] Figure 4 illustrates a wireless communication system represented as a Fifth Generation (5G) network architecture composed of core Network Functions (NFs);

[0054] Figure 5 illustrates a 5G network architecture using service-based interfaces between the NFs in the Control Plane (CP);

[0055] Figure 6A and 6B depict a message sequency chart of a method for performing Ambient Internet of Things (AIoT) device inventory according to one or more embodiments of the present disclosure;

[0056] Figure 7 is a schematic block diagram of a network node according to some embodiments of the present disclosure;

[0057] Figure 8 is a schematic block diagram that illustrates a virtualized embodiment of the network node according to some embodiments of the present disclosure;

[0058] Figure 9 is a schematic block diagram of the network node according to some other embodiments of the present disclosure;

[0059] Figure 10 is a schematic block diagram of a wireless communication device according to some embodiments of the present disclosure; and

[0060] Figure 11 is a schematic block diagram of the wireless communication device according to some other embodiments of the present disclosure.Detailed Description

[0061] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0062] Radio Access Node: As used herein, a "radio access node" or "radio network node" or "radio access network node" is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and / or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macrobase station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station (e.g., a network node that implements a gNB Central Unit (gNB-CU) or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.

[0063] Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

[0064] Network Node: As used herein, a "network node" is any node that is either part of the RAN or the core network of a cellular communications network / system.

[0065] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0066] Note that, in the description herein, reference may be made to the term "cell"; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

[0067] There currently exist certain challenge(s). The proposals in S2-2401057 and S2-2401058 focus quite a lot on the passive Ambient Internet of Things (loT) devices with extremely limited capabilities. For those devices, there are the following issues:• All Devices respond to the inventory procedure, which is not efficient. If the Ambient loT (AIoT) devices has responded to the inventory procedure, they do not need to respond again.• No authentication and authorization with the network. Network simply validate the device ID reported by the AIoT device. It is not a secure solution.• There is no periodic inventory from the network. Each time, the request must be initiated from the Application Function (AF). Which is not efficient and does not enable the network to provide enhanced services like keeping track of the AIoT devices.

[0068] Besides that, there are the following drawbacks in the solutions:• Lack of positioning information to be reported to AF. AF does not know the position of the device.• No aggregation of the information sent to AF for the inventory result (device ID reported), there would be signaling flood in the network, which is less efficient and may cause performance issues in network and AF.

[0069] Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges.

[0070] Various embodiments provide for a method for performing inventory of Ambient Internet of Things (AIoT) devices where an AIoT function (AIoTF) can receive an inventory request from an Application Function (AF) and then determine the relevant Radio Access Network (RAN) nodes based on information in the inventory request, forward the inventory request to the RAN nodes, then receive the inventory response. The inventory request message can specify whether AIoT devices that have already been inventoried within a predefined time period should respond. The inventory request can also include instructions for the AIoTF to aggregate the inventory responses before reporting them back to the AF via a Network Exposure Function (NEF) in order to minimize signaling in the network.

[0071] The proposed embodiments enable avoiding having to have all AIoT devices responding to an inventory procedure all the same time. Additionally, authentication and authorization of the AIoT devices can be made to the network, and the network can keep track of all devices. Similarly, location information can be provided to the AF from the AIoT device, and the device reporting can be aggregated.

[0072] Certain embodiments may provide one or more of the following technical advantage(s). The solution does not request all devices respond to the inventory procedure each time, which is more efficient. The solution enables authentication and authorization based on device capabilities. With periodic inventory introduced, thenetwork can keep track of the devices. The solution enables device location information provided to the AF. The solution enables report aggregation to minimize signaling in the network and towards AF.

[0073] Figure 3 illustrates one example of a cellular communications system 300 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 300 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC). In this example, the RAN includes base stations 302-1 and 302-2, which in the 5GS include NR base stations (gNBs), controlling corresponding (macro) cells 304-1 and 304-2. The base stations 302-1 and 302-2 are generally referred to herein collectively as base stations 302 and individually as base station 302. Likewise, the (macro) cells 304-1 and 304-2 are generally referred to herein collectively as (macro) cells 304 and individually as (macro) cell 304. The RAN may also include a number of low power nodes 306-1 through 306-4 controlling corresponding small cells 308-1 through 308-4. The low power nodes 306-1 through 306-4 can be small base stations (such as pico or femto base stations) or RRHs, or the like. Notably, while not illustrated, one or more of the small cells 308-1 through 308-4 may alternatively be provided by the base stations 302. The low power nodes 306-1 through 306-4 are generally referred to herein collectively as low power nodes 306 and individually as low power node 306. Likewise, the small cells 308-1 through 308-4 are generally referred to herein collectively as small cells 308 and individually as small cell 308. The cellular communications system 300 also includes a core network 310, which in the 5G System (5GS) is referred to as the 5GC. The base stations 302 (and optionally the low power nodes 306) are connected to the core network 310.

[0074] The base stations 302 and the low power nodes 306 provide service to wireless communication devices 312-1 through 312-5 in the corresponding cells 304 and 308. The wireless communication devices 312-1 through 312-5 are generally referred to herein collectively as wireless communication devices 312 and individually as AIoT device 312. In the following description, the wireless communication devices 312 are oftentimes UEs, but the present disclosure is not limited thereto.

[0075] Figure 4 illustrates a wireless communication system represented as a 5G network architecture composed of core Network Functions (NFs), where interactionbetween any two NFs is represented by a point-to-point reference point / interface. Figure 4 can be viewed as one particular implementation of the system 300 of Figure 3.

[0076] Seen from the access side the 5G network architecture shown in Figure 4 comprises a plurality of UEs 312 connected to either a RAN 302 or an Access Network (AN) as well as an AMF 400. Typically, the R(AN) 302 comprises base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5GC NFs shown in Figure 4 include a NSSF 402, an AUSF 404, a UDM 406, the AMF 400, a SMF 408, a PCF 410, a AIoTF 416 which can be stand alone, or as shown in Figure 4 as part of AMF 400. and an Application Function (AF) 412.

[0077] Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE 312 and AMF 400. The reference points for connecting between the AN 302 and AMF 400 and between the AN 302 and UPF 414 are defined as N2 and N3, respectively. There is a reference point, Nil, between the AMF 400 and SMF 408, which implies that the SMF 408 is at least partly controlled by the AMF 400. N4 is used by the SMF 408 and UPF 414 so that the UPF 414 can be set using the control signal generated by the SMF 408, and the UPF 414 can report its state to the SMF 408. N9 is the reference point for the connection between different UPFs 414, and N14 is the reference point connecting between different AMFs 400, respectively. N15 and N7 are defined since the PCF 410 applies policy to the AMF 400 and SMF 408, respectively. N12 is required for the AMF 400 to perform authentication of the UE 312. N8 and N10 are defined because the subscription data of the UE 312 is required for the AMF 400 and SMF 408.

[0078] The 5GC network aims at separating UP and CP. The UP carries user traffic while the CP carries signaling in the network. In Figure 4, the UPF 414 is in the UP and all other NFs, i.e., the AMF 400, SMF 408, PCF 410, AF 412, NSSF 402, AUSF 404, and UDM 406, are in the CP. Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.

[0079] The core 5G network architecture is composed of modularized functions. For example, the AMF 400 and SMF 408 are independent functions in the CP. SeparatedAMF 400 and SMF 408 allow independent evolution and scaling. Other CP functions like the PCF 410 and AUSF 404 can be separated as shown in Figure 4. Modularized function design enables the 5GC network to support various services flexibly.

[0080] Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the CP, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The UP supports interactions such as forwarding operations between different UPFs.

[0081] Figure 5 illustrates a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points / interfaces used in the 5G network architecture of Figure 4. However, the NFs described above with reference to Figure 4 correspond to the NFs shown in Figure 5. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In Figure 5 the service based interfaces are indicated by the letter "N" followed by the name of the NF, e.g. Namf for the service based interface of the AMF 400 and Nsmf for the service based interface of the SMF 408, etc. The NEF 500 and the NRF 502 in Figure 5 are not shown in Figure 4 discussed above. However, it should be clarified that all NFs depicted in Figure 4 can interact with the NEF 500 and the NRF 502 of Figure 5 as necessary, though not explicitly indicated in Figure 4.

[0082] Some properties of the NFs shown in Figures 4 and 5 may be described in the following manner. The AMF 400 provides UE-based authentication, authorization, mobility management, etc. A UE 312 even using multiple access technologies is basically connected to a single AMF 400 because the AMF 400 is independent of the access technologies. The SMF 408 is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF 414 for data transfer. If a UE 312 has multiple sessions, different SMFs 408 may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF 412 provides information on the packet flow to the PCF 410 responsible for policy control in order to support QoS. Based on the information, the PCF 410 determines policies about mobility and session management to make the AMF 400 and SMF 408 operate properly. The AUSF 404 supports authentication function for UEs or similar and thus stores data for authentication of UEsor similar while the UDM 406 stores subscription data of the UE 312. The Data Network (DN), not part of the 5GC network, provides Internet access or operator services and similar.

[0083] An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

[0084] This solution proposes an enhanced architecture based on 5GS to support AIoT Devices. The functional entities defined in TS 23.501 are reused with the exception for the following additions.

[0085] AIoT Function (AIoTF): AIoTF is introduced to support AIoT services, with some AMF's functionalities integrated, which includes RAN connectivity, Registration Management, Device Reporting (for some AIoT devices), 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 RAN, for Device Originated Device Terminated Triggering DO-DTT / DT traffic types, routing the response from RAN to AF (via NEF) for DO-DTT traffic type

[0086] 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 core network (CN) related information (e.g. serving NF)

[0087] NEF: NEF is enhanced to expose AIoT specific services towards AF

[0088] CHF: CHF is enhanced for the charging for AIoT services

[0089] NRF: NRF is enhanced to support the new NF type AIoTF and the corresponding NF profile

[0090] AUSF: AUSF is enhanced for the authentication for the access from AIoT devices

[0091] This solution addresses Key Issue #2: Identification, Subscription, Registration and Connection management that was described in the Background.

[0092] The AIoT device ID need to be introduced to uniquely identify the device. The AIoT device ID can be regarded as a combination of the subscription ID (SUPI / SUCI) and ME identity (PEI). The AIoT device ID contains or can contain the following nonlimiting parts:• Network ID: the network which hosts the device credentials.• Application ID: the application within the network• Unique ID: The unique ID within the application within the network

[0093] However, depending on AIoT device capability, trust model, one or more IDs (from above) can be merged or mapped to Network ID or Application ID or Unique ID. For e.g., in one application model, the device has only subscription ID (SUPI / SUCI), then this ID will also do the job of application ID. In another option, there is separate subscription ID and separate application ID (e.g., like Evolved Packet Core (EPC) is Radio Frequency Identification (RFID).

[0094] In addition, there can be a device (hardware ID), e.g., like International Mobile Equipment Identity (IMEI) or Tag ID (TID) in RFID, which 3GPP network or application can use to control or check the device's operation in addition to the above discussed IDs. This device (hardware) ID can also be considered under device ID or not depending on solution or protocol flow.

[0095] The AIoT device information can be stored in UDM, which is similar to 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).

[0096] For registration management, the passive AIoT devices cannot initiate procedures and send messages e.g. the registration actively without trigger from another entity. They can only respond to the commands from the network (or another entity, which makes them to be discovered by the network. The procedure that can be used is here called inventory procedure.

[0097] After that, the authentication and authorization can be performed, and the CN allocated device ID which is similar as 5G-GUTI can be passed to the device for further usage, if the devices are capable of handling them. The network can also keep track of the serving NFs, so that the network can serve the request effectively which is sent from the AF targeting to a specific AIoT device.

[0098] For connection management, without Radio Resource Control (RRC) states in RAN, the CM states are not applicable as well. The network handles the AIoT devices in the same way, without differentiating CM-IDLE state and CM-CONNECTED state. For DL data towards an AIoT device, the network does not differentiate core network-initiated paging or downlink (DL) Non-Access Stratum (NAS) Transport, as the network cannotassume whether the device is reachable or not. The CN sends the DL data to the last serving RAN node.

[0099] As some AIoT devices, e.g. passive, does not by themselves initiate procedures to update the serving RAN node, if the AIoT device moves to a new serving RAN node nor to another area (cell, TA or similar). The AIoT devices need to respond to the commands from the new serving RAN node. The procedure that can be used, e.g. to track the AIoT device's location, can be called a periodic inventory procedure.

[0100] In periodic inventory procedure, as the AIoT devices already performed the authentication and authorization and provided with the CN allocated device ID, those steps do not need to be performed again.

[0101] Figure 6A and 6B depict a message sequency chart of a method for performing Ambient Internet of Things (IOT) device inventory according to one or more embodiments of the present disclosure. It is to be appreciated that dashed lines in the figure depict steps that are optional.

[0102] At 602, the AF 412 sends Inventory Message Request to the NEF 500, containing the area information, device information, optional inventory strategy information, and optional report aggregation info.

[0103] The area information could be the external geographical area information.

[0104] The device information could be device ID, device group ID, and / or device type. Or can be a list of Device IDs, that can be used to determine when a complete inventory has been achieved.

[0105] The inventory strategy information contains, e.g., the inventory frequency and inventory period to guide the readers (e.g. RAN) to perform the inventory periodically. It also indicates whether:• all the targeting devices need to respond, or• only those who haven't performed the inventory procedure should respond.• Both devices that have not ever performed inventory to the network and devices that have been inventoried / registered to the network but have not been in communication with the network for a configured period. a. In case passive device is not able to maintain timer(s) to know how long it has been inventoried / registered, network (RAN / reader) can write the time when inventory takes place to memory of the device and provide the timestamp together with DL command for inventory. In this case, thedevice only responds to a new inventory command if the gap between the timestamp in DL command and the time value stored is greater than a configured period. This can be determined by CN (e.g., AIoTF) and provided to the devices via DL signaling and is stored in device memory / local variables or pre-defined / pre-configured. b. In case devices anyway reply, the network (e.g. CN e.g. AIoTF or RAN) can omit to forward the replies from these devices (see step 14).• A time period after which an inventoried / registered device is required to respond inventory command / request from the network.• Note, more information can be included depending on the use case, capabilities, etc. a. For instance, few bits or flag can be included indicating the time window or session or period, which means if users haven't responded during this specific window / period / session associated with an inventory command, then only those users will attempt to respond. b. In another example, few bits or flags can be indicated in inventory command asking users to respond, even though they are inventoried earlier, only if they have more data or the data value(s) changed compared to last report.• Optionally few bits indicate the source / id (e.g. AF ID) and optionally sequence of the request.

[0106] The location required indicates whether the AF requests the location information of the AIoT devices provided.

[0107] The report aggregation information 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.

[0108] At 604, the NEF 500 authorizes the request from the AF 412 and performs the area translation to translate external area information to the internal area information.Within the authorization, the NEF 500 further check whether the AF 412 is authorized to get the location information of the AIoT device 312.

[0109] At 606, the NEF 500 can optionally send the NRF 502 a query with internal area information to query AIoTFs serving the area.

[0110] At 608, the NEF 500 sends the Inventory Request to the AIoTFs 416 with the internal area information, device information and optionally inventory strategy information, optional location required information, optional report aggregation information.

[0111] At 610, the AIoTF 416 discovers RANs based on internal area information configured by an Operations, Administration and Maintenance function (OAM) (e.g. RAN node id mapping to area) or e.g. area information that the AIoTF 416 retrieved from RAN at management procedures (i.e. similar as NG-Application Protocol (NGAP) Setup and NGAP Configuration Update procedures in TS 38.413) in which the RAN nodes 302 declares the areas they serve (area can e.g. be a string that maps to e.g. a building, certain room etc.).

[0112] At 612, the AIoTF 416 sends an NGAP message (Inventory Request) to the RAN nodes 302 with the internal area information, device information and inventory strategy information, and optional location required information.

[0113] In an embodiment, the AIoTF 416 will send the inventory request only when it is the AIoTF 416 that is to initiate the periodic inventory procedure. The inventory strategy should only request AIoT devices who haven't performed the inventory procedure at all should respond. As an alternative, the inventory strategy can request AIoT devices who haven't performed the inventory procedure within a configured period should respond.

[0114] The RAN node 302 (reader, e.g., gNB (RAN) or UE assigned by gNB) performs inventory procedure at step 614 based on device information as well as the inventory strategy information provided by the AF 412. In addition to, or based on, information received from CN, the RAN node 302 may provide further information in the DL command / message, for example:

[0115] The RAN may provide reader identity information (e.g. RAN ID) to enable the AIoT devices to understand they are read / interrogated by which RAN node.

[0116] In an embodiment the RAN node 302 can perform inventory without receiving an inventory request from the AIoTF 416 if it is RAN 302 who initiates the periodic inventory procedure. The inventory strategy should only request AIoT devices who haven't performed the inventory procedure at all or haven't performed the inventory procedure within a configured period should respond.

[0117] The RAN 302 may provide information identifying the inventory request that the RAN 302 receives from the AIoTF 416, e.g. part of the inventory strategy information, e.g. inventory id set by the AF 412 or the AIoTF 416. a. The information identifying the source, and in some cases the information need to come from the CN / AF, of the request and optionally a sequence e.g. PLMN ID, RAN node ID, CN ID, AF ID, location (e.g. Access Stratum specific location cell id or similar) and the AloT Device takes the source and / or sequence into account to determine if the AloT Device has replied to the request. The information related to at least the last replied request need to be stored in the AloT device.

[0118] The RAN 302 may provide information identifying the network entity / function where the inventory request is originated, e.g., AIoTF ID / AMF ID / PLMN ID.

[0119] The RAN 302 may provide the current time (timestamp) as part of DL command / message so that device can compare with the time it was possibly earlier inventoried by the same network (gNB / AIoTF / PLMN) to determine whether to respond to the DL command / message or not.

[0120] Upon receiving request from AIoTF 416, RAN nodes can trigger request as per policies indicated by CN and combined with implementation (request triggering by RAN nodes subject to radio resource availability which only RAN node 302 is aware of). For example, in one policy, the RAN node must trigger an inventory within a time window and leave to RAN node when to trigger within that time window. In one option / policy, if a RAN node gets multiple inventory requests (NGAP messages) from CN / AIoTF within the same or overlapping time window, then RAN node 302 can combine or send one inventory request over RAN interface.

[0121] At 616, the AloT Device 312 reports the device ID, and device capability information (which can be optional or not). If the Inventory procedure indicates only who haven't performed the inventory procedure should respond, and if the AloT Device 312 has performed the inventory procedure towards this RAN node 302, it should skip the reporting.

[0122] In an embodiment, the AloT device 312 responds if it has not responded the inventory procedure, or it has responded the inventory procedure in other RAN nodes, or it has responded the inventory procedure for a time longer than a configured period / threshold. The device may provide CN allocated device ID if it received before.

[0123] The AloT Device can identify whether the AloT Device performed the inventory by comparing the network / reader identity information (e.g. RAN ID, inventoryid, information of network entity / fu notion that initiates inventory request) in the request from the RAN with the last performed inventory (e.g., information stored in memory or in local variables / parameters for the most recent inventory), or based on pre-configured thresholds. The AIoT Device (especially passive device) can know how long it is since the last time it was inventoried / registered to the network, as described above.

[0124] At 618, the RAN node 302 sends an NGAP message (Inventory Response or Inventory Notify) to the AIoTF, containing the device ID and the above said device capability information provided by the device (device capability information can be optional or not depending on solution / signaling / message design). The RAN may further provide user location information (ULI) of the device, if requested from the AIoTF and allowed by local policy. The RAN may further provide an end indicator to inform the AIoTF whether it is the last inventory response for the inventory round. RAN may need to perform multiple rounds of inventory over air interface to allow all / most of devices access opportunities to provide their device ID. In case CN sets the time that RAN needs to provide inventory results (aggregated or not), RAN may ask for extension to be able to get all / most of devices inventoried. The ULI can be an extension of the User Location Information in TS 38.413 clause 9.3.1.16 or be a separate new type of information e.g. see ULI example in clause 2.7.1.3.

[0125] At 620, the AIoTF 416 validates the device ID via interacting with AUSF 404 and UDM 406. The AIoTF 416 may further check the device capability information from the device subscription data stored in the UDM 406 for the device capability information.

[0126] Based on the device capability information from the device 312 and / or device subscription data in UDM 406, if the AIoT device 312 is capable of handling authentication and authorization, step 622 - step 626 are executed.

[0127] At step 622, the AIoTF 416 together with AUSF 404 and UDM 406, triggers authentication and authorization procedures towards the AIoT device 312. As the crypto operation to support authentication may require heavy processing, CN (AIoTF) can inform RAN node 302 to send a common DL command / message to require AIoT devices being inventoried / registered to prepare for upcoming authentication by pre-computing relevant crypto values. In case device (with low capability) needs more time to perform request for authentication, it should be possible for the device to reply with an indication to notify network the processing status (i.e., done or not done yet) so thatnetwork can wait for fi nal / actual response. This is similar to the Challenge command in RFID C1G2 protocol.

[0128] In an embodiment, the authentication and authorization step at 622 can be skipped if the AIoTF 416 finds the AIoT device 312 has performed the authentication and authorization with the network, based on CN allocated device ID.

[0129] At 624, the AIoTF 416 may further allocates CN device ID and sends to the AIoT device 312.

[0130] At 626, the AIoTF 416 registers with the UDM 406 for the device access. Similar to step 522, steps 624 and 626 can also be skipped if the AIoTF 416 decides not to allocate a new CN allocated device ID by local policy or if the AIoTF 416 has registered towards UDM 406.

[0131] At 628, the AIoTF 416 may perform aggregation for the device ID, based on the report aggregation information provided by the AF 412. Within the aggregation period, the AIoTF 416 will buffer the device IDs reported from the AIoT devices 312. When the aggregation period expires, the AIoTF 416 sends the report. The AIoTF 416 may stop buffering and send report immediately, if it receives end indicator from RAN 302 in step 618. For those device ID report after the aggregation period, if it is needed by the AF 412, the AIoTF 416 sends the report. Otherwise, it will be dropped.

[0132] The AIoTF can omit providing reports from AIoT devices that replied even if they should not be based on the inventory strategy information received from the NEF / AF, if possible, to determine.

[0133] In an embodiment, the AIoTF 416 may use the aggregation period provided by the AF 412, or a locally configured value or even skip the aggregation, based on local policy. The AIoTF 416 may stop buffering and send report immediately, if it receives end indicator from RAN 302. If the AIoT device 312 responds the inventory procedure due to the RAN is a new reader, the device ID may not be sent to AF 412 via NEF 500, unless AF 412 requires the location information.

[0134] If the AF provided a list of Device IDs and the aggregated Device ID reports, include reports from all the listed AIoT devices then the AIoTF can send the aggregated report to the AF via the NEF.

[0135] At step 630, the AIoTF 416 sends Inventory Response or Notification Request towards the NEF 500 for the device ID or the aggregated device ID information.

[0136] At step 632, the NEF 500 sends Inventory Response or Notification Request towards the AF 412 for the device ID or the aggregated device ID information.

[0137] In one embodiment, the capability information from A-IoT device can be delivered as part of an inventory procedure, e.g., in response to inventory command, or a Registration procedure. The inventory can be combined with registration procedure. In another option registration is considered a separate procedure, and if an A-IoT device is being inventoried then it must be registered or register before progressing with inventory.

[0138] In one embodiment, the capability information from A-IoT device can be mapped to network allocated identifier, e.g., Subscription Permanent Identifier (SUPI) / Subscription Concealed Identifier (SUCI), or sent in addition to SUPI / SUCI in same / separate signaling, e.g., NAS registration request, however, the aim is to send capability information as close as possible when device ID (SUPI / SUCI) is sent so that registration method can adapt based on device capabilities.

[0139] In one embodiment, the capability form A-IoT device can indicate following non limiting information (e.g., using bits, flags, etc.):• Ability to do authentication (mutual authentication)• Ability to have application payload• Ability to handle cryptographic / security keys / context• Ability to have user bank memory (e.g., to have or save application payload or keys)

[0140] In one embodiment, based on the capabilities, subscription information, etc., the network can provide following non-limiting registration features which can be:• Only validation (of SUPI / SUCI) is carried by the CN• Mutual authentication is required• Temporary identifier like GUTI will be o Allocated, or o Not allocated• Security Mode Command (SMC) or context allocation will be o Provided, or o NotThe SMCs can beo NAS level, o AS level, o Unified (one for both NAS and Access Stratum (AS))• Any combination of above.

[0141] In one example, based on the A-IoT device's capability, the network can indicate, the A-IOT device will be validated for device identifier (SUPI / SUCI) and upon validation only temporary identifier (e.g., Global Unique Temporary Identifier - GUTI) will be allocated. Based on the above non-limiting option, any subset of registration procedures can be combined subject to device capability and use cases.

[0142] The table below shows ULI extensions, where the new types proposed herein are underlined:Table 1

[0143] Figure 7 is a schematic block diagram of a network node 700 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 700 may be, for example, a radio access network node such as RAN node 302 or 306 or a core network node that implements all or part of the functionality of the network functions described herein. As illustrated, the network node 700 includes a control system 702 that includes one or more processors 704 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits(ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 706, and a network interface 708. The one or more processors 704 are also referred to herein as processing circuitry. In addition, if the network node 700 is a radio access node (e.g., a base station 302, gNB, or network node that implements at least some of the functionality of the base station 302 or gNB), the network node 700 may include one or more radio units 710 that each includes one or more transmitters 712 and one or more receivers 714 coupled to one or more antennas 716. The radio units 710 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 710 is external to the control system 702 and connected to the control system 702 via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) 710 and potentially the antenna(s) 716 are integrated together with the control system 702. The one or more processors 704 operate to provide one or more functions of the network node 700 as described herein (e.g., one or more functions of a base station 302 or gNB described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 706 and executed by the one or more processors 704.

[0144] Figure 8 is a schematic block diagram that illustrates a virtualized embodiment of the network node 700 according to some embodiments of the present disclosure. Again, optional features are represented by dashed boxes. As used herein, a "virtualized" network node is an implementation of the network node 700 in which at least a portion of the functionality of the network node 700 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, if the network node 700 is a radio access node, the network node 700 may include the control system 702 and / or the one or more radio units 710, as described above. The control system 702 may be connected to the radio unit(s) 710 via, for example, an optical cable or the like. The network node 700 includes one or more processing nodes 800 coupled to or included as part of a network(s) 802. If present, the control system 702 or the radio unit(s) are connected to the processing node(s) 800 via the network 802. Each processing node 800 includes one or more processors 804 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 806, and a network interface 808.

[0145] In this example, functions 810 of the network node 700 described herein (e.g., one or more functions of a base station 302 or gNB described herein) areimplemented at the one or more processing nodes 800 or distributed across the one or more processing nodes 800 and the control system 702 and / or the radio unit(s) 710 in any desired manner. In some particular embodiments, some or all of the functions 810 of the network node 700 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 800. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 800 and the control system 702 is used in order to carry out at least some of the desired functions 810. Notably, in some embodiments, the control system 702 may not be included, in which case the radio unit(s) 710 communicate directly with the processing node(s) 800 via an appropriate network interface(s).

[0146] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 700 or a node (e.g., a processing node 800) implementing one or more of the functions 810 of the network node 700 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0147] Figure 9 is a schematic block diagram of the network node 700 according to some other embodiments of the present disclosure. The network node 700 includes one or more functions such as AIoTF 416 or NEF 500, each of which is implemented in software. The AIoTF 416 or NEF 500 provides the functionality of the network node 700 described herein. This discussion is equally applicable to the processing node 800 of Figure 8 where the modules 1100 may be implemented at one of the processing nodes 800 or distributed across multiple processing nodes 800 and / or distributed across the processing node(s) 800 and the control system 702.

[0148] Figure 10 is a schematic block diagram of an AIoT device 312 (e.g., a UE) according to some embodiments of the present disclosure. As illustrated, the AIoT device 312 includes one or more processors 1002 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 1004, and one or more transceivers 1006 each including one or more transmitters 1008 and one or more receivers 1010 coupled to one or more antennas1012. The transceiver(s) 1006 includes radio-front end circuitry connected to the antenna(s) 1012 that is configured to condition signals communicated between the antenna(s) 1012 and the processor(s) 1002, as will be appreciated by on of ordinary skill in the art. The processors 1002 are also referred to herein as processing circuitry. The transceivers 1006 are also referred to herein as radio circuitry. In some embodiments, the functionality of the AIoT device 312 (or UE) described above may be fully or partially implemented in software that is, e.g., stored in the memory 1004 and executed by the processor(s) 1002. Note that the AIoT device 312 may include additional components not illustrated in Figure 10 such as, e.g., one or more user interface components (e.g., an input / output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and / or the like and / or any other components for allowing input of information into the AIoT device 312 and / or allowing output of information from the AIoT device 312), a power supply (e.g., a battery and associated power circuitry), etc.

[0149] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the AIoT device 312 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non- transitory computer readable medium such as memory).

[0150] Figure 11 is a schematic block diagram of the AIoT device 312 according to some other embodiments of the present disclosure. The AIoT device 312 includes one or more modules 1100, each of which is implemented in software. The module(s) 1100 provides the functionality of the AIoT device 312 (or UE) described herein.

[0151] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memorysuch as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0152] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

Claims

Claims1. A method of performing Ambient Internet of Things, AIoT, device inventory performed by an AIoT function, AIoTF, (416) the method comprising: receiving (608) an inventory request, originating from an Application Function, AF, (412), comprising area information, device information, inventory strategy information, location required information and report aggregation information; discovering (610) one or more radio access networks based on the area information; forwarding (612) the inventory request to one or more radio access network nodes (302) associated with the one or more radio access networks; receiving (618) one or more inventory responses from the one or more radio access network nodes (302), wherein the one or more inventory responses comprise device identification information associated with one or more AIoT devices (312); and forwarding (630) the one or more inventory responses toward the AF (412) via aNetwork Exposure Function, NEF, (500).

2. The method of claim 1, wherein the one or more inventory responses comprise location information associated with the one or more AIoT devices (312) in response to the inventory request forwarded to the one or more radio access network nodes (302) comprising a location request.

3. The method of any of claims 1 to 2, wherein the one or more inventory responses comprise an end indicator indicating whether there will be an additional inventory response.

4. The method of any of claims 1 to 3, wherein in response to information received in response to the validation indicating that an AIoT device (312) is capable of handling authentication and authorization, the method further comprises: triggering (622) authentication and authorization towards the AIoT device (312) via a radio access network node (302) of the one or more radio access network nodes (302) associated with the AIoT device (312); and registering (626) the AIoT device (312) with a network function by recording a serving AIOTF for the AIoT device (312) in the network function.

5. The method of claim 4, further comprising: providing (624) a core network device identifier to the AIoT device (312).

6. The method of claim 4, wherein the network function is a Unified Data Management Function, UDM, (406).

7. The method of any of claims 1 to 6, further comprising: based on the report aggregation information, buffering (628) the device identification information from a plurality of AIoT devices (312); and on expiration of an aggregation period, forwarding (630) aggregated device identification from the plurality of AIoT devices (312) to the NEF (500).

8. The method of any of claims 1 to 7, wherein the one or more inventory responses to the NEF (500) comprise reports that were not omitted based on the inventory strategy information received from the NEF (500).

9. The method of any of claims 1 to 8, wherein: the area information is internal geographical area information; the device information is at least one of a device identifier, a device group identifier, or a device type; the inventory strategy information comprises an inventory frequency, inventory period and an indicator that indicates whether all AIoT devices (312) should respond, only AIoT devices (312) that haven't performed inventory should respond, or that both AIoT devices (312) 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; the location required information indicates whether the AF (412) requests the location information of the AIoT devices (312); and the report aggregation information indicates whether reports are to be aggregated or not for a specific aggregation period, and whether the reports are needed after the aggregation period.

10. The method of any of claims 1 to 9, further comprising: facilitating (620) validation of the device identification information with an Authentication Server Function, AUSF, (404) and the UDM (406) and confirming device capability information with the UDM (406); and11. A network node (700) configured to implement an Ambient Internet of Things, AIoT, function, AIoTF, (416) for performing AIoT device inventory, the network node (700) comprising a network interface configured to communicate with other network nodes, and processing circuitry configured to: receive (608) an inventory request, originating from an Application Function, AF, (412), comprising area information, device information, inventory strategy information, location required information and report aggregation information; discover (610) one or more radio access networks based on the area information; forward (612) the inventory request to one or more radio access network nodes (302) associated with the one or more radio access networks; receive (618) one or more inventory responses from the one or more radio access network nodes (302), wherein the inventory responses comprise device identification information associated with one or more AIoT devices (312); and forward (630) the one or more inventory responses toward the AF (412) via a Network Exposure Function, NEF, (500).

12. The network node (700) of claim 11, wherein the processing circuitry is further configured to perform any of the methods of claims 2 to 10.

13. A method of performing Ambient Internet of Things, AIoT, device inventory performed by a Network Exposure Function, NEF, (500) the method comprising: receiving (602), from an Application Function, AF, an inventory request comprising external area information, device information, inventory strategy information, location required information and report aggregation information; providing (608), to an AIoT Function, AIoTF, (416) an inventory request comprising internal area information, the device information, the inventory strategy information, the location required information and the report aggregation information;receiving (630), from the AIoTF (416), one or more inventory responses, wherein the inventory responses comprise device identification information associated with one or more AIoT devices (312).

14. The method of claim 13, further comprising: discovering (606) the AIoTF (416) based on a query to a Network Repository Function (502).

15. The method of any of claims 13 to 14, wherein: the device information is at least one of a device identifier, a device group identifier, or a device type; the inventory strategy information comprises an inventory frequency, inventory period and an indicator that indicates whether all AIoT devices (312) should respond, only AIoT devices (312) that haven't performed inventory should respond, or that both AIoT devices (312) 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; the location required information indicates whether the AF requests the location information of the AIoT devices (312); and the report aggregation information indicates whether reports are to be aggregated or not for a specific aggregation period, and whether the reports are needed after the aggregation period.

16. The method of any of claims 13 to 15, further comprising: forwarding (632) the one or more inventory responses to the AF.

17. The method of any of claims 13 to 16, further comprising: determining (604) that the AF is authorized to receive device location information; and translating (604) the external area information to the internal area information.

18. A network node (700) configured to implement a Network Exposure Function, NEF, (500) for performing Ambient Internet of Things, AIoT, device inventory, thenetwork node (700) comprising a network interface configured to communicate with other network nodes, and processing circuitry configured to: receive (602), from an Application Function, AF, an inventory request comprising external area information, device information, inventory strategy information, location required information and report aggregation information; determine (604) that the AF is authorized to receive device location information; translate (604) the external area information to internal area information; provide (608), to an AIoT Function, AIoTF, (416) an inventory request comprising internal area information, the device information, the inventory strategy information, the location required information and the report aggregation information; and receive (630), from the AIoTF (416), one or more inventory responses, wherein the inventory responses comprise device identification information and device capability information associated with one or more AIoT devices (312).

19. The network node (700) of claim 18, wherein the processing circuitry is further configured to perform any of the methods of claims 14 to 17.

20. A method of performing Ambient Internet of Things, AIoT, device inventory performed by a radio access network node (302), the method comprising: performing (614) an inventory procedure based on AIoT device information and inventory strategy information received from an AIoT Function, AIoTF, (416); receiving (616) from one or more AIoT devices (312), device identification information and device capability information; and forwarding (618) one or more inventory responses to the AIoTF (416) comprising the device identification information and device capability information of the one or more AIoT devices (312).

21. The method of claim 20, wherein the one or more inventory responses comprise location information associated with the one or more AIoT devices (312) in response to an inventory request received from the AIoTF (416) comprising a location request.

22. The method of any of claims 20 to 21, wherein the method further comprises:receiving (612) an inventory request from the AIoTF (416).

23. The method of any of claims 20 to 22, wherein the inventory strategy information requests AIoT devices (312) that haven't performed an inventory procedure or have performed the inventory procedure within a predetermined period of time.

24. A radio access network node (302) configured to perform Ambient Internet of Things, AIoT, device inventory, the radio access network node (302) comprising a network interface configured to communicate with other network nodes, and processing circuitry configured to: perform (614) an inventory procedure based on AIoT device information and inventory strategy information received from an AIoT Function, AIoTF, (416); receive (616) from one or more AIoT devices (312), device identification information and device capability information; and forward (618) one or more inventory responses to the AIoTF (416) comprising the device identification information and device capability information of the one or more AIoT devices (312).

25. The radio access network node (302) of claim 24, wherein the processing circuitry is further configured to perform any of the methods of claims 21 to 23.

Images