METHOD AND APPARATUS OF SUPPORTING AMBIENT INTERNET OF THINGS (AIoT) DEVICE AUTHENTICATION

Abstract

Various aspects of the present disclosure relate to a method and apparatus of supporting ambient internet of things (AIoT) device authentication. An exemplary method performed by a CN entity may include: receiving, from a NF entity a first authentication request message associated with an AIoT device determined to be authenticated; and determining a credential holder for the AIoT device based on credential holder related information, wherein the credential holder related information indicates one or more of: AIoT device IDs, or subfields of AIoT device IDs, or mapping between AIoT device IDs or subfields of AIoT device IDs and credential holder addresses.

Description

METHOD AND APPARATUS OF SUPPORTING AMBIENT INTERNET OF THINGS (AIoT) DEVICE AUTHENTICATIONTECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to techniques associated with ambient internet of things (AIoT) device authentication.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: send, to a network function (NF) entity, an authentication request message associated with an AIoT device determined to be authenticated; and receive, from the NF entity, an authentication response message associated with the AIoT device.

[0005] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: obtain an identifier (ID) of the AIoT device; and determine whether the AIoT device needs to be authenticated based on one or more of stored authentication status of the AIoT device or an associated timer for authentication of the AIoT device.

[0006] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: send the authentication request message associated with the AIoT device directly to a unified data management (UDM) or via an authentication server function (AUSF) ; and receive the authentication response message directly from the UDM or via the AUSF, indicating that an authentication result of the AIoT device is successful or failed, or indicating that a credential holder for the AIoT device is a non-current public land mobile network (PLMN) , or indicating that a credential holder for the AIoT device is a 3rd party with information of an AIoT application function (AF) .

[0007] In some implementations of the methods and apparatuses described herein, in the case that the authentication response message indicates that a credential holder for the AIoT device is a non-current PLMN, the at least one processor is configured to cause the CN entity  to:send an authentication request message associated with the AIoT device to the non-current PLMN; and receive an authentication response message associated with the AIoT device from the non-current PLMN, indicating that an authentication result of the AIoT device is successful or failed.

[0008] In some implementations of the methods and apparatuses described herein, in the case that the authentication response message indicates that a credential holder for the AIoT device is a 3rd party, the at least one processor is configured to cause the CN entity to: send an authentication request message associated with the AIoT device to the AIoT AF; and receive an authentication response message associated with the AIoT device from the AIoT AF, indicating that an authentication result of the AIoT device is successful or failed.

[0009] In some implementations of the methods and apparatuses described herein, in the case of receiving an authentication result of the AIoT device being successful or failed, the at least one processor is configured to cause the CN entity to: allow or reject the AIoT device to access to current PLMN based on the authentication result of the AIoT device.

[0010] In some implementations of the methods and apparatuses described herein, the authentication response message further indicates one or more of an address of the credential holder or credential holder related information.

[0011] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: store one or more of the authentication result of the AIoT device, the address of the credential holder or credential holder related information; and determine a credential holder for the AIoT device based on stored one or more of the authenticate result of the AIoT device, the address of the credential holder, or the credential holder related information in the case that a timer associated with authentication of the AIoT device expires.

[0012] In some implementations of the methods and apparatuses described herein, in the case that the authentication result of the AIoT device is successful, the at least one processor is configured to cause the CN entity to: allocate a new device ID for the AIoT device; and send the new device ID with the authentication result to the AIoT device and a UDM.

[0013] In some implementations of the methods and apparatuses described herein, the authentication result is associated with an authentication timestamp.

[0014] 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, from a NF entity a first authentication request message associated with an AIoT device determined to be authenticated; and determine a credential holder for the AIoT device based on credential holder related information, wherein the credential holder related information indicates one or more of: AIoT device IDs, or subfields of AIoT device IDs, or mapping between AIoT device IDs or subfields of AIoT device IDs and credential holder addresses.

[0015] In some implementations of the methods and apparatuses described herein, the AIoT device IDs are allocated by an operator, and the subfields of AIoT device IDs include one or more: network ID, enterprise ID, owner ID, group ID, or instance ID.

[0016] In some implementations of the methods and apparatuses described herein, the AIoT device IDs are allocated by a 3rd party, and the subfields of AIoT device IDs include one or more: network ID, application ID, enterprise ID, owner ID, group ID, or instance ID.

[0017] In some implementations of the methods and apparatuses described herein, the AIoT device IDs indicate addresses of associated credential holders.

[0018] In some implementations of the methods and apparatuses described herein, at least one of the subfields of the AIoT device IDs indicates that a 3rd party is the credential holder.

[0019] In some implementations of the methods and apparatuses described herein, the credential holder related information is provided by an AIoT AF or pre-configured by an operation administration and maintenance (OAM) .

[0020] In some implementations of the methods and apparatuses described herein, in the case that a PLMN is determined as the credential holder, the at least one processor is configured to cause the CN entity to: determine whether the PLMN is a current PLMN or a  non-current PLMN for the AIoT device; and in the case of the current PLMN, interact with a local AUSF to authenticate the AIoT device; or in the case of the non-current PLMN, send an authentication response message to the NF entity, indicating that a credential holder for the AIoT device is a non-current PLMN.

[0021] In some implementations of the methods and apparatuses described herein, in the case that a 3rd party is determined as the credential holder and an address of the credential holder is available, the at least one processor is configured to cause the CN entity to: send a second authentication request message associated with the AIoT device to an AUSF with the address of the credential holder; and receive an authentication result of the AIoT device from the AUSF.

[0022] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: send the second authentication request message with information indicating that 3rd party authentication is needed and the credential holder is an authentication, authorization and accounting (AAA) sever.

