WO2025141553A1

WO2025141553A1 - Apparatus and method for ambient internet of things communication in a wireless communication system

Info

Publication number: WO2025141553A1
Application number: PCT/IB2025/051578
Authority: WO
Inventors: Genadi Velev
Original assignee: Lenovo Singapore Pte Ltd
Current assignee: Lenovo Singapore Pte Ltd
Priority date: 2024-02-14
Filing date: 2025-02-14
Publication date: 2025-07-03
Anticipated expiration: 2026-08-14
Also published as: WO2025150015A1; WO2025141552A1

Abstract

Various aspects of the present disclosure relate to methods, apparatuses, and devices for wireless communication. A user equipment (UE) may transmit (1102) a registration request message including an indication for capability of the UE as an ambient internet of things (AIoT) intermediate node. The UE may receive (1104) a registration response message comprising an AIoT policy that enables the UE as the AIoT intermediate node for an AIoT service.

Description

APPARATUS AND METHOD FOR AMBIENT INTERNET OF THINGS

COMMUNICATION IN A WIRELESS COMMUNICATION SYSTEM

TECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to ambient internet of things (AIoT) communication in a wireless communication system.

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] Various aspects of the present disclosure relate to wireless communications, including improved methods and apparatuses that support AIoT communication in a wireless communication system. A UE may transmit a registration request message including an indication for capability of the UE as an AIoT intermediate node. The UE may also receive a registration response message comprising an AIoT policy that enables the UE as the AIoT intermediate node for an AIoT service.

BRIEF DESCRIPTION OF THE DRAWINGS

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

[0006] Figure 2 illustrates an example of a first topology of a wireless network in accordance with aspects of the present disclosure.

[0007] Figure 3 illustrates an example of a second topology of a wireless network in accordance with aspects of the present disclosure.

[0008] Figure 4 illustrates an example of a block diagram of an ambient internet of things (AIoT) system in accordance with aspects of the present disclosure.

[0009] Figure 5 illustrates an example of a procedure in an AIoT system in accordance with aspects of the present disclosure.

[0010] Figure 6 illustrates another example of a procedure in an AIoT system in accordance with aspects of the present disclosure.

[0011] Figure 7 illustrates a further example of a procedure in an AIoT system in accordance with aspects of the present disclosure.

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

[0013] Figure 9 illustrates an example of a processor in accordance with aspects of the present disclosure. [0014] Figure 10 illustrates an example of a network equipment (NE) in accordance with aspects of the present disclosure.

[0015] Figure 11 illustrates a flowchart of a method performed by a UE in accordance with aspects of the present disclosure.

[0016] Figure 12 illustrates a flowchart of a method performed by a NE in accordance with aspects of the present disclosure.

DETAILED DESCRIPTION

[0017] Various aspects of the present disclosure relate to AIoT communications in a wireless communication system. The AIoT communications may be supported by a UE functioning (e.g., operating) as an AIoT reader. The AIoT communications may occur over a control plane. A wireless device, such as UE may output (e.g., transmit) a request to register with the wireless communication system based at least in part on the wireless device seeking to be an intermediate node for the AIoT communications (e.g., AIoT data transmission). However, in some cases, the wireless device may be incompatible and/or incapable of functioning as an intermediate node and thereby signaling associated with the request may result in wasted time, communication resources, and power consumption (e.g., battery life). To address these shortcomings, the wireless device, which is capable of AIoT communication, may be configured (e.g., enabled) with policy information when and how to receive and transmit data or signalling from the network to the AIoT devices in the downlink and to receive and transmit data or signaling from the AIoT devices to the network in the uplink. Assistance information with the request may provide for improvements to transmission efficiency, fewer use of communication resources, and time may be used efficiently.

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

[0019] 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 new radio (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.

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

[0021] 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 NTN. In some implementations, different geographic coverage areas associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0022] 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 Intemet-of-Things (loT) device, an Intemet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples.

[0023] 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 may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a UE-to-UE interface (PC5 interface).

[0024] 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., SI, N2, N2, 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).

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

[0026] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, N2, 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).

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

[0028] 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., i=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., i=l) 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., ju=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.

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

