METHOD AND APPARATUS OF SUPPORTING INTERNET OF THINGS (IoT)

Abstract

Various aspects of the present disclosure relate to a method and apparatus of supporting internet of things (IoT). An exemplary method performed by a CN entity for wireless communication may include receiving, from an AIoT reader, a request message associated with an AIoT device at least to access the core network, wherein the request message is based on a D2R transmission generated internally by the AIoT device; performing access control for the AIoT device; and determining an AF to which traffics from the AIoT device will be routed in the case that the request message is accepted based on the access control by the CN entity.

Description

METHOD AND APPARATUS OF SUPPORTING INTERNET OF THINGS (IoT)TECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to techniques of supporting internet of things (IoT) , e.g., ambient internet of things (AIoT or A-IoT) .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, from an AIoT reader, a request message associated with an AIoT device at least to access a core network, wherein the request message is based on a device to reader (D2R) transmission generated internally by the AIoT device; perform access control for the AIoT device; and determine an application function (AF) to which traffics from the AIoT device will be routed in the case that the request message is accepted based on the access control by the CN entity.

[0005] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to further cause the CN entity to send access control configuration to the AIoT reader, which may include one or multiple of: an allowed maximum number of AIoT devices; an allowed access frequency range; an allowed access area; allowed access waiting time; allowed access time or period; an allowed access type; an allowed data type; allowed 3rd party information; or allowed network information.

[0006] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to further cause the CN entity to send to the AIoT reader one or multiple of: a proximity report indication to request the AIoT reader to perform proximity determination for AIoT devices and report determined proximity information; load information of the CN entity; or priority information related to handling messages of AIoT devices.

[0007] In some implementations of the methods and apparatuses described herein, the priority information is based on one or multiple of AIoT device location, AIoT device group or filtering information, AIoT data type, AIoT device identifier (ID) , access type, service type, or an AF request.

[0008] In some implementations of the methods and apparatuses described herein, the request message includes one or multiple of: data from the AIoT device; an ID of the AIoT device; follow-up data transmission information of the AIoT device, including one or multiple of a follow-up data transmission request or a size of data to be transmitted from the AIoT device; or an access request of the AIoT device.

[0009] In some implementations of the methods and apparatuses described herein, the request message further includes one or multiple of: AF information; an access type of the AIoT device; an ID of the AIoT reader; proximity information; or a type of data to be transmitted from the AIoT device.

[0010] In some implementations of the methods and apparatuses described herein, in the case that the request message is accepted, the at least one processor is configured to further cause the CN entity to perform one or multiple of: generating a temporary device ID and storing the temporary device ID at CN side so that there is a mapping between a permanent device ID, the temporary device ID and the CN entity; sending a temporary device ID of the AIoT device to the AIoT reader and the AIoT device, wherein the temporary device ID is generated by the CN entity or retrieved from another CN entity; determining an access type of the AIoT device based on device context locally stored or stored in another CN entity; register the AIoT device locally or at another CN entity, where a status of the AIoT device status is set as registered; or store and manage device information as device context locally or at another CN entity.

[0011] In some implementations of the methods and apparatuses described herein, in the case that the request message is rejected, the at least one processor is configured to further cause the CN entity to send a response message to the AIoT reader and the AIoT device, rejecting the AIoT device to access network or rejecting the AIoT device to transmit data.

[0012] In some implementations of the methods and apparatuses described herein, in the case that the request message is accepted, the at least one processor is configured to further cause the CN entity to send a response message to the AIoT reader or a serving reader of the AIoT device same as or different from the AIoT reader, which may include one or multiple of: an allowed data transmission indication in response to follow-up data transmission information of the AIoT device; an allowed access indication in response to an access request of the AIoT device; an ID of the AIoT device; device access configuration indicating the AIoT device when to access the network; data report and device inventory configuration; aggregation assistance information; or a service correlation identifier.

[0013] In some implementations of the methods and apparatuses described herein, the device access configuration configures periodic access, event based access or device mobility based access.

[0014] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to further cause the CN entity to: determine the serving reader of the AIoT device from multiple readers associated with the AIoT device based on received proximity information.

[0015] In some implementations of the methods and apparatuses described herein, there are multiple readers associated with the AIoT device and the serving reader is determined, and the at least one processor is configured to further cause the CN entity to: send to other readers of the multiple readers a context release indication to release connection with the AIoT device.

[0016] In some implementations of the methods and apparatuses described herein, determining the AF to which traffics from the AIoT device will be routed is based on one or multiple of: AF information received from the AIoT device; 3rd party information included in an ID of the AIoT device; allowed 3rd party or AF information of the AIoT device stored in CN side; or a received AF service request.

[0017] In some implementations of the methods and apparatuses described herein, the AIoT reader is a user equipment (UE) reader, and the at least one processor is configured to cause the CN entity to: send the access control configuration to a radio access network (RAN) entity serving the UE reader.

[0018] In some implementations of the methods and apparatuses described herein, the AIoT reader is a UE reader, and the at least one processor is configured to cause the CN entity to: receive an indication of access control support for AIoT devices by the UE reader.

[0019] In some implementations of the methods and apparatuses described herein, the AIoT reader is a UE reader, and the at least one processor is configured to cause the CN entity to: receive information related to a serving reader selected by a RAN entity serving the UE reader from the NE.

[0020] In some implementations of the methods and apparatuses described herein, the AIoT reader is a UE reader serving by a RAN entity, and the at least one processor is configured to cause the CN entity to: receive, from the NE, information indicating readers selected by the NE and proximity information; and determine a serving reader from the readers selected by the NE based on the proximity information.

[0021] In some implementations of the methods and apparatuses described herein, the AIoT reader is a UE reader serving by a RAN entity, and the at least one processor is configured to cause the CN entity to: receive an ID of the AIoT device from multiple UE readers; and determine a serving reader from the multiple readers.

[0022] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: subscribe to connection information related to connection of access and mobility management function (AMF) with RAN entity; and receive the connection information from operations administration and maintenance (OAM) or the AMF, including information of RAN entities that has set up connection with the AMF.

[0023] Some implementations of the methods and apparatuses described herein may further include an AIoT reader 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 AIoT reader to: receive, from an AIoT device, a D2R transmission generated internally by the AIoT device to access a CN; perform access control for the AIoT device; and send a request message based on the D2R transmission to a CN entity in the case that the D2R transmission is accepted based on the access control by the AIoT reader.

[0024] In some implementations of the methods and apparatuses described herein, the D2R transmission includes one or multiple of: data that needs to be transmitted; follow-up data transmission information, including one or multiple of a follow-up data transmission request or a size of data to be transmitted; or an access request.

[0025] In some implementations of the methods and apparatuses described herein, in the case that the AIoT reader is a RAN entity, performing access control for the AIoT device is based on one or multiple of: access control configuration provided by the CN entity; access control configuration provided by OAM; or reader's own local configurations and implementations.

[0026] In some implementations of the methods and apparatuses described herein, in the case that the AIoT reader is a UE reader serving by a RAN entity, performing access control for the AIoT device is based on one or multiple of: access control configuration provided by the CN entity; access control configuration provided by the RAN entity; or reader's own implementations.

[0027] In some implementations of the methods and apparatuses described herein, in the case that the D2R transmission is accepted, the at least one processor is configured to cause the AIoT reader to perform one or multiple of: determining an access type of the AIoT device based on locally stored device context or an access type indication from the AIoT device and reporting to the CN entity; determining proximity information of the AIoT device and reporting to the CN entity; determining a handling order of the request message based on priority information provided by the CN entity or indicated by the AIoT device; or select the CN entity based on pre-established connection with CN entities, received load information of CN entities, or CN entity information indicated by the AIoT device.

[0028] In some implementations of the methods and apparatuses described herein, in the case that the D2R transmission is accepted and includes data that needs to be transmitted, the at least one processor is configured to further cause the AIoT reader to: include the data that needs to be transmitted in the request message; or hold the data that needs to be transmitted at the reader until receiving an allowed data transmission indication from the CN entity.

[0029] In some implementations of the methods and apparatuses described herein, in the case of holding the data that needs to be transmitted, the at least one processor is configured to further cause the AIoT reader to: include follow-up data transmission information of the AIoT device in the request message, wherein the follow-up data transmission information indicates one or multiple of a follow-up data transmission request or a size of data to be transmitted.