[0023] In some implementations of the methods and apparatuses described herein, in the case that a 3rd party is determined as the credential holder and an address of the credential holder is unavailable, the at least one processor is configured to cause the CN entity to: send an authentication response message to the NF entity, indicating that a credential holder for the AIoT device is a 3rd party with an ID of an AIoT AF; or send a second authentication request message associated with the AIoT device to an AIoT AF; or send a second authentication request message associated with the AIoT device to a network exposure function (NEF) or network slice-specific authentication and authorization function (NSSAAF) that have locally stored the credential related information for the AIoT device.

[0024] In some implementations of the methods and apparatuses described herein, in the case that a second authentication request message associated with the AIoT device is sent, the at least one processor is configured to cause the CN entity to: receive an authentication result of the AIoT device with or without the address of the credential holder.

[0025] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: receive the authentication result together with an authentication timestamp.

[0026] Some implementations of the methods and apparatuses described herein may further include a method performed by a CN entity, which may include: sending, to a NF entity, an authentication request message associated with an AIoT device that determined to be authenticated; and receiving, from the NF entity, an authentication response message associated with the AIoT device.

[0027] Some implementations of the methods and apparatuses described herein may further include a method performed by a CN entity, which may include: receiving, from a NF entity a first authentication request message associated with an AIoT device determined to be authenticated; and determining a credential holder for the AIoT device based on credential holder related information, wherein the credential holder related information indicates one or more of: AIoT device IDs, or subfields of AIoT device IDs, or mapping between AIoT device IDs or subfields of AIoT device IDs and credential holder addresses.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0029] Figure 2 illustrates examples of credential holders for AIoT devices in accordance with aspects of the present disclosure.

[0030] Figure 3 illustrates an example of credential holder related information provision procedure in accordance with aspects of the present disclosure.

[0031] Figure 4 illustrates an example of AIoT device authentication procedure in accordance with aspects of the present disclosure.

[0032] Figure 5 illustrates an example of a NF entity in accordance with aspects of the present disclosure.

[0033] Figure 6 illustrates a flowchart of method performed by a NF entity in accordance with aspects of the present disclosure.

[0034] Figure 7 illustrates another flowchart of method performed by a NF entity in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0035] IoT has attracted much attention in wireless communication world, where IoT devices usually have a smaller size, lower complexity, lower power consumption and huger number (e.g., tens or even hundreds of billion IoT devices) than existing UEs. The IoT devices are typically battery less devices with no energy storage capability, or devices with energy storage that do not need to be replaced or recharged manually, for which the energy may be provided through the harvesting of radio waves, light, motion, heat, or any other power sources that are suitable for providing energy for the devices. For simplicity, such kind of IoT devices may be referred to as AIoT devices (or tags) . In other words, an AIoT device may be an IoT device with limited energy storage capability and powered by energy harvesting.

[0036] There are two main types of AIoT devices to be studied for 3rd generation partnership program (3GPP) Release 19, including: device-terminated (DT) and device-originated -device-terminated triggered (DO-DTT) . Accordingly, the following two connectivity topologies are to be studied:

[0037] - Topology 1: BS (or the like) <--> AIoT Device;

[0038] - Topology 2: BS (or the like) <--> intermediate node <--> AIoT Device.

[0039] Moreover, two kinds of services are being considered: inventory and command. Regarding command, it may include read, write, enable and disable etc.

[0040] When an AIoT device tries to access the 5G core (5GC) network or the like, it is essential to authenticate the AIoT device first to prevent attacks from illegal AIoT devices. In order to authenticate the AIoT device, the credential holder which has the necessary information to authenticate the AIoT device needs to be known first. Accordingly, for AIoT device authentication, at least the following two issues need to be addressed: who is the credential holder for the AIoT devices that stores the security information, e.g., credential etc., for authentication; and in the case of a 3rd party, e.g., AAA server as the credential holder,  how can 5GC or the like find the AAA server and initiate the authentication procedure towards the AAA server.

[0041] In accordance with various aspects of the present disclosure, when, a NF (or NF entity) in 5GC or the like (or referred to as a CN entity) , e.g., an access and mobility management function (AMF) or an AIoT function (AIoTF) obtains the ID of an AIoT device, e.g., via inventory procedure or AIoT device registration procedure etc., the NF entity in 5GC may determine whether the AIoT device needs to be authenticated. If the AIoT device is determined to be authenticated, 5GC will authenticate the AIoT device first by the credential holder, and then permit the following procedures for the successfully authenticated AIoT device.

[0042] For example, the AMF or AIoTF or the like may send, to another CN entity or other NF entity, e.g., UDM (directly or via an AUSF) , an authentication request message (e.g., a first authentication request message) associated with an AIoT device determined to be authenticated. After receiving the first authentication request message, the UDM may determine a credential holder for the AIoT device based on credential holder related information. The credential holder related information may indicate one or more of: AIoT device IDs, or subfields of AIoT device IDs, or mapping between AIoT device IDs or subfields of AIoT device IDs and credential holder addresses. The determined credential holder may be a PLMN, e.g., current PLMN (e.g., local or serving PLMN etc. ) or non-current PLMN (e.g., home PLMN etc. ) , or may be a 3rd party, e.g., AAA server or the like. In different scenarios, the UDM may achieve the authentication result of the AIoT device or not. Then, the UDM may send to the AMF or AIoTF or the like (directly or via the AUSF) , an authentication response message associated with the AIoT device. The authentication response message may indicate that an authentication result of the AIoT device is successful or failed, or indicating that a credential holder for the AIoT device is a non-current PLMN, or indicating that a credential holder for the AIoT device is a 3rd party with information of an AIoT AF. In the case that the authentication response message indicates that a credential holder for the AIoT device is a non-current PLMN, or a credential holder for the AIoT device is a 3rd party with information of an AIoT AF, the AMF or AIoTF or the like may send another authentication request message (e.g., a second authentication request message)  associated with the AIoT device determined to be authenticated to the non-current PLMN or the AIoT AF associated with the 3rd party credential holder to authenticate the AIoT device.

