Ambient Internet of Things (IoT) validation based on provisioned device information

Abstract

The invention involves a registration phase (Fig. 5a) where an AF 316 registers with a core network function NF (preferably Network Exposure Function (NEF) 314) to access data from AIoT devices 402. The NEF checks whether the AF is authorised to access the AIoT devices and if so records this in a unified data repository (UDR) 310 and provides confirmation to the AF. Subsequently the AF actually requests data from the AIoT devices from the NEF 506. The NEF checks with the UDR if the AF’s request is valid 508-510 and if so the NEF retrieves data from the AIoT devices 512-514 and returns it to the AF 515. Registration and data requests may identify one or a group of AIoT devices and may in include credentials which may be stored in the UDR.

Description

[0002] A telecommunications system can be seen as a facility that enables communication sessions between two or more entities such as user terminals, base stations and / or other nodes by providing carriers between the various entities involved in the communications path. A telecommunications system can be provided for example by means of a communication network and one or more compatible communication devices. The communication sessions may comprise, for example, communication of data for carrying communications such as voice, video, electronic mail (email), text message, multimedia and / or content data and so on. Non-limiting examples of services provided comprise two-way or multi-way calls, data communication or multimedia services and access to a data network system, such as the Internet.

[0003] In a wireless telecommunications system at least a part of a communication session between at least two stations occurs over a wireless link. Examples of wireless systems comprise public land mobile networks (PLMN), satellite based communication systems and different wireless local networks, for example wireless local area networks (WLAN). Some wireless systems can be divided into cells, and are therefore often referred to as cellular systems.

[0004] A user can access the telecommunications system by means of an appropriate communication device or terminal. A communication device of a user may be referred to as user equipment (UE) or user device. A communication device is provided with an appropriate signal receiving and transmitting apparatus for enabling communications, for example enabling access to a communication network or communications directly with other users. The communication device may access a carrier provided by a station, for example a base station of a cell, and transmit and / or receive communications on the carrier.

[0005] The telecommunications system and associated devices typically operate in accordance with a given standard or specification which sets out what the various entities associated with the system are permitted to do and how that should be achieved. Communication protocols and / or parameters which shall be used for the connection are also typically defined. One example of a telecommunications system is the Universal Mobile Telecommunications System (UMTS). Other examples of telecommunications systems are Long-Term Evolution (LTE), LTE Advanced and the so-called 5G or New Radio (NR) networks. NR is being standardized by the 3rd Generation Partnership Project (3GPP). BRIEF SUMMARY

[0006] Example implementations of the present disclosure are directed to telecommunications and, in particular, to supporting ambient Internet of Things (loT) services in a telecommunications system. In this regard, a telecommunications system including a core network may support one or more ambient loT devices, but the ambient loT device(s) may lack the capability to register with the core network, the core network cannot be expected to possess any prior information, such as ambient loT device identifiers (IDs) or credentials, used for services such as device validation, charging, and security when communicating with ambient loT devices. To facilitate these services, example implementations of the present disclosure provide one or more services whereby the core network may acquire device information regarding ambient loT device(s) through means other than relying solely on device registration. This device information may then be managed and used by the core network for device validation and controlling a number of ambient loT devices that can be used.

[0007] The present disclosure thus includes, without limitation, the following example implementations.

[0008] Some example implementations provide an apparatus implemented by a network function of a core network, the apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory, and execute the instructions to cause the apparatus to at least: receive device information regarding one or more ambient Internet of Things (loT) devices from an application function; perform an authorization of the application function to provision the device information to the core network; and based on the authorization, send a request to a unified data management (UDM) to store the device information at a unified data repository (UDR) to enable the application function to retrieve data from the one or more ambient loT devices over the core network.

[0009] Some example implementations provide an apparatus implemented by a network function of a core network, the apparatus comprising: means for receiving device information regarding one or more ambient Internet of Things (loT) devices from an application function; means for performing an authorization of the application function to provision the device information to the core network; and based on the authorization, means for sending a request to an unified data management (UDM) to store the device information at an unified data repository (UDR) to enable the application function to retrieve data from the one or more ambient loT devices over the core network.

[0010] Some example implementations provide a method implemented at a network function of a core network, the method comprising: receiving device information regarding one or more ambient Internet of Things (loT) devices from an application function; performing an authorization of the application function to provision the device information to the core network; and based on the authorization, sending a request to a unified data management (UDM) to store the device information at a unified data repository (UDR) to enable the application function to retrieve data from the one or more ambient loT devices over the core network.

[0011] Some example implementations provide a computer-readable storage medium implemented at a network function of a core network, the computer-readable storage medium being non-transitory and having instructions stored therein that, in response to execution by at least one processing circuitry, causes an apparatus to at least: receive device information regarding one or more ambient Internet of Things (loT) devices from an application function; perform an authorization of the application function to provision the device information to the core network; and based on the authorization, send a request to a unified data management (UDM) to store the device information at a unified data repository (UDR) to enable the application function to retrieve data from the one or more ambient loT devices over the core network.

[0012] Some example implementations provide an apparatus implemented by a network function of a core network, the apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory, and execute the instructions to cause the apparatus to at least: receive a validation request based on a data request from an application function to retrieve data from one or more ambient Internet of Things (loT) devices; access device information regarding the one or more ambient loT devices stored at a unified data repository (UDR) of the core network; perform a validation of the one or more ambient loT devices for data retrieval by the application function, based on the device information; and send a validation response based on an outcome of the validation.

[0013] Some example implementations provide an apparatus implemented by a network function of a core network, the apparatus comprising: means for receiving a validation request based on a data request from an application function to retrieve data from one or more ambient Internet of Things (loT) devices; means for accessing device information regarding the one or more ambient loT devices stored at an unified data repository (UDR) of the core network; means for performing a validation of the one or more ambient loT devices for data retrieval by the application function, based on the device information; and means for sending a validation response based on an outcome of the validation.

[0014] Some example implementations provide a method implemented at a network function of a core network, the method comprising: receiving a validation request based on a data request from an application function to retrieve data from one or more ambient Internet of Things (loT) devices; accessing device information regarding the one or more ambient loT devices stored at a unified data repository (UDR) of the core network; performing a validation of the one or more ambient loT devices for data retrieval by the application function, based on the device information; and sending a validation response based on an outcome of the validation.

[0015] Some example implementations provide a computer-readable storage medium implemented at a network function of a core network, the computer-readable storage medium being non-transitory and having instructions stored therein that, in response to execution by at least one processing circuitry, causes an apparatus to at least: receive a validation request based on a data request from an application function to retrieve data from one or more ambient Internet of Things (loT) devices; access device information regarding the one or more ambient loT devices stored at a unified data repository (UDR) of the core network; perform a validation of the one or more ambient loT devices for data retrieval by the application function, based on the device information; and send a validation response based on an outcome of the validation.

[0016] These and other features, aspects, and advantages of the present disclosure will be apparent from a reading of the following detailed description together with the accompanying figures, which are briefly described below. The present disclosure includes any combination of two, three, four or more features or elements set forth in this disclosure, regardless of whether such features or elements are expressly combined or otherwise recited in a specific example implementation described herein. This disclosure is intended to be read holistically such that any separable features or elements of the disclosure, in any of its aspects and example implementations, should be viewed as combinable unless the context of the disclosure clearly dictates otherwise.

[0017] It will therefore be appreciated that this Brief Summary is provided merely for purposes of summarizing some example implementations so as to provide a basic understanding of some aspects of the disclosure. Accordingly, it will be appreciated that the above described example implementations are merely examples and should not be construed to narrow the scope or spirit of the disclosure in any way. Other example implementations, aspects and advantages will become apparent from the following detailed description taken in conjunction with the accompanying figures which illustrate, by way of example, the principles of some described example implementations. BRIEF DESCRIPTION OF THE FIGURE(S)

