Method and apparatus of supporting sensing data collection

Abstract

Various aspects of the present disclosure relate to a method and apparatus of supporting sensing data collection. An exemplary method performed by a CN entity, which may include: receiving an AIoT service request related to data collection; and initiating service procedures to related AIoT readers to obtain AIoT sensing data based on received AIoT service request in the case that the received AIoT service request is authorized.

Description

METHOD AND APPARATUS OF SUPPORTING SENSING DATA COLLECTIONTECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to techniques of supporting sensing data collection.BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, such as base stations, which may support wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE) , or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like) . Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G) ) .SUMMARY

[0003] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a, ” “at least one, ” “one or more, ” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of” or “one or more of” or “one or both of” ) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C) . Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is  described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0004] Some implementations of the methods and apparatuses described herein may further include a core network (CN) entity for wireless communication, which may include: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the CN entity to: receive an ambient internet of things (AIoT) service request related to data collection; and initiate service procedures to related AIoT readers to obtain AIoT sensing data based on received AIoT service request in the case that the received AIoT service request is authorized.

[0005] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to register in a network repository function (NRF) , including inputting one or more of the following in the NRF: service areas; available data types in AIoT device; supported AIoT services; available readers and AIoT devices associated with the available readers; a number of available AIoT devices within a service area; network function (NF) type; NF instance identifier (ID) ; fully qualified domain name (FQDN) or internet protocol (IP) address of NF; or public land mobile network (PLMN) ID.

[0006] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to register in a binding support function (BSF) , including inputting one or more of the following in the BSF: available data types in AIoT devices, NF instance ID, IP address or FQDN of NF, or location information.

[0007] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: determine whether to authorize the AIoT service request based on subscription data in the CN entity or a different CN entity, or based on whether the AIoT service request is from an allowed consumer of the CN entity.

[0008] In some implementations of the methods and apparatuses described herein, the AIoT service request indicates one or more of: target area, target data type, task ID, sensing function (SF) ID, sensing application function (AF) ID, device ID, or data collection duration.

[0009] In some implementations of the methods and apparatuses described herein, the AIoT service request is received from a SF or an access and mobility management function (AMF) .

[0010] In some implementations of the methods and apparatuses described herein, the AIoT service request is received via a service based interface provided by the CN entity for consumers of the CN entity.

[0011] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: determine the related readers based on one or more of: target area, target data type, or last known reader ID associated with AIoT device.

[0012] In some implementations of the methods and apparatuses described herein, initiating the service procedures includes initiating an inventory procedure and then a command procedure after the inventory procedure, or only initiating a command procedure.

[0013] In some implementations of the methods and apparatuses described herein, in the case of initiating an inventory procedure, at least one processor is configured to cause the CN entity to: transmit an inventory request to the related readers, wherein the inventory request indicates a target data type.

[0014] In some implementations of the methods and apparatuses described herein, in the case of initiating an inventory procedure, at least one processor is configured to cause the CN entity to report one or more of the following to a SF based on received inventory results: AIoT device ID that matches area and data type requirements; or a number of AIoT devices.

[0015] In some implementations of the methods and apparatuses described herein, after receiving command results from the related AIoT readers, the at least one processor is configured to cause the CN entity to: transmit obtained AIoT sensing data to a SF based on received command results.

[0016] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to transmit one or more of the following with the AIoT sensing data to the SF: AIoT device ID associated with the AIoT sensing data; task ID associated with the AIoT sensing data; data type associated with the AIoT sensing data; or time stamp associated with the AIoT sensing data.

[0017] Some implementations of the methods and apparatuses described herein may further include a CN entity for wireless communication, which may include: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the CN entity to: receive a first data collection related request from a data collection related entity; and transmit a second data collection related request to at least one selected AIoT related entity based on received first data collection related request to obtain AIoT sensing data.

[0018] In some implementations of the methods and apparatuses described herein, in the case that the CN entity is a SF, the data collection related entity is a sensing AF or an AMF; or in the case that the CN entity is an AMF, the data collection related entity is a sensing AF.

[0019] In some implementations of the methods and apparatuses described herein, the CN entity is a SF or an AMF, and the at least one processor is configured to cause the CN entity to: send a discovery request to one or more of a NRF or a BSF to discover an AIoT function (AIoTF) ; and receive a response indicating discovered AIoTF to use the discovered AIoTF as a selected AIoT related entity.

[0020] In some implementations of the methods and apparatuses described herein, the CN entity is a SF or an AMF, and the at least one processor is configured to cause the CN entity to: send a discovery request to one or more of a NRF or a BSF or a network exposure function (NEF) to discover an AIoT AF; and receive a response indicating discovered AIoT AF to use the discovered AIoT AF as a selected AIoT related entity.

[0021] In some implementations of the methods and apparatuses described herein, the CN entity is a SF, the data collection related entity is an AMF, and the at least one processor is configured to cause the CN entity to: receive information indicating one or more of: AIoTF  or AIoT AF from the AMF; and transmit an AIoT service request as the second data collection related request to the AIoTF or the AIoT AF.

[0022] In some implementations of the methods and apparatuses described herein, the CN entity is a SF, and the at least one processor is configured to cause the CN entity to: receive AIoT sensing data from one or more of associated AIoT readers, an associated AIoTF or an associated AIoT AF.

[0023] In some implementations of the methods and apparatuses described herein, the CN entity is an AMF, and the at least one processor is configured to cause the CN entity to: determine a SF based on locally stored one or more of target location information or UE sensing entity registration information, or by sending a discovery request to one or more of a NRF or unified data management (UDM) where one or more of target location information or UE sensing entity registration information is stored.

[0024] In some implementations of the methods and apparatuses described herein, the SF is the selected AIoT related entity, and the at least one processor is configured to cause the CN entity to: send a discovery request to a NRF or a BSF to discover an AIoTF; receive a response indicating discovered AIoTF; and transmit information indicating the discovered AIoTF with the AIoT service request to the SF.

[0025] In some implementations of the methods and apparatuses described herein, the SF is the selected AIoT related entity, and the at least one processor is configured to cause the CN entity to: send a discovery request to a NRF or a BSF or a NEF to discover an AIoT AF; receive a response indicating discovered AIoT AF; and transmit information indicating the discovered AIoT AF with the AIoT service request to the SF.