[0043] Considering 3GPP evolution, terminologies, especially the name of each NF entity (or NF) may change, and thus the related terminologies are only exemplary herein. In future, e.g., in 6G standardization, the network functions providing the same functionality / service may be differently named or may be incorporated or separated. Taking AIoTF as an example, it is assumed to be a dedicated CN network function to handle AIoT related traffics. An exemplary AIoTF may either be a standalone network function, or co-located with the AMF. The main functionalities of the AIoTF may include one or more of the following:

[0044] Receive and transmit AIoT related data and / or signalling from and / or to the AIoT application server

[0045] Select appropriate AIoT reader (e.g., UE or radio access network (RAN) ) for the transmission of AIoT data and / or signalling to the target location and / or area and / or AIoT device

[0046] Receive the registration request from the reader and store the reader information and the associated ambient IoT devices information

[0047] Establish an AIoT session with the A-IoT AF and / or access stratum (AS) for transmission

[0048] Authentication and authorization for the device access, which triggers interaction with AUSF and / or UDM

[0049] Collect charging data and interact with charging function (CHF) for charging

[0050] AIoT device and reader context management.

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

[0052] 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 core network (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.

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

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

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

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

[0057] 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) .

[0058] 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 access and mobility management functions (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.

[0059] 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) .

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

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

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

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

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

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

[0066] When an AIoT device tries to access the 5GC network, it is essential to authenticate the device by the credential holder which has credentials for AIoT devices. The credentials for AIoT devices can be in the form of a white list of AIoT devices. For example, if an AIoT device is listed on the white list, it will be regarded as legal AIoT devices and the authentication results will be successful. Otherwise, the AIoT device will be regarded as illegal AIoT device, and the authentication results will be failed. In the case that the 3rd party is a credential holder, it may be the same as the service provider. The credential holder domain and the PLMN network may have the service level agreement (SLA) to ensure the AIoT device ID to be verified or authenticated.

[0067] Figure 2 illustrates examples of credential holders for AIoT devices in accordance with aspects of the present disclosure.

[0068] As shown in Figure 2, in accordance with various aspects of the present disclosure, a credential holder for AIoT devices may be the PLMN or operator, or the 3rd party outside  the operator network, e.g., 5GC. Apart from the credential and other security materials, the credential holder may also store other information, e.g., device subscription data or the like, such as AIoT device ID information, device status information, or last serving reader information, etc. The information stored in the credential holder may be per device level or per group level.

[0069] In the case that the PLMN or operator is the credential holder, it may be the current PLMN, e.g., local or serving PLMN holding the credential for AIoT devices, or may be the non-current PLMN, e.g., home PLMN under roaming scenario, which can be determined based on the network identifier in the AIoT device ID. NF (s) within the PLMN or operator that stores security materials including the credential for AIoT devices may be a UDM or the like. Regarding the UDM, it may also be referred to as UDM / unified data repository (UDR) .

[0070] In the case that the 3rd party, e.g., an AAA server is the credential holder, the AAA server as the credential holder will have the SLA with the PLMN and the AF.

[0071] An AIoT device will be identified by an AIoT device ID. Regarding an AIoT device ID, it may be defined (or assigned or allocated or the like) by an operator or a 3rd party in accordance with various aspects of the present disclosure. In the case of an AIoT device ID allocated by an operator, exemplary subfields thereof may include one or more: network ID, enterprise ID, owner ID, group ID, or instance ID. A group ID is used to indicate many devices that belongs to the same group. An instance ID is an element or instance of a group, e.g., an AIoT device. The enterprise ID and the owner ID or even the group ID may be the same in some scenarios. For example, an enterprise, such as Lenovo, can own thousands of AIoT devices as an owner. An exemplary AIoT device ID may be:

[0072] network ID+enterprise ID (and / or owner ID and / or group ID) +instance ID.

[0073] The enterprise ID, owner ID and group ID can be used to indicate AIoT devices on a group level. Since the number of the AIoT devices may be huge, it is more efficient to determine the credential holder for AIoT devices on a group level than per device level, and needs not to store a large number of data in the 5GC, e.g., UDM / UDR.

[0074] In the case of an AIoT device ID allocated by a 3rd party, application (APP) ID (e.g., AF ID) may be used to indicate which APP allocates the AIoT device ID or own the AIoT device ID (same as the owner ID or the enterprise ID) . Exemplary subfields of an AIoT device ID allocated by a 3rd party may include one or more: network ID, APP ID, enterprise ID, owner ID, group ID, or instance ID. An exemplary AIoT device ID may be:

[0075] network ID+APP ID+ enterprise ID (and / or owner ID, and / or group ID) +instance ID. Similarly, the APP ID, enterprise ID, owner ID and group ID can be used to provide group level characteristic of AIoT devices, and will be more suitable to determine the credential holder for AIoT devices in the case that many AIoT devices may share the same credential holder.

[0076] Based on AIoT device IDs, credential holders for authentication of associated AIoT devices may be determined by a NF entity in 5GC, e.g., UDM or the like. Credential holder related information may be provided for the UDM or the like by an AIoT AF or preconfigured for the UDM or the like by an OAM in various manners, which will be stored as device or application or service subscription data in the UDM or the like. For example, credential holder related information may indicate AIoT device IDs, or indicate subfields of AIoT device IDs, or indicate mapping (or association or the like) between AIoT device IDs and credential holder addresses, or indicate mapping between subfields of AIoT device IDs and credential holder addresses, or any combination thereof. Accordingly, when the UDM or the like receive an authentication request message (amessage carrying an authentication request or the like) associated with an AIoT device, it may determine the credential holder for the AIoT device based on the stored credential holder related information.