[0018] Having thus described example implementations of the disclosure in general terms, reference will now be made to the accompanying figures, which are not necessarily drawn to scale, and wherein:

[0019] FIG. 1 illustrates a telecommunications system that includes one or more public land mobile networks (PLMNs) coupled to one or more external data networks, according to some example implementations of the present disclosure;

[0020] FIG. 2 illustrates a deployment of a PLMN, according to some example implementations;

[0021] FIG. 3 more particularly depicts aspects of the deployment of FIG. 2, according to some example implementations;

[0022] FIG. 4 more particularly depicts aspects of the deployment of FIG. 2, including one or more ambient Internet of Things (loT) devices, according to some example implementations;

[0023] FIGS. 5A and 5B illustrate a signaling chart of provisioning device information regarding one or more ambient loT devices, and validating usability of the ambient loT device(s), according to some example implementations;

[0024] FIGS. 6A, 6B and 6C are flowcharts illustrating various steps in a method implemented at a network function of a core network, according to various example implementations;

[0025] FIGS. 7A, 7B and 7C are flowcharts illustrating various steps in a method implemented at a network function of a core network, according to various example implementations; and

[0026] FIG. 8 illustrates an apparatus according to some example implementations. DETAILED DESCRIPTION

[0027] Some implementations of the present disclosure will now be described more fully hereinafter with reference to the accompanying figures, in which some, but not all implementations of the disclosure are shown. Indeed, various implementations of the disclosure may be embodied in many different forms and should not be construed as limited to the implementations set forth herein; rather, these example implementations are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. Like reference numerals refer to like elements throughout.

[0028] Unless specified otherwise or clear from context, references to first, second or the like should not be construed to imply a particular order. A feature described as being above another feature (unless specified otherwise or clear from context) may instead be below, and vice versa; and similarly, features described as being to the left of another feature else may instead be to the right, and vice versa. Also, while reference may be made herein to quantitative measures, values, geometric relationships or the like, unless otherwise stated, any one or more if not all of these may be absolute or approximate to account for acceptable variations that may occur, such as those due to engineering tolerances or the like.

[0029] As used herein, unless specified otherwise or clear from context, the “or” of a set of operands is the “inclusive or” and thereby true if and only if one or more of the operands is true, as opposed to the “exclusive or” which is false when all of the operands are true. Thus, for example, “[A] or [B]” is true if [A] is true, or if [B] is true, or if both [A] and [B] are true. Further, the articles “a” and “an” mean “one or more,” unless specified otherwise or clear from context to be directed to a singular form. Furthermore, it should be understood that unless otherwise specified, the terms “data,” “content,” “digital content,” “information,” and similar terms may be at times used interchangeably. The term “network” may refer to a group of interconnected computers including clients and servers; and within a network, these computers may be interconnected directly or indirectly by various means including via one or more switches, routers, gateways, access points or the like.

[0030] Reference may be made herein to terms specific to a particular system, architecture or the like, but it should be understood that example implementations of the present disclosure may be equally applicable to any of a number of systems, architectures and the like. For example, reference may be made to 3 GPP technologies such as Global System for Mobile Communications (GSM), UMTS, LTE, LTE Advanced, 5G NR, 5G Advanced and 6G; however, it should be understood that example implementations of the present disclosure may be equally applicable to non-3GPP technologies such as IEEE 802, Bluetooth and Bluetooth Low Energy.

[0031] Further, as used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry); (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and / or digital hardware circuit(s) with software / firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions); or (c) hardware circuits) and / or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0032] The above definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0033] FIG. 1 illustrates a telecommunications system 100 according to various example implementations of the present disclosure. The telecommunications system generally includes one or more telecommunications networks. As shown, for example, the system includes one or more public land mobile networks (PLMNs) 102 coupled to one or more other external data networks 104 - notably including a wide area network (WAN) such as the Internet. Each of the PLMNs includes a core network (CN) 106 backbone such as the Evolved Packet Core (EPC) of LTE, the 5G core network (5GC) or the like; and each of the core networks and the Internet are coupled to one or more radio access networks (RANs) 108, air interfaces or the like that implement one or more radio access technologies (RATs). As used herein, a “network device” refers to any suitable device at a network side of a telecommunications network. Examples of suitable network devices are described in greater detail below.

[0034] In addition, the system includes one or more radio units that may be varyingly known as user equipment (UE) 110, terminal device, terminal equipment, mobile station or the like. The UE is generally a device configured to communicate with a network device or a further UE in a telecommunication network. The UE may be a portable computer (e.g., laptop, notebook, tablet computer), mobile phone (e.g., cell phone, smartphone), wearable computer (e.g., smartwatch), or the like. In other examples, the UE may be an Internet of Things (loT) device, an industrial loT (IIoT device), a vehicle equipped with a vehicle-to-everything (V2X) communication technology, or the like. In some examples, as referenced by 3GPP, the UE may be a narrowband loT (NB-IoT) device, an enhanced machine-type communication (eMTC) device, a reduced capability (RedCap) device, an ambient loT device, or the like.

[0035] In operation, these UEs may be configured to connect to one or more of the RANs 108 according to their particular radio access technologies to thereby access a particular CN 106 of a PLMN 102, or to access one or more of the external data networks 104 (e.g., the Internet). The external data network may be configured to provide Internet access, operator services, 3rd party services, etc. For example, the International Telecommunication Union (ITU) has classified 5G mobile network services into three categories: enhanced mobile broadband (eMBB), ultra-reliable and low-latency communications (URLLC), and massive machine type communications (mMTC) or massive internet of things (MIoT).

[0036] Examples of radio access technologies include 3GPP radio access technologies such as GSM, UMTS, LTE, LTE Advanced, 5GNR, 5G Advanced, and 6G. Other examples of radio access technologies include IEEE 802 technologies such as IEEE 802.11 (Wi-Fi), IEEE 802.15 (including 802.15.1 (WPAN / Bluetooth), 802.15.4 (Zigbee) and 802.15.6 (WBAN)), Bluetooth, Bluetooth Low Energy (BLE), ultra wideband (UWB), and the like. Generally, a radio access technology may refer to any 2G, 3G, 4G, 5G, 6G or higher generation mobile communication technology and their different versions, as well as to any other wireless radio access technology that may be arranged to interwork with such a mobile communication technology to provide access to the CN 106 of a mobile network operator (MNO).

[0037] In various examples, a RAN 108 may be configured as one or more macrocells, microcells, picocells, femtocells or the like. The RAN may generally include one or more radio access nodes that are configured to interact with UEs 110. In various examples, a radio access node may be referred to as a base station (BS), access point (AP), base transceiver station (BTS), Node B (NB), evolved NB (eNB), macro BS, NB (MNB) or eNB (MeNB), home BS, NB (HNB) or eNB (HeNB), next generation NB (gNB), enhanced gNB (en-gNB), next generation eNB (ng-eNB), or the like. The RAN may include some type of network controlling / governing entity responsible for control of the radio access nodes. The network controlling / governing entity and radio access node may be separate or integrated into a single apparatus. The network controlling / governing entity may include processing circuity configured to carry out various management functions, etc. The processing circuity may be associated with a memory, computer-readable storage medium or database for maintaining information required in the management functions.

[0038] ARAN 108 may be centralized or distributed. In various examples, components of a RAN may be interconnected by Ethernet, Gigabit Ethernet, Asynchronous Transfer Mode (ATM), optical fiber, dark fiber, passive wavelength division multiplexing (WDM), WDM passive optical network (WDM-PON), optical transport network (OTN), time sensitive networking (TSN) and / or any other data link layer network, possibly including radio links. The RAN may be connected to a CN 106 through one or more gateways, network functions or the like.