[0026] In some implementations of the methods and apparatuses described herein, the discover request indicates a key using one or more of: target area, target sensing data type, AIoT device ID, or a number of AIoT devices.

[0027] In some implementations of the methods and apparatuses described herein, the CN entity is an AMF, and the at least one processor is configured to cause the CN entity to: determine AIoT readers as selected AIoT related entities based on locally stored AIoT reader information.

[0028] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: further determine AIoT devices associated with determined AIoT readers.

[0029] In some implementations of the methods and apparatuses described herein, the CN entity is an AMF, and the at least one processor is configured to cause the CN entity to: receive command results from associated AIoT readers; and transmit obtained AIoT sensing data to a SF based on received command results.

[0030] Some implementations of the methods and apparatuses described herein may further include a method performed by a CN entity, which may include: receiving an AIoT service request related to data collection; and initiating service procedures to related AIoT readers to obtain AIoT sensing data based on received AIoT service request in the case that the received AIoT service request is authorized.

[0031] Some implementations of the methods and apparatuses described herein may further include a method performed by a CN entity, which may include: receiving a first data collection related request from a data collection related entity; and transmitting a second data collection related request to at least one selected AIoT related entity based on received first data collection related request to obtain AIoT sensing data.BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.

[0033] Figure 2 illustrates an example of AIoT sensing data collection procedure initiated by SF in accordance with aspects of the present disclosure.

[0034] Figure 3 illustrates an example of AIoT sensing data collection procedure initiated by AMF in accordance with aspects of the present disclosure.

[0035] Figure 4 illustrates an example of a CN entity in accordance with aspects of the present disclosure.

[0036] Figure 5 illustrates a flowchart of method performed by a CN entity in accordance with aspects of the present disclosure.

[0037] Figure 6 illustrates another flowchart of method performed by a CN entity in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0038] Wireless sensing technologies aim at acquiring information on a remote object or environment and characteristics thereof, e.g., by using a camera or radar without physically contact. With deep research into AIoT, it is assumed that an AIoT device is capable of storing data within local memory. The AIoT device can be placed at some areas (e.g., target area) , e.g., factory, research lab and hospital, to monitor the surrounding environment, e.g., the indoor temperature, the humidity, the light condition, etc. From this point of view, the AIoT device itself can actually be treated as a kind of sensor that stores sensing data for the target area, which may be interested by sensing service consumers and sensing tasks. Thus, from sensing data (or sensor data or the like) point of view, the data in the AIoT device can be utilized for certain sensing task (or sensing service, or sensing service task or the like) and exposed to the sensing service consumer.

[0039] Currently, the data stored in the AIoT device can only be read by AIoT reader (s) (herein, or just reader (s) for simplification) , e.g., a base station (BS) reader (or radio access network (RAN) reader) or a UE reader as an intermediate node under the network control, then forwarded to the 5G core network (5GC) , e.g., reported to the AIoT related network function within the 5GC, and exposed to the AIoT AF. For sensing task targeting at collecting certain type (s) of data from some areas or locations, several issues, e.g., how to be aware of the AIoT services and devices that have the certain type (s) of sensing data, and how to utilize the AIoT services to get the target sensing data from proper AIoT device (s) , need to be addressed.

[0040] From the perspective of sensing task assignment, various aspects of the present disclosure propose a CN entity, e.g., a SF or an AMF in accordance with different sensing task assignment mechanisms to enable sensing data collection from AIoT devices for sensing task. The CN entity may receive a data collection related request (hereinafter, the first data collection related request) , e.g., a sensing service request or an AIoT service request from a data collection related entity, e.g., a sensing AF or an AMF. Based on the first data collection related request, the CN entity may transmit another data collection related request  (hereinafter, the second data collection related request) , e.g., another sensing service request or an AIoT service request to at least one selected AIoT related entity, e.g., a selected SF, AIoTF, AIoT AF or AIoT reader (s) etc.

[0041] For example, in the case that the CN entity is a SF, the SF may receive a sensing service request from a sensing AF, and may transmit an AIoT service request to an AIoTF or AIoT AF to enable AIoT sensing data collection. In some other implementations of the present disclosure, the SF may receive a sensing service request from an AMF, and may transmit an AIoT service request to an AIoTF or AIoT AF to trigger or enable AIoT sensing data collection.

[0042] In the case that the CN entity is an AMF, the AMF may receive a sensing service request (hereinafter, first sensing service request) from a sensing AF, and may transmit another sensing service request (hereinafter, second sensing service request) to a SF, or transmit an AIoT service request to an AIoTF, an AIoT AF or AIoT readers to trigger or enable AIoT sensing data collection.

[0043] Different methods can be utilized to enforce the AIoT service for sensing data collection as illustrated above, e.g., via the AIoTF, AIoT AF, or AIoT readers etc. For example, from the perspective of AIoT service enforcement, various aspects of the present disclosure propose a CN entity, e.g., an AIoTF. The CN entity may receive an AIoT service request related to data collection from a SF, an AMF or other allowed consumer of the CN entity. Based on the received AIoT service request which is authorized, the CN entity may initiate service procedures, e.g., an inventory procedure (if necessary) and a command procedure (if the related AIoT device (s) is inventoried for the requested sensing task) to related AIoT reader (s) to obtain requested AIoT sensing data.

[0044] Aspects of the present disclosure are described in the context of a wireless communications system.

[0045] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NE 102, one or more UE 104, and a CN 106. The wireless communications system 100 may support various radio access technologies. In some  implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE-Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G-Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi) , IEEE 802.16 (WiMAX) , IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA) , frequency division multiple access (FDMA) , or code division multiple access (CDMA) , etc.

[0046] The one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a network function, a network entity, a radio access network (RAN) , a NodeB, an eNodeB (eNB) , a next-generation NodeB (gNB) , or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signaling, transmit signaling) over a Uu interface.

[0047] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc. ) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN) . In some implementations, different geographic coverage areas 112 associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0048] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a  remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of-Things (IoT) device, an Internet-of-Everything (IoE) device, or machine-type communication (MTC) device, among other examples.