[0077] In some implementations of the present disclosure, at least one subfield of an AIoT device ID may indicate that the credential holder is the 3rd party, e.g., an AAA server, e.g., by indicating a pre-configured or predefined value. For example, the group ID of an AIoT device ID may indicate a pre-configured or predefined value "555, " indicating that the credential holder for the associated AIoT device is an AAA server. The address of the 3rd part credential holder, e.g., the AAA server address may still need to be known by the 5GC, e.g., known by the UDM. In the case of an AIoT device ID defined by the 3rd party, APP ID may also be a subfield of the 3rd party defined AIoT device ID.

[0078] In some implementations of the present disclosure, an AIoT device ID may indicate the address of the credential holder, e.g., AAA server address for authentication of the associated AIoT device. In this case, 5GC, e.g., the AMF or AIoTF or UDM in 5GC may determine the credential holder after reading the AIoT device ID, and request the authentication from the credential holder based on the AAA servicer address indicated in the AIoT device ID.

[0079] Figure 3 illustrates an example of credential holder related information provision procedure in accordance with aspects of the present disclosure. Herein, UDM is an exemplary NF entity (e.g., CN entity) where the credential holder related information, and a similar credential holder related information provision procedure may be applied to other NF entity.

[0080] Referring to Figure 3, in step 301, a 3rd party, e.g., AIoT AF may send credential holder related information to the NEF, so that the credential holder related information will be sent to the UDM.

[0081] In some implementations of the present disclosure, the credential holder related information may include mapping information between AIoT device ID and credential holder, e.g., AAA server address, which is per device ID mapping. For example, credential holder related information may include a per device ID level mapping list as follows:

[0082] Device ID #1---AAA server address #A

[0083] ……

[0084] Device ID#N------AAA server address #Z.

[0085] In some implementations of the present disclosure, the credential holder related information may be mapping information between subfields of AIoT device ID and credential holder, e.g., AAA server address, which is per device ID mapping or per group mapping. Compared with mapping per device granularity, UDM needs not to store a large number of data in the case of per group mapping, and can handle the large number of AIoT devices case to enforce group authentication.

[0086] For example, in the case of AIoT device ID defined by an operator, exemplary credential holder related information may include a one to one mapping list of subfields of AIoT device ID and AAA server addresses as follows:

[0087] Enterprise ID#1 (and / or owner ID#1, or group ID#1) ------AAA server address #X

[0088] Enterprise ID#2 (and / or owner ID#2, or group ID#2) ------AAA server address #Y

[0089] Enterprise ID#N (and / or owner ID#N, or group ID#N) ------AAA server address #W

[0090] In the case of AIoT device ID defined by a 3rd party, exemplary credential holder related information may include a one to one mapping list of subfields of AIoT device ID and AAA server addresses as follows:

[0091] Enterprise ID#1 (and / or owner ID#1, APP ID#1, or group ID#1) ------AAA server address #X

[0092] Enterprise ID#2 (and / or owner ID#2, APP ID#2, or group ID#2) ------AAA server address #Y

[0093] ……

[0094] Enterprise ID#N (and / or owner ID#N, APP ID#N, or group ID#N) ------AAA server address #W.

[0095] For another example, in the case of AIoT device ID defined by an operator, exemplary credential holder related information may include a one to multiple mapping list of subfields of AIoT device ID and AAA server addresses as follows:

[0096] Enterprise ID#1～N (and / or owner ID#1～N, or group ID#1～N) ------AAA server address #X

[0097] Enterprise ID# (N+1) ～Z (and / or owner ID# (N+1) ～Z, or group ID# (N+1) ～Z) ------AAA server address #Y.

[0098] In the case of AIoT device ID defined by a 3rd party, exemplary credential holder related information may include a one to multiple mapping list of subfields of AIoT device ID and AAA server addresses as follows:

[0099] Enterprise ID#1～N (and / or owner ID#1～N, APP ID#1～N, or group ID#1～N) ------AAA server address #X

[0100] Enterprise ID# (N+1) ～Z (and / or owner ID# (N+1) ～Z, APP ID# (N+1) ～Z, or group ID#(N+1) ～Z) ------AAA server address #Y.

[0101] In some implementations of the present disclosure, the credential holder related information may be only a list of AIoT device ID or a list of subfields of AIoT device ID,  which means that the associated credential holder is the 3rd party, e.g., an AAA server but the AAA server address is not exposed to the UDM by the 3rd party AF or the OAM.

[0102] In the case that the AIoT device ID includes information indicating the associated credential holder is the 3rd party, e.g., indicates the AAA server address, the credential holder related information may not need to be stored in the UDM to save memories in some scenarios.

[0103] Besides the credential holder related information, the AIoT AF may also provide other information to the NEF, e.g., the AIoT AF ID etc.

[0104] It is assumed that the the NEF will select the UDM from the network repository function (NRF) based on local policies and / or local configuration, or based on the AIoT AF ID. In step 303, NEF may authorize the credential holder related information and other provision information (if any) from the AIoT AF, e.g., based on the SLA by checking the application or service subscription data (or information) stored in the UDM.

[0105] If the credential holder related information is successfully authorized, in step 305, the NEF may send the authorized credential holder related information to the selected UDM. After receiving the credential holder related information from the AIoT AF via the NEF, if it is allowed, the UDM may send a permission response to the AIoT AF via the NEF in step 307, e.g., with the NF ID of the UDM. The UDM NF ID may be used by the AIoT AF for furture provisioning procedure.

[0106] In some cases, the NEF may transmit an authorization response to the AIoT AF in step 309, indicating the authorization for the provided information is successful or failed. In the case that the authorization is failed, the NEF may also indicate a cause reason for the failure.