[0030] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to further cause the AIoT reader to: aggregate data that needs to be transmitted to the CN entity based on one or multiple of aggregation assistance information receive from the CN entity or target application function ID.

[0031] Some implementations of the methods and apparatuses described herein may further include an AIoT device 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 AIoT device to: generate internally a D2R transmission to at least access network by including one or multiple of: data that needs to be transmitted to a CN, follow-up data transmission information related to data that needs to be transmitted later, or an access request requesting to access a core network; and transmit the D2R transmission to one or multiple AIoT readers.

[0032] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to further cause the AIoT device to: generate and transmit the D2R transmission only in the case that there are data to be transmitted or regardless whether there are data to be transmitted.

[0033] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to further cause the AIoT device to: determine whether there are data to be transmitted based on a data report configuration, wherein the data report configuration is preconfigured or configured by a CN entity.

[0034] In some implementations of the methods and apparatuses described herein, the data report configuration preconfigures or configures the AIoT device to periodically report data based on a time value or a timer, or event triggered report data.

[0035] Some implementations of the methods and apparatuses described herein may further include a method performed by a CN entity for wireless communication, which may include: receiving, from an AIoT reader, a request message associated with an AIoT device at least to access a core network, wherein the request message is based on a D2R transmission generated internally by the AIoT device; performing access control for the AIoT device; and determining an AF to which traffics from the AIoT device will be routed in the case that the request message is accepted based on the access control by the CN entity.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0037] Figure 2 illustrates an example of AIoT device access procedure under Topology 1 in accordance with aspects of the present disclosure.

[0038] Figure 3 illustrates an example of AIoT device access procedure under Topology 2 in accordance with aspects of the present disclosure.

[0039] Figure 4 illustrates an example of a UE in accordance with aspects of the present disclosure.

[0040] Figure 5 illustrates an example of a processor in accordance with aspects of the present disclosure.

[0041] Figure 6 illustrates an example of an AIoT reader in accordance with aspects of the present disclosure.

[0042] Figure 7 illustrates an example of an AIoT device in accordance with aspects of the present disclosure.

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

[0044] Figure 9 illustrates a flowchart of method performed by an AIoT reader in accordance with aspects of the present disclosure.

[0045] Figure 10 illustrates a flowchart of method performed by an AIoT device in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0046] 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, ” or just "devices" in some contexts) . In other words, an AIoT device may be an IoT device with limited energy storage capability and powered by energy harvesting.

[0047] 3rd generation partnership program (3GPP) Release 19 (R19) has achieved some preliminary agreements on AIoT, and there are more normative works needed to be pursued and studied for AIoT.

[0048] Various aspects of the present disclosure propose at least one technical solution of supporting IoT, wherein at least issues on how to handle unexpected access requests with or without data transmission from the AIoT devices and how to transmit the unexpected data from such AIoT devices to the target AIoT AF (or “AF” for simplification and clarity) in the case of the access request with data transmission are solved.

[0049] For example, in accordance with aspects of the present disclosure, an AIoT device may generate internally a D2R transmission to at least access the core network (or register in the CN or the like) in an explicit manner or implicit manner, and send the D2R transmission to a CN entity, e.g., an AIoT function (AIoTF) or the like via one or multiple AIoT readers (or “readers” for simplification and clarity) . Herein, for simplification and clarity, a D2R transmission generated internally by an AIoT device to at least access network is referred to as an access D2R transmission or registration D2R transmission or the like.

[0050] For example, in some implementations of the present disclosure, regardless whether there are data to be transmitted to the CN, the AIoT device may include an access request (or access indication or registration request or registration indication or the like) in the access D2R transmission to explicitly request to access CN. In the case that there are data to be reported at the AIoT device, the AIoT device may also transmit the data with the access request, or transmit the data later (referred to as followed up data transmission or the like) while includes follow-up data transmission information related to data that needs to be transmitted later.

[0051] In some implementations of the present disclosure, in the case that there are data to be reported at the AIoT device, the AIoT device may implicitly request to access CN rather than using an explicit access request. For example, the AIoT device may include data that needs to be transmitted to the CN or follow-up data transmission information related to data that needs to be transmitted later in an access D2R transmission.

[0052] For an AIoT reader that receives an access D2R transmission, the AIoT reader may perform access control for the AIoT device or the access D2R transmission (hereinafter, first access control) . If the AIoT device or the access D2R transmission is allowed or accepted based on the access control by the AIoT reader, the AIoT reader may send a request message based on the access D2R transmission to the CN entity, e.g., the AIoTF or the like. Similar to the access D2R transmission, the request message may also include data that needs to be transmitted, follow-up data transmission information (generated by the AIoT reader or received from the AIoT device) , an access request or registration request (generated by the AIoT reader or received from the AIoT device) or a combination thereof.

[0053] Accordingly, for an AIoTF or the like that receives the request message from the AIoT reader (may receive multiple request messages from multiple AIoT readers associated with the same AIoT device) , the AIoTF or the like may also perform access control for the AIoT device or the request message (hereinafter, second access control) . The access control at the AIOTF may include at least one or more of the AIoT device access determination, AIoT device authentication and verification, device authorization for access or registration, or authorization for data transmission. If the AIoT device or the request message is allowed or accepted based on the access control, the AIoTF will register the AIoT device and determine an AIoT AF to which traffics from the AIoT device will be routed, which means that the AIoT device is allowed to access the CN. The AIoTF will make a response to the AIoT device via the AIoT reader (each associated AIoT reader or a selected serving AIoT reader) to indicate the allowing either directly via AIoT NAS message, or indirectly.

[0054] 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: Receive and transmit AIoT related data and / or signalling from and / or to the AIoT  application server 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 Receive the registration request from the reader and store the reader information and the  associated ambient IoT devices information Establish an AIoT session with the A-IoT AF and / or access stratum (AS) for  transmission Authentication and authorization for the device access, which triggers interaction with  authentication server function (AUSF) and / or unified data management (UDM) Collect charging data and interact with charging function (CHF) for charging AIoT device and reader context management.

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

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

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

[0058] 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. In some embodiments, the NEs 102 may include one or more relay nodes, integrated access and backhaul (IAB) nodes or wireless access backhaul (WAB) nodes which can provide wireless access services for UEs 104. A relay node (or an IAB node or a WAB node) can directly connect to a BS or hop through one or more relay nodes (or one or more IAB or WAB nodes) before reaching the BS.

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

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

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

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

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

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

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

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

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

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

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

[0070] There are various AIoT connectivity topologies, and the following two connectivity topologies are mainly studied: - Topology 1: BS (or the like) <--> AIoT Device; - Topology 2: BS (or the like) <--> intermediate node <--> AIoT Device. Under Topology 1, an exemplary reader is a NE, RAN node or BS or the like, which may be  referred to as next generation (NG) RAN, NE reader, RAN reader, BS reader or AIoT RAN etc. In some cases, an AIoT RAN may include one or more RAN readers or BS readers or the like. Communications between the BS reader and AIoTF may be via the AMF or not, which may be referred to direct path (no AMF) or indirect path (via an AMF) respectively. Under Topology 2, the intermediate node acts as an AIoT reader. An exemplary intermediate node may be a UE, which may be referred to as a UE reader. A NE, RAN, RAN node or BS or the like serving a UE reader is AIoT enabled, which may be referred to an AIoT enabled RAN node, AIoT enabled RAN, AIoT BS, NG RAN or the like. In addition, there are two solutions under Topology 2, including control plane solution, e.g., radio resource control (RRC) based solution and user plane solution.

[0071] In any topology, two kinds of services are considered for AIoT, i.e., inventory and command. Regarding command, it may include read, write, enable and disable etc.