[0049] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link 114 may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0050] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., S1, N2, N3, or network interface) . In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g., via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC) . An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs) .

[0051] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC) , or a 5G core (5GC) , which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME) , an AMF) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW) , a Packet Data Network (PDN) gateway (P-GW) , or a user plane function (UPF) ) . In some implementations, the control plane entity may manage non-access stratum  (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc. ) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.

[0052] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an S1, N2, N3, or another network interface) . The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session) . The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106) .

[0053] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers) ) to perform various operations (e.g., wireless communications) . In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures) . The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0054] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., μ=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., μ=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., μ=1) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., μ=2) may be associated with a third  subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., μ=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., μ=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0055] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames) . Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0056] Additionally or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., μ=0, μ=1, μ=2, μ=3, μ=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols) . In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing) , a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., μ=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0057] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands,  frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz –7.125 GHz) , FR2 (24.25 GHz –52.6 GHz) , FR3 (7.125 GHz –24.25 GHz) , FR4 (52.6 GHz –114.25 GHz) , FR4a or FR4-1 (52.6 GHz –71 GHz) , and FR5 (114.25 GHz –300 GHz) . In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data) . In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0058] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies) . For example, FR1 may be associated with a first numerology (e.g., μ=0) , which includes 15 kHz subcarrier spacing; a second numerology (e.g., μ=1) , which includes 30 kHz subcarrier spacing; and a third numerology (e.g., μ=2) , which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies) . For example, FR2 may be associated with a third numerology (e.g., μ=2) , which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., μ=3) , which includes 120 kHz subcarrier spacing.

[0059] In accordance with various aspects of the present disclosure, based on different sensing task assignment mechanisms, two schemes or solutions are proposed for triggering or initiating AIoT services for collecting sensor data from AIoT devices, e.g., SF trigger (scheme 1) and AMF trigger (scheme 2) .

[0060] Specifically, considering sensing related services or tasks, it is assumed that there is a dedicated network function within 5GC, e.g., SF or the like, that handles sensing related services and traffics. The SF may either be a standalone network function, or be co-located with other CN entity or NF, e.g., location management function (LMF) . An exemplary SF or the like may further include a control plane (CP) part, e.g., SF-C that handles control plane function and user plane (UP) part, e.g., SF-U that handles user plane function. Exemplary SF may mainly include the following functionalities, wherein part or all of the SF functionalities may be supported in a single instance of SF:

[0061] -Receive sensing related data and / or signaling from sensing service consumer (s) ;

[0062] -Transmit sensing related data and / or signaling to the sensing service consumer (s) ;

[0063] -Select appropriate sensing mode, sensing entity (e.g., UE or RAN etc. ) and assign the sensing role for the selected sensing entity;

[0064] -Receive registration request (s) from the sensing entity, authorize the registration request (s) , and store the information locally or in UDM and / or unified data repository (UDR) ;

[0065] -Assign sensing task (s) to the selected sensing entity, together with configuration information; and

[0066] -Process the collected sensing data, generate sensing results, and expose the sensing results to the service consumer (s) .

[0067] On the other hand, considering AIoT, it is assumed that there may be a dedicated network function in 5GC, e.g., AIoTF that handles AIoT related services and traffics. The AIoTF may either be a standalone network function, or co-located with other CN entity or NF, e.g., AMF. Exemplary AIoTF or like may mainly include the following functionalities, wherein part or all of the AIoTF functionalities may be supported in a single instance of AIoTF:

[0068] -Receive AIoT related data and / or signaling from AIoT application server (AIoT AS);

[0069] -Transmit AIoT related data and / or signaling to the AIoT application server;

[0070] -Select appropriate AIoT reader (s) , e.g., UE reader and / or RAN reader for the transmission of AIoT data and / or signaling to target locations and / or areas, and / or AIoT devices;

[0071] -Receive registration request (s) from the AIoT reader (s) , and store AIoT reader information and associated AIoT device information;

[0072] -Establish AIoT sessions with AIoT AF and / or AIoT AS for transmission;

[0073] -Perform authentication and authorization for device access, which triggers interactions with authentication server function (AUSF) and / or UDM;

[0074] -Collect charging data and interact with charging function (CHF) for charging; and

[0075] -Perform AIoT device and reader context management.

[0076] In some implementations of the present disclosure, AIoTF may register itself in NRF, e.g., using Nnrf_NFManagement_NFRegister service or the like by providing AIoTF NF profiles. For example, for the registration, AIoTF may input one or more of the following in the NRF:

[0077] -service areas, e. g, in which area (e.g., tracking area, or cell) that the AIoTF is able to provide AIoT services;

[0078] -available data types in AIoT devices, e.g., what kind of (sensor) data is stored in the AIoT devices within its serving area, such as temperature, humdity, light condition and so on;

[0079] -supported AIoT services, e.g., inventory, read, write, enable and disable etc. ;

[0080] -available readers and AIoT devices associated with available readers, e.g., reader ID, device ID (or AIoT device ID) and location, and time stamp etc. ;

[0081] -a number of available AIoT devices within a service area, e.g., that can be categorized based on data type, e.g., type #1, or device number #X etc.. ;

[0082] -NF type;

[0083] -NF instance ID;

[0084] -FQDN or IP address of NF; or

[0085] -PLMN ID.

[0086] The AIoTF related registration information in the NRF may be updated upon change (e.g., event trigger) or periodically. For example, the AIoTF may use Nnrf_NFManagement_NFUpdate service or the like to update the AIoTF NF profile, such as the location or the serving reader of AIoT device etc.