[0107] In some implementations of the present disclosure, a similar credential holder related information provision procedure towards the UDM may also be done via the OAM, that is, the UDM is configured or preconfigured with the credential holder related information by the OAM, and will not repeat herein.

[0108] In some implementations of the present disclosure, similar to the UDM, the NEF and / or NSSAAF may also store the credential holder related information locally, which can be per-configured by the OAM, or provided by the AIoT AF. For example, in some scenarios, the credential holder related information in the UDM may only indicate a list of AIoT device ID or a list of subfields of AIoT device ID, while the mapping or association information between the AIoT device ID or subfields of AIoT device ID and the AAA server address is stored in the NEF and / or NSSAAF.

[0109] Figure 4 illustrates an example of AIoT device authentication procedure in accordance with aspects of the present disclosure.

[0110] Referring to Figure 4, in step 401, a NF entity in 5GC, e.g., AIoTF or AMF (hereinafter only taking AIoTF as an example for clearness and simplification, and the identical or similar operations are also applicable for the AMF) may obtain an AIoT device ID in various manners. For example, the AIoTF may obtain an AIoT device ID via an inventory procedure where the inventory result report from the associated AIoT reader (e.g., UE or gNB) or AIoT device may include the AIoT device ID, or via an AIoT device registration procedure where a device registration request from the associated AIoT reader or the 3rd party AF (e.g., AIoT AF) may provide the AIoT device ID. The inventory procedure and AIoT device registration procedure can be triggered by the 3rd party AF, or by the AIoT reader.

[0111] For the obtained AIoT device ID, the AIoTF may determine whether the AIoT device needs to be authenticated, e.g., based on one or more of the stored authentication status of the AIoT device or the associated timer for authentication of the AIoT device etc. For example, the AIoTF may determine the AIoT device to be authenticated in the case that the authentication status of the AIoT device is not authenticated (or failed) or the associated timer expires. For another example, the AIoTF may determine the AIoT device to be authenticated in the case that the authentication status of the AIoT device is successfully authenticated while the associated timer expires.

[0112] The timer for authentication of the AIoT device may be configured by the OAM, the UDM, the AIoT AF (e.g., via the UDM) , or the AIoTF or AMF (e.g., based on the received timestamp of authentication result) etc., and may be per AIoT device. The timer for  authentication of an AIoT device may start after an authentication procedure for the AIoT device is done, and only when the timer expires, will the 5GC be required to authenticate the AIoT device again. It is assumed that the AIoTF or UDM may store the authentication result or status for the AIoT device after the authentication procedure for this device is finished. Considering the movement of AIoT device and the AIoTF relocation, when an AIoT device moves to the serving area of a new AIoTF, which belongs to the same UDM, the UDM may forward the timer information associated with the AIoT device ID to the new AIoTF, e.g., timer value for authentication, or timer threshold for authentication etc., with the AIoT device ID.

[0113] If it is determined that the AIoT device needs to be authenticated, the AIoTF may send an authentication request message to the UDM in step 403, e.g., directly to the UDM in step 403a or via the AUSF in step 403b and 403c. When the authentication request message is sent to the AUSF first, the AUSF may select the UDM, e.g., from the NRF or as indicated by the AIoTF, and then send the authentication request message to the selected UDM.

[0114] It is assumed that the UDM has stored the credential holder related information (if necessary) provided by the AIoT AF or OAM, e.g., as illustrated in view of Figure 3. In step 405, the UDM may determine the credential holder for the AIoT device is a PLMN or 3rd party, e.g., an AAA server based on the credential holder related information and / or AIoT device ID.

[0115] For example, the UDM may determine the credential holder for the AIoT device based on the pre-configured value in the subfields of the AIoT device ID, such as the field of network identifier, enterprise ID or owner ID and / or the group ID etc. If a pre-configured value, e.g., 555 indicating a 3rd party is written into the corresponding subfield, the UDM will determine that the 3rd party is the credential holder.

[0116] For another example, the UDM may compare the AIoT device ID or subfield of the AIoT device ID with the locally stored mapping information between AIoT device ID or subfields of AIoT device ID and AAA server address. If the corresponding AIoT device or subfield of the AIoT device ID is listed on the mapping information, the UDM will determine that the 3rd party is the credential holder for this AIoT device ID and will also determine the AAA address.

[0117] For yet another example, the UDM may compare the AIoT device ID or subfield of the AIoT device ID with the locally stored AIoT device ID or subfields of AIoT device ID.If the corresponding AIoT device or subfield of the AIoT device ID is matched with the stored AIoT device ID information or subfield information of the AIoT device ID, the UDM will determine that the 3rd party is the credential holder for this AIoT device ID but fail to determine the AAA address.

[0118] Dependent on different determination results, the UDM may perform different following operations, which will be illustrated in the following in view of exemplary implementations of the present disclosure.

[0119] Result 1: PLMN is the credential holder

[0120] In some scenarios, the UDM may determine that the PLMN is the credential holder, e.g., based on the network identifier of the AIoT device ID and / or there is no matching result for 3rd party credential holder based on the credential holder related information (e.g., a mapping list based on enterprise ID is provided but the enterprise ID of the AIoT device ID is not on the list) . Then, the UDM may determine whether the PLMN that holds the credential for the AIoT device is the current PLMN or not based on the network identifer, e.g., using the PLMN ID. If it is the current PLMN (current PLMN is the credential holder) , the UDM may interact with the local AUSF to authenticate the AIoT device in step 407a. If it is not the current PLMN, e.g., being the home PLMN (home PLMN is the credential holder) , the UDM may send an authentication response message (or a message carrying an authentication response) to the AIoTF in step 407b, indicating the AIoTF to request authentication for the AIoT device from the home PLMN. After receiving the authentication response message, the AIoTF may send an authentication request message with the AIoT device ID to the home PLMN, e.g., via the security edge protection proxy (SEPP) to obtain the authentication result from home PLMN.