[0072] Different types of AIoT device may have different capabilities. For example, one type of AIoT device is: ～1 μW peak power consumption, has energy storage, initial sampling frequency offset (SFO) up to 10X ppm, neither reader to device (R2D) nor D2R amplification in the device. The device's D2R transmission is backscattered on a carrier wave provided externally, which may be referred to as Device type 1 or Device 1. Another type of AIoT device is: ≤ a few hundred μW peak power consumption, has energy storage, initial SFO up to 10X ppm, both R2D and / or D2R amplification in the device. The device’s D2R transmission is backscattered on a carrier wave provided externally, which may be referred to as Device type 2a or Device 2a. Yet another type of AIoT device is: ≤ a few hundred μW peak power consumption, has energy storage, initial SFO up to 10X ppm, both R2D and / or D2R amplification in the device, wherein the device’s D2R transmission is generated internally by the device, which may be referred to as Device type 2b or Device 2b and Device C. In other words, for Device 1 and Device 2a, the D2R transmission or message is backscattered on a carrier wave provided externally; while for Device 2b and Device C, the D2R transmission can be started by device itself using its own internally generated carrier wave.

[0073] An AIoT device can operate in different modes, e.g., device-terminated (DT) , device-originated -device-terminated triggered (DO-DTT) , or device originated autonomous (DOA) etc. For example, Device 1 and Device 2a or the like can operate in DT or DO-DTT mode, while Device 2b and Device C or the like can operate in DT or DO-DTT or DOA mode. However, 3GPP Release 19 only started the study of Device 1 and Device 2a in DT or DO-DTT mode. For example, it is agreed that an inventory request is sent from a BS reader to the AIoT device that cannot initiate the active message transmission towards the network, e.g., Device 1 or Device 2a or the like, so that the AIoT device can be triggered by the BS reader to perform the access towards the 5GC.

[0074] Different from Device 1 and Device 2a, some types of AIoT devices, e.g., Device type 2b and Device C can access the core network, e.g., 5GC, 6GC or higher generation CN before being inventoried by the core network, and even decide to send the stored data, e.g., application-layer data via uplink without receiving the command (e.g., read) from the core network. That is, the access D2R transmission can come from the device side without a trigger from the network side. Thus, the messages or the requests come from such devices will become quietly unpredictable (or unexpected or the like) and happen at any moment and area, which causes several issues to be solved, including but not limited to how to control such devices access the network, e.g., under the DOA mode, how do the AIoT reader and AIoTF conduct the access control for such devices, e.g., under Topology 1 and Topology 2 respectively, and how to support the uplink message or transmission (including data or not) from such AIoT devices to the AIoT AF etc.

[0075] In accordance with aspects of the present disclosure, an AIoT device, e.g., Device 2b or like can actively send an access D2R transmission without receiving the trigger, e.g., inventory request or the read command from the AIoT reader and CN (e.g., originally from AF) in the following exemplary manners.

[0076] In some implementations of the present disclosure (Option 1) , the AIoT device may only decide to access the core network via an AIoT reader (s) when it has data (e.g., application layer data) to transmit, and send an access D2R transmission to the network, which is first sent to the AIoT reader (s) . The access D2R transmission may include the AIoT data to be reported, e.g., along with the device ID and other information (if any) . For example, the access D2R transmission may further include AF information (or target AF information, e.g., target AF ID or target application ID) , AIoTF information (e.g., in the case that the AIoT device needs to be handled by a specific AIoTF) , credential and security information of AIoT device, a type of data to be transmitted (e.g., temperature) , a size of data to be transmitted from the AIoT device, energy status of the AIoT device, a priority indication of the D2R transmission etc., or any combination thereof. In some cases, the access D2R transmission may further include an explicit access request or registration request.

[0077] In Option 1, it is assumed that the AIoT device is preconfigured with data transmission configurations (or data report configurations) to support the data transmission, e.g., related to the time to send the data stored in the sensor, and / or the circumstances or conditions to send the data stored in the sensor, e.g., threshold based (or event based) or periodic based etc. For example, the AIoT device may be requested to periodically report based on a time value or a timer, or may be supposed to report the data in the sensor when it reaches certain threshold (s) , such as a temperature threshold or limit etc. The data transmission configuration may be updated by the network side, e.g., by the AIoT AF after a successful access control that may include authentication and authorization at AIOTF. For example, the AIoT AF may send and configure the data transmission configuration to the AIoT devices via network, e.g., first to the NEF, then to the AIoTF, to the AIoT reader and to the AIoT device, which may be via a write command or a new service procedure.

[0078] In some implementations of the present disclosure (Option 2) , similar to option 1, the AIoT device may only decide to access the core network via an AIoT reader (s) when it has data (e.g., application layer data) to transmit. However, the access D2R transmission sent to the network which is first sent to the AIoT reader (s) does not include the AIoT data to be reported. Instead, the D2R transmission includes follow-up data transmission information of the AIoT device in the access D2R transmission, e.g., one or multiple of a follow-up data transmission request, or a size of data to be transmitted from the AIoT device (may be deemed as an implicit follow-up data transmission request) or other information (e.g., as illustrated in Option 1) . In some cases, the access D2R transmission may further include an explicit access request. Similarly, in Option 2, it is assumed that the AIoT device is preconfigured with data transmission configurations to support the access D2R transmission with the follow-up data transmission information. The data transmission configuration may be updated by the network side, e.g., by the AIoT AF after a successful access.

[0079] In some implementations of the present disclosure (Option 3) , the AIoT device may decide to access the core network via an AIoT reader (s) to show its appearance without considering whether there are data to be transmitted. The access D2R transmission including an access request, e.g., with a device ID, which may be initiated or triggered by pre-configuration, or by internal device event, which is like the legacy UE registration procedure, or by AIoT AF or AIOTF configuration (e.g., periodic triggered access, device mobility triggered access etc. ) . The access D2R transmission may further include other information similar to that illustrated in Option 1, e.g., AF information (e.g., target AF ID or target application ID etc. ) , AIoTF information (e.g., in the case that the AIoT device needs to be handled by a specific AIoTF) , credential and security information of AIoT device, energy status of the AIoT device etc., or any combination thereof. If there are data to be transmitted, the AIoT device may further include the AIoT data to be reported, or follow-up data transmission information or other data related information etc.

[0080] Since Device 2b or the like can access the core network unpredictably and at any time based on its own decision, it is crucial for the AIoT reader (e.g., BS or UE reader) and AIoTF to perform the access control for such AIoT devices, including but not limited to deciding whether the AIoT device can be allowed to access, and sending the corresponding message to the corresponding network entity. In accordance with aspects of the present disclosure, the AIoT reader can perform the first access control that focuses on the radio and physical characteristics related access control. The AIoTF can provide the access control configuration for the first access control by the AIoT reader, or the AIoT reader can perform the first access control based on its own implementation (e.g., capability and / or status etc. ) or based on local configuration (e.g., preconfigured by the OAM for a BS reader or preconfigured by a NG RAN for a UE reader etc. ) .

[0081] If the first access control shows allowed or accepted, the AIoT reader may select the AIoTF for uplink transmission, either based on pre-configuration, e.g., by OAM for BS reader, or based on AIOTF information from the AIoT device, or based on the load information of the AIoTF, or based on the pre-established connection with the AIoTF etc. The AIoTF or the like can perform the second access control, e.g., the verification of the AIoT device and check of the device subscription data etc.

[0082] If the second access control shows allowed or accepted, the AIoTF may determine the target AF for data and / or device information forwarding etc. from the AIoT device. For example, the AIoTF may determine the target AF for traffic forwarding, e.g., based on device ID (e.g., that may have 3rd party information, e.g., AF ID) , or AF ID received from the AIoT device; or the device subscription data stored in a CN entity, e.g., ambient data management (ADM) or the like that has the authorized AF information for receiving traffic from the AIoT device, or AF sending service request (e.g., a read command) for the traffic from the AIoT device.

[0083] More detailed implementations of the present disclosure are illustrated as examples in the following respectively in view of Topology 1 and Topology 2 (but not limited) .

[0084] First of all, it is assumed that the type of the illustrated AIoT device is Device 2b or Device C or the like, which can internally generate D2R transmissions to access and even send data to the network without being required or triggered to do so. The AIoT device has a device ID, which is a pre-configured permanent and globally unique device ID or a temporary ID. In some cases, e.g., for a 3rd party allocated device ID, the device ID may have the 3rd party information or context, e.g., AF ID etc.