[0087] In some other implementations of the present disclosure, apart from finding the serving policy control function (PCF) for UE, BSF can be enhanced to provide service of finding an AIoT related entity, e.g., AIoTF or AIoT AF for AIoT data collection. Accordingly, the AIoTF may register itself in the BSF, e.g., using Nbsf_Management_Register service or the like by providing AIoTF NF profiles. For example, for the registration, the AIoTF may input one or more of the following in the BSF: available data types in AIoT devices, NF instance ID, IP address of NF, or location information. Similarly, the AIoTF may update the related registration information in the BSF upon change or periodically, e.g., by using Nbsf_Management_Update service or the like. After the AIoTF registers the available data types in associated AIoT devices in the BSF, the correspondence between the AIoTF and the available AIoT sensing data type will be established and used by service consumers of the BSF to find an appropriate AIoTF for certain kinds of sensing data collection. For example, the consumers of the BSF, e.g., SF and AMF etc., may use Nbsf_Management_Discovery service or the like to input the target data type, target location and / or other information that they want to obtain for the sensing task, and the BSF may output the AIoTF ID (s) that covers the AIoT device (s) with the required sensor data type etc.

[0088] Besides AIoTF, it is also assumed that there may be a dedicated AIoT application (APP) , e.g., AIoT AF. AIoT devices and the AIoT APP have the application layer on both sides. Thus, the data within the AIoT devices can be retrieved by a 3rd party AIoT AF via  application signaling, and exposed to the SF upon request as a kind of sensing data. The AIoT AF may also register itself, e.g., in the NRF, which is similar to that described in Clause 6.3.25, 3GPP TS. 23.501. Therefore, the SF may use certain input criteria to find the AIoT AF, e.g., device ID (e.g., AIoT device ID) , target location and target device data type etc. Accordingly, the SF is able to discover and retrieve the information of AIoT AF (e.g., AIoT AF ID or IP address, or FQDN) and find the appropriate AIoT AF for collecting sensing data from AIoT devices via application layer interaction. In some other implementations of the present disclosure, the AIoT AF may also register itself in the BSF as listed below in Table 1, or NEF may locally store information on AIoT AF when the AIoT AF sends service requests to the 5GC. Accordingly, BSF and / or NEF may also be used by SF and / or AMF or the like to find the appropriate AIoT AF for data collection. In any case, the AIoT AF may update the registration information upon change or periodically.

[0089] Table 1 NF services provided by BSF

[0090] More details of the present disclosure will be further illustrated in the following in view of some exemplary implementations respectively based on scheme 1 and scheme 2. Persons skilled in the art should well know that the illustrated NFs, e.g., sensing AF, SF, AMF, AIoTF, and / or AIoT AF etc., are only used for clearly illustrating the technical solution of the present disclosure, the name of respective NFs may change, and / or part or all of the functionalities of respective NFs may be incorporated with other NF (s) along with the evolutions of 3GPP network architectures and new service scenarios. In addition, even for UE initiating sensing service, UE may be a sensing service consumer and need to obtain  sensor data from certain area (s) , which makes it necessary to check available AIoT service and devices.

[0091] Firstly, Figure 2 illustrates an example of AIoT sensing data collection procedure initiated by SF in accordance with aspects of the present disclosure.

[0092] Referring to Figure 2, in step 201, SF may receive a first data collection related request from a sensing service consumer. For example, SF may receive a sensing service request from a 3rd party sensing AF, e.g., via NEF (not shown) . In some scenarios, for an untrusted sensing AF, the NEF will authorize the sensing service request by checking subscription data (e.g., application and / or service subscription data) stored in UDM / UDR (not shown) , which is based on the service layer agreement (SLA) between the network mobile network operator (MNO) and the 3rd party sensing AF. It is assumed that the SF has registered itself in the NRF (not shown) , including the service area and supported sensing capability etc. Herein, it is also assumed that the SLA can guarantee the SF to touch the content of the command response (e.g., AIoT sensor data) for processing and generating the sensing results. If the sensing AF (or the sensing service request from the sensing AF) is authorized, the NEF may determine or select the SF from the NRF where the SF is registered, e.g., based on target location and other sensing service requirements, and forward the sensing service request to the selected SF. In some scenarios, based on the decision, the NEF may send a service authorization accepted message or service authorization rejected message (e.g., with a reject cause) to the sensing AF.