[0030] 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., /r=0, ju=l, ,11=2. [1=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., orthogonal frequency division multiplexing (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., i=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

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

[0032] 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., i=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., i=3), which includes 120 kHz subcarrier spacing.

[0033] In one wireless communication system (also referred to as a wireless network), for example, a 5G system (5GS), cellular loT services may be provided to devices with reduced capabilities. The system may include simplified devices referred to as AIoT devices. These AIoT devices may be anew class of loT devices that are powered by harvesting energy from various sources such as radio frequency (RF) energy, solar energy, wind energy, and so forth. Distinct from traditional loT devices, AIoT devices may not rely on batteries and may have limited energy storage capabilities, often using an internal capacitor for energy storage. RF energy may be harvested from transmissions made by the network itself. AIoT devices may transmit and/or receive data by making AIoT communications with another device.

[0034] RF energy harvesting may enable ambient loT devices to harvest energy from RF signals available in their environment, such as RF signals transmitted from mobile networks or from nearby Wi-Fi networks. The RF energy harvesting may be a technology that enables self-sustainable wireless loT networks and analyzes the energy harvesting performance of a Wi-Fi-based loT network. [0035] For an ambient loT device to transmit data, it may first receive an RF signal that provides sufficient energy to power the device. This RF signal may commonly be referred to as a trigger signal or trigger message. The trigger message may be transmitted by a base station (BS) or a UE acting as AIoT reader as an intermediate node (UE-AIoT-I). Both the BS and the UE-AIoT-I may be assumed to be in close proximity to the AIoT device.

[0036] Several connectivity topologies may be used to enable an AIoT device to communicate with a mobility network (e.g., 5GS). Connectivity topologies for AIoT networks and devices shown in Figures 2 and 3 may be used in 3GPP. In such examples, the AIoT device may be provided with a carrier wave from other nodes either inside or outside the topology. The links in each topology may be bidirectional or unidirectional.

[0037] Figure 2 illustrates an example of a first topology 200 of a wireless network in accordance with aspects of the present disclosure. The first topology 200 includes a BS 202 communicating directly with an AIoT device 204 over a link 206 (e.g., BS 202 «-> AIoT device 204). The communication between the BS 202 and the AIoT device 204 includes AIoT data and/or signaling 208 received from or transmitted to a core network.

[0038] Figure 3 illustrates an example of a second topology 300 of a wireless network in accordance with aspects of the present disclosure. The second topology 300 includes a BS 302 communicating bidirectionally with an intermediate node 304 (e.g., UE) between the BS 302 and an AIoT device 306 using communication links 308 and 310. This is denoted as “BS «-> intermediate node «-> AIoT device”. The intermediate node 304 may be a special UE capable of transmitting and receiving data and/or signaling 310 with the AIoT device 306. The intermediate node 304 as a UE may be denoted for short as “UE-AIoT-I” for a UE capable of AIoT communication as the intermediate node 304. The UE-AIoT-I may receive and transmit AIoT-related data and/or signalling 312 to a core network via the base station 302.

[0039] Figure 4 illustrates an example of a block diagram of an AIoT system 400 in accordance with aspects of the present disclosure. The AIoT system 400 may be for an AIoT service (e.g., function and/or service provided by an AIoT device) for an automated warehouse inventory. The inventory may use a request-response operation. Another example of an AIoT service may use sensor monitoring where the network may need to read and write data to the AIoT device. At 402, the truck is unloaded and the goods with embedded AIoT devices pass through an AIoT device reader into the warehouse. The AIoT device reader is shown at 404 as a gate. According to the first topology 200, the AIoT device reader may be a BS. According to the second topology 300, the AIoT device reader may be a UE-AIoT-I. At 406, the goods with embedded AIoT devices are stored in the warehouse. During this time the goods with embedded AIoT devices may be reached by a BS. At 408, the goods with embedded AIoT devices pass through an AIoT device reader out of the warehouse. At 410, the goods with embedded AIoT devices pass through an AIoT device reader and are loaded into a truck.

[0040] At 404, 406, and 408 the AIoT devices may be empowered and the network (to which the AIoT reader is connected) may communicate with the devices and read the AIoT device identifier (ID). Thus, the network may determine the location of the AIoT device and the corresponding good and/or stock.

[0041] Certain examples herein my use a connectivity topology where an AIoT reader (or gate as in Figure 4 at 404 and 408) is implemented as a UE capable of AIoT communication as an intermediate node (e.g., UE-AIoT-I) (e.g., the second topology 300 wherein the intermediate node is denoted as UE-AIoT-I). For this purpose, the UE- AIoT-I node may be registered with the network and the AIoT data and/or signaling may pass through the UE-AIoT-I node.

[0042] In various examples, to allow a UE to act as an intermediate node for AIoT data and/or signaling transmission (e.g., UE-AIoT-I node) to communicate with an AIoT device and with a network (e.g., via Uu interface) the following may be determined: how the UE-AIoT-I is configured to perform AIoT communication, and how the AIoT data and/or signaling is sent and/or received between the UE-AIoT-I and core network (CN) of the network.

[0043] Figure 5 illustrates an example of a procedure 500 in an AIoT system in accordance with aspects of the present disclosure. In some implementations, the procedure 500 may implement, or be implemented by, aspects of the wireless communication system 100 as described with reference to Figure 1. The procedure 500 may include a AIoT device 502 (or multiple AIoT devices), an AIoT device reader 503 (including a UE-AIoT-I 504 and a radio access network (RAN) 506), a CN 507 (including an AIoT-GW, access and mobility management function (AMF), session management function (SMF), user plane functions (UPFs) 508, a unified data repository (UDR)/unified data management (UDM) 510, and a charging function (CHF) 512), an operations, administration, and management (0AM) 514, and an AIoT application function (AF) and/or application server (AS) 516. In the following description of the procedure 500, the operations may be transmitted in a different order than the example order shown, or the operations may be performed in different orders or at different times. Some operations may also be omitted from the procedure 500, and other operations may be added to the procedure 500. The AIoT device 502 communicates with the AIoT device reader 503.

[0044] Specifically, Figure 5 illustrates an overview of deployment and configuration of an AIoT service in a communication network. The Figure 5 shows steps (or phases) for the deployment of the AIoT service including the configuration of the network entities and AIoT transmitters and the communication service for the transmission of the AIoT data and/or signaling.

[0045] In Figure 5, CN control plane (CP) (or user plane) NFs may be used for the purposes of the AIoT service in the 3GPP network. Such NFs may be referred to as an AIoT gateway 508 (AIoT-GW) or AIoT NF. The AIoT-GW 508 may: store the AIoT service parameters and configure UE-AIoT-I 504, RAN 506 and/or BS or CP NFs for the AIoT service, receive and transmit AIoT data and/or signaling from and/or to the AIoT AS 516, receive and transmit AIoT data and/or signaling from and/or to the AIoT reader (e.g. RAN 506 and/or BS or UE-AIoT-I 504), perform store-and-forward functionality for the AIoT data and/or signaling, create charging data for the AIoT data and/or signaling and transmit the data to the CHF 512, and/or verify the identity of the AIoT device 502.

[0046] During a service provisioning phase 517, at 518, the AIoT AF and/or AS 516 is configured with at least one of the following information: a list of AIoT device IDs (to which data and/or signaling has to be transmitted or inventory action is to be performed), a service ID (which may identify the AIoT service) and credentials for the service and the AIoT devices. The AIoT devices may be identified with a Group ID.

[0047] At 520, there may be configuration of the AIoT device 502 which includes at least one of: a device ID, a service ID, and credentials. At 522, the service provisioning or service level agreement (SLA) between the AIoT AF/AS 516 and the CN 597 of the network. Information like the list of AIoT device IDs, the service ID, the credentials, the service area, and the service operation type are provisioned to the network. Two examples of signaling may be used. In one example, the AIoT AF/AS 516 sends the AIoT provisioning data to the 0AM 514 and the 0AM 514 provides the data to the UDM/UDR 510. In another example, the AIoT AF/AS 516 sends the data directly to the UDM/UDR 510 (e.g., via a network exposure function (NEF)).

[0048] The service provisioning phase 517 may also include AIoT device management procedures which are used to manage the AIoT states in the network and in the AIoT AF/AS 516.

[0049] During a configuration phase 523, the AIoT device reader 503 (e.g., the RAN 506 or the UE-AIoT-I 504) is configured to act as an AIoT reader in general or for a particular AIoT service. Such configuration may also include the configuration of the CN 507 entities to serve the particular AIoT service. At 524, the RAN 506 may select and register with the CN 507 its AIoT capability and/or service area with the CN 507 responsible for AIoT communication. At 526, the UE-AIoT-I 504 may register with the CN 507 and indicate its AIoT capability and/or service area with the CN 507 entity responsible for AIoT communication. At 524 and 526, the CN 507 responsible for AIoT communication may configure or enable the AIoT device reader 503 to serve as such for a particular AIoT service. At 528, the CN 507 NFs responsible for AIoT communication may exchange information to configure or activate the parameters related to the particular AIoT service. At 530, the CN 507 NFs responsible for AIoT communication may exchange information for further service parameter configuration or update with the AIoT AF/AS 516.

[0050] During an AIoT service procedure phase 531, the AIoT data and/or signaling is transmitted between the AIoT AF/AS 516 and the AIoT device 502. For this phase, it may be assumed that the AIoT service agreement is established and network together with the AIoT devices are configured with necessary information. It may also be assumed that the procedure for the AIoT service is initiated from the network to support traffic types of device-terminated (DT) and device-originated (DO)-device-terminated triggered (DTT). This phase may also include the authentication and/or authorization of the AIoT device 502 or the AIoT device ID. At 532, the AIoT service provider (e.g., represented as AF or AS) sends the data or signaling to be transmitted in the AIoT device 502. One or more entities in the CN 507 may store the data and/or signaling, process the data and/or signaling and prepare for transmission to the AIoT device reader 503. At 534, the CN 507 may transmit the AIoT data and/or signaling to the AIoT device reader 503. The AIoT device reader 503 may transmit the AIoT data and/or signaling to the AIoT device 502 which may backscatter or actively transmit the signal back to the AIoT device reader 503. The AIoT device reader 503 may transmit the AIoT data and/or signaling to the CN 507. At 536, the AIoT responsible CN 507 entity may collect the AIoT data and/or signaling and prepare an AIoT data report. The AIoT responsible CN 507 entity transmits the AIoT data report to the AIoT AF/AS 516. In addition, at 538, the AIoT responsible CN 507 entity may collect charging data and transmit it to the CHF 512 for charging purposes.

[0051] In one example, the parameters for an AIoT service (e.g., called AIoT service parameters) may be made available to the UE-AIoT-I 504 in one of the following ways: provisioned in the mobile equipment (ME) part of the UE-AIoT-I 504, configured in a universal integrated circuit card (UICC) part of the UE-AIoT-I 504, provisioned in the ME part of the UE-AIoT-I 504 and configured in the UICC part of the UE-AIoT-I 504, provided or updated by the AIoT-AF/AS 516 via a policy control function (PCF) and/or a user plane communication, or provided or updated by the PCF to the UE-AIoT-I 504.

[0052] Figure 6 illustrates another example of a procedure in an AIoT system 600 in accordance with aspects of the present disclosure. In some implementations, the procedure 600 may implement, or be implemented by, aspects of the wireless communication system 100 as described with reference to Figure 1. The procedure 600 may include an AIoT device reader 602 (including a UE-AIoT-I 604), a CN 606 (including AMF, SMF 608, a UPF 610, a PCF 612, and a UDR/UDM 614), and an AIoT AF/AS 616. In the following description of the procedure 600, the operations may be transmitted in a different order than the example order shown, or the operations may be performed in different orders or at different times. Some operations may also be omitted from the procedure 600, and other operations may be added to the procedure 600. [0053] Specifically, Figure 6 shows on a high-level how the AIoT AF/AS 616 may transmit an AIoT policy to the UE-AIoT-I 604 acting as the AIoT device reader 602. At 618, the AIoT AF/AS 616 may store information (or parameters) related to the operation of the AIoT service in the communication network. At 620, the AIoT AF/AS 616 may use exposed services by the control plane (CP) of the CN to provision service parameters or application parameters in the CN, more specifically in the PCF 612 or UDR/UDM 614. At 622, the AIoT AF/AS 616 may send information associated with the policy to the CN, more specifically to the PCF 612 either directly or via the UDM/UDR 614. Based on the received information, the PCF 612 may create the AIoT policy specific for the UE-AIoT-I 604. The PCF 612 transmits the UE -related AIoT policy to the UE-AIoT-I 604 (e.g., via the serving AMF 608) and/or an access and mobility (AM)-related AIoT policy to the serving AMF 608.

[0054] At 624, the AIoT policy is sent via an application layer between the UE- AIoT-I 604 and the AIoT AF/AS 616. The AIoT policy may be carried via the user plane and may be transparent to the communication network (e.g., to the 5GS).

[0055] In certain examples, a UE (e.g., UE-AIoT-I 604) capable of communicating with AIoT devices as an intermediate node is configured with an AIoT policy. The UE uses the AIoT policy to configure (e.g., enable, disable, reconfigure) its operation on an interface to the AIoT device. The policy may be configured on different levels: on a non-access stratum (NAS) level from an AMF or on a UE level from a PCF. The policy may be associated with a specific AIoT service for transmission of a AIoT data and/or signaling. Furthermore, the UE may be capable of:

[0056] A. Transmitting an indication to the AMF (e.g., in a registration request message) that the UE is capable of AIoT communication while serving as an intermediate node; and

[0057] B. Receiving one or more indications about whether the operation as the AIoT intermediate node is allowed (or disallowed) and which AIoT services are allowed to be served (e.g., included in signaling from the AMF or from the PCF).

[0058] In one example, the AMF may handle registration of the UE-AIoT-I, more specifically the AMF may: receive a registration request (e.g., from a UE) indicating an AIoT capability for an intermediate node, receive UE subscription data (e.g., from a UDM) indicating an AIoT service authorization and/or a service identification, select an appropriate PCF capable of AIoT configuration, transmit an indication to the selected PCF including the authorization for AIoT services, and/or transmit an indication to the UE (e.g., in a registration accept message or UE configuration command message) that one or more AIoT services are enabled or disabled.

[0059] In another example, the PCF may create policies for a UE-AIoT-I node, more specifically the PCF may: receive a request (e.g., from an AMF) for AM policy association or UE policy association including an indication that the UE is authorized for one or more AIoT services, receive a notification (e.g., from a UDR or application function (AF)) about the AIoT (e.g., service or subscriber) configuration parameters that may be used to derive the AM or UE policies specific to the AIoT operation of the UE as an intermediate node, create the following policy types: a UE -related policy to enable an AIoT service as an intermediate node (e.g., including AIoT policy and/or tailored UE route selection policy (URSP) rules) or an AM-related policy for AIoT service (e.g., specific data network name (DNN) selection and replacement, specific service area restrictions for the AIoT intermediate node), transmit the UE-related AIoT policy or modified URSP rules to the UE (e.g., via the AMF), and/or transmit the AM-related policy to the AMF.

[0060] A UE-AIoT-I may serve one or more AIoT services or applications which transmit AIoT data and/or signaling to different groups of AIoT devices. In other words, the UE-AIoT-I may implement one or multiple AIoT service clients. The AIoT policy may include information transmitted to the UE indicating how to map the traffic of the different AIoT services to PDU sessions.

[0061] In some examples, an AIoT policy sent from a PCF to a UE-AIoT-I may include:

[0062] A. An indication of whether the operation as an AIoT intermediate node is allowed (or disallowed);

[0063] B. A list of one or more AIoT services which are allowed to be served by the UE making transmissions towards the AIoT devices. The AIoT service may identified by a AIoT application ID or AIoT service ID, and may include a group ID identifying the group of AIoT devices to which AIoT data is sent and/or received; [0064] C. A configuration of how to transmit AIoT data and/or signaling to an AIoT device and over a radio interface (e.g., Uu) (e.g., the communication parameters for the AIoT device). This may include the signal strength to be used for transmissions, the carrier frequency to be used for backscattering transmission, how to schedule AIoT devices for transmission, and so forth;

[0065] C-l. A type of AIoT service for which the UE is configured to operate. The type of AIoT service may be one of the following: (A) inventory service, which is used to discover what goods (e.g. boxes, containers, packages, tools) are present in a specific area. The network may transmit a request within the specific area and the AIoT devices (attached to the goods) report an identifier associated with the good, possibly supplemented with other information such as status, measurement results and/or location. (B) sensor data collection service, which is used to transfer sensor data from AIoT device to the network. The transfer can be done periodically, when the AIoT device has enough power for transmission, or when the AIoT device is triggered by the network. (C) asset tracking service, which is used to determine the location of goods to which AIoT device is attached. The AIoT devices attached to these goods report an identifier associated with the good and associated location information. (D) actuator control service, which is used by the network to transfer (actuator) commands to the AIoT device. The AIoT device can store the command and act correspondingly;

[0066] D. The service areas where the AIoT transmission to and/or from the AIoT devices is allowed. The service areas may include either geographical areas (e.g., identified by global positioning (GPS) coordinates, destination area) or network topology areas (e.g., tracking area indicators (TAIs) or cells IDs). The service area may be associated with an AIoT service ID so that the UE may be configured with service areas per AIoT service ID;

[0067] E. Network identifiers (e.g., PLMNs) in which the UE is authorized to perform AIoT communication with the AIoT devices;

[0068] F. The RATs at which camping on the Uu interface is allowed where AIoT communication is allowed on the interface for communication with the AIoT devices;

[0069] G. An indication about whether the UE is allowed to perform AIoT communications when the UE is not served by evolved universal terrestrial radio access (E-UTRA) and not served by NR; [0070] H. Mapping of the AIoT service to a set of parameters used to establish a PDU session - including: a PDU session type (e.g., internet protocol (IP) type or unstructured type), transport layer protocol (e.g., UDP or transmission control protocol (TCP), only applicable for IP PDU session type), session and service continuity (SSC) mode, single network slice selection assistance information (S-NSSAI), and/or DNNs; and

[0071] I. A validity time of the AIoT policy.

[0072] Figure 7 illustrates a further example of a procedure 700 in an AIoT system in accordance with aspects of the present disclosure. In some implementations, the procedure 700 may implement, or be implemented by, aspects of the wireless communication system 100 as described with reference to Figure 1. The procedure 700 may include a UE 702 (e.g., AIoT-I), a RAN 704, an AMF 706, a PCF 708, and a UDR/UDM 710. In the following description of the procedure 700, the operations may be transmitted in a different order than the example order shown, or the operations may be performed in different orders or at different times. Some operations may also be omitted from the procedure 700, and other operations may be added to the procedure 700.

[0073] Specifically, Figure 7 shows the signaling flow for the procedure 700 of how to configure of an AIoT policy (e.g., for AIoT services) in the UE 702 using the PCF 708. The PCF 708 may be a specific type of PCF capable of AIoT policy configuration. There may be one or more PCFs 708 (e.g., specific for an AIoT service for a particular AIoT customer). For this purpose, the PCF 708 may register itself with an NRF and indicate its capability for a AIoT policy. For example, the PCF 708 may use a Nnrf_NFManagement_NFRegister service operation and include an AIoT capability indication as an input parameter.

[0074] The PCF 708 may be either a UE-PCF (e.g., responsible for creating UE- specific policies), an AM PCF (e.g., responsible for creating AM-specific policies for the AMF 706 and the RAN 704), or a session management (SM) PCF (e.g., responsible for creating SM-specific policies for a PDU session).

[0075] At 712, the UE 702 implements a capability to act as an intermediate node AIoT with transmission capability toward AIoT devices. The UE 702 may be denoted as UE-AIoT-I. In addition, the UE 702 may store various parameters for an AIoT service, denoted as AIoT service parameters, which may be stored in an ME part and/or in a UICC part.

[0076] At 714, the UDM/UDR 710 may store UE subscription data related and/or AIoT application subscription data. The UE subscription data may contain information related to the AIoT service. For example, the UE subscription data may contain at least one of: that the UE 702 is allowed to operate at an intermediate AIoT device, the AIoT services which are allowed for the UE 702, AIoT-gateway (GW) selection information, control plane (CP)/user plane (UP) transmission allowed and/or subscribed for the allowed AIoT services, and so forth. The UE subscription data (e.g., application subscription data, SM subscription data, AIoT UP configuration data) may contain information about an association between the UE 702 and an AIoT AF/AS or AIoT service ID.

[0077] The application subscription data may contain the AIoT configuration information as received. It should be noted that the use of AIoT service in this disclosure has the meaning of the communication service provided by the network to the AIoT data and/or signaling exchange between the AIoT device and the AIoT AF/AS. The AIoT service may be identified by an AIoT service ID which may be used in the signaling between the AIoT AF/AS and the CN of the network. This may mean that the CN of the network (e.g., UDR/UDM 710) may store an association between the AIoT service ID and related service parameters (e.g., service area, transmission time or periodicity, and so forth), the related AIoT application ID, group credentials associated for the network layer security, a list of one or more AIoT devices, and a list of UEs acting as intermediate readers allowed to serve this AIoT service.

[0078] At 716, the UE 702 may initiate a registration procedure. A registration request message (e.g., a non-access stratum (NAS) message) may include: that the UE 702 is capable of AIoT communication serving as an intermediate node, whether the UE 702 can receive AIoT data from the network via CP or UP transmission, AIoT capabilities (e.g., supported frequency bands, range of communication, power mode, mobile or stationary, indoor, outdoor, etc.). The indications may be implemented in the NAS protocol as a mobility management (MM) capability container sent from the UE 702 to the AMF 706 or the indications may be transmitted as a stand-alone informational element in the NAS message. [0079] At 718, the AMF 706 may process the registration request message and a successful UE 702 authentication and authorization. The AMF 706 may send a request message to retrieve the UE’s subscription data from the UDM/UDR 710. The AMF 706 may use a subscription permanent identifier (SUPI) as a reference identifier.

[0080] The response message from the UDM/UDR 710 may include at least one of the following indications: the UE 702 is authorized or enabled and/or disabled to serve as an AIoT intermediate node, a list of one or more AIoT services that are allowed to transmit AIoT data and/or signaling to the AIoT devices, AIoT-GW selection information, and/or whether CP or UP transmission for each of the allowed services is preferred (or configured).

[0081] The AIoT services may be identified by an identifier (ID) or a combination of DNN and/or S-NSSAI. If may be different AIoT-GWs deployed for different AIoT services, then AIoT service identification may be required.

[0082] At 720, the AMF 706 may select the PCF 708 which supports creating policies for AIoT configuration. The AMF 706 may use either a local policy for PCF selection, or the AMF 706 may use NRF services, or the UDR/UDM 710 may have indicated information for PCF selection. The PCF 708 may have registered itself with the NRF. When the AMF 706 sends a request to the NRF for PCF selection, the AMF 706 may include an indication that the PCF 708 should support an AIoT capability.

[0083] At 722, the AMF 706 may send a request message to the PCF 708 for AM policy association establishment with the PCF 708 (e.g., AM-PCF). The AMF 706 may use a Npcf_AMPolicyControl_Create service operation. The AMF 706 may include: the SUPI (e.g., as a UE ID), a list of TAIs of the registration area, an access type, an indication that the UE 702 is subscribed (or authorized) for AIoT service, the AIoT service (or application) IDs for which the UE 702 is subscribed and UE location information or whether the UE is located indoor or outdoor.

[0084] The PCF 708 may create an AM-related AIoT policy specifically for the UE 702 which may include to apply a specific RAT/frequency selection priority (RFSP) index for operating as an AIoT intermediate node, a specific DNN selection and/or DNN replacement policy, a specific CHF selection, a specific SMF selection for AIoT DNN and/or S-NSSAI, a specific service area restrictions for an AIoT intermediate node, policies for operating as AIoT intermediate node indoors or policies for operating as intermediate node outdoors and other policies. The policy ‘specific service area restrictions for an AIoT intermediate node’ may include either a network topology information (e.g., NR cell ID(s) or TAI, or LTE cell ID(s) or TAIs), geographical information (e.g., GPS coordinates, elevation), or an indication for indoor restrictions or outdoor restrictions where the UE is allowed to operate as an AIoT intermediate node.

[0085] At 724, the AMF 706 may send a registration accept message (or in various scenarios also a UE configuration update command (UCU)) which may include one or more indications about whether the operation as an AIoT intermediate node is allowed (or disallowed) and which AIoT service IDs are allowed to be served.

[0086] The AMF 706 may consider service area restrictions for an AIoT intermediate node policy when the AMF 706 creates the registration area for the UE 702. Or the AMF 706 may indicate (e.g., in addition to the registration area) an AIoT service area where the UE is allowed to operate as an AIoT intermediate node.

[0087] Moreover, the AMF 706 may also send AIoT service area restrictions for the UE operating as an AIoT intermediate node to the RAN 704 as part of a UE context. For example, the RAN 704 may take a restriction policy when determining the target RAN 704 for UE mobility.

[0088] At 726, the PCF 708 may request the application subscription data and/or the UE subscription data (e.g., related to policy creation) from the UDR/UDM 710. The PCF 708 may indicate that the application subscription data should be associated with the AIoT service IDs for which the UE 702 is subscribed or authorized to be used.

[0089] The UDR/UDM 710 may send a response message including the application subscription data of one or more applications associated with the AIoT service IDs.

[0090] At 728, the PCF 708 may subscribe to the UDR/UDM 710 to be notified when the application subscription data changes. For example, the PCF 708 may use a Nudr_DM_Subscribe request service operation. The PCF 708 may include at least one of the following parameters: application data for AIoT service change and/or UE subscription data change request.

[0091] At 730, the PCF 708 may create a policy for the UE acting as an intermediate node for AIoT transmission (e.g., UE-AIoT-I). The transmission of the UE AIoT policy may be done at 734. [0092] The UE policy may include at least one of the following parameters:

[0093] A. A configuration of how to transmit AIoT data and/or signaling to the AIoT device(s) and over Uu (e.g., the communication parameters for the AIoT device). This may include the frequencies and/or power levels for the radio transmission to the AIoT devices. In addition or alternatively, a configuration of how to transmit AIoT data and/or signaling to the network, e.g. whether to use control plane transmission or user plane transmission;

[0094] B. Public land mobile networks (PLMNs) in which the UE 702 is authorized to perform AIoT communication;

[0095] C. An indication about whether the UE 702 is allowed to perform AIoT communication when the UE 702 is not served by E-UTRA and not served by NR; and/or

[0096] D. One or more AIoT service areas where the UE 702 is allowed to perform AIoT communication. For example, the AIoT service areas may be identified by network topological information (e.g., list of TAIs, list of cell IDs) or by geographical information (e.g., using the polygon of GPS coordinates). Each AIoT service area may be associated with an AIoT service ID.

[0097] At 732, the PCF 708 may create one or more URSP rules which are specific to an AIoT application. For example, the URSP rule may be identified by an AIoT application ID, AIoT-AS fully qualified domain name (FQDN) or IP address or a 5 tuple of the destination traffic to the AIoT-AS. A route selection descriptor (RSD) may include the S-NSSAI and/or DNN and validity information (e.g., location validity, time validity) which is specific to the AIoT application validity information.

[0098] At 734, the PCF 708 may transmit the UE AIoT policy and/or URSP policy towards the UE 702. The policy information may be encapsulated in an N1 UE policy container. In one example, a new type of N1 UE policy container may be used to indicate that the UE policy is of type AIoT. The PCF 708 may use a Namf_Communication_NlN2MessageTransfer or similar service to transmit the UE policy container.

[0099] At 736, the AMF 706 includes the N 1 UE policy container in an NAS DL transport message and sends the NAS message to the UE 702. [0100] At 738, the UE 702 may reply by creating an N1 UE policy container and including it in an NAS UL transport message. The UE 702 may indicate whether the policy has been accepted, which part of the policy is accepted, and so forth.

[0101] At 740, an AIoT AF 742 (and/or AIOT AS) may use an existing or a new service exposed by the 5GC (e.g., a network exposure function (NEF) 744) to send AIoT service (or subscriber) configuration parameters to the 5GC. In one example, one existing service may be Nnef_ServiceParameter_Create/Update for service parameter provisioning (e.g., parameters provisioned to UE subscription data in the UDR/UDM 710). In another example, a new NEF service may be used specifically for AIoT service parameter provisioning (e.g., Nnef_AIoT_ServiceProvisioning for service parameters provisioned to application-level subscription data in the UDR/UDM 710).

[0102] The information sent from the AIoT AF 742 to the 5GC may include at least one of: an AIoT application external identifier, a UE external identifier, a list of one or more AIoT service IDs which the UE 702 is allowed to serve, a specific S-NSSAI or DNN to be configured in the UE 702 to be used for the AIoT traffic to the AIoT AF 742, one or more AIoT (service or subscriber) configuration parameters (e.g., including a type of AIoT service), and so forth.

[0103] The AIoT (service or subscriber) configuration parameters may include at least one of:

[0104] A. An AM policy for an application identified by a AIoT service ID (e.g., to be applied for any AIoT reader and/or transmitter serving this AIoT service);

[0105] B. An AM policy for an individual UE (e.g., to be applied independently of conditions related to the application traffic); and/or

[0106] C. Parameters or assistance information to create the AIoT policy in 5GC (e.g., PCF 708) for the UE 702.

[0107] The NEF 744 may select a UDR/UDM 710 serving the UE 710 and/or AIoT application to transmit the requested service provisioning from the AIoT AF 742 to the UDR/UDM 710.

[0108] If the AIoT AF 742 is a trusted entity and may contact the PCF 708 directly (e.g., without using the NEF 744 services or APIs), the AIoT AF 742 may need to select the PCF 708 by firstly sending a request to a binding support function (BSF) to resolve the serving PCF 708 for the UE 702, for the DNN, or for the S-NSSAI.

[0109] At 746, if the PCF 708 has subscribed for notification from the UDR/UDM 710 when the UE subscription data or application subscription data in the UDR/UDM 710 changes, the UDR/UDM 710 may use a Nudr_DM_Notify service to transmit the changed subscription data to the PCF 708. It should be noted that 740 and 746 may be performed at any time during the procedure 700 when the UE 702 is registered with the network.

[0110] At 748, the PCF 708 may create a new AIoT policy or update an existing stored AIoT policy for a particular UE. The PCF 708 may execute the steps described herein to configure the UE AIoT policy.

[0111] At 750, the AIoT AF 742 may use an existing or a new service exposed by the 5GC (e.g., PCF) to send the AIoT service (or subscriber) configuration parameters to a PCF 752. In one example, one existing service may be a Npcf_AMPolicyAuthorization service used by a trusted application function (AF) to create or update an application policy at the PCF 752. The AIoT AF 742 may include the application policy information described herein.

[0112] In one implementation, the AIoT AF 742 may include a policy container to be transmitted to the UE 702. This may be a new type of information sent from the AIoT AF 702 to the PCF 752, a kind of policy container from the AIoT AF 742 to the UE 702. It may be regarded as an application policy container including an intermediate node AIoT policy. The PCF 752 may store and forward this application policy container to the UE 702 included in aNl UE policy container.

[0113] At 754, the PCF 752 may perform an AM policy association modification with the AMF 706. The AMF 706 may reconfigure the UE 702 and the RAN 704 serving the UE 702 considering the update policies.

[0114] It should be noted that examples shown in Figure 7 may be applied to public networks (e.g., PLMN), or private networks (e.g., non-public network (NPN) or standalone NPN (SNPN)). Moreover, benefits of the examples of Figure 7 may enable a dynamic configuration of UE-related AIoT policies for the UE 702 and AM-related AIoT policies for the AMF 706 and RAN 704. [0115] Figure 8 illustrates an example of a UE 800 in accordance with aspects of the present disclosure. The UE 800 may include a processor 802, a memory 804, a controller 806, and a transceiver 808. The processor 802, the memory 804, the controller 806, or the transceiver 808, 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.

[0116] The processor 802, the memory 804, the controller 806, or the transceiver 808, 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.

[0117] The processor 802 may include an intelligent hardware device (e.g., a general-purpose processor, a DSP, a CPU, an ASIC, a field programmable gate array (FPGA), or any combination thereof). In some implementations, the processor 802 may be configured to operate the memory 804. In some other implementations, the memory 804 may be integrated into the processor 802. The processor 802 may be configured to execute computer-readable instructions stored in the memory 804 to cause the UE 800 to perform various functions of the present disclosure.

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

[0119] In some implementations, the processor 802 and the memory 804 coupled with the processor 802 may be configured to cause the UE 800 to perform one or more of the functions described herein (e.g., executing, by the processor 802, instructions stored in the memory 804). For example, the processor 802 may support wireless communication at the UE 800 in accordance with examples as disclosed herein. For example, the processor 802 coupled with the memory 804 may be configured to cause the UE 800 to transmit a registration request message including an indication for capability of the UE as an AIoT intermediate node. The UE 800 may also receive a registration response message comprising an AIoT policy that enables the UE as the AIoT intermediate node for an AIoT service.

[0120] The controller 806 may manage input and output signals for the UE 800. The controller 806 may also manage peripherals not integrated into the UE 800. In some implementations, the controller 806 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 806 may be implemented as part of the processor 802.

[0121] In some implementations, the UE 800 may include at least one transceiver 808. In some other implementations, the UE 800 may have more than one transceiver 808. The transceiver 808 may represent a wireless transceiver. The transceiver 808 may include one or more receiver chains 810, one or more transmitter chains 812, or a combination thereof.

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

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

[0124] Figure 9 illustrates an example of a processor 900 in accordance with aspects of the present disclosure. The processor 900 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 900 may include a controller 902 configured to perform various operations in accordance with examples as described herein. The processor 900 may optionally include at least one memory 904, which may be, for example, an L1/L2/L3 cache. Additionally, or alternatively, the processor 900 may optionally include one or more arithmetic -logic units (ALUs) 906. 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).