[0085] It is also assumed that AIoT RAN or NG RAN establishes the association or connection with the AIoTF directly or indirectly via an AMF. The AIoT RAN can select the AIoTF either based on local configuration by the OAM, or with the assistance of AMF, e.g., via the NRF, or being pre-configured.

[0086] Figure 2 illustrates an example of AIoT device access procedure under Topology 1 in accordance with aspects of the present disclosure.

[0087] Referring to Figure 2, at step 201, an AIoT reader (one is shown as an example) , which is a BS reader (e.g., AIoT RAN or NG RAN etc. ) in Topology 1 may send broadcasting information to all the AIoT devices (only one is shown as an example) within its serving area, Whether an AIoT device can monitor, compare with the broadcasting information and choose an appropriate reader to access, or send the access signal to all the available readers within its reaching limit, depends on the AIoT device’s capability.

[0088] In some cases, the broadcasting information may include information or parameter (s) of access control configuration at the BS reader, e.g., including one or multiple of:an allowed maximum number of AIoT devices, an allowed access frequency range, an allowed access area, allowed access waiting time, allowed access time or period, an allowed access type, an allowed data type; allowed 3rd party information, or allowed network information etc.

[0089] Part or all of the access control configuration information or parameters may be provided by the AIoTF, or preconfigured by the OAM or determined based on BS reader’s own implementations, e.g., considering the status and / or capability etc., of the BS reader.

[0090] An exemplary allowed maximum number of AIoT devices may be related to a time duration or a period, e.g., defining that within a certain period (e.g., 3 minutes) , only 3000 devices are allowed to access to the network via the reader.

[0091] An exemplary allowed access frequency range for AIoT devices means that an AIoT device can only access the network within a certain frequency range, which may be obtained from the device subscription data and / or profile in the AIoT AF or ADM or the like.

[0092] An exemplary allowed area for AIoT devices means that an AIoT device can only access the network when it is located at a certain area. If the access signal is transmitted from some restricted areas, the access request will be denied or rejected.

[0093] An exemplary allowed access waiting time indicates a time length after that the AIoT devices will be allowed to access the network, or after how long will the AIoT devices be allowed to access the network.

[0094] An exemplary allowed access time and period indicates the time and / or period the AIoT devices are allowed to access the network.

[0095] An exemplary allowed access type may be periodic access, mobility based access or event based access (e.g., when there is data needed to be transmitted) etc. The allowed access type may be determined by the AIoTF by checking the locally stored device context at the AIoTF, or may be determined by the BS reader by checking the locally stored device context at the BS reader.

[0096] An exemplary allowed data type indicates that only an AIoT device with a certain kind of data transmission can be allowed, which is based on the assumption that the AIoT device needs to send the type of the stored data in a D2R transmission or message so that the AIoT reader will be able to know the type of the transmitted data.

[0097] Exemplary allowed 3rd party information and / or allowed network information is based on that assumption that 3rd party information and / or network information may be included as a part of the device ID, and the AIoT reader will be able to identify whether the AIoT device is allowed to access the network. The network information may be public land mobile network (PLMN) ID (e.g., MCC and MNC) and network identifier (NID) .

[0098] At step 203, an AIoT device may transmit an access D2R transmission to one or multiple AIoT readers including the shown AIoT reader. As illustrated above, the access D2R transmission may include data that needs to be transmitted, follow-up data transmission information, an access request, and / or other information, and will not repeat herein.

[0099] In some cases, some information of the access D2R transmission may be transparent to the AIoT reader and only be seen by the AIoTF in an AIoT NAS message, e.g., credential and security information of the AIoT device and / or the application data that stored in the AIoT device etc., which may be also seen by the AIoT reader if not fully encrypted via the NAS message. Some information of the access D2R transmission may be seen by both the AIoT reader and AIoTF, e.g., data type (if indicated by the AIoT device) , target AF information, AIoTF information, energy status of the AIoT device, data size or follow-up data transmission request or indication, device ID, access request or indication etc.

[0100] After receiving the access D2R transmission, the AIoT reader may perform the first access control for the AIoT device at step 205 based on the access control configuration, e.g., received from the AIoTF, or preconfigured by the OAM or based on its own implementations.

[0101] For example, the AIoT reader may check whether the access type of the AIoT device is allowed or not based on locally stored device context (if available) . The access type of the AIoT device may be indicated by the AIoT device or determined by the AIoT reader.

[0102] If there are many messages arriving at the AIoT reader at the same time and cause the congestion, then a priority handling at the AIoT reader side may be needed. For example, in the case that the AIoT reader receives multiple transmissions or messages (uplink and / or downlink, including but not limited to the access D2R transmission) , the AIoT reader may use priority information (or referred to as priority mapping information, or priority handling information or the like) to determine the handling order. The priority mapping information at the AIoT reader side may be from the AIoTF (or originally from the AF) or from the AIoT device or AIoT AF. The priority mapping can be applied for both downlink and uplink.

[0103] Exemplary priority mapping information may be based on one or multiple of AIoT device location, AIoT device group or filtering information, AIoT data type, AIoT device information or device ID, access type, service type, or AF request etc. For example, the priority mapping information may indicate that for uplink messages, the data comes from a certain group of devices (e.g., identified by the mask or filtering information or 3rd party information etc. ) may have the highest priority and needs to be handled first. The priority mapping can be 1 to 1 (different services or device groups have different priorities) , or multiple to 1 (some of the services or device groups correspond to the same priority) . In the case that the priority mapping information is provided by the AIoT device or AIoT AF, it may be a priority indication with the corresponding transmission or message or service request to show that the priority of the transmission or message. For example, when the AIoT AF sends a service request to the AIoT reader (and / or AIoTF) , it may include the priority indication with the service request to indicate that the current service request has a higher priority, or when the AIoT device sends the access D2R transmission (or other D2R transmission or message later) , the AIoT device may include a priority indication to the AIoT reader (and / or AIoTF) (assuming that the AIoT device has the capability of doing so) to indicate that the message from this device has a higher priority and needs to be considered by the AIoT reader or AIOTF when handling. In some cases, for information received from the AIoTF, e.g., the priority information, it may be initiated from the AIoT AF or other CN entity

[0104] In some implementations of the present disclosure, the AIoT reader may perform the proximity determination for the AIoT device by calculating, e.g., the signal to interference noise ratio (SINR) , or received signal strength indicator (RSSI) , etc. For example, the AIoT reader may receive a proximity report indication from the AIoTF or the like, which requests the AIoT reader to perform the proximity determination for an AIoT device, and report the determined proximity information to the AIoTF or the like, so that the AIoTF can use it to select the serving AIoT reader for the AIoT device in the case that multiple readers are receiving the access D2R transmission from the same device. In some cases, the AIoT reader may determine and report the proximity information on its own initiative.

[0105] The AIoT reader, e.g., the AIoT RAN may select an AIoTF for the AIoT device and the uplink information forwarding, e.g., by taking into account the AIoTF load information received from AIoTF (s) , the pre-established connection with the AIoTF (s) (either directly or indirectly via AMF) , and / or the AIoTF information sent by the AIoT device etc. Regarding the AIoTF load information or the like, it is beneficial for the AIoT reader to further select the AIoTF, which may indicate whether an AIoTF is overload or not, or indicate a percentage on how much of the AIoTF capacity has been used. The AIoTF load information may be determined by AIoTF itself, e.g., based on the Nz connection with AMF, Nx connection with the AIoT RAN, and / or other on-going connection within the core network. The AIoTF may actively notify the load information, or the NG RAN may subscribe to AIoTF load information and be notified by the AIoTF accordingly.

[0106] If the access D2R transmission or the AIoT device is not allowed or accepted based on the first access control, the AIoT reader may send a response message to the AIoT device at step 207, explicitly rejecting the access or registration request of the AIoT device, or implicitly rejecting the access or registration request, e.g., by requesting the AIoT device to try later, which is based on the AIoT reader’s implementations, together with a rejection or failure cause.

[0107] If the access D2R transmission or the AIoT device is allowed or accepted based on the first access control, the AIoT reader may send to the selected AIoTF a request message based on the access D2R transmission at step 209. Similar to the access D2R transmission, the request message may include one or multiple of: an ID of the AIoT device, data from the AIoT device, follow-up data transmission information of the AIoT device, an access request of the AIoT device, AF information, an access type of the AIoT device, an ID of the AIoT reader, proximity information, or a type of data to be transmitted from the AIoT device etc., which may be received from the AIoT device or generated or determined by the AIoT reader.