[0093] An exemplary sensing service request may include one or more of: sensing task ID (or sensing transaction ID) , sensing requirements (or, key performance indicators (KPIs) , required or target area, required or target data type, UE ID (e.g., generic public subscription identifier (GPSI) ) , destination AF IP address or APP ID (e.g., AIoT AF ID) etc. The sensing requirements (or sensing service requirements or sensing task requirements or the like) may include: resolution and accuracy of the sensing object’s location, velocity and / or angle, refresh rate, target detection ratio, target false alarm ratio, sensing duration (e.g., start time and end time) , and / or reporting strategy, etc. Regarding target data type, it will be used to filter AIoT devices and the corresponding data AIoT devices response as command results, either by AIoT devices or by an AIoTF etc. For example, a target data type means  what kind of data that the sensing AF wants, which indicates that the service consumer wants to get certain types or kinds of sensing data from the target area (if provided) , then, the SF needs to know whether there are sensors within the target area that store the certain types of data that the sensing AF wants, and then, the AIoT device that serves as a sensor will be useful for providing the requested types of data to fulfill the sensing task.

[0094] After receiving the first data collection related request, e.g., from the sensing AF forwarded by the NEF, the SF (e.g., SF-C) in the 5GC may determine or select an AIoT related entity to enforce AIoT services for sensing data collection in step 203. In accordance with various aspects of the present disclosure, the AIoT related entity may be an AIoTF or an AIoT AF or the like.

[0095] For example, in the case that the AIoT related entity is an AIoTF registered in NRF, based on the first data collection related request, the SF may send a discovery request (or selection request) to the NRF, e.g., using Nnrf_NFDiscovery_Request discovery service (or message) to ask whether there is available and appropriate AIoT service or AIoTF that can be used for the required sensing data collection. In the case that the AIoT related entity is an AIoTF registered in BSF (not shown) , based on the first data collection related request, the SF may send a discovery request (or selection request) to the BSF, e.g., using Nbsf_Management discovery service to ask whether there is available and appropriate AIoT service or AIoTF that can be used for the sensing data collection.

[0096] An exemplary discovery request may indicate a key (or index) using one or more of: target area, target sensing data type, device ID (e.g., AIoT device ID) , or a number of AIoT devices etc., so that an AIoTF will be selected from the NRF or BSF. For example, in some scenarios, the SF has utilized the AIoT service before receiving the sensing service request, and received AIoT data from AIoT devices via the AIoTF. Thus, the SF may have locally stored AIoT device information, e.g., device IDs and data types etc. Therefore, it is possible that the SF may provide the device ID as the index to select the appropriate AIoTF.

[0097] Based on the input index, the NRF or BSF may check local information and respond the SF with the appropriate NF instance profiles, e.g., AIoTF ID, IP address and / or FQDN etc.

[0098] In the case that the AIoT related entity is an AIoT AF, which is registered in the NRF, BSF or NEF, the SF may send a discovery request (or selection request) to the NRF, BSF or NEF to discover an AIoT AF from the NRF, BSF or NEF by providing a key (or index) using one or more of: target area, target sensing data type, device ID (e.g., AIoT device ID) , or a number of AIoT devices etc. Regarding the AIoT device ID, it may include an owner ID, enterprise ID and / or application ID to be used to discover the appropriate AIoT AF by matching with the AF ID, to collect the data from the AIoT devices.

[0099] Similarly, based on the input index, the NRF, BSF or NEF may check local information and respond the SF with the appropriate NF instance profiles, e.g., AIoT AF ID, IP address and / or FQDN etc.

[0100] The SF (e.g., SF-C) may send a second data collection related request to the selected AIoT related entity, indicating one or more of: SF ID, sensing AF ID, device ID, required or target area, required or target data type, task ID, data collection duration or other service requirements, etc. What information, e.g., service requirement or configuration information indicated in the first data collection related request will be included in or transferred to the second data collection related request by the SF based on its own implementation.

[0101] For example, in the case that an AIoTF is selected, the SF may transmit an AIoT service request to the selected AIoTF, e.g., via Naiotf_AIoT service like message in step 205a, which may be built on a service based interface provided by the AIoTF for its allowed consumers, e.g., for SF, AMF and / or NEF etc. In the case that an AIoT AF is selected, the SF may transmit an AIoT service request to the selected AIoT AF via Naf_EventExposure_Subscribe message in step 205b.

[0102] After an AIoTF is selected and receives the AIoT service request, the AIoTF may determine whether the AIoT service request is authorized in step 207. For example, the AIoTF may check the subscription data of the SF with the UDM and / or UDR (e.g., using the sensing AF ID) , or based on locally stored information, and then decide whether to authorize or reject the AIoT service requested by the SF. Herein, it is assumed that the SF and / or the sensing AF behind the SF (the sensing AF sending the first data collection related request to the SF) , have the business SLA with the MNO, and then the AIoTF will authorize the SF to  use the AIoT service. This kind of SLA may be reflected in the UDM and / or UDR as the service subscription data, and this kind of authorization is similar to NEF authorizing the service request from an AF, e.g., from the sensing AF. For another example, the SF may be allowed or authorized to utilize the service provided by the AIoTF due to being the allowed consumer of the AIoTF.

[0103] The AIoTF may send the authorization response to the SF, which may indicate that the AIoT service request is accept, or rejected (e.g., with a rejection cause in some cases) . In the case that the AIoT service request from the SF is authorized by the AIoTF, the AIoTF may initiate service procedures to related AIoT readers or AIoT devices to obtain AIoT sensing data based on the received AIoT service request, which may be triggered in various manners.

[0104] For example, in some implementations of the present disclosure, if specific AIoT device ID (s) is provided by the SF based on the locally stored information (e.g., from the last AIoT sensor data collection procedure) , then the AIoTF may initiate the inventory (if necessary) and command procedure towards the specific AIoT device (s) via related reader (s) . In some other implementations of the present disclosure, if the target data type and / or the target area are provided by the SF while no specific AIoT device ID (s) is provided, then the AIoTF may initiate the inventory (if necessary) for all associated AIoT readers (e.g., no AIoT device ID in the paging message) and forward the command (s) , e.g., "read" to the AIoT devices found by the inventory (or discovery) procedure.

[0105] Specifically, in accordance with some aspects of the present disclosure, in step 209a, in the case of being triggered by the SF (e.g., receiving an authorized AIoT service request) , the AIoTF may send an inventory request (the first one) to the selected AIoT reader (s) (e.g., UE reader (s) and / or RAN reader (s) ) , e.g., based on target area information, or based on the last known reader ID (s) associated with the AIoT device (s) (e.g., if device ID provided) etc.

[0106] In step 209b, the related reader (s) may interact with the associated AIoT device (s) , e.g., sending an inventory request (the second one based on the first one) , e.g., by a paging message, either with specific device ID (s) contained in the paging message, or towards all the devices within the coverage area. The AIoT device (s) that receives the second inventory  request may match the received paging message and respond to the associated readers, e.g., by including their respective device ID in corresponding messages. For example, the AIoTF may include the target data type as a kind of matching criteria in the inventory request. When an AIoT device receives the inventory request from the associated reader, the AIoT device may compare the required device data type with locally stored data, and respond accordingly if the required data type that the AIoTF intends to fetch is matched.

[0107] After receiving the inventory response or result from the associated AIoT device (s) , in step 209c, the AIoT reader may send the inventory response or result to the AIoTF, e.g., together with the reader ID, reader location, and / or time stamp etc.

[0108] In some cases, after receiving the inventory response, the AIoTF may expose the AIoT device ID (s) that matches the area and / or data type etc., requirements, to the SF based on the inventory response or result in step 211. In some scenarios, the AIoTF may also expose the number of the related AIoT devices to the SF.

[0109] In accordance with some aspects of the present disclosure, the inventory procedure 209 may be unnecessary, e.g., in the case that the AIoTF may determine the AIoT devices to which the command (s) will be sent based on the last inventory result or the AIoT service request has provided specific AIoT device ID (s) etc.

[0110] In step 213a, the AIoTF may send a command request (e.g., read request) towards the related AIoT devices via the related reader (s) to obtain the required data via a command procedure. An exemplary command request may include at least one of the following: task ID, filtering criteria (e.g., target data type) , device ID, aggregation indication, waiting duration, CP and / or UP transmission indication, or SF ID etc.

[0111] The AIoT reader that receives the command request may interact with the associated AIoT device (s) in step 213b, and receive the command response or result, e.g., including the sensing data stored in the AIoT devices as required.

[0112] After receiving the command response or result, the AIoT reader may send the AIoT sensing data to the AIoTF in step 215a. The AIoTF may do preliminary processing on the AIoT sensing data received from the AIoT devices, and expose the results to the SF for further processing in step 217. In some scenarios, the AIoT reader may also transmit one or  more of the following to the AIoTF: AIoT device ID associated with the AIoT sensing data, task ID associated with the AIoT sensing data, data type associated with the AIoT sensing data, time stamp associated with the AIoT sensing data, or location information of the associated AIoT device (s) etc., which may also be further exposed to the SF by the AIoTF in step 217.

[0113] In some other implementations of the present disclosure, after receiving the command response or result, the AIoT reader may forward the AIoT sensing data directly to the SF in step 215b, e.g., according to the received SF ID. Similarly, in some scenarios, the AIoT reader may also transmit one or more of the following to the SF: AIoT device ID associated with the AIoT sensing data, task ID associated with the AIoT sensing data, data type associated with the AIoT sensing data, time stamp associated with the AIoT sensing data, or location information of the associated AIoT device (s) etc.

[0114] In some yet other implementations of the present disclosure, the AIoT devices may not need to transmit the command response or result to the AIoT readers. The data within the AIoT device may be retrieved by its owner AIoT AF via application layer signaling. For example, in the case that the SF transmits the AIoT service request to the selected AIoT AF in step 205b, the selected AIoT AF may directly retrieve the required data from the related AIoT device (s) in step 219a. The AIoT AF may further send the obtained AIoT sensing data to the SF in step 219b. Similarly, the AIoT AF may also transmit one or more of the following to the SF: AIoT device ID associated with the AIoT sensing data; task ID associated with the AIoT sensing data; data type associated with the AIoT sensing data; or time stamp associated with the AIoT sensing data etc.

[0115] After receiving the sensing data, e.g., from the AIoT reader (s) , AIoTF or AIoT AF with or without any other information, the SF may process the received AIoT sensing data, generate the sensing result, and then expose the sensing result to the sensing AF in step 221.

[0116] Different from scheme 1 where the sensing task is routed to the dedicated sensing related NF directly, e.g., SF, under scheme 2, the NEF may forward the received sensing service task or request to the AMF selected from NRF and / or UDM if certain information, e.g., UE ID and target area etc., is provided in the sensing service task or request. After the  AMF receives the sensing task from the NEF, the AMF may also utilize the AIoT service provided by AIoTF and obtain the data stored in the AIoT device as a sensor.

[0117] Figure 3 illustrates an example of AIoT sensing data collection procedure initiated by AMF in accordance with aspects of the present disclosure.

[0118] Referring to Figure 3, in step 301, the AMF may receive a first data collection related request from a sensing service consumer. For example, the AMF may receive a sensing service request from a 3rd party sensing AF, e.g., via NEF (not shown) if the sensing AF is untrusted. Similarly, the NEF will authorize the service request by checking the subscription data stored in the UDM and / or UDR (not shown) , select the appropriate AMF from the UDM and / or UDR, or NRF, and forward the sensing task to the selected AMF. The information element (IE) within an exemplary sensing service request may include: task ID, UE ID, target area, target data type, destination AF ID and IP address, and / or other sensing requirement information, which is similar to that illustrated in scheme 1 and will not repeat.

[0119] After receiving the first data collection related request, e.g., from the sensing AF forwarded by the NEF, the AMF may determine or select an AIoT related entity based on the first data collection related request in step 303. In accordance with various aspects of the present disclosure, the AIoT related entity may be a SF, an AIoTF, or an AIoT AF, or AIoT reader (s) or the like. Accordingly, the AMF may transmit a second data collection related request to at least one selected AIoT related entity to obtain required AIoT sensing data.

[0120] Regarding the determination or selection of AIoTF and AIoT AF performed by the AMF, it is similar to that illustrated in scheme 1 performed by the SF, and will not repeat herein. The AMF may send an AIoT service request to the selected AIoTF or AIoT AF respectively in step 305a and step 305b, which are similar to that performed by the SF illustrated in scheme 1 and will not repeat.

[0121] Regarding the determination or selection of the SF, based on the first data collection related request, the AMF may send a discovery request (or selection request) to the NRF or UDM (e.g., in the case of UE based sensing) to discover or select an appropriate SF for the sensing task, e.g., by indicating target location and / or UE sensing entity registration information etc. In some other implementations of the present disclosure, the  AMF may discover or select an appropriate SF based on local stored information. The AMF may transmit a sensing service request (the second one based on that received from the sensing AF) to the selected SF in step 305c, which is similar to the first sensing service request, e.g., indicating sensing task ID, target area, target data type, and / or sensing requirements etc.

[0122] Based on the second sensing service request, the selected SF may determine or select an AIoTF or AIoT AF in step 307, and send an AIoT service request to the selected AIoTF or AIoT AF respectively in step 309a and step 309b, which are identical or similar to that illustrated in scheme 1 and will not repeat. In some other implementations of the present disclosure, the SF may not need to determine or select the AIoTF and / or AIoT AF. For example, in some scenarios, besides determining the SF, the AMF may also determine or select the AIoTF and / or AIoT AF, and may indicate the selected AIoTF and / or AIoT AF to the selected SF.

[0123] In some other scenarios, the selected SF is only for receiving and processing the obtained sensing data etc., that is related to the first data collection related request, while not for triggering or initiating AIoT sensing data collection. Accordingly, the selected SF may not determine the AIoT related entity, e.g., AIoTF or AIoT AF for obtaining required sensing data, or transmit the AIoT service request to the selected AIoTF or AIoT AF etc.

[0124] Regardless of being triggered by the AMF or SF, in step 311, the selected AIoTF may determine whether to authorize the received AIoT service request, and initiate service procedures to related AIoT readers to obtain AIoT sensing data based on the received AIoT service request in the case that the received AIoT service request is authorized, which are identical or similar to that illustrated in scheme 1 and will not repeat. The AIoTF may expose the received AIoT sensing data to the AMF and SF.

[0125] Similarly, regardless of being triggered by the AMF or SF, in step 313, the selected AIoT AF may directly retrieve the required data from the related AIoT device (s) as illustrated in scheme 1 and will not repeat. The AIoT AF may expose the received AIoT sensing data to the SF.

[0126] In some scenarios, the AMF is for both the AIoT service and sensing service, and has locally stored AIoT reader information for the same area, e.g., during the reader registration procedure. Therefore, the AMF may have the information on readers and the associated AIoT devices. Based on that, the AMF may select the appropriate AIoT devices and readers for the AIoT service request to obtain the sensor data within the AIoT devices. In some cases, the AMF may also have other AIoT service information to help discover the AIoT reader (s) , e.g., data type information etc.

[0127] The AMF may send an AIoT service request to the selected AIoT reader (s) in step 305d, e.g., indicating the target data type, device ID, and / or the SF ID etc. The AMF may also indicate the task ID and other service configuration, e.g., inventory strategy, aggregation indication, CP / UP transmission indication, and / or waiting duration, etc., to the selected AIoT reader (s) , which is based on its own implementation. The AIoT reader (s) may perform an inventory procedure (if necessary) and command procedure towards the associated AIoT devices to obtain the required sensing data, e.g., included in the command response. The AIoT reader (s) may respond the requested sensing data with or without other information, e.g., task ID and / or SF ID etc., to the SF via the AMF. The AMF may directly forward the requested AIoT sensing data with or without other information to the SF, or to the AIoTF and then the AIoTF will expose the sensing data with or without other information to the SF based on the SF ID.

[0128] After receiving the sensing data, e.g., from the AIoT reader (s) in step 315a, from the AIoTF in step 315b or from the AIoT AF in step 315c (including the case that the AMF is for forwarding data) , the SF may process the received AIoT sensing data, generate the sensing result, and then expose the sensing result to the sensing AF in step 317.

[0129] Figure 4 illustrates an example of a CN entity 400 in accordance with aspects of the present disclosure. The CN entity 400 may include a processor 402, a memory 404, a controller 406, and a transceiver 408. The processor 402, the memory 404, the controller 406, or the transceiver 408, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0130] The processor 402, the memory 404, the controller 406, or the transceiver 408, or various combinations or components thereof may be implemented in hardware (e.g., circuitry) . The hardware may include a processor, a digital signal processor (DSP) , an application-specific integrated circuit (ASIC) , or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0131] The processor 402 may include an intelligent hardware device (e.g., a general-purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof) . In some implementations, the processor 402 may be configured to operate the memory 404. In some other implementations, the memory 404 may be integrated into the processor 402. The processor 402 may be configured to execute computer-readable instructions stored in the memory 404 to cause the CN entity 400 to perform various functions of the present disclosure.