[0121] Result 2: 3rd party is the credential holder

[0122] In some scenarios, the UDM may determine that the 3rd party, e.g., an AAA server is the credential holder for the AIoT device. However, the AAA server address may be available or known by the UDM or not.

[0123] If the AAA server address is provided by the credential holder related information, e.g., indicated in the mapping list or included in the AIoT device ID, the UDM will know the information of the AAA server. Accordingly, after the UDM determines that the credential holder for the AIoT device is the AAA server, the UDM may obtain the authentication result from the AAA server in step 409.

[0124] For example, the UDM may send an authentication request message to the AUSF, e.g., together with the AAA server address and the AIoT device ID etc., in step 409a. In some implementations of the present disclosure, the UDM may also send an indication to the AUSF to indicate that the 3rd party authentication is needed and the credential holder is the AAA server. The AUSF may select the NSSAAF, e.g., based on Clause 6.3.17, TS 23.501 or the like, and send the AIoT device ID and AAA server address etc., to the selected NSSAAF in step 409b. The NSSAAF may find the AAA server using the provided AAA server address, interacts with the AAA server and obtains the authentication result (e.g., successful or failed) in step 409c. The NSSAAF may send the authentication result associated with the AIoT device ID to the AUSF in step 409d, and then the AUSF may send the authentication result to the UDM in step 409e. In some implementations of the present disclosure, the authentication result for the AIoT device may be sent to the UDM with a timestamp or other information. In some implementations of the present disclosure, the UDM may store the information of the AUSF that sends the authentication result for this AIoT device ID for authentication of the AIoT device in the future.

[0125] In some scenarios, the UDM may determine that the 3rd party, e.g., the AAA server is the credential holder for the AIoT device while the AAA server address is not available for the UDM. The UDM may initiate a procedure to authenticate the AIoT device, e.g., via the AIoT AF, or NEF or NSSAAF etc., or indicate the AIoTF to initiate an authentication procedure, e.g., via the AIoT AF etc.

[0126] In some implementations of the present disclosure, the UDM may have the mapping or association information between the AIoT device ID and the corresponding AF (e.g., AF ID) that owns the AIoT device. Therefore, when the AAA server address is not available in the UDM, the UDM may know to which AF the authentication request will be forwarded, and the AF may send the authentication request to the AAA server. The  association information between the AIoT device ID and the corresponding AF may be derived by the UDM in various ways, e.g., based on the enterprise ID of the AIoT device ID and the stored subscription data, or based on the information of the AF that initiates the AIoT device registration and / or service procedures (e.g., sending inventory and / or command request etc. ) etc.

[0127] For example, when the AAA server address is not available at the UDM and the association information between the AIoT device ID and the corresponding AF can be obtained by the UDM, the UDM may send an authentication response message to the AIoTF (directly or via the AUSF) in step 411a, indicating the information of the AF associated with the AIoT device, e.g., the ID of the associated AIoT AF with AIoT device ID. The authentication response message may explicitly or implicitly indicate that the 3rd party is the credential holder. Based on the received AF ID, the AIoTF may send an authentication request message to the AIoT AF in step 411b, e.g., via the NEF, which may indicate the AIoT device ID. In some cases, instead of indicating the AIoTF, the UDM may send an authentication request message to the AIoT AF via the NEF, e.g., together with the AIoT device ID etc., in step 411c.

[0128] It is assumed that the AIoT AF can find the AAA server for the AIoT device based on the SLA between the AAA server and the AIoT AF. The AIoT AF may discover and interact with the AAA server to authenticate the AIoT device in step 411d, and send the authentication result (successful or not) associated with the AIoT device ID to the AIoTF in step 411e, or to the UDM in step 411f. In some implementations of the present disclosure, besides the authentication result, the AAA server address and other information, e.g., timestamp of the authentication result may also be sent or exposed to the AIoTF or the UDM. The AIoTF or UDM may locally store (and / or update) the AAA server information etc., for the AIoT device.

[0129] In some implementations of the present disclosure, the NEF and / or NSSAAF may have locally stored the mapping or association information between AIoT device ID or the subfields of AIoT device ID and the AAA address. When the UDM determines that the credential holder for an AIoT device is the AAA server and does not have the AAA server information, the UDM may send an authentication request message to the NEF or NSSAAF  (e.g., via the AUSF) with the AIoT device ID in step 413a (herein, for simplification and clearness, only steps based on NSSAAF is shown as an example) .

[0130] The NEF or NSSAAF may check the locally stored information to find the AAA server, and interact with the AAA server in step 413b for authenticating the AIoT device. For the NSSAAF, it may directly interact with the AAA server to authenticate the AIoT device. For the NEF, it may send the AAA server address and the AIoT device ID etc., to the AAA server via the NSSAAF to authenticate the AIoT device. Then, the NSSAAF or NEF may send the authentication result to the UDM in step 413c. Similarly, in some implementations of the present disclosure, besides the authentication result, the AAA server address etc., may also be sent or exposed to the NEF or NSSAAF or UDM. The NEF or NSSAAF or UDM may locally store (and / or update) the AAA server information etc., for the AIoT device.

[0131] In the case that the UDM obtains the authentication result for the AIoT device, e.g., by interacting with the AUSF, or via the AIoT AF or via the NEF or NSSAAF etc., the UDM may send the authentication result of the AIoT device to the AIoTF in step 415 (directly or via the AUSF) , e.g., with the AIoT device ID, and / or time stamp etc. In some implementations of the present disclosure, the UDM may also send to the AIoTF the credential holder related information, e.g., the mapping information between AIoT device IDs or subfields of the AIoT device ID and the AAA server etc. In some implementations of the present disclosure, the UDM may locally store the authentication result (or status) for the AIoT device, e.g., as the device subscription data or the like.