[0039] As will be appreciated, a PLMN 102 may be deployed in a number of different manners. In a 4G LTE deployment, the EPC is the CN 106, and the evolved UMTS terrestrial radio access network (E-UTRAN) is the RAN 108; and the E-UTRAN includes one or more eNBs (radio access nodes) configured to connect UEs 110 to the E-UTRAN to thereby access the EPC. FIG. 2 illustrates a deployment 200, such as a 5G or 6G deployment. As shown, the 5GC 202 is the CN, and the next generation (NG) radio access network (NG-RAN) 204 is the RAN; and the NG-RAN includes one or more gNBs 206 (radio access nodes) configured to connect UEs 208 to the NG-RAN to thereby access the 5GC. The term ‘gNB’ in 5G may correspond to the eNB in 4G LTE.

[0040] Some 4G LTE and 5G deployments are considered standalone (SA) deployments. Other deployments combine 4G LTE and 5G technologies, and are referred to as non-standalone (NSA) deployments. In some deployments, the E-UTRAN includes one or more ng-eNBs that are configured to communicate with the 5GC, and that may also be configured to communicate with one or more gNBs. Similarly, in another deployment, the NG-RAN may include one or more en-gNBs that are configured to communicate with the EPC, and that may also be configured to communicate with one or more eNBs. In various instances, a single UE 110, a dual-mode or multimode UE, may support multiple (two or more) RANs—thereby being configured to connect to multiple RANs, such as 4G LTE and 5G.

[0041] FIG. 3 more particularly depicts aspects of the deployment 200 for a MNO, according to some example implementations. As shown, the deployment includes the 5GC 202, and NG-RAN 204 with one or more gNBs 206 configured to connect UEs 208 to the NG-RAN to thereby access the 5GC. The 5GC may include a number of network functions (NFs) divided between the control plane and the user plane. In particular, the 5GC may include, for example, an access and mobility management function (AMF) 302, a session management function (SMF) 304, a user plane function (UPF) 306, and the like. As also shown, for example, the 5GC may include a unified data management (UDM) 308, unified data repository (UDR) 310, network data analytics function (NWDAF) 312, a network exposure function (NEF) 314, and / or an application function (AF) 316. The 5GC may also include one or more other NFs.

[0042] In the control plane, the AMF 302 is configured to provide UE-based authentication, authorization, mobility management, etc. The SMF 304 is configured to provide various functionality including session management (SM), UE Internet Protocol (IP) address allocation and management, selection and control of UPF(s) 306, control part of policy enforcement and Quality of Service (QoS), lawful intercept, termination of SM parts of NAS messages, Downlink Data Notification (DNN), roaming functionality, handle local enforcement to apply QoS for Service Level Agreements (SLAs), charging data collection and charging interface, etc. If the UE 208 has multiple sessions, different SMFs may be allocated to each session to manage them individually and possibly provide different functionalities per session.

[0043] The UDM 308 serves as a centralized repository for user-related subscription and authentication data. The UDM manages user authentication, authorization, and profile information, ensuring secure and authorized access to the 5GC 202. The UDR 310 is responsible for storing and managing user-related data, including session and policy information. The UDR facilitates functions such as data storage, retrieval, and update, ensuring the maintenance of user-related information across the 5G network. The NWDAF 312 collects and analyzes network data to provide insights into the performance, optimization, and overall health of the 5GC This information may be used for network management, optimization, and decision-making processes to enhance the network’s efficiency.

[0044] The UPF 306 supports various user plane operations and functionalities, such as packet routing and forwarding, traffic handling (e.g., QoS enforcement), an anchor point for intra-RAT / inter-RAT mobility (when applicable), packet inspection and policy rule enforcement, lawful intercept (UP collection), traffic accounting and reporting, etc. The UPF is the point of interconnect between the 5GC and at least one external data network (DN) 318 (i.e., point of ingress or egress for a DN), and routes packets to and from the DN. The DN may be configured to provide Internet access, operator services, 3rd party services, etc. The

[0045] The AF 316 may interact with the 5GC 202 to enable the deployment of specific services and applications. The AF communicates with other NFs to request and manage network resources, ensuring that the network adapts to the requirements of different applications and services. The NEF 314 allows authorized third-party applications and services to access specific network functions and services in a controlled manner. The NEF enables the exposure of network capabilities to external entities, fostering innovation and the development of new services.

[0046] In some deployments, such as deployment 200, operations of the gNB 206 or other radio access node may be carried out, at least partly, in a central / centralized unit (CU), such as a server, host or node, operationally coupled to a distributed unit (DU), such as a radio head / node. It is also possible that node operations may be distributed among a plurality of servers, hosts or nodes. It should also be understood that the distribution of work between 5GC 202 (or other CN) operations and gNB (or other radio access node) operations may vary depending on implementation.

[0047] A 5G network architecture may be based on a so-called CU-DU split. One gNB-CU (central node) may control one or more gNB-DUs. The gNB-CU may control a plurality of spatially separated gNB-DUs, acting at least as transmit / receive (Tx / Rx) nodes. In some example implementations, however, the gNB-DUs (also called DU) may include, for example, a radio link control (RLC), medium access control (MAC) layer and a physical (PHY) layer, whereas the gNB-CU (also called a CU) may include the layers above the RLC layer, such as a packet data convergence protocol (PDCP) layer, a radio resource control (RRC), and an internet protocol (IP) layer. Other functional splits are also possible. It is considered that a skilled person is familiar with the open systems interconnection (OSI) model and the functionalities within each layer.

[0048] In some example implementations, the server or CU may generate a virtual network through which the server communicates with the radio node. In general, virtual networking may involve a process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Such virtual network may provide flexible distribution of operations between the server and the radio head / node. In practice, any digital signal processing task may be performed in either the CU or the DU, and the boundary where the responsibility is shifted between the CU and the DU may be selected according to implementation.

[0049] Some deployments support loT devices, and the number loT devices is anticipated to be greatly increase, with the lifespan of many of these devices being very long (e.g., five years or more). In many cases, charging or regularly replacing batteries that power these loT devices is becoming increasingly impractical, considering the significant consumption of manpower and materials.

[0050] Ambient loT devices are loT devices powered by energy harvesting, making them either battery-less or equipped with limited energy storage capabilities (e.g., using a capacitor). In some of these deployments, ambient loT complements other loT technologies such as NB-IoT / eMTC and RedCap. Ambient loT aims to cover additional use cases that demand more cost-effective, power-efficient, and particularly battery-less functionalities. In particular, for example, ambient loT may be used in ID tags (replacing radio frequency identification with a wider range), sensors (e.g., temperature sensors, humidity sensors), healthcare (e.g., monitoring personal medical information), logistics (e.g., tracking objects), and the like.

[0051] An ambient loT system architecture may include the ambient loT device, as well as an activator (or illuminator) and a reader. An ambient loT device may include a passive radio, and the activator is a device configured to send an activation signal to provide energy to wake-up the passive radio, and thereby allow the ambient loT device to transmit one or more signals that carry messages. The reader is a device configured to listen and detect the signal(s) from the ambient loT device. The activator and reader may be co-located or separate devices.

[0052] In 3GPP, an ambient loT device may be categorized by type as a Device A, Device B or Device C. In this regard, Device A (passive) are pure battery-less devices with no energy storage capability at all, incapable of independent signal generation / amplification (only capable of backscattering). These devices rely completely on the availability of an external source of energy. Device B (semi-passive) are devices with limited energy storage capability that do not require manual replacement or recharging. These devices do not generate independent signals but may utilize backscattering with potential reflection gain. Device C (active) are actively-transmitting devices with limited energy storage capabilities based on ambient energy sources.

[0053] As shown in FIG. 4, deployment 200 may support one or more ambient loT devices 402. Since at least passive ambient loT devices (types A and B) lack the capability to register with the 5GC 202, the 5GC cannot be expected to possess any prior information, such as ambient loT device identifiers (IDs) or credentials, used for services such as device validation, charging, and security when communicating with ambient loT devices through the AF 316 over the 5GC. To facilitate these services, example implementations of the present disclosure provide one or more services whereby the 5GC may acquire device information regarding one or more ambient loT devices through means other than relying solely on device registration. This device information may then be managed and used by the 5GC for device validation and controlling a number of ambient loT devices that can be used by an AF.