[0132] The memory 404 may include volatile or non-volatile memory. The memory 404 may store computer-readable, computer-executable code including instructions when executed by the processor 402 cause the CN entity 400 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 404 or another type of memory. Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0133] In some implementations, the processor 402 and the memory 404 coupled with the processor 402 may be configured to cause the CN entity 400 to perform one or more of the functions described herein (e.g., executing, by the processor 402, instructions stored in the memory 404) . For example, the processor 402 may support wireless communication at the CN entity 400 in accordance with examples as disclosed herein.

[0134] From the perspective of sensing task assignment, the CN entity 400 may be configured to support a means for receiving an AIoT service request related to data collection; and a means for initiating service procedures to related AIoT readers to obtain AIoT sensing  data based on received AIoT service request in the case that the received AIoT service request is authorized.

[0135] From the perspective of AIoT service enforcement, the CN entity 400 may be configured to support a means for receiving a first data collection related request from a data collection related entity; and a means for transmitting a second data collection related request to at least one selected AIoT related entity based on received first data collection related request to obtain AIoT sensing data.

[0136] The controller 406 may manage input and output signals for the CN entity 400. The controller 406 may also manage peripherals not integrated into the CN entity 400. In some implementations, the controller 406 may utilize an operating system such as  or other operating systems. In some implementations, the controller 406 may be implemented as part of the processor 402.