[0132] Based on the authentication result, e.g., received from the AIoT AF or UDM (directly or via the AUSF) , the AIoTF or AMF may allow the AIoT device access the current PLMN in the case of successful authentication or reject the AIoT device to the current PLMN accordingly in the case of failed authentication. The AIoTF or AMF may also send the authentication result to the AIoT device, e.g., via AIoT non-access stratum (NAS) message between the AIoTF or AMF and AIoT device.

[0133] In some implementations of the present disclosure, the AIoTF or AMF may also allocate a new device ID for the successfully authenticated AIoT device, and send the new assigned device ID to the AIoT device, e.g., together with the authentication result via AIoT  NAS message. Since the new AIoT device ID is assigned by the 5GC, its uniqueness is guaranteed, e.g., based on the instance ID.

[0134] Besides that case that the AAA address is included in the AIoT device ID, the AIoTF or AMF may also be the NF to determine the credential holder for AIoT devices, partially owning the functionality of the UDM. For example, in the case that the AIoTF or AMF obtains and / or stores the credential holder related information, e.g., the mapping information between AIoT device ID or subfields of AIoT device ID, the authentication result of the AIoT device, and / or the AAA server address, for an obtained AIoT device ID, the AIoTF or AMF may determine whether the associated AIoT device has been authenticated, and if not, further determine whether its credential holder is a PLMN credential holder or a 3rd party credential holder etc., and may interact with the corresponding credential holder directly, e.g., send the authentication request to the UDM or the AAA server (via NSSAAF) based on the credential holder information obtained locally.

[0135] Figure 5 illustrates an example of a CN entity or other NF entity 500 in accordance with aspects of the present disclosure. The CN entity or other NF entity 500 may include a processor 502, a memory 504, a controller 506, and a transceiver 508. The processor 502, the memory 504, the controller 506, or the transceiver 508, 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.

[0136] The processor 502, the memory 504, the controller 506, or the transceiver 508, 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.

[0137] The processor 502 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 502 may be configured to operate the memory 504. In some other implementations, the memory 504 may be integrated into the processor 502. The  processor 502 may be configured to execute computer-readable instructions stored in the memory 504 to cause the CN entity or other NF entity 500 to perform various functions of the present disclosure.

[0138] The memory 504 may include volatile or non-volatile memory. The memory 504 may store computer-readable, computer-executable code including instructions when executed by the processor 502 cause the CN entity or other NF entity 500 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 504 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.

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

[0140] In some implementations, the CN entity or other NF entity 500 may act as an AMF or AIoTF or the like and be configured to support a means for sending, to a NF entity, an authentication request message associated with an AIoT device that determined to be authenticated; and a means for receiving, from the NF entity, an authentication response message associated with the AIoT device.

[0141] In some implementations, the CN entity or other NF entity 500 may act as a UDM or the like and be configured to support a means for receiving, from a NF entity a first authentication request message associated with an AIoT device determined to be authenticated; and a means for determining a credential holder for the AIoT device based on credential holder related information and the value of the subfield or device ID, wherein the credential holder related information indicates one or more of: AIoT device IDs, or subfields  of AIoT device IDs, or mapping between AIoT device IDs or subfields of AIoT device IDs and credential holder addresses.

[0142] The controller 506 may manage input and output signals for the NF entity 500. The controller 506 may also manage peripherals not integrated into the NF entity 500. In some implementations, the controller 506 may utilize an operating system such as or other operating systems. In some implementations, the controller 506 may be implemented as part of the processor 502.

[0143] In some implementations, the NF entity 500 may include at least one transceiver 508. In some other implementations, the NF entity 500 may have more than one transceiver 508. The transceiver 508 may represent a wireless transceiver. The transceiver 508 may include one or more receiver chains 510, one or more transmitter chains 512, or a combination thereof.

[0144] A receiver chain 510 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 510 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 510 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. The receiver chain 510 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 510 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0145] A transmitter chain 512 may be configured to generate and transmit signals (e.g., control information, data, packets) . The transmitter chain 512 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 512 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 512 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0146] Figure 6 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 or other NF entity as described herein. In some implementations, the CN entity or other NF entity may execute a set of instructions to control the function elements of the CN entity or other NF entity to perform the described functions.

[0147] At step 601, the method may include sending, to a NF entity, an authentication request message associated with an AIoT device that determined to be authenticated. The operations of step 601 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 601 may be performed by a CN entity or other NF entity as an AMF or AIoTF as described with reference to Figure 5.

[0148] At step 603, the method may include receiving, from the NF entity, an authentication response message associated with the AIoT device. 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 or other NF entity as an AMF or AIoTF as described with reference to Figure 5.

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

[0150] Figure 7 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 or other NF entity as described herein. In some implementations, the CN entity or other NF entity may execute a set of instructions to control the function elements of the CN entity or other NF entity to perform the described functions.

[0151] At step 701, the method may include receiving, from a NF entity a first authentication request message associated with an AIoT device determined to be authenticated. The operations of step 701 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 701 may be  performed by a CN entity or other NF entity as the UDM or the like described with reference to Figure 5.

[0152] At step 703, the method may include determining a credential holder for the AIoT device based on credential holder related information and the value of the subfield or device ID, wherein the credential holder related information indicates one or more of: AIoT device IDs, or subfields of AIoT device IDs, or mapping between AIoT device IDs or subfields of AIoT device IDs and credential holder addresses. The operations of step 703 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 703 may be performed by a CN entity or other NF entity as UDM or the like as described with reference to Figure 5.

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