[0108] For example, in the case that the access D2R transmission includes data to be transmitted, the AIoT reader may transmit the data in the request message with other information received from the AIoT device (needed to be forwarded to the AIoTF) or generated by the AIoT reader (if any) , or hold the data locally and may include follow-up data transmission information with other information received from the AIoT device (needed to be forwarded to the AIoTF) or generated by the AIoT reader (if any) in the request message. Part or all of the follow-up data transmission information is generated by the AIoT reader based on the received data. After the AIoT reader receives the confirmation or authorization from the AIoTF that the data transmission from the AIoT device towards the AIoT AF is allowed or authorized, the AIoT reader will then send the on hold data to the AIoTF. If the AIoT reader decides to transmit the AIoT data to the AIoTF, it may perform aggregation on the data, e.g., area based aggregation, time or time interval based aggregation, service type or data type based aggregation, or service correlation identifier based aggregation, or target AF information based aggregation etc.

[0109] In the case that the access D2R transmission includes follow-up data transmission information of the AIoT device, the AIoT reader may still transmit the follow-up data transmission information to the AIoTF with other information received from the AIoT device (needed to be forwarded to the AIoTF) or generated by the AIoT reader (if any) .

[0110] In the case that the access D2R transmission includes an access request, the AIoT reader may still transmit the access request to the AIoTF with other information received from the AIoT device (needed to be forwarded to the AIoTF) or generated by the AIoT reader (if any) .

[0111] After receiving the request message from the AIoT reader, the AIoTF may perform the second access control for the AIoT device (or access control for the request message) at step 211, e.g., performing the device verification and / or authentication by interacting with, e.g., the authentication server function (AUSF) , ADM or the authentication authorization accounting (AAA) server outside the network. Part or all of the access control that illustrated at the AIoT reader side may be performed by the AIoTF.

[0112] For example, the AIoTF may check the device subscription data in the ADM or the like within the network by using the device ID as the key to further perform access control, e.g., whether the AIoT device is authorized for the access to the core network, whether the AIoT device from the current location is allowed for accessing the network, whether the data transmission to the target AF is allowed or not, whether the access type of the AIoT device is allowed etc. Similarly, the AIoTF itself can determine the access type for the AIoT device, e.g., based on the locally stored device context, or by checking the device subscription information in the ADM or the like, or the AIoTF may receive access type of the AIoT device from the AIoT reader (from the AIoT device or generated by the AIoT reader) .

[0113] In order for data transmission authorization, the authorized or allowed target AF information (e.g., 3rd party information) needs to be stored, e.g., as a part of the device subscription data stored in the ADM or the like. This information can also be used by the AIoTF to determine the target AF to forward the data and / or device information received from the device and the reader etc.

[0114] If the AIoT device is not allowed or accepted based on the access control performed by the AIoTF, the AIoTF may send a rejection response message to the AIoT reader at step 213a and then to the AIoT device at step 213b, rejecting the access request even the data transmission or follow-data transmission request. The AIoTF may indicate a failure cause based on device subscription data or application subscription data etc., e.g., the device is not allowed to enter the network, or not allowed to send the data etc.

[0115] If the AIoT device is allowed or accepted based on the access control performed by the AIoTF, the AIoTF may store and manage device information as device context locally or at another CN entity. Regarding the device information, it may include the device ID and access context in the ADM or the like. The access context may include at least the access type, such as initial access, periodic access, mobility access, or event based access etc. For example, the AIoTF may also store the verified device information at the ADM or the like, e.g., as the device profile information including the device ID, store the device access type as the device information, and store or update the serving AIoTF and serving AIoT reader for the AIoT device.

[0116] In some cases, the AIoTF may register the AIoT device locally or at the ADM or the like, with the device ID, the device status (e.g., registered, unregistered) , device context, and / or security materials etc.

[0117] In some cases, the AIoTF may generate or allocate a temporary device ID for the AIoT device based on its own implementation. It is assumed that the ADM or the like may be a hub to store the temporary device ID for the AIoT device, and has a mapping between the permanent ID and temporary ID locally. The AIoTF may also store and / or update the temporary device ID at the ADM or the like so that the ADM or the like will have a local mapping between the permanent device ID, temporary device ID and the AIoTF that assigns or generates the temporary device ID. The AIoTF may even retrieve the temporary ID from the ADM or the like. For example, when the AIoT device is moving and firstly processed by the AIOTF, the AIoTF may retrieve the temporary ID from ADM or the like.

[0118] In some cases, e.g., there are multiple AIoT readers associated with the same AIoT device, the AIoTF may determine a serving AIoT reader for the AIoT device, e.g., based on the received proximity information from the multiple readers. For example, the AIoTF may select an AIoT reader with the best receiving quality towards the AIoT device as the serving AIoT reader, and then send downlink messages to the AIoT device only via the serving AIoT reader to avoid resource waste.

[0119] If AIoT readers cannot provide detailed physical calculations of the proximity information associated with a specific AIoT device, the AIoTF may not select the serving reader and may send the downlink messages associated with the specific AIoT device to all the related AIoT readers, e.g., that have sent the device ID to the AIoTF before.

[0120] The AIoTF may also select or determine a target AIoT AF to which traffics from the AIoT device (e.g., data or device information etc. ) will be routed, e.g., based on one or multiple of: AF information received from the AIoT device, 3rd party information included in the device ID, allowed 3rd party or AF information of the AIoT device stored in CN side, or a received AF service request etc. Such an AF service request may be sent to the AIOTF earlier as periodic inventory request for a target area, or periodic read command or data report for AIoT devices within a target area. The AIoTF may store the request context either locally, or at ADM or the like as the AF or device subscription data.

[0121] For example, in some cases, by checking the 3rd party information that contained in the device ID (if the device ID is allocated by the 3rd party) or in the case that the AIoT device explicitly sends the target AF information in the access D2R transmission, the AIoTF may select or determine the indicated AF or the target AIoT AF. In some cases, based on the subscription data (e.g., device subscription data or AF subscription data etc. ) in the ADM or the like (assuming that the subscription data for the AIoT device has, e.g., the allowed AF) , the AIoTF may know which AF is allowed to receive the data from a specific AIoT device, using device ID as the key. The target AF information can include one or more of the AF ID, AF IP address or FQDN, etc.

[0122] The AIoTF may send an access response message to the AIoT reader at step 213a and then to the AIoT device 213b, indicating one or multiple of: that the access request is allowed (e.g., an access allowed indication in response to an access request) , the data transmission is allowed (e.g., a data transmission allowed indication in response to follow-up data request information) , the allocated temporary device ID, or the permanent device ID, device access configuration (configured to the AIoT device) , data report and device inventory configuration (to the AIoT reader, or locally stored at AIoTF) , aggregation assistance information, a service correlation ID, e.g., task ID (if data is expected to be transmitted later, this correlation ID can be used for identifying the follow data transmission from the device) , or other information.

[0123] The information indicated in the access response message may be only for the AIoT reader, or only for the AIoT device (transparent to the AIoT reader) , or for both of them. For example, the data report and device inventory configuration may only be forwarded to the AIoT reader, the device access configuration may be transparent to the AIoT reader and forwarded to the AIoT device in an AIoT NAS message, while the other information, e.g., access allowed indication, data transmission allowed indication etc., may be for both the AIoT reader and device.

[0124] Moreover, regarding the device access configuration, it may be determined by the AIoTF itself or from the AIoT AF. If the device access configuration is provided for the AIoT device, the AIoT device may update the stored access configuration. Similarly, the device access configuration sent to the AIoT device is used to indicate the AIoT device when to do the active access (under what kind of case should the device initiated) towards the network, such as periodic access (atime period or a timer will also be provided to the device) , event (only access the network when the data has reached certain threshold, which is application layer provided configuration) , or mobility based access (may have an area or distance threshold information that being sent to the device to indicate that if device moving out side of the area, then initiate the access towards the network) etc. For example, if an AIoT device enters the area or an AIoT device leaves the area, then the AIoT device will report at least its device ID, current location and area, via the AIoT reader.