[0054] According to some example implementations, the 5GC 202 may provide a capability to an AF 316 to be able to provide device information regarding ambient loT devices that the AF would like to communicate with via 5GC later. The device information may include, for example, device IDs, the group IDs, AF ID, and / or one or more credentials to enable secure communication between the 5GC and the ambient loT devices. The 5GC may store the provisioned device information in a UDM 308 / UDR 310. The UDR may keep track of a number of ambient loT devices requested by the AF, and compare it with a maximum allowed number of ambient loT devices (e.g., based on an SLA).

[0055] The AF 316 may later request data from specific ambient loT devices 402 by device ID or group ID. The 5GC 202 may validate whether the requested device IDs and / or their corresponding group IDs are within the values stored in the UDM 308 / UDR 310 to ensure that the AF accesses only the pre-stored ambient loT devices. The 5GC may proceed with subsequent procedures for data retrieval from the ambient loT devices, when the validation and authorization are successful. And in case credential(s) are provisioned, the credential(s) can be used to apply security (e.g., integrity, confidentiality protection) between the ambient loT devices and the 5GC.

[0056] Some implementations of the present disclosure therefore provide a NF of a core network, such as the NEF 314 of the 5GC 202. The NEF is configured to receive device information regarding one or more ambient loT devices 402 from an AF 316. In some examples, the device information includes one or more of a device identifier or a group identifier of the ambient loT device(s). Additionally or alternatively, in some examples, the device information includes one or more credentials of the ambient loT device(s) to enable secure communication between the 5GC and the ambient loT device(s).

[0057] The NEF 314 may be configured to perform an authorization of the AF 316 to provision the device information to the 5GC 202; and based on the authorization, the NEF is configured to send a request to a UDM 308 to store the device information at a UDR 310 to enable the AF to retrieve data from the ambient loT device(s) over the 5GC.

[0058] In some examples, the NEF 314 is further configured to receive a (first) data request from the AF 316 to retrieve data from the ambient loT device(s) 402. In some of these examples, the NEF is configured to send a validation request to the UDM 308 based on the data request. The validation request is sent to the UDM to perform a validation of the ambient loT device(s) for data retrieval by the AF, with the validation performed based on the device information stored at the UDR.

[0059] The UDM 308 may be configured to receive the validation request based on the (first) data request from the AF 316, and access device information regarding the ambient loT device(s) 402 stored at the UDR 310. The UDM may be configured to perform a validation of the ambient loT device(s) for data retrieval by the AF, based on the device information. In some examples, the validation request includes one or more device IDs or group IDs of the ambient loT device(s), and the UDM is configured to determine whether the device information stored at the UDR also includes the one or more device IDs or group IDs. The UDM may be configured to then send a validation response based on an outcome of the validation.

[0060] The NEF 314 may be configured to receive the validation response from the UDM 308 that indicates the validation is successful. Based on the successful validation, the NEF may be configured to initiate one or more procedures to retrieve the data for the AF 316 from the ambient loT device(s) over the 5GC 202, which may include the NEF configured to send a (second) data request to an AMF 302 based on the validation response. And in some examples in which the device information stored at the UDR 310 includes credential(s), the (second) data request may include the credential(s) to enable secure communication between the 5GC 202 and the ambient loT device(s) 402.

[0061] To further illustrate example implementations of the present disclosure, FIGS. 5A and 5B illustrate a signaling chart 500 of provisioning device information regarding one or more ambient loT devices 402, and validating data retrieval from the ambient loT device(s), according to some example implementations. In this regard, FIG. 5A illustrates procedures for provisioning device information regarding the ambient loT device(s), and FIG. 5B illustrates procedures for validating usability of the ambient loT device(s). In FIG. 5A, in some examples, the provisioning procedures assume the 5GC 202 is preconfigured with a maximum number of ambient loT devices allowed for use by an AF 316 for an application, such as based on an SLA. In some examples, the maximum number of ambient loT devices allowed for use may be specified for a time and / or in total (e.g., for one day, one week or one month depending on charging plan).

[0062] As shown at step 501, the AF 316 requests a provisioning service to provide ambient loT (AIoT) device information to the 5GC 202 (NEF 314), such as using a NEF exposure service operation. The AIoT device information may include, for example, an AF ID, ambient loT device IDs defined by the application, and / or group IDs that may indicate what ambient loT device IDs belong to which group. In some examples, the AIoT device information may also include one or more credentials that can be used to apply security and authentication protocols for the communication between either or both the 5GC 202 or NG-RAN 204, and the ambient loT devices 402.

[0063] The NEF 314 at step 502 performs an authorization to determine whether the AF 316 is allowed to request the provisioning service, using the AF ID. If authorized, the NEF at step 503 requests that the UDM 308 store the AIoT device information (e.g., AF ID, ambient loT device IDs, group IDs, credential). The UDM at step 504 updates or otherwise stores the AIoT device information in the UDR 310. In some examples in which the total number of the ambient loT device IDs exceeds the agreed maximum number, however, the UDR may reject updating or otherwise storing the AIoT device information.

[0064] As shown at steps 505a, 505b and 505c, the UDR 310 responds to the UDM 308, and the UDM responds to the NEF 314, which in turn responds to the AF 316. In case of failure, by one of the NFs, their response may contain a cause of the failure.

[0065] To validate data, the AF 316 requests a data retrieval service to retrieve data from one or more target ambient loT devices 402 over the 5GC 202, as shown at step 506 of FIG. 5B. In some examples, this request to the NEF 314 may include the AF ID and either the ambient loT device IDs and / or group IDs.

[0066] The NEF then at step 507 performs an authorization to determine whether the AF 316 is allowed to request the data retrieval service, using the AF ID. If authorized, the NEF 314 at step 508 requests that UDM 308 validate whether the requested ambient loT device ID and / or group IDs can be requested by the AF 316 to retrieve data. This request message may include the AF ID, and ambient loT device IDs or / and group IDs.

[0067] The UDM 308 at step 509 queries the UDR for AIoT device information in the UDR 310, using the AF ID. This AIoT device information data may include, for example, ambient loT device IDs, group IDs and / or credential(s) stored by the UDM at step 504. The UDM then compares the requested ambient loT device IDs and / or group IDs with the AIoT device information, and performs a validation that is successful when the requested IDs are in the AIoT device information data. The UDM then at step 510 sends a validation result to the NEF 314. This comparison and validation may ensure that only agreed ambient loT devices 402 are used for the AF 316, and may be used for charging purposes by the 5GC 202.

[0068] If the validation is unsuccessful, NEF 314 notifies the AF 316 at step 511; otherwise, if the validation is successful, the NEF proceeds with the subsequent procedures for requesting that the gNB 206 get the data from the target ambient loT device(s) 402. In this regard, the NEF may at step 512 send a data request to the serving AMF for the target ambient loT device(s). This request may include AIoT device information data such as, for example, ambient loT device IDs, group IDs and / or credential(s). As explained above, the credential(s) can be used by the AMF 302 and / or gNB 206 to securely communicate with the target ambient loT device(s).

[0069] The gNB 206 at step 513 retrieves data from the target ambient loT device(s) 402, and provides the data to the 5GC 202 via the AMF 302. The AMF then at step 514 forwards the retrieved data from the target ambient loT devices 402 along with either the ambient loT device IDs and / or the group IDs to the NEF 314. Then at step 515, the NEF reports the retrieved data to the AF 316. In case a group was targeted, the NEF may aggregate the data from the target ambient loT devices in the group before reporting the retrieved data to the AF.