[0125] The processor 900 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 900) 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).

[0126] The controller 902 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 900 to cause the processor 900 to support various operations in accordance with examples as described herein. For example, the controller 902 may operate as a control unit of the processor 900, generating control signals that manage the operation of various components of the processor 900. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

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

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

[0129] The memory 904 may store computer-readable, computer-executable code including instructions that, when executed by the processor 900, cause the processor 900 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 902 and/or the processor 900 may be configured to execute computer-readable instructions stored in the memory 904 to cause the processor 900 to perform various functions. For example, the processor 900 and/or the controller 902 may be coupled with or to the memory 904, the processor 900, the controller 902, and the memory 904 may be configured to perform various functions described herein. In some examples, the processor 900 may include multiple processors and the memory 904 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.

[0130] The one or more ALUs 906 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 906 may reside within or on a processor chipset (e.g., the processor 900). In some other implementations, the one or more ALUs 906 may reside external to the processor chipset (e.g., the processor 900). One or more ALUs 906 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 906 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 906 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 906 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not-AND (NAND), enabling the one or more ALUs 906 to handle conditional operations, comparisons, and bitwise operations.

[0131] The processor 900 may support wireless communication in accordance with examples as disclosed herein. The processor 900 may be configured to or operable to support a means for: transmitting a registration request message including an indication for capability of the UE as an AIoT intermediate node, and receiving a registration response message comprising an AIoT policy that enables the UE as the AIoT intermediate node for an AIoT service.