[0125] Regarding the data report and device inventory configuration, it may be originally from the AIoT AF in some cases. In some cases, the data report and device inventory configuration may be sent by the AIoTF in the form of inventory or command when needed, e.g., periodically read the data from the AIoT devices, or inventory the AIoT device to check whether it is still within the area.

[0126] In the case that a serving AIoT reader is selected, the AIoTF may only send the access response message to the serving AIoT reader. The AIoTF may send a release context indication to other AIoT readers associated with the same AIoT device, e.g., with device ID. In some cases, the AIoT reader that is not selected as the serving AIoT reader may release the context of the AIoT device based on its own implementations, e.g., a local timer. Herein, it is assumed that the shown AIoT reader is the serving reader or the AIoTF does not select the serving reader and send the access response message to each associated AIoT reader.

[0127] In addition, if the AIoTF receives data from the AIoT device (directly or via the AIoT reader) and the data transmission initiated by the AIoT device is allowed, the AIoTF may send the received AIoT data to the selected AIoT AF at step 215, with the AIoT device information, e.g., device ID, device location (e.g., on a reader granularity level or a finer level etc. ) , reader information (e.g., reader ID and location etc. ) , service correlation ID, e.g., task ID (e.g., if based on AF request) etc. The AIoTF may perform aggregation for received data based on aggregation rules determined by itself or received from the AIoT AF, e.g., area based aggregation, time based aggregation, service type or data type based aggregation etc., when transmitting AIoT data to the AIoTF AF.

[0128] At the AIoT device side, after receiving the access response message, if the AIoT device has data to be transmitted (e.g., the data transmission is allowed) , the AIoT device may send the AIoT data to the AIoT AF, e.g., to the AIoT reader first at step 217, e.g., with the data type, time stamp, AF information, AIoTF information and / or other information similar to that illustrated at step 203, and will not repeat.

[0129] Similarly, after receiving the D2R transmission including the data, the AIoT reader may transmit the data to the AIoTF at step 219, e.g., optionally determining the handling or transmission priority based on the priority information, performing aggregation for the data based on the aggregation assistance information etc., and will not repeat. For uplink transmission aggregation, apart from the aggregation assistance information, if the data is sent originally from the AIoT device, e.g., Device 2b or the like in DOA mode, only using the service correlation ID may not be applicable (e.g., the service correlation ID generated by the AIoT device may not be aligned) . In this case, if aggregation is needed, the AIoT reader may further use the target AF information as the criteria to perform the aggregation.

[0130] Then, the AIoTF will forward the data to the selected AIoT AF at step 221 either via NEF or directly to the trusted AIoT AF, which is similar to step 215. For example, the AIoTF may also perform aggregation for received data based on aggregation rules determined by itself or received from the AIoT AF when transmitting AIoT data to the AIoTF AF.Details will not be repeated.

[0131] Figure 3 illustrates an example of AIoT device access procedure under Topology 2 in accordance with aspects of the present disclosure.

[0132] Referring to Figure 3, the UE reader may send a registration request towards the AIoTF via the AMF not shown) with a UE reader indication at step 301, and may optionally send an access support indication (or access control support indication) of UE reader (e.g., specific for Device 2b and Device C under DOA mode) together. That is, the access support indication as a UE reader may be provided for the AIoTF.

[0133] In the case that, the UE reader sends the UE reader registration request via the AMF, the AMF may check the UE subscription data, e.g., in UDM and authorize the UE to act as a reader. Then, the AMF may send the UE information (e.g., including the access support indication) , RAN information, UE status (e.g., RRC or connection management (CM) state) , to the AIoTF. In some cases, the AIOTF can also check the authorization data of the UE by itself from UDM, and authorize the UE to act as a reader. In some cases, AIoTF may subscribe to UE reader status from the AMF and / or the RAN (e.g., a gNB) of the UE reader. Herein, it is assumed that the UE is authorized to act as a reader.

[0134] Similarly to a BS reader, other information, e.g., one or multiple of proximity determination indication, AIoTF load information, priority mapping information, UE load status report indication, AIoTF IP address or fully qualified domain name (FQDN) etc., may also be provided for the UE reader.

[0135] Similar to step 201, UE reader may send the broadcasting message over the AIoT radio interface at step 303, which may include the access control information. Regarding the access control information, it is similar to that illustrated in view of Figure 2 and thus only list some potential differences.

[0136] For example, in some cases, after receiving the authorization for UE to act as the UE reader, e.g., from the AIoTF or the AMF, the AIoT enabled RAN may configure the UE reader with the access control information based on its local configuration. In some cases, the UE reader may implement or perform the access control based on its own implementations, e.g., capability, status and local configuration etc. In some cases, the AIoTF may send the access control configuration to both the AIoT enabled RAN and UE reader. The access control configuration to the AIoT enabled RAN may assist the AIoT enabled RAN to configure resources for both the AIoT radio interface between the AIoT device and the UE reader, and the Uu interface between the UE reader and AIoT enabled RAN, e.g., gNB.

[0137] At step 305, an AIoT device may transmit an access D2R transmission to one or multiple AIoT readers including the shown AIoT reader, which is similar to that illustrated at step 203 and will not repeat.

[0138] At step 307, the UE reader may perform access control for the AIoT device, which is similar to that illustrated in Figure 2 by a BS reader and thus will not repeat. If the access D2R transmission of the AIoT device is not accepted, the UE reader may send a response message to the AIoT device at step 309, which is similar to that illustrated at step 207. If the access D2R transmission or the AIoT device is allowed or accepted, the UE reader may send to the selected AIoTF a request message based on the access D2R transmission, which may be via a control plane (or RRC solution) or user plane. Details of the request message are similar to that illustrated in Figure 2 and will not repeat. Other possible operations at the UE reader after the AIoT device is allowed are also identical or similar to that performed by the BS reader illustrated in Figure 2, and will not repeat.

[0139] In the case of the control plane solution, the UE reader may send the request message to the selected AIoTF via the AIoT enabled RAN (and further via the AMF in some cases) at steps 311a and 311b. In some cases, the UE reader may send to the AIoT enabled RAN the data size and / or the follow-up (or later-on) data transmission information provided by the AIoT device, so that the AIoT enabled RAN enables the resource configuration of the AIoT radio interface for this UE reader and AIoT device.

[0140] In some cases, the AIoT enabled RAN may determine or select a serving UE reader based on the proximity information received from multiple UE readers for the same AIoT device, e.g., taking into account the radio conditions between the AIoT enabled RAN and the UEs. The AIoT enabled RAN may send the request message to the selected AIoTF at step 311b, with the information of the selected UE reader for the AIoT device, and may further provide the proximity information for this AIoT device.

[0141] In the case of the user plane solution, the UE reader may send the request message to the selected AIoTF via the UPF at step 311c, e.g., based on the pre-configured or received specific data network name (DNN) and / or single network slice selection assistance Information (S-NSSAI) and the AIoTF FQDN and / or IP address etc.

[0142] After the AIoTF receives the request message, it may perform the identical or similar operations as that illustrated in Figure 2.

[0143] For example, if the AIoT device is not allowed or accepted based on the access control performed by the AIoTF, the AIoTF may send a rejection response message to the AIoT device via the UE reader in control plane at steps 313a, 313b and 313c or user plane at step 313d and 313e.

[0144] If the AIoT device is allowed or accepted based on the access control performed by the AIoTF, the AIoTF may send an access response message to the AIoT device via the UE reader in control plane at steps 313a, 313b and 313c or user plane at step 313d and 313e. The AIoTF may also perform other possible operations as illustrated in Figure 2, e.g., selecting or determining a target AIoT AF to which traffics from or to the AIoT device will be routed, store and manage device information as device context locally or at another CN entity, and register the AIoT device locally or at the ADM or the like etc. If the AIoTF receives data from the AIoT device (via the control plane or user plane) and the data transmission initiated by the AIoT device is allowed, the AIoTF may send the received AIoT data to the selected AIoT AF at step 315. Details will not be repeated.