[0070] FIGS. 6A- 6C are flowcharts illustrating various steps in a method 600 implemented at a network function of a core network, according to various example implementations. The method includes receiving device information regarding one or more ambient loT devices from an application function, as shown at block 602 of FIG. 6A. The method includes performing an authorization of the application function to provision the device information to the core network, as shown at block 604. And the method includes, based on the authorization, sending a request to a UDM to store the device information at a UDR to enable the application function to retrieve data from the one or more ambient loT devices over the core network, as shown at block 606.

[0071] In some examples, the device information includes one or more of a device identifier or a group identifier of the one or more ambient loT devices.

[0072] In some examples, the device information includes one or more credentials of the one or more ambient loT devices to enable secure communication between the core network and the one or more ambient loT devices.

[0073] In some examples, the method 600 further includes receiving a data request from the application function to retrieve data from the one or more ambient loT devices, as shown at block 608 of FIG. 6B. In some of these examples, the method includes sending a validation request to the UDM based on the data request, the validation request sent to the UDM to perform a validation of the one or more ambient loT devices for data retrieval by the application function, the validation performed based on the device information stored at the UDR, as shown at block 610 And the method includes, based on a successful validation, initiating one or more procedures to retrieve the data for the application function from the one or more ambient loT devices over the core network, as shown at block 612.

[0074] In some examples, the data request is a first data request, and the method further comprises receiving a validation response from the UDM that indicates the validation is successful, as shown at block 614 of FIG. 6C. In some of these examples, initiating the one or more procedures at block 612 includes sending a second data request to an AMF based on the validation response, as shown at block 616.

[0075] In some examples, the device information stored at the UDR includes one or more credentials, and the second data request includes the one or more credentials to enable secure communication between the core network and the one or more ambient loT devices.

[0076] FIGS. 7A- 7C are flowcharts illustrating various steps in a method 700 implemented at a network function of a core network, according to various example implementations. The method includes receiving a validation request based on a data request from an application function to retrieve data from one or more ambient loT devices, as shown at block 702 of FIG. 7A. The method includes accessing device information regarding the one or more ambient loT devices stored at a UDR of the core network, as shown at block 704. The method includes performing a validation of the one or more ambient loT devices for data retrieval by the application function, based on the device information, as shown at block 706. And the method includes sending a validation response based on an outcome of the validation, as shown at block 708.

[0077] In some examples, the validation request includes one or more device identifiers or group identifiers of the one or more ambient loT devices. And the method includes performing the validation includes determining at block 710 whether the device information stored at the UDR also includes the one or more device identifiers or group identifiers, as shown at block 706 of FIG. 7B.

[0078] In some examples, validation request is received at block 702 from a NEF, the validation response indicates a successful validation, and the validation response is sent at block 708 to the NEF to enable the NEF to initiate one or more procedures to retrieve the data for the application function from the one or more ambient loT devices over the core network.

[0079] In some examples, the method 700 further includes receiving a request to store the device information from a NEF, as shown at block 712 of FIG. 7C. And the method includes storing the device information at the UDR based on the request, as shown at block 714.

[0080] In some examples, the device information includes at least one of one or more device identifiers or group identifiers of the one or more ambient loT devices, or one or more credentials of the one or more ambient loT devices to enable secure communication between the core network and the one or more ambient loT devices.

[0081] According to example implementations of the present disclosure, a telecommunications system 100 or PLMN 102, and its components such as a UE 110, CN 106, RAN 108, 5GC 202, NG-RAN 204, gNB 206, UE 208, NF (e g., AMF 302, SMF 304, UPF 306, UDM 308, UDR 310, NWDAF 312, NEF 314, AF 316) and / or ambient loT device 402, may be implemented by various means. Means for implementing the system and its components may include hardware, firmware, software, or combinations thereof. In some examples, one or more apparatuses may be configured to function as or otherwise implement the system and its components shown and described herein. In examples involving more than one apparatus, the respective apparatuses may be connected to or otherwise in communication with one another in a number of different manners, such as directly or indirectly via a wired or wireless network or the like.

[0082] According to some example implementations, at least some of the method 600 described with respect to FIGS. 6A-6C may be carried out by an apparatus comprising means for performing functions corresponding steps of the method. Similarly, at least some of the method 700 described with respect to FIGS. 7A-7C may be carried out by an apparatus comprising means for performing functions corresponding steps of the method. Examples of a suitable apparatus may include NF (e.g., NEF, UDM), a gNB (e.g., gNB-DU, gNB-CU), ng-eNB or any suitable apparatus, such as a server, host or node.

[0083] FIG. 8 illustrates an apparatus 800 in which means for performing various functions includes hardware, alone or under direction of one or more computer programs from a computer-readable storage medium or other memory, such as computer memory, according to some example implementations of the present disclosure. The apparatus may include one or more of each of a number of components such as, for example, processing circuitry 802 connected to computer-readable storage medium or other memory 804.

[0084] The processing circuitry 802 may be composed of one or more processors alone or in combination with one or more computer-readable storage media. The processing circuitry is generally any piece of computer hardware that is capable of processing information such as, for example, data, computer programs and / or other suitable electronic information. The processing circuitry is composed of a collection of electronic circuits some of which may be packaged as an integrated circuit or multiple interconnected integrated circuits (an integrated circuit at times more commonly referred to as a “chip”). The processing circuitry may be configured to execute computer programs, which may be stored onboard the processing circuitry or otherwise stored in the memory 804 (of the same or another apparatus).

[0085] The processing circuitry 802 may be a number of processors, a multi-core processor or some other type of processor, depending on the particular implementation. Further, the processing circuitry may be implemented using a number of heterogeneous processor systems in which a main processor is present with one or more secondary processors on a single chip. As another illustrative example, the processing circuitry may be a symmetric multi-processor system containing multiple processors of the same type. In yet another example, the processing circuitry may be embodied as or otherwise include one or more ASICs, FPGAs or the like. Thus, although the processing circuitry may be capable of executing a computer program to perform one or more functions, the processing circuitry of various examples may be capable of performing one or more functions without the aid of a computer program. In either instance, the processing circuitry may be appropriately programmed to perform functions or operations according to example implementations of the present disclosure.

[0086] The memory 804 is generally any piece of computer hardware that is capable of storing information such as, for example, data, computer programs, instructions 806 (e.g., computer-readable program code) and / or other suitable information either on a temporary basis and / or a permanent basis. The memory may include volatile and / or nonvolatile memory, and may be fixed or removable. Examples of suitable memory include recording media, random access memory (RAM), read-only memory (ROM), a hard drive, a flash memory, a thumb drive, a removable computer diskette, an optical disk or some combination thereof.

[0087] The memory 804 is a non-transitory device capable of storing information. One example of a suitable memory is a computer-readable storage medium, which is distinguishable from a computer-readable transmission medium capable of carrying information from one location to another. Examples of suitable computer-readable transmission media comprise electronic carrier signals, telecommunications signals, software distribution packages, or some combination thereof. As used herein, the term “non-transitory” is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM versus ROM). A computer-readable medium as described herein generally refers to a computer-readable storage medium or computer-readable transmission medium. A computer-readable medium is any entity or device capable in which information, such as one or more computer programs or portions thereof, may be stored and carried.

[0088] In addition to the memory 804 (e.g., computer-readable storage medium), the processing circuitry 802 may also be connected to one or more interfaces for displaying, transmitting and / or receiving information. The interfaces may include a communications interface 808 and / or one or more user interfaces (e.g., display, user input interface). The communications interface may be configured to transmit and / or receive information, such as to and / or from other apparatus(es), network(s) or the like. The communications interface may be configured to transmit and / or receive information by physical (wired) and / or wireless communications links. Examples of suitable communication interfaces include a network interface controller (NIC), wireless NIC (WNIC) or the like.