[0154] 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:send, to a network function (NF) entity, an authentication request message associated with an ambient internet of things (AIoT) device determined to be authenticated; andreceive, from the NF entity, an authentication response message associated with the AIoT device.2.The CN entity of claim 1, wherein the at least one processor is configured to cause the CN entity to:obtain an identifier (ID) of the AIoT device; anddetermine whether the AIoT device needs to be authenticated based on one or more of stored authentication status of the AIoT device or an associated timer for authentication of the AIoT device.3.The CN entity of claim 1, wherein the at least one processor is configured to cause the CN entity to:send the authentication request message associated with the AIoT device directly to a unified data management (UDM) or via an authentication server function (AUSF) ; andreceive the authentication response message directly from the UDM or via the AUSF, indicating that an authentication result of the AIoT device is successful or failed, or indicating that a credential holder for the AIoT device is a non-current public land mobile network (PLMN) , or indicating that a credential holder for the AIoT device is a 3rd party with information of an AIoT application function (AF) .4.The CN entity of claim 3, wherein in the case that the authentication response message indicates that a credential holder for the AIoT device is a non-current PLMN, the at least one processor is configured to cause the CN entity to:send an authentication request message associated with the AIoT device to the non-current PLMN; andreceive an authentication response message associated with the AIoT device from the non-current PLMN, indicating that an authentication result of the AIoT device is successful or failed.5.The CN entity of claim 1, wherein in the case of receiving an authentication result of the AIoT device being successful or failed, the at least one processor is configured to cause the CN entity to:allow or reject the AIoT device to access to current public land mobile network (PLMN) based on the authentication result of the AIoT device.6.The CN entity of claim 5, wherein the authentication response message further indicates one or more of an address of the credential holder or credential holder related information.7.The CN entity of claim 6, wherein the at least one processor is configured to cause the CN entity to:store one or more of the authentication result of the AIoT device, the address of the credential holder or credential holder related information; anddetermine a credential holder for the AIoT device based on stored one or more of the authenticate result of the AIoT device, the address of the credential holder, or the credential holder related information in the case that a timer associated with authentication of the AIoT device expires.8.The CN entity of claim 5, wherein in the case that the authentication result of the AIoT device is successful, the at least one processor is configured to cause the CN entity to:allocate a new device identifier (ID) for the AIoT device; andsend the new device ID with the authentication result to the AIoT device and a unified data management (UDM) .9.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, from a network function (NF) entity a first authentication request message associated with an ambient internet of things (AIoT) device determined to be authenticated; anddetermine a credential holder for the AIoT device based on credential holder related information, wherein the credential holder related information indicates one or more of: AIoT device identifiers (IDs) , or subfields of AIoT device IDs, or mapping between AIoT device IDs or subfields of AIoT device IDs and credential holder addresses.10.The CN entity of claim 9, wherein the AIoT device IDs are allocated by an operator, and the subfields of AIoT device IDs comprise one or more: network ID, enterprise ID, owner ID, group ID, or instance ID.11.The CN entity of claim 9, wherein the AIoT device IDs are allocated by a 3rd party, and the subfields of AIoT device IDs comprise one or more: network ID, application ID, enterprise ID, owner ID, group ID, or instance ID.12.The CN entity of claim 10 or 11, wherein at least one of the subfields of the AIoT device IDs indicates that a 3rd party is the credential holder.13.The CN entity of claim 9, wherein the credential holder related information is provided by an AIoT application function (AF) or pre-configured by an operation administration and maintenance (OAM) .14.The CN entity of claim 9, wherein in the case that a public land mobile network (PLMN) is determined as the credential holder, the at least one processor is configured to cause the CN entity to:determine whether the PLMN is a current PLMN or a non-current PLMN for the AIoT device; andin the case of the current PLMN, interact with a local authentication server function (AUSF) to authenticate the AIoT device; orin the case of the non-current PLMN, send an authentication response message to the NF entity, indicating that a credential holder for the AIoT device is a non-current PLMN.15.The CN entity of claim 9, wherein in the case that a 3rd party is determined as the credential holder and an address of the credential holder is available, the at least one processor is configured to cause the CN entity to:send a second authentication request message associated with the AIoT device to an authentication server function (AUSF) with the address of the credential holder; andreceive an authentication result of the AIoT device from the AUSF.16.The CN entity of claim 15, wherein the at least one processor is configured to cause the CN entity to:send the second authentication request message with information indicating that 3rd party authentication is needed and the credential holder is an authentication, authorization and accounting (AAA) sever.17.The CN entity of claim 9, wherein in the case that a 3rd party is determined as the credential holder and an address of the credential holder is unavailable, the at least one processor is configured to cause the CN entity to:send an authentication response message to the NF entity, indicating that a credential holder for the AIoT device is a 3rd party with an ID of an AIoT application function (AF) ; orsend a second authentication request message associated with the AIoT device to an AIoT AF; orsend a second authentication request message associated with the AIoT device to a network exposure function (NEF) or network slice-specific authentication and authorization function (NSSAAF) that have locally stored the credential related information for the AIoT device.18.The CN entity of claim 17, wherein in the case that a second authentication request message associated with the AIoT device is sent, the at least one processor is configured to cause the CN entity to:receive an authentication result of the AIoT device with or without the address of the credential holder.19.A method performed by a core network (CN) entity, comprising:sending, to a network function (NF) entity, an authentication request message associated with an ambient internet of things (AIoT) device determined to be authenticated; andreceiving, from the NF entity, an authentication response message associated with the AIoT device.20.A method performed by a core network (CN) entity, comprising:receiving, from a network function (NF) entity a first authentication request message associated with an ambient internet of things (AIoT) device determined to be authenticated; anddetermining a credential holder for the AIoT device based on credential holder related information, wherein the credential holder related information indicates one or more of: AIoT device identifiers (IDs) , or subfields of AIoT device IDs, or mapping between AIoT device IDs or subfields of AIoT device IDs and credential holder addresses.

Images