[0145] At the AIoT device side, after receiving the access response message, if there is data to be transmitted, it may send another D2R transmission with the data to the UE reader first, and then to the AIoTF and AF via the control plane or user plane, and will not repeat.

[0146] Figure 4 illustrates an example of a CN entity 400 in accordance with aspects of the present disclosure, e.g., AIoTF. 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.

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

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

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

[0150] 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. The CN entity 400 may be configured to support a means for a means for receiving, from an AIoT reader, a request message associated with an AIoT device at least to access a core network, wherein the request message is based on a D2R transmission generated internally by the AIoT device; a means for performing access control for the AIoT device; and a means for determining an AF to which traffics from the AIoT device will be routed in the case that the request message is accepted based on the access control by the CN entity.

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

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

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

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

[0155] Figure 5 illustrates an example of a processor 500 in accordance with aspects of the present disclosure. The processor 500 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 500 may include a controller 502 configured to perform various operations in accordance with examples as described herein. The processor 500 may optionally include at least one memory 504, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 500 may optionally include one or more arithmetic-logic units (ALUs) 506. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses) .

[0156] The processor 500 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the processor 500) or other memory (e.g., random access memory (RAM) , read-only memory (ROM) , dynamic RAM (DRAM) , synchronous dynamic RAM (SDRAM) , static RAM (SRAM) , ferroelectric RAM (FeRAM) , magnetic RAM (MRAM) , resistive RAM (RRAM) , flash memory, phase change memory (PCM) , and others) .