[0089] Execution of the instructions 806 by the processing circuitry 802, or storage of the instructions in the memory 804, supports combinations of operations for implementing example implementations of the present disclosure. In this manner, an apparatus 800 may comprise at least one processing circuitry and at least one memory coupled to the at least one processing circuitry, where the at least one processing circuitry is configured to execute instructions stored in the at least one memory. It will also be understood that one or more functions, and combinations of functions, may be implemented by special purpose hardware-based computer systems and / or processing circuitry which perform the specified functions, or combinations of special purpose hardware and program code instructions.

[0090] Some example implementations of the present disclosure may also be carried out in the form of a computer process defined by one or more computer programs or portions thereof. Example implementations of the present disclosure may be carried out by executing at least one portion of a computer program comprising instructions. The computer program may be in source code form, object code form, or in some intermediate form. The computer program may be stored in a computer-readable medium that is readable by a computer, processing circuitry or other suitable apparatus. As indicated above, for example, the computer program may be stored in a memory, such as a computer-readable storage medium. Additionally or alternatively, for example, the computer program may be stored in a computer-readable transmission medium. The coding of software for carrying out example implementations of the present disclosure is well within the scope of a person of ordinary skill in the art.

[0091] As will be appreciated, any suitable instructions may be loaded onto a computer, a processing circuitry or other programmable apparatus from a memory or a computer-readable medium (e.g., computer-readable storage medium, computer-readable transmission medium) to produce a particular machine, such that the particular machine becomes a means for implementing the functions specified herein. The instructions may also be stored in a computer-readable medium that can direct a computer, a processing circuitry or other programmable apparatus to function in a particular manner to thereby generate a particular machine or particular article of manufacture. In some examples, the instructions stored in the computer-readable medium may produce an article of manufacture, where the article of manufacture becomes a means for implementing functions described herein. The instructions may be retrieved from a computer-readable medium and loaded into a computer, processing circuitry or other programmable apparatus to configure the computer, processing circuitry or other programmable apparatus to execute operations to be performed on or by the computer, processing circuitry or other programmable apparatus.

[0092] Retrieval, loading and execution of instructions comprising program code instructions may be performed sequentially such that one instruction is retrieved, loaded and executed at a time. In some example implementations, retrieval, loading and / or execution may be performed in parallel such that multiple instructions are retrieved, loaded, and / or executed together. Execution of the program code instructions may produce a computer-implemented process such that the instructions executed by the computer, processing circuitry or other programmable apparatus provide operations for implementing functions described herein.

[0093] As explained above and reiterated below, the present disclosure includes, without limitation, the following example implementations.

[0094] Clause 1. An apparatus implemented by a network function of a core network, the apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory, and execute the instructions to cause the apparatus to at least: receive device information regarding one or more ambient Internet of Things (loT) devices from an application function; perform an authorization of the application function to provision the device information to the core network; and based on the authorization, send a request to a unified data management (UDM) to store the device information at a unified data repository (UDR) to enable the application function to retrieve data from the one or more ambient loT devices over the core network.

[0095] Clause 2. The apparatus of clause 1, wherein the device information includes one or more of a device identifier or a group identifier of the one or more ambient loT devices.

[0096] Clause 3. The apparatus of clause 1 or clause 2, wherein the device information includes one or more credentials of the one or more ambient loT devices to enable secure communication between the core network and the one or more ambient loT devices.

[0097] Clause 4. The apparatus of any of clauses 1 to 3, wherein the at least one processing circuitry is configured to execute the instructions to cause the apparatus to further at least: receive a data request from the application function to retrieve data from the one or more ambient loT devices; send a validation request to the UDM based on the data request, the validation request sent to the UDM to perform a validation of the one or more ambient loT devices for data retrieval by the application function, the validation performed based on the device information stored at the UDR; and based on a successful validation, initiate one or more procedures to retrieve the data for the application function from the one or more ambient loT devices over the core network.

[0098] Clause 5. The apparatus of clause 4, wherein the data request is a first data request, and the at least one processing circuitry is configured to execute the instructions to cause the apparatus to further receive a validation response from the UDM that indicates the validation is successful, and wherein the apparatus caused to initiate the one or more procedures includes the apparatus caused to send a second data request to an access and mobility management function (AMF) based on the validation response.

[0099] Clause 6. The apparatus of clause 5, wherein the device information stored at the UDR includes one or more credentials, and the second data request includes the one or more credentials to enable secure communication between the core network and the one or more ambient loT devices.

[0100] Clause 7. An apparatus implemented by a network function of a core network, the apparatus comprising: means for receiving device information regarding one or more ambient Internet of Things (loT) devices from an application function, means for performing an authorization of the application function to provision the device information to the core network; and based on the authorization, means for sending a request to an unified data management (UDM) to store the device information at an unified data repository (UDR) to enable the application function to retrieve data from the one or more ambient loT devices over the core network.

[0101] Clause 8. The apparatus of clause 7, wherein the device information includes one or more of a device identifier or a group identifier of the one or more ambient loT devices.

[0102] Clause 9. The appara tus of clause 7 or clause 8, wherein the device information includes one or more credentials of the one or more ambient loT devices to enable secure communication between the core network and the one or more ambient loT devices.

[0103] Clause 10. The apparatus of any of clauses 7 to 9, wherein the apparatus further comprises: means for receiving a data request from the application function to retrieve data from the one or more ambient loT devices; means for sending a validation request to the UDM based on the data request, the validation request sent to the UDM to perform a validation of the one or more ambient loT devices for data retrieval by the application function, the validation performed based on the device information stored at the UDR; and based on a successful validation, means for initiating one or more procedures to retrieve the data for the application function from the one or more ambient loT devices over the core network.

[0104] Clause 11. The apparatus of clause 10, wherein the data request is a first data, request, the apparatus further comprises means for receiving a validation response from the UDM that indicates the validation is successful, and the means for initiating the one or more procedures includes means for sending a second data request to an access and mobility management function (AMF) based on the validation response.

[0105] Clause 12. The apparatus of clause 11, wherein the device information stored at the UDR includes one or more credentials, and the second data request includes the one or more credentials to enable secure communication between the core network and the one or more ambient loT devices.

[0106] Clause 13. A method implemented at a network function of a core network, the method comprising: receiving device information regarding one or more ambient Internet of Things (loT) devices from an application function; performing an authorization of the application function to provision the device information to the core network; and based on the authorization, sending a request to a unified data management (UDM) to store the device information at a unified data repository (UDR) to enable the application function to retrieve data from the one or more ambient loT devices over the core network.

[0107] Clause 14. The method of clause 13, wherein the device information includes one or more of a device identifier or a group identifier of the one or more ambient loT devices.

[0108] Clause 15. The method of clause 13 or clause 14, wherein the device information includes one or more credentials of the one or more ambient loT devices to enable secure communication between the core network and the one or more ambient loT devices.

[0109] Clause 16. The method of any of clauses 13 to 15, wherein the method further comprises: receiving a data request from the application function to retrieve data from the one or more ambient loT devices; sending a validation request to the UDM based on the data request, the validation request sent to the UDM to perform a validation of the one or more ambient loT devices for data retrieval by the application function, the validation performed based on the device information stored at the UDR; and based on a successful validation, initiating one or more procedures to retrieve the data for the application function from the one or more ambient loT devices over the core network.

[0110] Clause 17. The method of clause 16, wherein the data request is a first data request, the method further comprises receiving a validation response from the UDM that indicates the validation is successful, and initiating the one or more procedures includes sending a second data request to an access and mobility management function (AMF) based on the validation response.

[0111] Clause 18. The method of clause 17, wherein the device information stored at the UDR includes one or more credentials, and the second data request includes the one or more credentials to enable secure communication between the core network and the one or more ambient loT devices.