[0132] Figure 10 illustrates an example of a NE 1000 in accordance with aspects of the present disclosure. The NE 1000 may include a processor 1002, a memory 1004, a controller 1006, and a transceiver 1008. The processor 1002, the memory 1004, the controller 1006, or the transceiver 1008, 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. [0133] The processor 1002, the memory 1004, the controller 1006, or the transceiver 1008, 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.

[0134] The processor 1002 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 1002 may be configured to operate the memory 1004. In some other implementations, the memory 1004 may be integrated into the processor 1002. The processor 1002 may be configured to execute computer- readable instructions stored in the memory 1004 to cause the NE 1000 to perform various functions of the present disclosure. For example, the processor 1002 coupled with the memory 1004 may be configured to cause the NE 1000 to: receive a request message for an AIoT policy, wherein the request message comprises an indication that a UE is authorized as an AIoT intermediate node for an AIoT service, determine the AIoT policy for the UE that enables the UE as the AIoT intermediate node for the AIoT service, and transmit a response message comprising the AIoT policy.

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

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

[0137] The controller 1006 may manage input and output signals for the NE 1000. The controller 1006 may also manage peripherals not integrated into the NE 1000. In some implementations, the controller 1006 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 1006 may be implemented as part of the processor 1002.

[0138] In some implementations, the NE 1000 may include at least one transceiver 1008. In some other implementations, the NE 1000 may have more than one transceiver 1008. The transceiver 1008 may represent a wireless transceiver. The transceiver 1008 may include one or more receiver chains 1010, one or more transmitter chains 1012, or a combination thereof.

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