[0157] The controller 502 may be configured to manage and coordinate various operations (e.g., signaling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 500 to cause the processor 500 to support various operations in accordance with examples as described herein. For example, the controller 502 may operate as a control unit of the processor 500, generating control signals that manage the operation of various components of the processor 500. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

[0158] The controller 502 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 504 and determine subsequent instruction (s) to be executed to cause the processor 500 to support various operations in accordance with examples as described herein. The controller 502 may be configured to track memory address of instructions associated with the memory 504. The controller 502 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 502 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 500 to cause the processor 500 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 502 may be configured to manage flow of data within the processor 500. The controller 502 may be configured to control transfer of data between registers, arithmetic logic units (ALUs) , and other functional units of the processor 500.

[0159] The memory 504 may include one or more caches (e.g., memory local to or included in the processor 500 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 504 may reside within or on a processor chipset (e.g., local to the processor 500) . In some other implementations, the memory 504 may reside external to the processor chipset (e.g., remote to the processor 500) .

[0160] The memory 504 may store computer-readable, computer-executable code including instructions that, when executed by the processor 500, cause the processor 500 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. The controller 502 and / or the processor 500 may be configured to execute computer-readable instructions stored in the memory 504 to cause the processor 500 to perform various functions. For example, the processor 500 and / or the controller 502 may be coupled with or to the memory 504, the processor 500, the controller 502, and the memory 504 may be configured to perform various functions described herein. In some examples, the processor 500 may include multiple processors and the memory 504 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.

[0161] The one or more ALUs 506 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 506 may reside within or on a processor chipset (e.g., the processor 500) . In some other implementations, the one or more ALUs 506 may reside external to the processor chipset (e.g., the processor 500) . One or more ALUs 506 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 506 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 506 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 506 may support logical operations such as AND, OR, exclusive-OR (XOR) , not-OR (NOR) , and not-AND (NAND) , enabling the one or more ALUs 506 to handle conditional operations, comparisons, and bitwise operations.

[0162] The processor 500 may support wireless communication in accordance with examples as disclosed herein. The processor 500 may be configured to or operable to support a means for receiving, from an AIoT reader, a request message associated with an AIoT device at least to access a core network, wherein the request message is based on a D2R transmission generated internally by the AIoT device; a means for performing access control for the AIoT device; and a means for determining an AF to which traffics from the AIoT device will be routed in the case that the request message is accepted based on the access control by the CN entity.

[0163] Figure 6 illustrates an example of an AIoT reader 600 in accordance with aspects of the present disclosure. The AIoT reader 600 may include a processor 602, a memory 604, a controller 606, and a transceiver 608. The processor 602, the memory 604, the controller 606, or the transceiver 608, 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.

[0164] The processor 602, the memory 604, the controller 606, or the transceiver 608, 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.

[0165] The processor 602 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 602 may be configured to operate the memory 604. In some other implementations, the memory 604 may be integrated into the processor 602. The processor 602 may be configured to execute computer-readable instructions stored in the memory 604 to cause the AIoT reader 600 to perform various functions of the present disclosure.

[0166] The memory 604 may include volatile or non-volatile memory. The memory 604 may store computer-readable, computer-executable code including instructions when executed by the processor 602 cause the AIoT reader 600 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 604 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.

[0167] In some implementations, the processor 602 and the memory 604 coupled with the processor 602 may be configured to cause the AIoT reader 600 to perform one or more of the functions described herein (e.g., executing, by the processor 602, instructions stored in the memory 604) . For example, the processor 602 may support wireless communication at the AIoT reader 600 in accordance with examples as disclosed herein. The AIoT reader 600 may be configured to support a means for receiving, from an AIoT device, a D2R transmission generated internally by the AIoT device to access a CN; a means for performing access control for the AIoT device; and a means for sending a request message based on the D2R transmission to a CN entity in the case that the D2R transmission is accepted based on the access control by the AIoT reader.

[0168] The controller 606 may manage input and output signals for the AIoT reader 600. The controller 606 may also manage peripherals not integrated into the AIoT reader 600. In some implementations, the controller 606 may utilize an operating system such as or other operating systems. In some implementations, the controller 606 may be implemented as part of the processor 602.

[0169] In some implementations, the AIoT reader 600 may include at least one transceiver 608. In some other implementations, the AIoT reader 600 may have more than one transceiver 608. The transceiver 608 may represent a wireless transceiver. The transceiver 608 may include one or more receiver chains 610, one or more transmitter chains 612, or a combination thereof.

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

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

[0172] Figure 7 illustrates an example of an AIoT device 700 in accordance with aspects of the present disclosure. The AIoT device 700 may include a processor 702, a memory 704, a controller 706, and a transceiver 708. The processor 702, the memory 704, the controller 706, or the transceiver 708, 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.

[0173] The processor 702, the memory 704, the controller 706, or the transceiver 708, 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.

[0174] The processor 702 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 702 may be configured to operate the memory 704. In some other implementations, the memory 704 may be integrated into the processor 702. The processor 702 may be configured to execute computer-readable instructions stored in the memory 704 to cause the AIoT device 700 to perform various functions of the present disclosure.

[0175] The memory 704 may include volatile or non-volatile memory. The memory 704 may store computer-readable, computer-executable code including instructions when executed by the processor 702 cause the AIoT device 700 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 704 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.

[0176] In some implementations, the processor 702 and the memory 704 coupled with the processor 702 may be configured to cause the AIoT device 700 to perform one or more of the functions described herein (e.g., executing, by the processor 702, instructions stored in the memory 704) . For example, the processor 702 may support wireless communication at the AIoT device 700 in accordance with examples as disclosed herein. The AIoT device 700 may be configured to support a means for generating internally a D2R transmission to at least access network by including one or multiple of: data that needs to be transmitted to a CN, follow-up data transmission information related to data that needs to be transmitted later, or an access request requesting to access a core network; and a means for transmitting the D2R transmission to one or multiple AIoT readers.

[0177] The controller 706 may manage input and output signals for the AIoT device 700. The controller 706 may also manage peripherals not integrated into the AIoT device 700. In some implementations, the controller 706 may utilize an operating system such as or other operating systems. In some implementations, the controller 706 may be implemented as part of the processor 702.

[0178] In some implementations, the AIoT device 700 may include at least one transceiver 708. In some other implementations, the AIoT device 700 may have more than one transceiver 708. The transceiver 708 may represent a wireless transceiver. The transceiver 708 may include one or more receiver chains 710, one or more transmitter chains 712, or a combination thereof.

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

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

[0181] Figure 8 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.

[0182] At step 801, the method may include receiving, from an AIoT reader, a request message associated with an AIoT device at least to access the core network, wherein the request message is based on a D2R transmission generated internally by the AIoT device. The operations of step 801 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 801 may be performed by a CN entity as described with reference to Figure 4.

[0183] At step 803, the method may include performing access control for the AIoT device. The operations of step 803 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 803 may be performed by a CN entity as described with reference to Figure 4.

[0184] At step 805, the method may include determining an AF to which traffics from the AIoT device will be routed in the case that the request message is accepted based on the access control by the CN entity. The operations of step 805 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 803 may be performed by a CN entity as described with reference to Figure 4.

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

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

[0187] At step 901, the method may include receiving, from an AIoT device, a D2R transmission generated internally by the AIoT device to access a CN; a means for performing access control for the AIoT device. The operations of step 901 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 901 may be performed by an AIoT reader as described with reference to Figure 6.

[0188] At step 903, the method may include performing access control for the AIoT device. The operations of step 903 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 903 may be performed by an AIoT reader as described with reference to Figure 6.

[0189] At step 905, the method may include sending a request message based on the D2R transmission to a CN entity in the case that the D2R transmission is accepted based on the access control by the AIoT reader. The operations of step 905 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 903 may be performed by an AIoT reader as described with reference to Figure 6.

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

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

[0192] At step 1001, the method may include generating internally a D2R transmission to at least access network by including one or multiple of: data that needs to be transmitted to a CN, follow-up data transmission information related to data that needs to be transmitted later, or an access request requesting to access a core network. The operations of step 901 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 1001 may be performed by an AIoT device as described with reference to Figure 7.

[0193] At step 1003, the method may include transmitting the D2R transmission to one or multiple AIoT readers. The operations of step 1003 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 1003 may be performed by an AIoT device as described with reference to Figure 7.

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

[0195] 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, from an ambient internet of things (AIoT) reader, a request message associated with an AIoT device at least to access a core network, wherein the request message is based on a device to reader (D2R) transmission generated internally by the AIoT device;perform access control for the AIoT device; anddetermine an application function (AF) to which traffics from the AIoT device will be routed in the case that the request message is accepted based on the access control by the CN entity.2.The CN entity of claim 1, wherein the at least one processor is configured to further cause the CN entity to send to the AIoT reader one or multiple of:a proximity report indication to request the AIoT reader to perform proximity determination for AIoT devices and report determined proximity information;load information of the CN entity; orpriority information related to handling messages of AIoT devices.3.The CN entity of claim 2, wherein the priority information is based on one or multiple of AIoT device location, AIoT device group or filtering information, AIoT data type, AIoT device identifier (ID) , access type, service type, or an AF request.4.The CN entity of claim 1, wherein the request message comprises one or multiple of:data from the AIoT device;an identifier (ID) of the AIoT device;follow-up data transmission information of the AIoT device, including one or multiple of a follow-up data transmission request or a size of data to be transmitted from the AIoT device; oran access request of the AIoT device.5.The CN entity of claim 4, wherein the request message further comprises one or multiple of:AF information;an access type of the AIoT device;an ID of the AIoT reader;proximity information; ora type of data to be transmitted from the AIoT device.6.The CN entity of claim 1, wherein in the case that the request message is accepted, the at least one processor is configured to further cause the CN entity to perform one or multiple of:generating a temporary device identifier (ID) and storing the temporary device ID at CN side so that there is a mapping between a permanent device ID, the temporary device ID and the CN entity;sending a temporary device ID of the AIoT device to the AIoT reader and the AIoT device, wherein the temporary device ID is generated by the CN entity or retrieved from another CN entity;determining an access type of the AIoT device based on device context locally stored or stored in another CN entity;register the AIoT device locally or at another CN entity, where a status of the AIoT device status is set as registered; orstore and manage device information as device context locally or at another CN entity.7.The CN entity of claim 1, wherein in the case that the request message is rejected, the at least one processor is configured to further cause the CN entity to send a response message to the AIoT reader and the AIoT device, rejecting the AIoT device to access network or rejecting the AIoT device to transmit data.8.The CN entity of claim 1, wherein in the case that the request message is accepted, the at least one processor is configured to further cause the CN entity to send a response message to the AIoT reader or a serving reader of the AIoT device same as or different from the AIoT reader, comprising one or multiple of:an allowed data transmission indication in response to follow-up data transmission information of the AIoT device;an allowed access indication in response to an access request of the AIoT device;an identifier (ID) of the AIoT device;device access configuration indicating the AIoT device when to access the network;data report and device inventory configuration;aggregation assistance information; ora service correlation identifier.9.The CN entity of claim 8, wherein the device access configuration configures periodic access, event based access or device mobility based access.10.The CN entity of claim 1, wherein determining the AF to which traffics from the AIoT device will be routed is based on one or multiple of:AF information received from the AIoT device;3rd party information included in an identifier (ID) of the AIoT device;allowed 3rd party or AF information of the AIoT device stored in CN side; ora received AF service request.11.The CN entity of claim 1, wherein the at least one processor is configured to cause the CN entity to:subscribe to connection information related to connection of access and mobility management function (AMF) with radio access network (RAN) entity; andreceive the connection information from operations administration and maintenance (OAM) or the AMF, including information of RAN entities that has set up connection the AMF.12.An ambient internet of things (AIoT) reader for wireless communication, comprising:at least one memory; andat least one processor coupled with the at least one memory and configured to cause the AIoT reader to:receive, from an ambient internet of things (AIoT) device, a device to reader (D2R) transmission generated internally by the AIoT device to access a core network (CN) ;perform access control for the AIoT device; andsend a request message based on the D2R transmission to a CN entity in the case that the D2R transmission is accepted based on the access control by the AIoT reader.13.The AIoT reader of claim 12, wherein the D2R transmission comprises one or multiple of:data that needs to be transmitted;follow-up data transmission information, including one or multiple of a follow-up data transmission request or a size of data to be transmitted; oran access request.14.The AIoT reader of claim 12, wherein in the case that the AIoT reader is a radio access network (RAN) entity, performing access control for the AIoT device is based on one or multiple of:access control configuration provided by the CN entity;access control configuration provided by operations administration and maintenance (OAM) ; orreader's own local configurations and implementations.15.The AIoT reader of claim 12, wherein in the case that the AIoT reader is a user equipment (UE) reader serving by a radio access network (RAN) entity, performing access control for the AIoT device is based on one or multiple of:access control configuration provided by the CN entity;access control configuration provided by the RAN entity; orreader's own implementations.16.The AIoT reader of claim 12, wherein in the case that the D2R transmission is accepted, the at least one processor is configured to cause the AIoT reader to perform one or multiple of:determining an access type of the AIoT device based on locally stored device context or an access type indication from the AIoT device and reporting to the CN entity;determining proximity information of the AIoT device and reporting to the CN entity;determining a handling order of the request message based on priority information provided by the CN entity or indicated by the AIoT device; orselect the CN entity based on pre-established connection with CN entities, received load information of CN entities, or CN entity information indicated by the AIoT device.17.The AIoT reader of claim 12, wherein in the case that the D2R transmission is accepted and comprises data that needs to be transmitted, the at least one processor is configured to further cause the AIoT reader to:include the data that needs to be transmitted in the request message; orhold the data that needs to be transmitted at the reader until receiving an allowed data transmission indication from the CN entity.18.An ambient internet of things (AIoT) device for wireless communication, comprising:at least one memory; andat least one processor coupled with the at least one memory and configured to cause the AIoT device to:generate internally a device to reader (D2R) transmission to at least access network by including one or multiple of: data that needs to be transmitted to a core network (CN) , follow-up data transmission information related to data that needs to be transmitted later, or an access request requesting to access a core network; andtransmit the D2R transmission to one or multiple AIoT readers.19.The AIoT device of claim 18, wherein the at least one processor is configured to further cause the AIoT device to:determine whether there are data to be transmitted based on a data report configuration, wherein the data report configuration is preconfigured or configured by a CN entity.20.A method performed by a core network (CN) entity for wireless communication, comprising:receiving, from an ambient internet of things (AIoT) reader, a request message associated with an AIoT device at least to access a core network, wherein the request message is based on a device to reader (D2R) transmission generated internally by the AIoT device;performing access control for the AIoT device; anddetermining an application function (AF) to which traffics from the AIoT device will be routed in the case that the request message is accepted based on the access control by the CN entity.

Images