[0112] Clause 19. A computer-readable storage medium implemented at a network function of a core network, the computer-readable storage medium being non-transitory and having instructions stored therein that, in response to execution by at least one processing circuitry, causes an apparatus to at least: receive device information regarding one or more ambient Internet of Things (loT) devices from an application function; perform an authorization of the application function to provision the device information to the core network; and based on the authorization, send a request to a unified data management (UDM) to store the device information at a unified data repository (UDR) to enable the application function to retrieve data from the one or more ambient loT devices over the core network.

[0113] Clause 20. The computer-readable storage medium of clause 19, wherein the device information includes one or more of a device identifier or a group identifier of the one or more ambient loT devices.

[0114] Clause 21. The computer-readable storage medium of clause 19 or clause 20, wherein the device information includes one or more credentials of the one or more ambient loT devices to enable secure communication between the core network and the one or more ambient loT devices.

[0115] Clause 22. The computer-readable storage medium of any of clauses 19 to 21, wherein the computer-readable storage medium has further instructions stored therein that, in response to execution by the at least one processing circuitry’, causes the apparatus to further at least: receive a data request from the application function to retrieve data, from the one or more ambient loT devices; send a validation request to the UDM based on the data request, the validation request sent to the UDM to perform a validation of the one or more ambient loT devices for data retrieval by the application function, the validation performed based on the device information stored at the UDR; and based on a successful validation, initiate one or more procedures to retrieve the data for the application function from the one or more ambient loT devices over the core network.

[0116] Clause 23. The computer-readable storage medium of clause 22, wherein the data request is a first data request, and the computer-readable storage medium has further instructions stored therein that, in response to execution by the at least one processing circuitry, causes the apparatus to further receive a validation response from the UDM that indicates the validation is successful, and wherein the apparatus caused to initiate the one or more procedures includes the apparatus caused to send a second data request to an access and mobility management function (AMF) based on the validation response.

[0117] Clause 24. The computer-readable storage medium of clause 23, wherein the device information stored at the UDR includes one or more credentials, and the second data request includes the one or more credentials to enable secure communication between the core network and the one or more ambient loT devices.

[0118] Clause 25. An apparatus comprising means for performing the method of any of clauses 13 to 18.

[0119] Clause 26. A computer-readable medium comprising computer-readable program code that, in response to execution by at least one processing circuitry, causes an apparatus to perform the method of any of clauses 13 to 18.

[0120] Clause 27. A computer-readable storage medium comprising computer-readable program code that, in response to execution by at least one processing circuitry, causes an apparatus to perform the method of any of clauses 13 to 18.

[0121] Clause 28. A computer program comprising computer-readable program code that, in response to execution by at least one processing circuitry, causes an apparatus to perform the method of any of clauses 13 to 18.

[0122] Clause 29. An apparatus implemented by a network function of a core network, the apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory, and execute the instructions to cause the apparatus to at least: receive a validation request based on a data request from an application function to retrieve data from one or more ambient Internet of Things (loT) devices; access device information regarding the one or more ambient loT devices stored at a unified data repository (UDR) of the core network; perform a validation of the one or more ambient. loT devices for data retrieval by the application function, based on the device information; and send a validation response based on an outcome of the validation.

[0123] Clause 30. The apparatus of clause 29, wherein the validation request includes one or more device identifiers or group identifiers of the one or more ambient loT devices, and the apparatus caused to perform the validation includes the apparatus caused to determine whether the device information stored at the UDR also includes the one or more device identifiers or group identifiers.

[0124] Clause 31. The apparatus of clause 29 or clause 30, wherein validation request, is received from a network exposure function (NEF), the validation response indicates a successful validation, and the validation response is sent to the NEF to enable the NEF to initiate one or more procedures to retrieve the data for the application function from the one or more ambient loT devices over the core network.

[0125] Clause 32. The apparatus of any of clauses 29 to 31, wherein the at least one processing circuitry is configured to execute the instructions to cause the apparatus to further at least: receive a request to store the device information from a network exposure function (NEF); and store the device information at the UDR based on the request.

[0126] Clause 33. The apparatus of clause 32, wherein the device information includes at least one of one or more device identifiers or group identifiers of the one or more ambient loT devices, or one or more credentials of the one or more ambient loT devices to enable secure communication between the core network and the one or more ambient loT devices.

[0127] Clause 34. An apparatus implemented by a network function of a core network, the apparatus comprising: means for receiving a validation request based on a data request from an application function to retrieve data from one or more ambient Internet of Things (loT) devices: means for accessing device information regarding the one or more ambient loT devices stored at an unified data repository (UDR) of the core network; means for performing a validation of the one or more ambient loT devices for data retrieval by the application function, based on the device information; and means for sending a validation response based on an outcome of the validation.

[0128] Clause 35. The apparatus of clause 34, wherein the validation request includes one or more device identifiers or group identifiers of the one or more ambient loT devices, and the means for performing the validation includes means for determining whether the device information stored at the UDR also includes the one or more device identifiers or group identifiers.

[0129] Clause 36. The apparatus of clause 34 or clause 35, wherein validation request, is received from a network exposure function (NEF), the validation response indicates a successful validation, and the validation response is sent to the NEF to enable the NEF to initiate one or more procedures to retrieve the data for the application function from the one or more ambient loT devices over the core network.

[0130] Clause 37. The apparatus of any of clauses 34 to 36, wherein the apparatus further comprises: means for receiving a request to store the device information from a network exposure function (NEF); and means for storing the device information at the UDR. based on the request.

[0131] Clause 38. The apparatus of clause 37, wherein the device information includes at least one of one or more device identifiers or group identifiers of the one or more ambient loT devices, or one or more credentials of the one or more ambient loT devices to enable secure communication between the core network and the one or more ambient loT devices.

[0132] Clause 39. A method implemented at a network function of a core network, the method comprising: receiving a validation request based on a data request from an application function to retrieve data from one or more ambient Internet of Things (loT) devices; accessing device information regarding the one or more ambient loT devices stored at a unified data repository (UDR) of the core network; performing a validation of the one or more ambient loT devices for data retrieval by the application function, based on the device information; and sending a validation response based on an outcome of the validation.

[0133] Clause 40. The method of clause 39, wherein the validation request includes one or more device identifiers or group identifiers of the one or more ambient loT devices, and performing the validation includes determining whether the device information stored at the UDR also includes the one or more device identifiers or group identifiers.

[0134] Clause 41. The method of clause 39 or clause 40, wherein validation request is received from a network exposure function (NEF), the validation response indicates a successful validation, and the validation response is sent to the NEF to enable the NEF to initiate one or more procedures to retrieve the data for the application function from the one or more ambient loT devices over the core network.

[0135] Clause 42. The method of any of clauses 39 to 41, wherein the method further comprises: receiving a request to store the device information from a network exposure function (NEF); and storing the device information at the UDR. based on the request.

[0136] Clause 43. The method of clause 42, wherein the device information includes at least one of one or more device identifiers or group identifiers of the one or more ambient loT devices, or one or more credentials of the one or more ambient loT devices to enable secure communication between the core network and the one or more ambient loT devices.

[0137] Clause 44. A computer-readable storage medium implemented at a network function of a core network, the computer-readable storage medium being non-transitory and having instructions stored therein that, in response to execution by at least one processing circuitry, causes an apparatus to at least: receive a validation request based on a data request from an application function to retrieve data from one or more ambient Internet of Things (loT) devices; access device information regarding the one or more ambient loT devices stored at a unified data repository (UDR) of the core network; perform a validation of the one or more ambient loT devices for data retrieval by the application function, based on the device information; and send a validation response based on an outcome of the validation.

[0138] Clause 45. The computer-readable storage medium of clause 44, wherein the validation request includes one or more device identifiers or group identifiers of the one or more ambient loT devices, and the apparatus caused to perform the validation includes the apparatus caused to determine whether the device information stored at the UDR. also includes the one or more device identifiers or group identifiers.