[0140] A transmitter chain 1012 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1012 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 1012 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 1012 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium. [0141] Figure 11 illustrates a flowchart of a method 100 in accordance with aspects of the present disclosure. The operations of the method 1100 may be implemented by a first apparatus (e.g., UE) as described herein. In some implementations, a UE 1100 may execute a set of instructions to control the function elements of a processor to perform the described functions.

[0142] At 1102, the method may include transmitting a registration request message including an indication for capability of the UE as an AIoT intermediate node. The operations of 1102 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1102 may be performed by a UE as described with reference to Figure 8.

[0143] At 1104, the method may include receiving a registration response message comprising an AIoT policy that enables the UE as the AIoT intermediate node for an AIoT service. The operations of 1104 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1104 may be performed by a UE as described with reference to Figure 8.

[0144] Figure 12 illustrates a flowchart of another method 1200 in accordance with aspects of the present disclosure. The operations of the method 1200 may be implemented by a second apparatus (e.g., NE) as described herein. In some implementations, a NE 1000 may execute a set of instructions to control the function elements of a processor to perform the described functions.

[0145] At 1202, the method may include receiving a request message for an AIoT policy, wherein the request message comprises an indication that a UE is authorized as an AIoT intermediate node for an AIoT service. The operations of 1202 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1202 may be performed by a NE as described with reference to Figure 10.