[0137] In some implementations, the CN entity 400 may include at least one transceiver 408. In some other implementations, the CN entity 400 may have more than one transceiver 408. The transceiver 408 may represent a wireless transceiver. The transceiver 408 may include one or more receiver chains 410, one or more transmitter chains 412, or a combination thereof.

[0138] A receiver chain 410 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 410 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 410 may include at least one amplifier (e.g., a low-noise amplifier (LNA) ) configured to amplify the received signal. The receiver chain 410 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 410 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0139] A transmitter chain 412 may be configured to generate and transmit signals (e.g., control information, data, packets) . The transmitter chain 412 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission  over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM) , frequency modulation (FM) , or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM) . The transmitter chain 412 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 412 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0140] Figure 5 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a CN entity as described herein. In some implementations, the CN entity may execute a set of instructions to control the function elements of the CN entity to perform the described functions.

[0141] At step 501, the method may include receiving an AIoT service request related to data collection. The operations of step 501 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 501 may be performed by a CN entity as described with reference to Figure 4 from the perspective of sensing task assignment.

[0142] At step 503, the method may include initiating service procedures to related AIoT readers to obtain AIoT sensing data based on received AIoT service request in the case that the received AIoT service request is authorized. The operations of step 503 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 503 may be performed by a CN entity as described with reference to Figure 4 from the perspective of sensing task assignment.

[0143] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0144] Figure 6 illustrates another flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a CN entity as described herein. In some implementations, the CN entity may execute a set of instructions to control the function elements of the CN entity to perform the described functions.

[0145] At step 601, the method may include receiving a first data collection related request from a data collection related entity. The operations of step 601 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 601 may be performed by a CN entity as described with reference to Figure 4 from the perspective of AIoT service enforcement.

[0146] At step 603, the method may include transmitting a second data collection related request to at least one selected AIoT related entity based on received first data collection related request to obtain AIoT sensing data. The operations of step 603 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 603 may be performed by a CN entity as described with reference to Figure 4 from the perspective of AIoT service enforcement.