[0139] Clause 46. The computer-readable storage medium of clause 44 or clause 45, wherein validation request is received from a network exposure function (NEF), the validation response indicates a successful validation, and the validation response is sent to the NEF to enable the NEF to initiate one or more procedures to retrieve the data for the application function from the one or more ambient loT devices over the core network.

[0140] Clause 47. The computer-readable storage medium of any of clauses 44 to 46, wherein the computer-readable storage medium has further instructions stored therein that, in response to execution by the at least one processing circuitry, causes the apparatus to further at least: receive a request to store the device information from a network exposure function (NEF); and store the device information at the UDR based on the request,

[0141] Clause 48. The computer-readable storage medium of clause 47, wherein the device information includes at least one of one or more device identifiers or group identifiers of the one or more ambient loT devices, or one or more credentials of the one or more ambient loT devices to enable secure communication between the core network and the one or more ambient loT devices.

[0142] Clause 49. An apparatus comprising means for performing the method of any of clauses 39 to 43.

[0143] Clause 50. A computer-readable medium comprising computer-readable program code that, in response to execution by at least one processing circuitry, causes an apparatus to perform the method of any of clauses 39 to 43.

[0144] Clause 51. A computer-readable storage medium comprising computer-readable program code that, in response to execution by at least one processing circuitry, causes an apparatus to perform the method of any of clauses 39 to 43.

[0145] Clause 52. A computer program comprising computer-readable program code that, in response to execution by at least one processing circuitry, causes an apparatus to perform the method of any of clauses 39 to 43.

[0146] Many modifications and other implementations of the disclosure set forth herein will come to mind to one skilled in the art to which the disclosure pertains having the benefit of the teachings presented in the foregoing description and the associated figures. Therefore, it is to be understood that the disclosure is not to be limited to the specific implementations disclosed and that modifications and other implementations are intended to be included within the scope of the appended claims. Moreover, although the foregoing description and the associated figures describe example implementations in the context of certain example combinations of elements and / or functions, it. should be appreciated that different combinations of elements and / or functions may be provided by alternative implementations without departing from the scope of the appended claims. In this regard, for example, different combinations of elements and / or functions than those explicitly described above are also contemplated as may be set forth in some of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. An apparatus implemented by a network function of a core network, the apparatus comprising:means for receiving device information regarding one or more ambient Internet of Things (loT) devices from an application function;means for performing an authorization of the application function to provision the device information to the core network; and based on the authorization,means for sending a request to an unified data management (UDM) to store the device information at an unified data repository (UDR) to enable the application function to retrieve data from the one or more ambient loT devices over the core network.

2. The apparatus of claim 1, wherein the device information includes one or more of a device identifier or a group identifier of the one or more ambient loT devices.

3. The apparatus of claim 1 or claim 2, wherein the device information includes one or more credentials of the one or more ambient loT devices to enable secure communication between the core network and the one or more ambient loT devices.

4. The apparatus of any of claims 1 to 3, wherein the apparatus further comprises:means for receiving a data request from the application function to retrieve data from the one or more ambient loT devices;means for sending a validation request to the UDM based on the data request, the validation request sent to the UDM to perform a validation of the one or more ambient loT devices for data retrieval by the application function, the validation performed based on the device information stored at the UDR; and based on a successful validation,means for initiating one or more procedures to retrieve the data for the application function from the one or more ambient loT devices over the core network.

5. The apparatus of claim 4, wherein the data request is a first data request, the apparatus further comprises means for receiving a validation response from the UDMthat indicates the validation is successful, and the means for initiating the one or more procedures includes means for sending a second data request to an access and mobility management function (AMF) based on the validation response.

6. The apparatus of claim 5, wherein the device information stored at the UDR includes one or more credentials, and the second data request includes the one or more credentials to enable secure communication between the core network and the one or more ambient loT devices.

7. A method implemented at a network function of a core network, the method comprising:receiving device information regarding one or more ambient Internet of Things (loT) devices from an application function;performing an authorization of the application function to provision the device information to the core network; and based on the authorization,sending a request to a unified data management (UDM) to store the device information at a unified data repository (UDR) to enable the application function to retrieve data from the one or more ambient loT devices over the core network.

8. The method of claim 7, wherein the device information includes one or more of a device identifier or a group identifier of the one or more ambient loT devices.

9. The method of claim 7 or claim 8, wherein the device information includes one or more credentials of the one or more ambient loT devices to enable secure communication between the core network and the one or more ambient loT devices.

10. The method of any of claims 7 to 9, wherein the method further comprises:receiving a data request from the application function to retrieve data from the one or more ambient loT devices;sending a validation request to the UDM based on the data request, the validation request sent to the UDM to perform a validation of the one or more ambient loT devices for data retrieval by the application function, the validation performed based on the device information stored at the UDR; and based on a successful validation,initiating one or more procedures to retrieve the data for the application function from the one or more ambient loT devices over the core network.

11. The method of claim 10, wherein the data request is a first data request, the method further comprises receiving a validation response from the UDM that indicates the validation is successful, and initiating the one or more procedures includes sending a second data request to an access and mobility management function (AMF) based on the validation response.

12. The method of claim 11, wherein the device information stored at the UDR includes one or more credentials, and the second data request includes the one or more credentials to enable secure communication between the core network and the one or more ambient loT devices.

13. An apparatus implemented by a network function of a core network, the apparatus comprising:means for receiving a validation request based on a data request from an application function to retrieve data from one or more ambient Internet of Things (loT) devices;means for accessing device information regarding the one or more ambient loT devices stored at an unified data repository (UDR) of the core network;means for performing a validation of the one or more ambient loT devices for data retrieval by the application function, based on the device information; andmeans for sending a validation response based on an outcome of the validation.

14. The apparatus of claim 13, wherein the validation request includes one or more device identifiers or group identifiers of the one or more ambient loT devices, andthe means for performing the validation includes means for determining whether the device information stored at the UDR also includes the one or more device identifiers or group identifiers.

15. The apparatus of claim 13 or claim 14, wherein validation request is received from a network exposure function (NEF), the validation response indicates a successful validation, and the validation response is sent to the NEF to enable the NEF to initiate one or more procedures to retrieve the data for the application function from the one or more ambient loT devices over the core network.

16. The apparatus of any of claims 13 to 15, wherein the apparatus further comprises:means for receiving a request to store the device information from a network exposure function (NEF); andmeans for storing the device information at the UDR based on the request.

17. The apparatus of claim 16, wherein the device information includes at least one of one or more device identifiers or group identifiers of the one or more ambient loT devices, or one or more credentials of the one or more ambient loT devices to enable secure communication between the core network and the one or more ambient loT devices.

18. A method implemented at a network function of a core network, the method comprising:receiving a validation request based on a data request from an application function to retrieve data from one or more ambient Internet of Things (loT) devices;accessing device information regarding the one or more ambient loT devices stored at a unified data repository (UDR) of the core network;performing a validation of the one or more ambient loT devices for data retrieval by the application function, based on the device information; andsending a validation response based on an outcome of the validation.

19. The method of claim 18, wherein the validation request includes one or more device identifiers or group identifiers of the one or more ambient loT devices, and performing the validation includes determining whether the device information stored at the UDR also includes the one or more device identifiers or group identifiers.

20. The method of claim 18 or claim 19, wherein validation request is received from a network exposure function (NEF), the validation response indicates a successful validation, and the validation response is sent to the NEF to enable the NEF to initiate one or more procedures to retrieve the data for the application function from the one or more ambient loT devices over the core network.

21. The method of any of claims 18 to 20, wherein the method further comprises:receiving a request to store the device information from a network exposure function (NEF); andstoring the device information at the UDR based on the request.

22. The method of claim 21, wherein the device information includes at least one of one or more device identifiers or group identifiers of the one or more ambient loT devices, or one or more credentials of the one or more ambient loT devices to enable secure communication between the core network and the one or more ambient loT devices.

Images