[0146] At 1204, the method may include determining the AIoT policy for the UE that enables the UE as the AIoT intermediate node for the AIoT service. The operations of 1204 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1204 may be performed by a NE as described with reference to Figure 10. [0147] At 1206, the method may include transmitting a response message comprising the AIoT policy. The operations of 1206 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1206 may be performed by a NE as described with reference to Figure 10. [0148] It should be noted that the methods described herein describe possible implementations, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

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

CLAIMS What is claimed is:

1 . A user equipment (UE), comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: transmit a registration request message including an indication for capability of the UE as an ambient internet of things (AIoT) intermediate node; and receive a registration response message comprising an AIoT policy that enables the UE as the AIoT intermediate node for an AIoT service.

2. The UE of claim 1, wherein the AIoT policy comprises one or more of: a UE policy for the UE as the AIoT intermediate node or a UE route selection policy (URSP) for routing AIoT communication by the UE as the AIoT intermediate node.

3. The UE of claim 1, wherein the AIoT policy is based one or more of: application subscription data or session management (SM) subscription data of the UE including AIoT user plane (UP) configuration data.

4. The UE of claim 1, wherein the AIoT policy is based on one or more of: application subscription data or session management (SM) policy data of the UE including AIoT user plane (UP) configuration data.

5. The UE of claim 1, wherein the AIoT policy for the UE comprises one or more of: an indication to enable or disable the UE as the AIoT intermediate node; a list of one or more AIoT services or AIoT applications supported for the UE as the AIoT intermediate node; a configuration for one or more of transmission of AIoT data or signaling to an AIoT device and over a radio interface; at least one coverage area that allows AIoT communication with the AIoT device; or a network identifier associated with the allowed AIoT communication with the AIoT device.