[0147] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0148] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

Claims

1.A core network (CN) entity for wireless communication, comprising:at least one memory; andat least one processor coupled with the at least one memory and configured to cause the CN entity to:receive an ambient internet of things (AIoT) service request related to data collection; andinitiate service procedures to related AIoT readers to obtain AIoT sensing data based on received AIoT service request in the case that the received AIoT service request is authorized.2.The CN entity of claim 1, wherein the at least one processor is configured to cause the CN entity to register in a network repository function (NRF) , including inputting one or more of the following in the NRF:service areas;available data types in AIoT device;supported AIoT services;available readers and AIoT devices associated with the available readers;a number of available AIoT devices within a service area;network function (NF) type;NF instance identifier (ID) ;fully qualified domain name (FQDN) or internet protocol (IP) address of NF; orpublic land mobile network (PLMN) ID.3.The CN entity of claim 1, wherein the at least one processor is configured to cause the CN entity to register in a binding support function (BSF) , including inputting one or more of the following in the BSF: available data types in AIoT devices, network function (NF)  instance identifier (ID) , internet protocol (IP) address or fully qualified domain name (FQDN) of NF, or location information.4.The CN entity of claim 1, wherein the at least one processor is configured to cause the CN entity to:determine whether to authorize the AIoT service request based on subscription data in the CN entity or a different CN entity, or based on whether the AIoT service request is from an allowed consumer of the CN entity.5.The CN entity of claim 1, wherein, the AIoT service request indicates one or more of: target area, target data type, task identifier (ID) , sensing function (SF) ID, sensing application function (AF) ID, device ID, or data collection duration.6.The CN entity of claim 1, wherein initiating the service procedures comprises initiating an inventory procedure and then a command procedure after the inventory procedure, or only initiating a command procedure.7.The CN entity of claim 6, wherein in the case of initiating an inventory procedure, at least one processor is configured to cause the CN entity to:transmit an inventory request to the related readers, wherein the inventory request indicates a target data type.8.The CN entity of claim 6, wherein in the case of initiating an inventory procedure, at least one processor is configured to cause the CN entity to report one or more of the following to a sensing function (SF) based on received inventory results:AIoT device identifier (ID) that matches area and data type requirements; ora number of AIoT devices.9.The CN entity of claim 6, wherein after receiving command results from the related AIoT readers, the at least one processor is configured to cause the CN entity to:transmit obtained AIoT sensing data to a sensing function (SF) based on received command results.10.A core network (CN) entity for wireless communication, comprising:at least one memory; andat least one processor coupled with the at least one memory and configured to cause the CN entity to:receive a first data collection related request from a data collection related entity; andtransmit a second data collection related request to at least one selected ambient internet of things (AIoT) related entity based on received first data collection related request to obtain AIoT sensing data.11.A CN entity of claim 10, wherein the CN entity is a sensing function (SF) or an access and mobility management function (AMF) , and the at least one processor is configured to cause the CN entity to:send a discovery request to one or more of a network repository function (NRF) or a binding support function (BSF) to discover an AIoT function (AIoTF) ; andreceive a response indicating discovered AIoTF to use the discovered AIoTF as a selected AIoT related entity.12.A CN entity of claim 10, wherein the CN entity is a sensing function (SF) or an access and mobility management function (AMF) , and the at least one processor is configured to cause the CN entity to:send a discovery request to one or more of a network repository function (NRF) or a binding support function (BSF) or a network exposure function (NEF) to discover an AIoT application function (AF) ; andreceive a response indicating discovered AIoT AF to use the discovered AIoT AF as a selected AIoT related entity.13.A CN entity of claim 10, wherein the CN entity is a sensing function (SF) , the data collection related entity is an access and mobility management function (AMF) , and the at least one processor is configured to cause the CN entity to:receive information indicating one or more of: AIoT function (AIoTF) or AIoT application function (AF) from the AMF; andtransmit an AIoT service request as the second data collection related request to the AIoTF or the AIoT AF.14.A CN entity of claim 10, wherein the CN entity is a sensing function (SF) , and the at least one processor is configured to cause the CN entity to:receive AIoT sensing data from one or more of associated AIoT readers, an associated AIoT function (AIoTF) or an associated AIoT application function (AF) .15.A CN entity of claim 10, wherein the CN entity is an access and mobility management function (AMF) , and the at least one processor is configured to cause the CN entity to:determine a sensing function (SF) based on locally stored one or more of target location information or UE sensing entity registration information, or by sending a discovery request to one or more of a network repository function (NRF) or unified data management (UDM) where one or more of target location information or UE sensing entity registration information is stored.16.A CN entity of claim 15, wherein the SF is the selected AIoT related entity, and the at least one processor is configured to cause the CN entity to:send a discovery request to a network repository function (NRF) or a binding support function (BSF) to discover an AIoT function (AIoTF) ;receive a response indicating discovered AIoTF; andtransmit information indicating the discovered AIoTF with the AIoT service request to the SF.17.A CN entity of claim 15, wherein the SF is the selected AIoT related entity, and the at least one processor is configured to cause the CN entity to:send a discovery request to a network repository function (NRF) or a binding support function (BSF) or a network exposure function (NEF) to discover an AIoT application function (AF) ;receive a response indicating discovered AIoT AF; andtransmit information indicating the discovered AIoT AF with the AIoT service request to the SF.18.A CN entity of claim 11 or 12 or 16 or 17, wherein the discover request indicates a key using one or more of: target area, target sensing data type, AIoT device identifier (ID) , or a number of AIoT devices.19.A method performed by a core network (CN) entity, comprising:receiving an ambient internet of things (AIoT) service request related to data collection; andinitiating service procedures to related AIoT readers to obtain AIoT sensing data based on received AIoT service request in the case that the received AIoT service request is authorized.20.A method performed by a core network (CN) entity, comprising:receiving a first data collection related request from a data collection related entity; andtransmitting a second data collection related request to at least one selected ambient internet of things (AIoT) related entity based on received first data collection related request to obtain AIoT sensing data.

Images