6. The UE of claim 1, wherein the at least one processor is further configured to cause the UE to: enable the UE as the AIoT intermediate node based at least in part on the AioT policy; or disable the UE as the AioT intermediate node based at least in part on the AioT policy.

7. The UE of claim 1, wherein the at least one processor is further configured to cause the UE to: determine a coverage area applicable for AioT communication with an AioT device based at least in part on the AioT policy; and perform the AioT communication with the AioT device within the coverage area applicable for the AioT communication.

8. The UE of claim 1, wherein the at least one processor is further configured to cause the UE to: identify one or more of a service identifier associated with at least one AioT service or an application identifier associated with at least one AioT application, based at least in part on the AioT policy; and perform AioT communication associated with one or more of the at least one AioT service or the at least one AioT application.

9. A processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: transmit a registration request message including an indication for capability of the UE as an ambient internet of things (AioT) intermediate node; and receive a registration response message comprising an AIoT policy that enables a user equipment (UE) as the AIoT intermediate node for an AIoT service.

10. The processor of claim 9, wherein the AIoT policy comprises one or more of: a UE policy for the UE as the AIoT intermediate node or a UE route selection policy (URSP) for routing AIoT communication by the UE as the AIoT intermediate node.

11. The processor of claim 9, wherein the AIoT policy is based one or more of: application subscription data or session management (SM) subscription data of the UE including AIoT user plane (UP) configuration data.

12. The processor of claim 9, wherein the AIoT policy is based on one or more of: application subscription data or session management (SM) policy data of the UE containing AIoT user plane (UP) configuration data.

13. A method of a user equipment (UE), the method comprising : transmitting a registration request message including an indication for capability of the UE as an ambient internet of things (AIoT) intermediate node; and receiving a registration response message comprising an AIoT policy that enables the UE as the AIoT intermediate node for an AIoT service.

14. An apparatus for performing a network function, the apparatus comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the apparatus to: receive a request message for an ambient internet of things (AIoT) policy, wherein the request message comprises an indication that a user equipment (UE) is authorized as an AIoT intermediate node for an AIoT service; determine the AIoT policy for the UE that enables the UE as the AIoT intermediate node for the AIoT service; and transmit a response message comprising the AIoT policy.

15. The apparatus of claim 14, wherein the network function comprises a policy control function (PCF).

16. The apparatus of claim 15, wherein the PCF comprises a PCF that creates UE- specific policies, or a PCF that creates access and mobility polices for an access and mobility management function (AMF).

17. The apparatus of claim 14, wherein the AIoT policy comprises one or more of: a UE policy for the UE as the AIoT intermediate node or a UE route selection policy (URSP) for routing AIoT communication by the UE as the AIoT intermediate node.

18. The apparatus of claim 14, wherein the AIoT policy is determined based on one or more of: application subscription data or session management (SM) subscription data of the UE including AIoT user plane (UP) configuration data.

19. The apparatus of claim 14, wherein the AIoT policy is determined based on one or more of: application subscription data or session management (SM) policy data of the UE containing AIoT user plane (UP) configuration data.

20. The apparatus of claim 14, wherein the AIoT policy for the UE comprises one or more of: an indication to enable or disable the UE as the AIoT intermediate node; a list of one or more AIoT services or AIoT applications supported for the UE as the AIoT intermediate node; a configuration for one or more of transmission of AIoT data or signaling to an AIoT device and over a radio interface; at least one coverage area that allows AIoT communication with the AIoT device; or a network identifier associated with the allowed AIoT communication with the AIoT device.