Policy rule for AIOT data transmission

Abstract

Various aspects of the present disclosure relate to apparatuses and methods for policy rules for AIoT data transmission. In one aspect, a first apparatus receives, from a second apparatus, ambient internet-of-things (AIoT) related information associated with a user equipment (UE). The first apparatus determines at least one AIoT-related policy rule for the UE based on the AIoT related information, and transmits the at least one AIoT-related policy rule to the UE.

Description

POLICY RULE FOR AIOT DATA TRANSMISSIONTECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to a user equipment (UE) , apparatuses, processors for wireless communication, methods, and non-transitory computer readable media for policy rules for ambient internet of things (AIoT) data transmission.BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, such as base stations, which may be otherwise known as an eNodeB (eNB) , a next-generation NodeB (gNB) , or other suitable terminology. Each network communication devices, such as a base station 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) . 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) ) .

[0003] AIoT has been regarded as an important internet of things (IoT) service and is being extensively studied. SA1 is considering devices being either battery-less or with limited energy storage capability (i.e., using a capacitor) and the energy is provided through the harvesting of radio waves, light, motion, heat, or any other power source that could be seen suitable. SA2 has decided to study two main types of AIoT devices in Release 19, i.e., device-terminated (DT) and device-originated -device-terminated triggered (DO-DTT) .

[0004] Two connectivity topologies for AIoT are to be studied. In AIoT Topology 1, an AIoT device directly and bidirectionally communicates with a network entity. In AIoT Topology 2, an AIoT device communicates bidirectionally with an intermediate node  between the AIoT device and a network entity. The intermediate node transfers AIoT data and / or signalling between the network entity and the AIoT device. In AIoT Topology 2, a UE can act as the intermediate node which is under the network control.

[0005] What’s more, three different kinds of services are being considered, namely, inventory, command read and command write.SUMMARY

[0006] The present disclosure relates to a UE, apparatuses, processors for wireless communication, methods, and non-transitory computer readable media for policy rules for AIoT data transmission. With the UE, apparatuses, processors for wireless communication, methods, and non-transitory computer readable media, the first apparatus may receive AIoT related information associated with the UE from the second apparatus and then determine at least one AIoT-related policy rule for the UE based on the AIoT related information. The UE may determine a protocol data unit (PDU) session for AIoT data based on the at least one AIoT-related policy rule received from the first apparatus and information of the AIoT data, and then transmit the AIoT data on the PDU session. Therefore, if a UE is authorized to act as an AIoT intermediate node, the UE may be configured with AIoT-related policy rule (s) and may route AIoT data on a PDU session determined for the AIoT data based on the AIoT-related policy rule (s) . In this way, a scheme for routing data from AIoT data to a related PDU session under AIoT topology 2 is designed.

[0007] In a first aspect of the solution, a first apparatus receives, from a second apparatus, ambient internet-of-things (AIoT) related information associated with a user equipment (UE) . The first apparatus determines at least one AIoT-related policy rule for the UE based on the AIoT related information, and transmits the at least one AIoT-related policy rule to the UE.

[0008] In some implementations of the method and apparatuses described herein, the at least one AIoT-related policy rule may include at least one AIoT-related traffic descriptor component. The at least one AIoT-related traffic descriptor component may include one of the following: at least one AIoT device identifier; or at least one AIoT device group identifier.

[0009] In some implementations of the method and apparatuses described herein, the  at least one AIoT-related policy rule may include at least one AIoT-related traffic descriptor component. The at least one AIoT-related traffic descriptor component may include at least one of the following: at least one operator identifier of at least one AIoT device; at least one manufacturer identifier of at least one AIoT device; at least one owner identifier of at least one AIoT device; an operator identifier of the UE; a manufacturer identifier of the UE; an owner identifier of the UE; at least one identifier of at least one AIoT application; a connection capability of AIoT communication; or a traffic category of AIoT communication.

[0010] In some implementations of the method and apparatuses described herein, each of the at least one AIoT-related traffic descriptor component is associated with at least one data network or at least one slice that is used to determine a protocol data unit (PDU) session for routing AIoT data.

[0011] In some implementations of the method and apparatuses described herein, the AIoT related information may include at least one of the following: subscription data of the UE; subscription data of at least one AIoT application; subscription data of at least one AIoT device; an identifier of the UE; an AIoT-related indication; an indication of subscribing policy update notification associated with the UE; or location information of the UE.

[0012] In some implementations of the method and apparatuses described herein, the subscription data of the UE may include at least one of the following: operator information of the UE; manufacturer information of the UE; owner information of the UE;information of at least one data network that the UE is subscribed to; or information of at least one slice that the UE is subscribed to; or information of whether the UE is authorized to act as a reader.

[0013] In some implementations of the method and apparatuses described herein, the subscription data of the at least one AIoT application may include at least one of the following: an indication of whether the at least one AIoT application is allowed to use a service provided by a network; or a credential for network layer security of the at least one AIoT application.

[0014] In some implementations of the method and apparatuses described herein, the at least one AIoT application is allowed to use the service provided by the network. The indication of whether the at least one AIoT application is allowed to use the service  provided by the network may include at least one of the following: at least one application type of the at least one AIoT application; or at least one identifier of the at least one AIoT application.

[0015] In some implementations of the method and apparatuses described herein, the AIoT related information may include at least one of the following: AIoT-related rule guidance information; an identifier of the UE; an AIoT-related indication; or an indication of subscribing policy update notification associated with the UE.

[0016] In some implementations of the method and apparatuses described herein, the AIoT-related rule guidance information may include at least one of the following: at least one identifier of at least one AIoT application; at least one AIoT device identifier; at least one AIoT device group identifier; at least one operator identifier of at least one AIoT device; at least one manufacturer identifier of at least one AIoT device; at least one owner identifier of at least one AIoT device; operator information of the UE; manufacturer information of the UE; owner information of the UE; data network information; or slice information.

[0017] In some implementations of the method and apparatuses described herein, the at least one AIoT device identifier may include at least one of the following: at least one electronic product code of at least one AIoT device; at least one tag identification (TID) of at least one AIoT device; at least one operator identifier of at least one AIoT device; at least one manufacturer identifier of at least one AIoT device; or at least one owner identifier of at least one AIoT device.

[0018] In some implementations of the method and apparatuses described herein, the at least one AIoT device group identifier may include at least one of the following: at least one electronic product code of at least one AIoT device; at least one TID of at least one AIoT device; at least one operator identifier of at least one AIoT device; at least one manufacturer identifier of at least one AIoT device; or at least one owner identifier of at least one AIoT device.

[0019] In some implementations of the method and apparatuses described herein, determining the at least one AIoT-related policy rule may include: determining at least one route selection description based on at least one of the following: data network information associated with the UE; data network information associated with at least one AIoT device; slice information associated with the UE; or slice information associated  with the at least one AIoT device.

[0020] Some implementations of the method and apparatuses described herein may further include: receiving, from the UE, a policy rule enforcement report, wherein the policy rule enforcement report may include an indication of a connection capability of AIoT communication; and updating the at least one AIoT related policy rule based on the policy rule enforcement report.

[0021] In some implementations of the method and apparatuses described herein, the policy rule enforcement report is received from the UE via an AIoT function (AIoTF) or via a session management function (SMF) .

[0022] In some implementations of the method and apparatuses described herein, the first apparatus implements a policy control function (PCF) . The second apparatus implements one of the following: an access and mobility management function (AMF) serving the UE; an AIoT function (AIoTF) ; a unified data management (UDM) ; a unified data repository (UDR) ; an AIoT application function; an AIoT application server; or a location management function (LMF) that has location information of the UE.

[0023] In a second aspect of the solution, a second apparatus transmits, to a first apparatus, ambient internet-of-things (AIoT) related information associated with a user equipment (UE) . The AIoT related information is used to determine at least one AIoT-related policy rule for the UE.

[0024] In some implementations of the method and apparatuses described herein, the AIoT related information may include at least one of the following: subscription data of the UE; subscription data of at least one AIoT application; subscription data of at least one AIoT device; or an identifier of the UE; an AIoT-related indication; an indication of subscribing policy update notification associated with the UE; or location information of the UE.

[0025] Some implementations of the method and apparatuses described herein may further include: transmitting, to a third apparatus, at least one of the following: an identifier of the UE, at least one identifier of the at least one AIoT application, at least one AIoT device identifier of the at least one AIoT device, or at least one AIoT device group identifier associated with the at least one AIoT device; and receiving, from the third apparatus, at least one of the following: the subscription data of the UE; the subscription  data of the at least one AIoT application; the subscription data of the at least one AIoT device; information of at least one AIoT service associated with the UE.

[0026] In some implementations of the method and apparatuses described herein, the subscription data of the UE may include at least one of the following: operator information of the UE; manufacturer information of the UE; owner information of the UE;information of at least one data network that the UE is subscribed to; or information of at least one slice that the UE is subscribed to; or information of whether the UE is authorized to act as a reader.

[0027] In some implementations of the method and apparatuses described herein, the subscription data of the at least one AIoT application may include at least one of the following: an indication of whether the at least one AIoT application is allowed to use a service provided by a network; or a credential for network layer security of the at least one AIoT application.

[0028] In some implementations of the method and apparatuses described herein, the at least one AIoT application is allowed to use the service provided by the network. The indication of whether the at least one AIoT application is allowed to use the service provided by the network may include at least one of the following: at least one application type of the at least one AIoT application; or at least one identifier of the at least one AIoT application.

[0029] In some implementations of the method and apparatuses described herein, the second apparatus implements one of the following: an access and mobility management function (AMF) serving the UE; an AIoT function (AIoTF) ; a unified data management (UDM) ; a unified data repository (UDR) ; or a location management function (LMF) that has location information of the UE.

[0030] In some implementations of the method and apparatuses described herein, the AIoT related information may include at least one of the following: AIoT-related rule guidance information; an identifier of the UE; an AIoT-related indication; or an indication of subscribing policy update notification associated with the UE.

[0031] Some implementations of the method and apparatuses described herein may further include: receiving, from a fourth apparatus, the AIoT-related rule guidance information.

[0032] In some implementations of the method and apparatuses described herein, the AIoT-related rule guidance information may include at least one of data network information or slice information. Some implementations of the method and apparatuses described herein may further include: receiving, from a third apparatus, subscription data of the UE; and determining whether to accept the AIoT-related rule guidance information based on the subscription data of the UE. The AIoT-related rule guidance information is rejected in the case that the at least one of data network information or slice information does not comply with the subscription data of the UE.

[0033] Some implementations of the method and apparatuses described herein may further include: receiving, from the UE, a policy selection identifier (PSI) ; and determining whether policy updating is needed for the UE based on the PSI and at least one of the subscription data of the UE or the AIoT-related rule guidance information received from the fourth apparatus. The AIoT related information is transmitted to the first apparatus in the case that policy updating is needed for the UE.

[0034] In some implementations of the method and apparatuses described herein, the AIoT-related rule guidance information may include at least one of the following: at least one identifier of at least one AIoT application; at least one AIoT device identifier; at least one AIoT device group identifier; at least one operator identifier of at least one AIoT device; at least one manufacturer identifier of at least one AIoT device; at least one owner identifier of at least one AIoT device; operator information of the UE; manufacturer information of the UE; owner information of the UE; data network information; or slice information.

[0035] In some implementations of the method and apparatuses described herein, the second apparatus implements one of the following: an access and mobility management function (AMF) serving the UE; an AIoT function (AIoTF) ; an AIoT application function; or an AIoT application server; or a location management function (LMF) that has location information of the UE.

[0036] In some implementations of the method and apparatuses described herein, the at least one AIoT device identifier may include at least one of the following: at least one electronic product code of at least one AIoT device; at least one tag identification (TID) of at least one AIoT device; at least one operator identifier of at least one AIoT device; at least one manufacturer identifier of at least one AIoT device; or at least one owner  identifier of at least one AIoT device.

[0037] In some implementations of the method and apparatuses described herein, the at least one AIoT device group identifier may include at least one of the following: at least one electronic product code of at least one AIoT device; at least one TID of at least one AIoT device; at least one operator identifier of at least one AIoT device; at least one manufacturer identifier of at least one AIoT device; or at least one owner identifier of at least one AIoT device.

[0038] Some implementations of the method and apparatuses described herein may further include: receiving, from the UE, a policy selection identifier (PSI) ; receiving, from a third apparatus, subscription data of the UE; and determining whether policy updating is needed for the UE at least based on the PSI and the subscription data of the UE. The AIoT related information is transmitted to the first apparatus in the case that policy updating is needed for the UE.

[0039] In some implementations of the method and apparatuses described herein, the second apparatus implements an AIoT function (AIoTF) . Some implementations of the method and apparatuses described herein may further include: receiving, from a fifth apparatus, AIoT data on a protocol data unit (PDU) session, wherein the PDU session follows the at least one AIoT-related policy rule, and the fifth apparatus implements a user plane function (UPF) ; performing an inspection or a verification of the AIoT data; and transmitting, to a sixth apparatus, the AIoT data.

[0040] In some implementations of the method and apparatuses described herein, the second apparatus implements an AIoT function (AIoTF) . Some implementations of the method and apparatuses described herein may further include: receiving, from the UE, a policy rule enforcement report, wherein the policy rule enforcement report may include an indication of a connection capability of AIoT communication; and transmitting, to the first apparatus, the policy rule enforcement report.

[0041] In some implementations of the method and apparatuses described herein, the first apparatus implements a policy control function (PCF) . In some implementations of the method and apparatuses described herein, the third apparatus implements an UDM or an UDR. In some implementations of the method and apparatuses described herein, the fourth apparatus implements an AIoT application function or an AIoT application server. In some implementations of the method and apparatuses described herein, the  sixth apparatus implements an AIoT application function or an AIoT application server.

[0042] In a third aspect of the solution, a UE receives, from a first apparatus, at least one ambient internet-of-things (AIoT) -related policy rule for the UE; receives a message carrying AIoT data from an AIoT device; determines a protocol data unit (PDU) session for the AIoT data based on the at least one AIoT-related policy rule and information of the AIoT data; and transmits the AIoT data to a fifth apparatus on the PDU session.

[0043] In some implementations of the method and apparatuses described herein, the at least one AIoT-related policy rule may include at least one AIoT-related traffic descriptor component. The at least one AIoT-related traffic descriptor component may include one of the following: at least one AIoT device identifier; or at least one AIoT device group identifier.

[0044] In some implementations of the method and apparatuses described herein, the at least one AIoT device identifier may include at least one of the following: at least one electronic product code of at least one AIoT device; at least one tag identification (TID) of at least one AIoT device; at least one operator identifier of at least one AIoT device; at least one manufacturer identifier of at least one AIoT device; or at least one owner identifier of at least one AIoT device.

[0045] In some implementations of the method and apparatuses described herein, the at least one AIoT device group identifier may include at least one of the following: at least one electronic product code of at least one AIoT device; at least one TID of at least one AIoT device; at least one operator identifier of at least one AIoT device; at least one manufacturer identifier of at least one AIoT device; or at least one owner identifier of at least one AIoT device.

[0046] In some implementations of the method and apparatuses described herein, the at least one AIoT-related policy rule may include at least one AIoT-related traffic descriptor component. The at least one AIoT-related traffic descriptor component may include at least one of the following: at least one operator identifier of at least one AIoT device; at least one manufacturer identifier of at least one AIoT device; at least one owner identifier of at least one AIoT device; an operator identifier of the UE; a manufacturer identifier of the UE; an owner identifier of the UE; at least one identifier of at least one AIoT application; a connection capability of AIoT communication; or a traffic category of AIoT communication.

[0047] In some implementations of the method and apparatuses described herein, the information of the AIoT data may include at least one of the following: an AIoT device identifier of the AIoT device; an AIoT device group identifier of the AIoT device; an operator identifier of the AIoT device; an manufacturer identifier of the AIoT device; an owner identifier of the AIoT device; an identifier of the AIoT application; or a traffic category of AIoT communication.

[0048] In some implementations of the method and apparatuses described herein, the AIoT device identifier may include at least one of the following: an electronic product code of the AIoT device; a tag identification (TID) of the AIoT device; an operator identifier of the AIoT device; a manufacturer identifier of the AIoT device; or an owner identifier of the AIoT device.

[0049] In some implementations of the method and apparatuses described herein, the information of the AIoT data is obtained by the UE from an unencrypted part of the message from AIoT device.

[0050] In some implementations of the method and apparatuses described herein, the at least one AIoT-related policy rule may include at least one route selection description, wherein the at least one route selection description is associated with at least one of the following: data network information associated with the UE; data network information associated with at least one AIoT device; slice information associated with the UE; or slice information associated with the at least one AIoT device.

[0051] Some implementations of the method and apparatuses described herein may further include: establishing at least one PDU session based on the at least one AIoT-related policy rule. Determine the PDU session for the AIoT data may include: determining whether the information of the AIoT data matches the at least one PDU session based on the at least one AIoT-related policy rule; and in the case that the information of the AIoT data matches the at least one PDU session, determine a matched PDU session among the at least one PDU session as the PDU session; or in the case that the information of the AIoT data does not match the at least one PDU session, establish a PDU session based on the information of the AIoT data, wherein the PDU session is the established PDU session.

[0052] Some implementations of the method and apparatuses described herein may further include: transmitting, to a first apparatus, a policy rule enforcement report,  wherein the policy rule enforcement report may include an indication of a connection capability of AIoT communication.

[0053] In some implementations of the method and apparatuses described herein, the first apparatus implements a policy control function (PCF) , and the policy rule enforcement report is transmitted to the first apparatus via an AIoT function (AIoTF) or via a session management function (SMF) . In some implementations of the method and apparatuses described herein, the fifth apparatus implements a user plane function (UPF) .

[0054] In a fourth aspect of the solution, a fifth apparatus receives, from a user equipment (UE) , ambient internet-of-things (AIoT) data on a protocol data unit (PDU) session, wherein the PDU session follows at least one AIoT-related policy rule for the UE; and transmits, to an AIoT function (AIoTF) or to a sixth apparatus, the AIoT data.

[0055] In some implementations of the method and apparatuses described herein, the sixth apparatus implements an AIoT application function or an AIoT application server, and the fifth apparatus implements a user plane function (UPF) .

[0056] In a fourth aspect of the solution, a third apparatus receives, from a second apparatus, at least one of the following: an identifier of a user equipment (UE) ; at least one identifier of the at least one AIoT application; at least one AIoT device identifier of the at least one AIoT device; or at least one AIoT device group identifier associated with the at least one AIoT device. and transmits, to the second apparatus, at least one of the following: subscription data of the UE, wherein the UE is authorized to act as an ambient internet-of-things (AIoT) intermediate node; subscription data of at least one AIoT application; subscription data of at least one AIoT device; an indication that the UE is authorized to act as an AIoT intermediate node; or information of at least one AIoT service associated with the UE.

[0057] In some implementations of the method and apparatuses described herein, the at least one AIoT device identifier may include at least one of the following: at least one electronic product code of the at least one AIoT device; at least one tag identification (TID) of the at least one AIoT device; at least one operator identifier of the at least one AIoT device; at least one manufacturer identifier of the at least one AIoT device; or at least one owner identifier of the at least one AIoT device.

[0058] In some implementations of the method and apparatuses described herein, the  at least one AIoT device group identifier may include at least one of the following: at least one electronic product code of the at least one AIoT device; at least one TID of the at least one AIoT device; at least one operator identifier of the at least one AIoT device; at least one manufacturer identifier of the at least one AIoT device; or at least one owner identifier of the at least one AIoT device.

[0059] In some implementations of the method and apparatuses described herein, the subscription data of the UE may include at least one of the following: operator information of the UE; manufacturer information of the UE; owner information of the UE; information of at least one data network that the UE is subscribed to; information of at least one slice that the UE is subscribed to; or information of whether the UE is authorized to act as a reader.

[0060] In some implementations of the method and apparatuses described herein, the subscription data of the at least one AIoT application may include at least one of the following: an indication of whether the at least one AIoT application is allowed to use a service provided by a network; or a credential for network layer security of the at least one AIoT application.

[0061] In some implementations of the method and apparatuses described herein, the at least one AIoT application is allowed to use the service provided by the network. The indication of whether the at least one AIoT application is allowed to use the service provided by the network may include at least one of the following: at least one application type of the at least one AIoT application; or at least one identifier of the at least one AIoT application.

[0062] In some implementations of the method and apparatuses described herein, the second apparatus implements an access and mobility management function (AMF) serving the UE or an AIoT function (AIoTF) ; wherein the third apparatus implements a unified data management (UDM) or a unified data repository (UDR) .

[0063] It is to be understood that the summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.BRIEF DESCRIPTION OF THE DRAWINGS

[0064] Figs. 1A and 1B illustrates an example of a wireless communications system that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure.

[0065] Fig. 1C illustrates an example of a control plane protocol stack for AIoT topology 2 in accordance with aspects of the present disclosure.

[0066] Fig. 1D illustrates an example of a user plane protocol stack for AIoT topology 2 in accordance with aspects of the present disclosure.

[0067] Fig. 2A illustrates a signaling diagram illustrating an example process that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure.

[0068] Figs. 2B to 2C illustrate a signaling diagram illustrating an example process that supports generation of policy rules for AIoT data transmission in accordance with aspects of the present disclosure.

[0069] Fig. 3 illustrates a signaling diagram illustrating an example general overview process that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure.

[0070] Figs. 4A to 4C illustrate a signaling diagram illustrating an example process that supports generation of AIoT-related policy rules triggered by subscription data in accordance with aspects of the present disclosure, respectively.

[0071] Figs. 5A to 5B illustrate a signaling diagram illustrating an example process that supports generation of AIoT-related policy rules triggered by AIoT-related rule guidance information in accordance with aspects of the present disclosure, respectively.

[0072] Fig. 6 illustrates an example of a device that supports policy rules for AIoT data transmission in accordance with some aspects of the present disclosure.

[0073] Fig. 7 illustrates an example of a processor that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure.

[0074] Figs. 8 to 12 illustrate a flowchart of a method that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure, respectively.DETAILED DESCRIPTION

[0075] Principles of the present disclosure will now be described with reference to some embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. The disclosure described herein may be implemented in various manners other than the ones described below.

[0076] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0077] References in the present disclosure to “one embodiment, ” “an example embodiment, ” “an embodiment, ” “some embodiments, ” and the like indicate that the embodiment (s) described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment (s) . Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0078] It shall be understood that although the terms “first” and “second” or the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, a first element could also be termed as a second element, and similarly, a second element could also be termed as a first element, without departing from the scope of embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0079] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but  do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0080] As used herein, the term “communication network” refers to a network following any suitable communication standards, such as 5G new radio (NR) , LTE, LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) , and so on. Further, the communications between a UE and a network device in the communication network may be performed according to any suitable generation communication protocols, including but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the 4G, 4.5G, the 5G communication protocols, and / or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will also be future type communication technologies and systems in which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned systems.

[0081] As used herein, the term “network device” generally refers to a node in a communication network via which a UE can access the communication network and receive services therefrom. The network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , a radio access network (RAN) node, an evolved NodeB (eNodeB or eNB) , a NR NB (also referred to as a gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , an infrastructure device for a vehicle-to-everything (V2X) communication, a transmission and reception point (TRP) , a reception point (RP) , a remote radio head (RRH) , a relay, an integrated access and backhaul (IAB) node, a low power node such as a femto a base station (BS) , a pico BS, and so forth, depending on the applied terminology and technology. The network device may further refer to a network function (NF) in the core network, for example, a service management function (SMF) , an access and mobility management function (AMF) , a policy control function (PCF) , a user plane function (UPF) or devices with same function in future network architectures, and so forth.

[0082] As used herein, the term “user equipment (UE) ” generally refers to any end device that may be capable of wireless communications. By way of example rather than a limitation, a UE may also be referred to as a communication device, a terminal device,  an end user device, a subscriber station (SS) , an unmanned aerial vehicle (UAV) , a portable subscriber station, a mobile station (MS) , or an access terminal (AT) . The UE may include, but is not limited to, a mobile phone, a cellular phone, a smart phone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet, a wearable UE, a personal digital assistant (PDA) , a portable computer, a desktop computer, an image capture UE such as a digital camera, a gaming UE, a music storage and playback appliance, a vehicle-mounted wireless UE, a wireless endpoint, a mobile station, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , a USB dongle, a smart device, wireless customer-premises equipment (CPE) , an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device (for example, a remote surgery device) , an industrial device (for example, a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. In the following description, the terms: “UE, ” “communication device, ” “terminal, ” and “UE, ” may be used interchangeably.

[0083] As used herein, the term “AIoT device” refers to a device without batteries or with limited energy storage capabilities. For the AIoT device, energy is provided by harvesting radio waves, light, motion, heat, or any other suitable source. The AIoT device can also be called a zero-power terminal, a near-zero power terminal, a passive IoT device, an ambient backscatter communication (AmBC) device, a tag, etc. Compared with low-power and wide-coverage services, such as narrow band (NB) IoT, and enhanced machine type communication (eMTC) , AIoT has lower complexity and lower power consumption, and is suitable for more application scenarios.

[0084] For inventory and read command of the AIoT devices, the obtained data / information needs to be transmitted from the AIoT devices to the service consumer (e.g., AIoT APP) via a reader. Such data transmission can either be done via the control plane or via the user plane. Under AIoT topology 2 when a UE is acting as the AIoT reader, it is natural to reuse the PDU session to forward the AIoT data via the user plane. In other words, the AIoT data may be transmitted from the UE to the NG-RAN node and then to the UPF and then to the AIoTF via the N6 (which is a new N6 interface between UPF and AIoTF-UP) and finally to the AIoT application server (AS) , or directly from UPF to the AIoT application server. In the PDU session scheme for transmitting non-AIoT data, a PDU session is initiated by a UE client to forward the data between the UE  and AS. When the application data comes to the UE, the UE can determine which PDU session to use or may establish a new PDU session, to route for the uplink data transmission. In the PDU session scheme for transmitting non-AIoT data, this process is done by the PCF providing user route selection policy (URSP) rules to the UE and guide the UE on how to forward the uplink data received from the UE application. Similarly, for AIoT data received from AIoT devices, the UE reader needs to determine the correspondence / mapping between the UL AIoT data and the PDU sessions and route the UL data onto a proper PDU session. It is necessary for the PCF to generate URSP rules for AIoT data transmission under AIoT topology 2.

[0085] In view of the above, the present disclosure provides a solution that supports policy rules for AIoT data transmission. In this solution, the PCF may receive AIoT related information associated with the UE from the other network nodes and then generate at least one AIoT-related policy rule for the UE based on the AIoT related information. The UE may determine a protocol data unit (PDU) session for AIoT data based on the at least one AIoT-related policy rule generated by the PCF and information of the AIoT data, and then transmit the AIoT data on the PDU session. Therefore, if a UE is authorized to act as an AIoT intermediate node, the UE may be configured with AIoT-related policy rule (s) and may route AIoT data on a PDU session determined for the AIoT data based on the AIoT-related policy rule (s) . In this way, a scheme for routing data from AIoT data to a related PDU session under AIoT topology 2 is designed.

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

[0087] Fig. 1A illustrates an example of a wireless communications system 100A that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure. The wireless communications system 100A may include one or more network entities 102 (also referred to as network equipment (NE) ) , one or more terminal devices or UEs 104, a core network 106, and a packet data network 108. The wireless communications system 100A may support various radio access technologies. In some implementations, the wireless communications system 100A 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 100A may be a 5G network, such as an NR network. In other implementations, the wireless communications system 100A  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 100A may support radio access technologies beyond 5G. Additionally, the wireless communications system 100A may support technologies, such as time division multiple access (TDMA) , frequency division multiple access (FDMA) , or code division multiple access (CDMA) , etc.

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

[0089] A network entity 102 may provide a geographic coverage area 112 for which the network entity 102 may support services (e.g., voice, video, packet data, messaging, broadcast, etc. ) for one or more UEs 104 within the geographic coverage area 112. For example, a network entity 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, a network entity 102 may be moveable, for example, a satellite associated with a non-terrestrial network. 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 112 may be associated with different network entities 102. Information and signals described herein may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0090] The one or more UEs 104 may be dispersed throughout a geographic region  of the wireless communications system 100A. A UE 104 may include or may be referred to as a mobile device, a wireless device, a remote device, a remote unit, a handheld device, or a subscriber 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. In some implementations, a UE 104 may be stationary in the wireless communications system 100A. In some other implementations, a UE 104 may be mobile in the wireless communications system 100A.

[0091] The one or more UEs 104 may be devices in different forms or having different capabilities. Some examples of UEs 104 are illustrated in FIG. 1. A UE 104 may be capable of communicating with various types of devices, such as the network entities 102, other UEs 104, or network equipment (e.g., the core network 106, the packet data network 108, a relay device, an integrated access and backhaul (IAB) node, or another network equipment) , as shown in FIG. 1. Additionally, or alternatively, a UE 104 may support communication with other network entities 102 or UEs 104, which may act as relays in the wireless communications system 100A.

[0092] A UE 104 may also be able to support wireless communication directly with other UEs 104 over a communication link 114. 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.

[0093] A network entity 102 may support communications with the core network 106, or with another network entity 102, or both. For example, a network entity 102 may interface with the core network 106 through one or more backhaul links 116 (e.g., via an S1, N2, N2, or another network interface) . The network entities 102 may communicate with each other over the backhaul links 116 (e.g., via an X2, Xn, or another network interface) . In some implementations, the network entities 102 may communicate with each other directly (e.g., between the network entities 102) . In some other implementations, the network entities 102 may communicate with each other or indirectly  (e.g., via the core network 106) . In some implementations, one or more network entities 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) .

[0094] In some implementations, a network entity 102 may be configured in a disaggregated architecture, which may be configured to utilize a protocol stack physically or logically distributed among two or more network entities 102, such as an integrated access backhaul (IAB) network, an open RAN (O-RAN) (e.g., a network configuration sponsored by the O-RAN Alliance) , or a virtualized RAN (vRAN) (e.g., a cloud RAN (C-RAN) ) . For example, a network entity 102 may include one or more of a central unit (CU) , a distributed unit (DU) , a radio unit (RU) , a RAN Intelligent Controller (RIC) (e.g., a Near-Real Time RIC (Near-RT RIC) , a Non-Real Time RIC (Non-RT RIC) ) , a Service Management and Orchestration (SMO) system, or any combination thereof.

[0095] An RU may also be referred to as a radio head, a smart radio head, a remote radio head (RRH) , a remote radio unit (RRU) , or a transmission reception point (TRP) . One or more components of the network entities 102 in a disaggregated RAN architecture may be co-located, or one or more components of the network entities 102 may be located in distributed locations (e.g., separate physical locations) . In some implementations, one or more network entities 102 of a disaggregated RAN architecture may be implemented as virtual units (e.g., a virtual CU (VCU) , a virtual DU (VDU) , a virtual RU (VRU) ) .

[0096] Split of functionality between a CU, a DU, and an RU may be flexible and may support different functionalities depending upon which functions (e.g., network layer functions, protocol layer functions, baseband functions, radio frequency functions, and any combinations thereof) are performed at a CU, a DU, or an RU. For example, a functional split of a protocol stack may be employed between a CU and a DU such that the CU may support one or more layers of the protocol stack and the DU may support one or more different layers of the protocol stack. In some implementations, the CU may host upper protocol layer (e.g., a layer 3 (L3) , a layer 2 (L2) ) functionality and signaling (e.g., Radio Resource Control (RRC) , service data adaption protocol (SDAP) , Packet Data Convergence Protocol (PDCP) ) . The CU may be connected to one or more DUsor RUs,  and the one or more DUs or RUs may host lower protocol layers, such as a layer 1 (L1) (e.g., physical (PHY) layer) or an L2 (e.g., radio link control (RLC) layer, medium access control (MAC) layer) functionality and signaling, and may each be at least partially controlled by the CU 160.

[0097] Additionally, or alternatively, a functional split of the protocol stack may be employed between a DU and an RU such that the DU may support one or more layers of the protocol stack and the RU may support one or more different layers of the protocol stack. The DU may support one or multiple different cells (e.g., via one or more RUs) . In some implementations, a functional split between a CU and a DU, or between a DU and an RU may be within a protocol layer (e.g., some functions for a protocol layer may be performed by one of a CU, a DU, or an RU, while other functions of the protocol layer are performed by a different one of the CU, the DU, or the RU) .

[0098] A CU may be functionally split further into CU control plane (CU-CP) and CU user plane (CU-UP) functions. A CU may be connected to one or more DUs via a midhaul communication link (e.g., F1, F1-c, F1-u) , and a DU may be connected to one or more RUs via a fronthaul communication link (e.g., open fronthaul (FH) interface) . In some implementations, a midhaul communication link or a fronthaul communication link may be implemented in accordance with an interface (e.g., a channel) between layers of a protocol stack supported by respective network entities 102 that are in communication via such communication links.

[0099] The core network 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The core network 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 network entities 102 associated with the core network 106.

[0100] The core network 106 may communicate with the packet data network 108  over one or more backhaul links 116 (e.g., via an S1, N2, N2, or another network interface) . The packet data network 108 may include an application (APP) server 118. In some implementations, one or more UEs 104 may communicate with the application server 118. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the core network 106 via a network entity 102. The core network 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server 118 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 core network 106 (e.g., one or more network functions of the core network 106) .

[0101] In the wireless communications system 100A, the network entities 102 and the UEs 104 may use resources of the wireless communications system 100A (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 network entities 102 and the UEs 104 may support different resource structures. For example, the network entities 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the network entities 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 network entities 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures) . The network entities 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0102] One or more numerologies may be supported in the wireless communications system 100A, 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.

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

[0104] 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 100A. 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.

[0105] In the wireless communications system 100A, 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 100A 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 network entities 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 network entities 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 network entities 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

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

[0107] Fig. 1B illustrates an example of a wireless communications system 100B that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure. Generally, Fig. 1B illustrates network entities or network functions (NFs) in the core network 106 as shown in Fig. 1A.

[0108] As shown in Fig. 1B, the core network 106 may at least comprise an access and mobility management function (AMF) 120, a session management function (SMF) 122, an AIoT function (AIoTF) 124, a policy control function (PCF) 126, a unified data management (UDM) 128, a unified data repository (UDR) 130, a network exposure function (NEF) 132, and a user plane function (UPF) 136.

[0109] In some implementations, the AIoTF 124 may be a dedicated NF in the 5GC that handles the AIoT related service. Alternatively, the AIoTF 124 may be co-located with the AMF 120.

[0110] In some implementations, the AIoTF 124 may implement at least one of the following functions:

[0111] -Receive and transmit AIoT related data / signalling from / to the AIoT APP server 132;

[0112] -Select appropriate UE / RAN reader for the transmission of AIoT data / signalling to the target location / area;

[0113] -Receive a registration request from the reader (such as the UE 104) and store information about the reader and information about the associated AIoT devices; or

[0114] -Establish an AIoT session with the AIoT AF / AS for transmission.

[0115] -Establish an AIoT session with the UE / RAN reader for transmission.

[0116] -Authorize and authenticate the AIoT device and reader by interacting with UDM and AUSF.

[0117] As shown in Fig. 1B, the wireless communications system 100B also comprises the RAN node 102, the UE 104, an application function (AF) 134, at least one AIoT device 140 and the DN 108. The DN 108 may include at least one AIoT application server (AS) 138.

[0118] In some implementations, the at least one AIoT device 140 communicates bidirectionally with an intermediate node between the AIoT device 140 and the RAN node 102. The intermediate node transfers AIoT data and / or signalling between the RAN node 102 and the at least one AIoT device 140. The UE 104 may act as the intermediate node between the AIoT device 140 and the RAN node 102.

[0119] In some implementations, the AF 134 may support interaction with the core network 106 to provide services, such as influencing data routing decisions, policy control functions or providing third-party services to the network.

[0120] It shall be noted that the name of each NF as described above is only exemplary. For example, the AIoTF 124 may be named differently.

[0121] It shall be also noted that although one AIoT device is shown in Fig. 1B by way of example, the wireless communications system 100B may comprise more than one AIoT devices.

[0122] Fig. 1C illustrates an example of a control plane protocol stack for AIoT Topology 2 in accordance with aspects of the present disclosure. As shown in Fig. 1C, there can be a direct connection between the UE 104 and the AIoTF 124 in the 5GC via an AIoT Layer. Based on this, once the UE 104 has registered at the AIoTF 124 via the AMF 120, the UE 104 and the AIoTF 124can communicate with each other directly, i.e., the AMF 120 transparently transfers a message between the AIoTF 124 and the UE 104. The UE 104 can have an N1 NAS layer connection with the AMF 120, and the AMF 120 can have an interface Nxx based on the service-based interface (SBI) with the AIoTF 124,  just like the AMF 120 interacting with other 5GC NF.

[0123] Fig. 1D illustrates an example of a user plane protocol stack for AIoT Topology 2 in accordance with aspects of the present disclosure. As shown in Fig. 1D, the UE 104 can communicate with the UPF 134 via the PDU layer. Instead of directly communicating with the AIoT AS 138, the UPF 134 will forward the user plane data to the AIoTF 124 first for data inspection / authentication via a new N6 interface, and then the AIoTF 124 can expose the AIoT data to the AIoT AS 138. It should be noted that there is a UE AIoT layer connection between the UE 104 and the AIoTF 124, and an AIoT device NAS layer between AIoT device 140 and the AIoTF 124.

[0124] Fig. 2A illustrates a signaling diagram illustrating an example process 200A that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure. The process 200A may involve a first apparatus 201, a second apparatus 202, a fifth apparatus 205, a UE 104 and at least one AIoT device 206. In some implementations, the first apparatus 201 may perform the PCF 126 in Fig. 1B. Alternatively, the first apparatus may perform other network functions than the PCF 126 in Fig. 1B. In some implementations, the second apparatus may perform one of the AMF 120, the AIoTF 124, the UDM 128, the UDR 130, the AF 134 or the AIoT AS 138 in Fig. 1B. Alternatively, the second apparatus may perform other network functions not shown in FIG. 1B, e.g., a location management function (LMF) . In some implementations, the fifth apparatus 205 may perform the UPF 136 in Fig. 1B. Alternatively, the first apparatus may perform other network functions than the UPF 136 in Fig. 1B. It is to be understood that the steps and the order of the steps in Fig. 2A are merely for illustration, and not for limitation. It is to be understood that the process 200A may further include additional blocks not shown and / or omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[0125] As shown in Fig. 2A, the second apparatus 202 transmits (211) AIoT related information 212 associated with the UE 104 to the first apparatus 201. The first apparatus 201 receives (213) the AIoT related information 212 associated with the UE 104 from the second apparatus 202. The first apparatus 201 determines (214) at least one AIoT-related policy rule 216 for the UE 104 based on the AIoT related information 212. The first apparatus 201 then transmits (215) the at least one AIoT-related policy rule 216 to the UE 104. The UE 104 receives (217) the at least one AIoT-related policy rule 216 for the UE  104 from the first apparatus 201. When the AIoT device 206 transmits (218) a message 219 carrying AIoT data 223 to the UE 104, the UE 104 receives (220) the message 219 carrying the AIoT data 223 and determines (221) a protocol data unit (PDU) session for the AIoT data 223. The PDU session for routing the AIoT data 223 is determined based on the at least one AIoT-related policy rule 216 and information of the AIoT data 223. The UE 104 then transmits (222) the AIoT data 223 on the PDU session to the fifth apparatus 205. The fifth apparatus 205 receives (224) the AIoT data 223 on the PDU session. The fifth apparatus 205 may then transmit the AIoT data 223 towards the specific service consumer (e.g., the AF or the AIoT AS) .

[0126] When transmitting UL data, the URSP rules will be provided to the UE 104 from a PCF to help UE 104 determine on how to route the UL data from an UE application. The URSP rule is composed of two main parts, i.e., Traffic descriptor and Route Selection descriptor. Traffic descriptor is used to determine which application or which type of service this PDU session is related to. Route selection descriptor is used to determine the PDU session related characteristic, e.g., PDU session type, session and service continuity (SSC) mode, data network name (DNN) and single network slice selection assistance information (S-NSSAI) that the PDU session corresponds to. The UE 104 will receive a set of URSP rules in a prioritized order and by comparing the received URSP rules with the UL traffic, the UE 104 will be able to offload the data onto the corresponding PDU sessions, or initiate the PDU session establishment procedure if there is no match between the existing PDU sessions established based on the URSP rules and the UL traffic.

[0127] Table 1 shows Traffic descriptor components of URSP rule. As shown in Table 1, the traffic descriptor gives the traffic / application characteristic of the URSP rule. When the UE 104 receives the UPSP rules from the PCF and detects the UL traffic from an UE application, the UE 104 evaluates the URSP rules in the order of Rule Precedence and determines whether the application is matching any IE of the traffic descriptor in the URSP rule. If a URSP rule is determined to be applicable for the detected application, e.g., matching the Application descriptors (same application etc. ) , then the UE 104 will continue to determine the Route Selection descriptor. If one of the PDU sessions matches the Route Selection descriptor, then the UL data from that application will be routed to this PDU session.

[0128] Table 1 Traffic descriptor components of URSP rule

[0129] For AIoT data transmission over PDU sessions, the URSP rules need to be redesigned or improved and the AIoT related parameters need to be added in order for the UE 104 acting as an intermediate reader to match and route the UL AIoT data from AIoT devices onto the PDU session towards the specific service consumer (e.g., the AF or the AIoT AS) . Therefore, there is a need to define some components within the Traffic Descriptor for determining corresponding PDU session for AIoT data transmission, i.e., identifying the traffic that matches the AIoT traffic related parameters within the URSP rules.

[0130] In some embodiments, the at least one AIoT-related policy rule 216 may include at least one AIoT-related traffic descriptor component. In some embodiments, each of the at least one AIoT-related traffic descriptor component is associated with at least one data network or at least one slice that is used to determine a PDU session for routing AIoT data.

[0131] In some embodiments, the at least one AIoT-related traffic descriptor component may include at least one operator identifier of at least one AIoT device. For example, the AIoT device operator ID may be used as a traffic descriptor component in the USRP rules. The operator ID of the AIoT device may be used to determine which  operator operates the AIoT device.

[0132] In some embodiments, the at least one AIoT-related traffic descriptor component may include an operator identifier of the UE 104. For example, the UE operator ID may be used as a traffic descriptor component in the USRP rules. The operator ID of the UE 104 may be used to determine which operator operates the UE 104 which serves as an intermediate reader.

[0133] In some embodiments, the operator identifier may be implemented as a public land mobile network (PLMN) identifier used to identify the home mobile network operator (MNO) . In some embodiments, the at least one AIoT-related traffic descriptor component may include an operator identifier. If the USRP rule comprises an operator identifier as the traffic descriptor, the AIoT traffic matches the traffic descriptor when the operator information in the AIoT traffic is the same as the operator identifier in the USRP rule. The operator identifier in the USRP rule may be generated based on the reader information or the device information.

[0134] In some embodiments, the at least one AIoT-related traffic descriptor component may include at least one manufacturer identifier of at least one AIoT device. For example, the AIoT device manufacturer ID may be used as a traffic descriptor component in the USRP rules. The manufacturer ID of the AIoT device may be used to determine which manufacturer produces / makes / manufactures the AIoT device.

[0135] In some embodiments, the at least one AIoT-related traffic descriptor component may include a manufacturer identifier of the UE 104. For example, the UE manufacturer ID may be used as a traffic descriptor component in the USRP rules. The manufacturer ID of the UE 104 may be used to determine which manufacturer produces / makes / manufactures the UE 104 which serves as an intermediate reader.

[0136] In some embodiments, the manufacturer identifier may be implemented as a manufacturer ID or manufacturer name. In some embodiments, the at least one AIoT-related traffic descriptor component may include a manufacturer identifier. If the USRP rule comprises a manufacturer identifier as the traffic descriptor, the AIoT traffic matches the traffic descriptor when the manufacturer information in the AIoT traffic is the same as the manufacturer identifier in the USRP rule. The manufacturer identifier in the USRP rule may be generated based on the reader information or the device information.

[0137] In some embodiments, the at least one AIoT-related traffic descriptor component may include at least one owner identifier of at least one AIoT device. For example, the AIoT device owner ID may be used as a traffic descriptor component in the USRP rules. The owner ID of the AIoT device may be used to determine which company owns the AIoT device.

[0138] In some embodiments, the at least one AIoT-related traffic descriptor component may include an owner identifier of the UE 104. For example, the UE owner ID may be used as a traffic descriptor component in the USRP rules. The owner ID of the UE 104 may be used to determine which company owns the UE 104 which serves as an intermediate reader. If the UL AIoT data matches the UE owner ID in the USRP, the UL AIoT data may be routed to the PDU session that the UE owner ID is associated with.

[0139] In some embodiments, the owner identifier may be implemented as an owner ID or owner name. In some embodiments, the owner identifier may be implemented as an application ID if a certain application can represent the company that owns the device or the UE reader. In some embodiments, the at least one AIoT-related traffic descriptor component may include an owner identifier. If the USRP rule comprises an owner identifier as the traffic descriptor, the AIoT traffic matches the traffic descriptor when the owner information in the AIoT traffic is the same as the owner identifier in the USRP rule. The owner identifier in the USRP rule may be generated based on the reader information or the device information.

[0140] In some implementations, the DNN and the S-NSSAI may be associated with a certain application. The UE reader and the AIoT device (s) need to be subscribed to the same DNN / S-NSSAI so that the PCF can forward the URSP rules to the UE within the same slice / network.

[0141] In some embodiments, the at least one AIoT-related traffic descriptor component may include at least one identifier of at least one AIoT application. For example, the AIoT application ID may be used to determine the application that the AIoT device belongs to or the AIoT service belongs to. In some implementations, the AIoT application ID can also be regarded as the Application descriptor shown in Table 1. Each application is associated with a certain DNN / slice that can be used to determine the route selection descriptor.

[0142] In some embodiments, the at least one AIoT-related traffic descriptor  component may include at least one AIoT device identifier. The AIoT device identifier may be implemented in various types. For example, the at least one AIoT device identifier may include at least one electronic product code of at least one AIoT device. Alternatively or additionally, the at least one AIoT device identifier may include at least one tag identification (TID) of at least one AIoT device. Alternatively or additionally, the at least one AIoT device identifier may include at least one operator identifier of at least one AIoT device. Alternatively or additionally, the at least one AIoT device identifier may include at least one manufacturer identifier of at least one AIoT device. Alternatively or additionally, the at least one AIoT device identifier may include at least one owner identifier of at least one AIoT device.

[0143] In some embodiments, the at least one AIoT-related traffic descriptor component may include at least one AIoT device group identifier. The AIoT device group identifier may be implemented in various types. For example, the at least one AIoT device group identifier may include at least one electronic product code (EPC) of at least one AIoT device. Alternatively or additionally, the at least one AIoT device group identifier may include at least one tag identification (TID) of at least one AIoT device. Alternatively or additionally, the at least one AIoT device group identifier may include at least one operator identifier of at least one AIoT device. Alternatively or additionally, the at least one AIoT device group identifier may include at least one manufacturer identifier of at least one AIoT device. Alternatively or additionally, the at least one AIoT device group identifier may include at least one owner identifier of at least one AIoT device. In some implementations, the AIoT device group identifier may be provided as a separate identifier with the AIoT device identifier. In some implementations, the AIoT device group identifier may be provided as a part of the AIoT device identifier.

[0144] The AIoT device identifier or the AIoT device group identifier, if provided as a traffic descriptor component, may be matched against the identifier information provided by the AIoT device. When receiving the data from a certain AIoT device, the UE reader can compare the device ID / group ID of the AIoT device with the traffic descriptor of the URSP rule. If there is a match, then the data from this AIoT device will be routed to the corresponding PDU session that the AIoT device or AIoT device group is associated with. In some embodiments, the AIoT device identifier or the AIoT device group identifier may be mutually exclusive to other information elements within the traffic descriptors of the URSP rule. In other words, if the AIoT device identifier or the  AIoT device group identifier is included in a URSP rule, no other traffic descriptor components are supported in the same URSP rule.

[0145] In some embodiments, the at least one AIoT-related traffic descriptor component may include a connection capability of AIoT communication. Alternatively or additionally, the at least one AIoT-related traffic descriptor component may include a traffic category of AIoT communication. When such indication or information is provided in the AIoT data and detected by the UE reader, the UE reader will compare with the URSP rules and determine the PDU session for AIoT communication.

[0146] Table 2 shows some specific examples of AIoT traffic related parameters that can be added as components for Traffic Descriptor to represent the characteristics of the AIoT traffic. Each of the AIoT traffic related parameters is supposed to be associated with the DNN / S-NSSAI for PDU session traffic routing. In some embodiments, no more than two components of the Traffic Descriptor will be included within one URSP rule.

[0147] Table 2 Enhancement of URSP rules regarding AIoT transmission

[0148] For route selection description, the DNN and the S-NSSAI that the UE and / or AIoT devices are subscribed to, or the UE and / or AIoT devices belong to, can also be used to generate the route selection description of the URSP rules by the PCF.

[0149] With some embodiments of the present disclosure, based on the AIoT-related parameters within the URSP rules, the data from AIoT devices may be routed to the corresponding PDU session under topology 2.

[0150] Hereinbefore, some embodiments are described to improve the URSP rule with AIoT related parameters. Hereinafter, some embodiments will be described regarding how to generate the URSP rule for AIoT data transmission. The PCF needs to be triggered by some inputs to generate the URSP rules that have AIoT related parameters included. This input can either be from UDM / UDR that includes at least one of the UE subscription data, application subscription data or AIoT device subscription data, or from the AIoT application as guidance information for URSP rule determination.

[0151] In some options, the generation of the URSP rules may be triggered by inputs including subscription data from the UDR or the UDM. In some implementations, the second apparatus 202 may be implemented as a UDM or a UDR. In other words, the UDR or the UDM may transmit the subscription data to trigger the first apparatus 202 (e.g., a PCF) to generate the URSP rules for AIoT transmission. Alternatively, the second apparatus 202 may be implemented as a AMF serving the UE 104 or an AIoTF which may acquire the subscription data from the UDR or the UDM or a LMF that has location information of the UE 104.

[0152] In some embodiments, the AIoT related information 212 may include subscription data of the UE 104. In some implementations, the subscription data of the  UE 104 may include operator information of the UE 104. Alternatively or additionally, the subscription data of the UE 104 may include manufacturer information of the UE 104. Alternatively or additionally, the subscription data of the UE 104 may include owner information of the UE 104. Alternatively or additionally, the subscription data of the UE 104 may include information of at least one data network that the UE 104 is subscribed to. Alternatively or additionally, the subscription data of the UE 104 may include information of at least one slice that the UE 104 is subscribed to. Alternatively or additionally, the subscription data of the UE 104 may include information of whether the UE is authorized to act as a reader.

[0153] In some embodiments, the AIoT related information 212 may further include subscription data of at least one AIoT application. In some implementations, the subscription data of the at least one AIoT application may include an indication of whether the at least one AIoT application is allowed to use a service provided by a network. For example, if the at least one AIoT application is allowed to use the service provided by the network, the indication of whether the at least one AIoT application is allowed to use the service provided by the network may include at least one application type of the at least one AIoT application and / or at least one identifier of the at least one AIoT application. Alternatively or additionally, the subscription data of the at least one AIoT application may include a credential for network layer security of the at least one AIoT application.

[0154] Alternatively or additionally, the AIoT related information 212 may include subscription data of at least one AIoT device. Alternatively or additionally, the AIoT related information 212 may include an identifier of the UE 104. Alternatively or additionally, the AIoT related information 212 may include an AIoT-related indication. Alternatively or additionally, the AIoT related information 212 may include an indication of subscribing policy update notification associated with the UE 104.

[0155] Alternatively or additionally, the AIoT related information 212 may include location information of the UE 104. The second apparatus 202 may be implemented as an AMF serving the UE 104 or a LMF that has location information of the UE 104.

[0156] In some embodiments, the AIoT related information 212 may be determined by the second apparatus 202 based on the inputs from the UDM or the UDR. Fig. 2B illustrates a signaling diagram illustrating an example process 200B that supports  generation of policy rules for AIoT data transmission in accordance with aspects of the present disclosure. The process 200B may involve the first apparatus 201, the second apparatus 202 and a third apparatus 203. In some implementations, the first apparatus 201 may perform the PCF 126 in Fig. 1B. Alternatively, the first apparatus 201 may perform other network functions than the PCF 126 in Fig. 1B. In some implementations, the second apparatus 202 may perform the AMF 120 or the AIoTF 124 in Fig. 1B. Alternatively, the second apparatus 202 may perform other network functions than the AMF 120 or the AIoTF 124 in FIG. 1B, e.g., or a LMF that has location information of the UE 104. In some implementations, the third apparatus 203 may perform the UDM 128 or the UDR 130 in Fig. 1B. Alternatively, the third apparatus 203 may perform other network functions than the UDM 128 or the UDR 130 in FIG. 1B. The process 200B may be considered as an example implementation of a part of the process 200A. The same reference numerals are used to denote the elements or components described in Fig. 2B having the same operations as the elements or components described in Fig. 2A, and detailed description thereof will be omitted. It is to be understood that the steps and the order of the steps in Fig. 2B are merely for illustration, and not for limitation. It is to be understood that the process 200B may further include additional blocks not shown and / or omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[0157] As shown in the example process 200B, the second apparatus 202 may transmit (225) the UE identifier 226 to the third apparatus 203. The third apparatus 203 may receive (227) the UE identifier 226 and transmit (228) the subscription data 229 of the UE to the second apparatus 202. The second apparatus 202 may receive (230) the subscription data 229 of the UE and provide the AIoT related information 212 including the subscription data 229 of the UE to the first apparatus 201 to determine the at least one AIoT-related policy rule for the UE.

[0158] Alternatively or additionally, the second apparatus 202 may transmit at least one AIoT application identifier to the third apparatus 203 and receive subscription data of the at least one AIoT application. The at least one AIoT-related policy rule for the UE may be determined at least based on the subscription data of the at least one AIoT application.

[0159] Alternatively or additionally, the second apparatus 202 may transmit at least  one AIoT device identifier to the third apparatus 203 and receive subscription data of the at least one AIoT device. The at least one AIoT-related policy rule for the UE may be determined at least based on the subscription data of the at least one AIoT device. In some embodiments, the second apparatus 202 may transmit at least one AIoT device group identifier to the third apparatus 203 and receive subscription data of the at least one AIoT device group. The at least one AIoT-related policy rule for the UE may be determined at least based on the subscription data of the at least one AIoT device group.

[0160] In some embodiments, the second apparatus 202 may also receive an indication that the UE is authorized to act as an AIoT intermediate node. Alternatively or additionally, the second apparatus 202 may receive information of at least one AIoT service associated with the UE. The second apparatus 202 may determine the AIoT related information 212 based on the inputs from the third apparatus 203 and transmit the AIoT related information 212 to the first apparatus 201 to trigger the first apparatus 201 to determine the at least one AIoT-related policy rule for the UE.

[0161] In some embodiments, the second apparatus 202 may receive a policy selection identifier (PSI) from the UE. The second apparatus 202 may determine whether policy updating is needed for the UE at least based on the PSI and the subscription data of the UE. If policy updating is needed for the UE, the second apparatus 202 may transmit the AIoT related information 212 to the first apparatus 201.

[0162] Turning back to Fig. 2A, in some options, the generation of the URSP rules may be triggered by inputs including guidance information from the AF or the AIoT AS. In some implementations, the second apparatus 202 may be implemented as an AF or an AIoT AS. In other words, the AF or the AIoT AS may transmit the guidance information to trigger the first apparatus 202 (e.g., a PCF) to generate the URSP rules for AIoT transmission. Alternatively, the second apparatus 202 may be implemented as a AMF serving the UE 104 or an AIoTF which may acquire the guidance information from the AF or the AIoT AS.

[0163] In some embodiments, the AIoT related information 212 may include AIoT-related rule guidance information. In some implementations, the AIoT-related rule guidance information may include at least one of the following: at least one identifier of at least one AIoT application; at least one AIoT device identifier; at least one AIoT device group identifier; at least one operator identifier of at least one AIoT device; at least one  manufacturer identifier of at least one AIoT device; at least one owner identifier of at least one AIoT device; operator information of the UE 104; manufacturer information of the UE 104; owner information of the UE 104; data network information; or slice information.

[0164] In some embodiments, the AIoT related information 212 may further include an identifier of the UE 104. Alternatively or additionally, the AIoT related information 212 may further include an AIoT-related indication. Alternatively or additionally, the AIoT related information 212 may further include an indication of subscribing policy update notification associated with the UE.

[0165] In some embodiments, the AIoT related information 212 may be determined by the second apparatus 202 based on the inputs from the AF or the AIoT AS. Fig. 2C illustrates a signaling diagram illustrating an example process 200C that supports generation of policy rules for AIoT data transmission in accordance with aspects of the present disclosure. The process 200C may involve the first apparatus 201, the second apparatus 202 and a fourth apparatus 204. In some implementations, the first apparatus 201 201 may perform the PCF 126 in Fig. 1B. Alternatively, the first apparatus 201 may perform other network functions than the PCF 126 in Fig. 1B. In some implementations, the second apparatus 202 may perform the AMF 120 or the AIoTF 124 in Fig. 1B. In some implementations, the fourth apparatus 204 may perform the AF 134 or the AIoT AS 138 in Fig. 1B. Alternatively, the third apparatus 204 may perform other network functions than the AF 134 or the AIoT AS 138 in FIG. 1B. The process 200C may be considered as an example implementation of a part of the process 200A. The same reference numerals are used to denote the elements or components described in Fig. 2C having the same operations as the elements or components described in Fig. 2A, and detailed description thereof will be omitted. It is to be understood that the steps and the order of the steps in Fig. 2C are merely for illustration, and not for limitation. It is to be understood that the process 200C may further include additional blocks not shown and / or omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[0166] As shown in the example process 200C, the fourth apparatus 204 may transmit (231) the AIoT related rule guidance information 232 to the second apparatus 202. The second apparatus 202 may receive (233) the AIoT related rule guidance information 232  and determine (234) whether to accept the AIoT-related rule guidance information based on the subscription data of the UE. If the at least one of data network information or slice information does not comply with the subscription data of the UE 104, the AIoT-related rule guidance information may be rejected. If the second apparatus 202 determines to accept the AIoT-related rule guidance information, the second apparatus 202 may provide the AIoT related information 212 including the AIoT-related rule guidance information 232 to the first apparatus 201 to determine the at least one AIoT-related policy rule for the UE.

[0167] In some embodiments, the second apparatus 202 may receive a PSI from the UE. The second apparatus 202 may determine whether policy updating is needed for the UE at least based on the PSI and at least one of the subscription data of the UE or the AIoT-related rule guidance information 232 received from the fourth apparatus 204. If policy updating is needed for the UE, the second apparatus 202 may transmit the AIoT related information 212 to the first apparatus 201.

[0168] Turning back to Fig. 2A, in addition to the at least one AIoT-related traffic descriptor component, the at least one AIoT-related policy rule 216 may also include at least one route selection description. In some embodiments, the at least one route selection description may be determined based on data network information associated with the UE 104. Alternatively or additionally, the at least one route selection description may be determined based on data network information associated with at least one AIoT device. Alternatively or additionally, the at least one route selection description may be determined based on slice information associated with the UE 104. Alternatively or additionally, the at least one route selection description may be determined based on slice information associated with the at least one AIoT device.

[0169] Based on the message 219 carrying the AIoT data 223 received from the AIoT device 206, the UE 104 may obtain information of the AIoT data 223 from an unencrypted part of the message 219. Examples of the information of the AIoT data 223 may include at least one of the following: an AIoT device identifier of the AIoT device 206; an AIoT device group identifier of the AIoT device 206; an operator identifier of the AIoT device 206; a manufacturer identifier of the AIoT device 206; an owner identifier of the AIoT device 206; an identifier of the AIoT application; or a traffic category of AIoT communication. In some embodiments, the AIoT device identifier may include at least  one of the following: an EPC of the AIoT device 206; a TID of the AIoT device 206; an operator identifier of the AIoT device 206; a manufacturer identifier of the AIoT device 206; or an owner identifier of the AIoT device 206.

[0170] After receiving the at least one AIoT-related policy rule 216 for the UE 104 from the first apparatus 201, the UE 104 may establish at least one PDU session based on the at least one AIoT-related policy rule 216. After receiving the message 219 carrying the AIoT data 223, when determine the PDU session for the AIoT data 223, the UE 104 may determine whether the information of the AIoT data 223 matches the at least one PDU session based on the at least one AIoT-related policy rule 216. If the information of the AIoT data 223 matches the at least one PDU session, the UE 104 may determine a matched PDU session among the at least one PDU session as the PDU session for routing the AIoT data 223. If the information of the AIoT data 223 does not match the at least one PDU session, the UE 104 may determine establish a PDU session based on the information of the AIoT data 223 and the established PDU session is used for routing the AIoT data 223.

[0171] In some embodiments, after receiving the AIoT data 223 on the PDU session from the UE 104, the fifth apparatus 205 may transmit the AIoT data 223 to a sixth apparatus. Alternatively, after receiving the AIoT data 223 on the PDU session from the UE 104, the fifth apparatus 205 may transmit the AIoT data 223 to an AIoTF. The AIoTF may perform an inspection or a verification of the AIoT data 223 and transmit the AIoT data 223 to the sixth apparatus after the inspection or verification.

[0172] In some implementations, the fifth apparatus 205 may be implement the UPF and the sixth apparatus may be implement an AIoT application function or an AIoT application server.

[0173] In some embodiments, the UE 104 may also transmit a policy rule enforcement report to the first apparatus 201. The policy rule enforcement report may include an indication of a connection capability of AIoT communication. After receiving the policy rule enforcement report, the first apparatus 201 may update the at least one AIoT related policy rule based on the policy rule enforcement report. In some embodiments, the first apparatus 201 implements a PCF, and the policy rule enforcement report may be transmitted to the PCF via an AIoTF or via a SMF.

[0174] Fig. 3 illustrates a signaling diagram illustrating an example general overview  process 300 that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure. The process 300 may be considered as an example implementation of the process 200A.

[0175] The process 300 may involve the at least one AIoT device 140, the UE 104 and the PCF 126 in Fig. 1B. The UE 104 may serve as an intermediate node between the AIoT device and the RAN node and thus may be referred as an intermediate reader or an UE reader. In some embodiments, the process 300 may also involve at least one of the AMF 120, the AIoTF 124, the UDM 128, the UDR 130, the NEF 132, the AF 134, the AIoT AS 138 or the UPF 136 in Fig. 1B. It is to be understood that the steps and the order of the steps in Fig. 3 are merely for illustration, and not for limitation. It is to be understood that the process 300 may further include additional blocks not shown and / or omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[0176] In the process 300, at 302, the UE reader 104 initiates a registration procedure to the 5GC. At 304, the PCF 126 may be triggered to generate the URSP rules related to AIoT data. There may be various manners to trigger the PCF 126 to generate the URSP rules, for example, based on input from the UDM / UDR 128 / 130 or based on the application influence from the AF / AS 134 / 138.

[0177] For example, at 304A, the AMF 120 may initiate the UE policy association establishment / update procedure with the PCF 126 and provides the UE reader subscription data, APP subscription data, the identifier of the UE, and UE location to the PCF 126, which is obtained either from UDR 130, or from the UE 104 during registration procedure (at 302) . In another example, at 304B, the PCF 126 may subscribe to the UDM / UDR 128 / 130 about the subscription data change and be notified about UE related data and application related data. In a further example, at 304C, the AIoT application transmits the URSP rule guidance to the PCF 126, together with an AIoT traffic indication. In yet another example, at 304E, the AIoTF 124 transmits the UE policy update information to the PCF 126, which may include the AIoT related information, either received from AF 134 as URSP rule guidance (at 304E) or from the UE 104 upon registration (at 302) , or obtained from UDM / UDR 128 / 130 as subscription data.

[0178] Triggered by the information at 304, at 306, the PCF 126 generates the URSP rules that contain the AIoT related parameters, such as the example in Table 2, including  the AIoT related information of the UE reader 104 (e.g., the UE owner / manufacturer / operator information) , device information (e.g., AIoT device owner / manufacturer / operator information) , AIoT communication (as a connection capability) , APP ID, as the Traffic descriptor and the associated DNN / slice information in the route selection descriptor. Additionally, the PCF 126 may also determine and generate the URSP rules based on local operator configurations / policies.

[0179] Specific examples on how the PCF 126 is triggered to generate the URSP rules related to AIoT data will be detailed with reference to Figs. 4A-5B. Steps 308 to 320 illustrate an example implementation of the provisioning of the URSP rules from the PCF 126 to the UE 104 and the following procedures of PDU session establishment and UE determination of proper PDU session for the AIoT data based on the URSP rules.

[0180] At 308, the PCF 126 transmits the URSP rules to the UE reader 104 tailored for AIoT data via the AMF 120. At 310, the UE client initiates the PDU sessions establishment procedure using the URSP rules towards the AMF 120 and SMF (not shown) . One or multiple PDU sessions may be established towards different DNN / S-NSSAI. The SMF may determine the AIoT configuration for the UE reader 104 for the PDU Session either based on the session management (SM) subscription data received from the UDM / UDR 128 / 130, or based on the SM policy control information received from the PCF 126. The IP address of the AIoTF-UP will be provided to the UE 104, so that the UE reader 104 can establish user plane connection to the AIoTF 124.

[0181] At 312, upon a service request from the AIoTF 124, the UE 104 may interact with the AIoT devices 140 and receive the UL AIoT data from the AIoT devices 140. At 314, the UE reader 104 compares the information contained in the UL AIoT data with the URSP rules. The information contained in the UL AIoT data may include at least one of the following: (1) AIoT device ID and / or AIoT device group ID; (2) operator ID of the AIoT devices, which can be separately provided or provided as a part of the AIoT device ID or the AIoT device group ID; (3) AIoT device company / owner information (e.g., company name / ID) , which can be separately provided or provided as a part of the AIoT device ID or the AIoT device group ID; (4) AIoT device manufacture information (e.g., manufacture name / ID) , which can be separately provided or provided as a part of the AIoT device ID or the AIoT device group ID; (5) AIoT APP ID; (6) a traffic category as AIoT communication, which may be provided as an indication.

[0182] If any of the information of the UL AIoT data matches the URSP rules for both the traffic descriptor and route selection descriptor, then UE reader 104 will route the UL data from the AIoT device to the corresponding PDU session. If none of the URSP rules matches the information of the UL AIoT data, the UE 104 will start the PDU session establishment procedure to establish a new PDU session. In some embodiments, if the AIoT data is encrypted by the AIoT device APP layer, then the UE reader 104 can obtain the information of the UL AIoT data from the unencrypted portion of the message (e.g., the message header) .

[0183] At 316, the UE reader 104 transmits the UL AIoT data using the existing matched PDU session or the newly established PDU session to the UPF 136. The UE 104 will also transmit the URSP rule enforcement report to the PCF 126 via SMF including the AIoT communication as the connection capabilities. For example, the SMF may receive a UE report of URSP rule enforcement via a PDU session establishment message or a PDU session modification message. Optionally, at 318, the UE 104 can transmit the URSP rule enforcement report to the AIoTF 124 and then to the PCF 126. The PCF 126 can update / adjust the URSP rules based on the feedback from UE reader 104.

[0184] At 320, the UPF 136 forwards the AIoT data session to the AIoTF-UP using the AIoTF UP IP address received from the SMF. It is assumed that the SMF configures the UPF 136 with a forwarding rule to receive and transmit AIoT data from / to the AIoTF 124 on the N6 interface, or to the AIoT AS 138 directly. The AIoTF 124 perform inspection of the AIoT data and / or perform verification of the AIoT devices and data. Then, AIoTF 124 will expose the data to the AIoT AS / AF via NEF 132. It is assumed that the destination IP address of the AIoT AS 138 has been provided to the AIoTF 124.

[0185] In some embodiments, a simple mapping may be configured to the UE reader 104 by the AIoTF 124 or the AMF 120 to use for routing the AIoT data onto the PDU session, e.g., depends on the service request type.

[0186] Fig. 4A illustrates a signaling diagram illustrating an example process 400A that supports generation of AIoT-related policy rules triggered by subscription data in accordance with aspects of the present disclosure, respectively. The process 400A may be considered as example implementations of the steps 302 and 304 of the process 300. The same reference numerals are used to denote the elements or components described in Fig. 4A having the same operations as the elements or components described in Fig. 3,  and detailed description thereof will be omitted. It is to be understood that the steps and the order of the steps in Fig. 4A are merely for illustration, and not for limitation. It is to be understood that the process 400A may further include additional blocks not shown and / or omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[0187] In the process 400A, the generation of the URSP rules by the PCF 126 is triggered by the information from the AIoTF 124. At 402, the UE reader 104 initiates a registration procedure and transmits a registration request to the AMF 120 and then to the AIoTF 124 in the 5GC. The registration request massage may include an UE reader indication, a user plane (UP) transmission support indication, UE ID, UE location, UE radio and reader related capability, a URSP rule report support indication and the Policy Selection Identifier (PSI) stored at UE 104. The URSP rule report support indication is used to indicate to PCF 126 that the UE 104 supports the feedback / report of the matched URSP rules at the UE side and the PCF 126 will accordingly include this indication in the URSP rules transmitted to the UE 104 that supports the feedback / report of the matched URSP rules. The PCF 126 may divide the UE policy information into different Policy Sections, each one identified by a PSI. By receiving the PSI stored at UE 104, the AMF 120 or the AIoTF 124 can determine whether the UE reader 104 needs to be configured with the new URSP rules.

[0188] The AMF 120 will store and forward the UE reader registration request to the selected AIoTF 124. AMF 120 can either select the AIoTF 124 from the UDM / UDR 128 / 130 using the UE location information and subscription data, or based on local configuration. Alternatively, the AMF 120 can also obtain the subscription data from the UDM / UDR 128 / 130 that includes both UE reader subscription data and AIoT APP subscription data. It can be assumed that the AIoT APP ID is installed in the UE reader 104, as the UE 104 indicated its reader capabilities to the network. In this way, the AMF 120 may obtain the AIoT APP subscription data by using the APP ID towards the UDM / UDR.

[0189] At 404, the AIoTF 124 interacts with the UDM / UDR 128 / 130 to check the subscription information using the UE ID and the AIoT APP ID as index. It is assumed that the subscription data of the UE reader and the AIoT application has been pre-configured at the UDM / UDR 128 / 130. The subscription information may include AIoT  related data of the UE reader 104, an authorization indication of the UE reader to act as AIoT intermediate node, a list of AIoT service (s) for which is allowed to transmit AIoT data / signalling to the AIoT devices, and AIoT related data of AIoT application. The AIoT related data of the UE reader 104 may include UE subscription data, such as UE group information, UE company / owner / operator / manufacture information associated with the DNN / S-NSSAI. The AIoT related data of AIoT application may include AIoT application subscription data, such as the AIoT types of applications that are authorised for the UE reader 104, etc. All the subscription information may be provided to the AIoTF 124.

[0190] In some embodiments, the AIoT related data of AIoT devices (e.g., AIoT device subscription data) , if available in the UDM / UDR 128 / 130, can also be provided to the AIoTF 124 if the device ID, or the reader-device binding information is used as an index to check from UDM / UDR 128 / 130, either by AMF 120, AIoTF 124 or PCF 126. In some embodiments, the AIoTF 124 can also forward the AIoT device subscription information associated with the UE reader 104 to the PCF 126 to generate the URSP rules.

[0191] At 406, the AIoTF 124 transmits the registration response to the UE 104 (an indication of accept / reject) . The UE 104 may be authorized to serve as the AIoT reader and for UP transmission at least based on the UE subscription information.

[0192] At 410, the AIoTF 124 determines whether UE 104 needs new URSP rules based on the stored PSI transmitted from the UE 104, and the obtained subscription information including the AIoT related data of the UE reader 104 and application subscription data from the UDM / UDR 128 / 130. If the stored PSI and the obtained subscription information are not consistent, the process 400A goes to step 412 to ask PCF 126 to update the URSP rules of the UE 104. At 412, the AIoTF 124 transmits the UE policy update request to the PCF 126. The UE policy update request may include the UE ID, UE reader subscription data and application subscription data. For example, the UE policy update request may include the UE ID, and an indication that the UE is authorized for AIoT APP ID#1, AIoT APP ID#2, etc. Optionally, the AIoTF 124 may also transmit the AIoT traffic indication / UE reader indication to the PCF 126 to indicate that the policy update is for AIoT traffic. In some embodiments, the AIoTF 124 may further subscribe to the PCF 126 about policy update notification of the UE reader 104.

[0193] Optionally, if AIoT device information associated with the UE 104 is available  at the AIoTF 124 via inventory / discovery procedure, the AIoTF 124 may also forward the AIoT device information to the PCF 126 to generate the URSP rule, e.g., the device ID / device group ID as the traffic descriptor.

[0194] At 306, triggered by the information from the AIoTF 124, the PCF 126 generates the URSP rules that contain the AIoT related parameters, such as the example in Table 2, including the UE owner / manufacturer / operator information, AIoT device owner / manufacturer / operator information, AIoT communication (as a connection capability) , APP ID, as the Traffic descriptor and the associated DNN / slice information in the route selection descriptor.

[0195] For example, the PCF 126 receives the UE subscription data from the UDR 130 including the owner of the reader / device and created URSP rule for PDU session towards the data network of the owner identified by DNN. Additionally, the PCF 126 may also determine and generate the URSP rules based on local operator configurations / policies. In addition, the PCF 126 may get the location of the UE reader 104 from the AMF 120 / LMF and generate the URSP rules for the DN that operates the specific location.

[0196] When generating the URSP rules based on the AIoT device information, e.g., device ID, device owner ID, the PCF 126 will need to make sure that the AIoT device is within the coverage of the UE reader 104, or which AIoT device groups or AIoT types of applications are authorized for the UE reader 104. In some embodiments, if only the AIoT related information of the UE reader 104 is provided to the PCF 126, then the generated URSP rules are accordingly determined based on the information of the UE 104, instead of the device information.

[0197] At 308, the PCF 126 transmits the URSP rules to the UE reader 104 tailored for AIoT data via the AMF 120. In some embodiments, the registration response and the URSP rules may be transmitted to the UE reader 104 in the same message or in separate messages.

[0198] Fig. 4B illustrates another signaling diagram illustrating an example process 400B that supports generation of AIoT-related policy rules triggered by subscription data in accordance with aspects of the present disclosure, respectively. The process 400B may be considered as example implementations of the steps 302 and 304 of the process 300. The same reference numerals are used to denote the elements or components described in  Fig. 4B having the same operations as the elements or components described in Fig. 3 or Fig. 4A, and detailed description thereof will be omitted. It is to be understood that the steps and the order of the steps in Fig. 4B are merely for illustration, and not for limitation. It is to be understood that the process 400B may further include additional blocks not shown and / or omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[0199] In the process 400B, the generation of the URSP rules by the PCF 126 is triggered by the information from the AMF 120. The AMF 120 determines whether UE 104 needs new URSP rules based on the PSI received from the UE 104 and the subscription information including the AIoT related data of the UE reader 104 and application subscription data. In some embodiments, the AMF 120 may obtain the subscription information at 420 via interactions with the UDM / UDR 128 / 130. Alternatively, the AMF 120 may obtain the subscription information at the UE registration procedure. At 422, the AMF 120 initiates the UE reader policy association establishment / update procedure towards the PCF 126. For example, the AMF 120 transmits the UE ID, UE reader location, UE reader subscription data, application subscription data, and an optional AIoT traffic indication / UE reader indication to the PCF 126 to indicate that this procedure is for URSP rules of the AIoT UE reader 104. The location information can be used by the PCF 126 to create the URSP rule for PDU session towards the data network (DN) that runs / operates the location that UE reader 104 resides in. Optionally, if AIoT device information is available at the AMF 120 e.g., via an inventory / discovery procedure, the AMF 120 will also forward the AIoT device information to the PCF 126 associated with the UE 104 to generate the URSP rules, e.g., the device ID / device group ID as the traffic descriptor.

[0200] At 308, the PCF 126 transmits the URSP rules to the UE reader 104 tailored for AIoT data via the AMF 120. In some embodiments, the registration response and the URSP rules may be transmitted to the UE reader 104 in the same message or in separate messages.

[0201] Fig. 4C illustrates another signaling diagram illustrating an example process 400C that supports generation of AIoT-related policy rules triggered by subscription data in accordance with aspects of the present disclosure, respectively. The process 400C may be considered as example implementations of the steps 302 and 304 of the process 300.  The same reference numerals are used to denote the elements or components described in Fig. 4C having the same operations as the elements or components described in Figs. 3 to 4B, and detailed description thereof will be omitted. It is to be understood that the steps and the order of the steps in Fig. 4C are merely for illustration, and not for limitation. It is to be understood that the process 400C may further include additional blocks not shown and / or omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[0202] In the process 400C, the generation of the URSP rules by the PCF 126 is triggered by the information from the UDM / UDR 128 / 130. At 430, the PCF 126 subscribes to the UDR 130 about the UE policy information update by providing the UE ID and / or APP ID if available. The UDR 130 may provide the UE reader subscription data and application subscription data to the PCF 126. The information within the UDM / UDR 128 / 130 can either be pre-configured by the operation administration and maintenance (OAM) or provided by the AIoT APP.

[0203] Optionally, if the AIoT device subscription data is available in the UDM / UDR 128 / 130, and the PCF 126 is provided with the device ID associated with the UE ID, then the PCF 126 can also obtain the AIoT device subscription information from UDR 130 using device ID as index.

[0204] Turning back to Fig. 3, another way for the PCF 126 to generate the URSP rules is based on the AF / AS guidance / input. An AF / AS 134 / 138 related with AIoT may need to guide the PCF 126 to determine proper URSP rules. The guidance transmitted by the AF / AS 134 / 138 may apply to any UE reader 104 or to a set of UE 104 (s) e.g. identified by a UE group ID. The AF / AS 134 / 138 may belong to the operator or to a third party.

[0205] Fig. 5A illustrates a signaling diagram illustrating an example process 500A that support generation of AIoT-related policy rules triggered by AIoT-related rule guidance information in accordance with aspects of the present disclosure, respectively. The processes 500A may be considered as example implementations of the steps 302 and 304 of the process 300. The same reference numerals are used to denote the elements or components described in Fig. 5A having the same operations as the elements or components described in Fig. 3, and detailed description thereof will be omitted. It is to be understood that the steps and the order of the steps in Fig. 5A are merely for illustration,  and not for limitation. It is to be understood that the process 500A may further include additional blocks not shown and / or omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[0206] In the process 500A, there is no UE reader ID provided by the AF / AS 134 / 138. The AIoTF 124 may select the corresponding UE reader and forward the URSP rule guidance information associated with the selected UE 104 to the PCF 126. In some embodiments, the AF / AS guidance for URSP rules determination needs to be authorized by the UDM / UDR 128 / 130.

[0207] At 302, the UE reader 104 performs the registration procedure towards the AMF 120 or the AIoTF 124 in the 5GC and is authorized as the UE reader 104 after the AMF 120 or the AIoTF 124 checks the UE subscription data from the UDM / UDR 128 / 130. The UP transmission of the UE reader 104 can also be authorized. An example of the step 302 may be performed in the same manner as the steps 402, 404 and 406 in Fig. 4A, and detailed description thereof will be omitted.

[0208] At 512, the AF / AS 134 / 138 transmits the service request (e.g., inventory, read and write) to the 5GC, which may contain: target device ID, target UE reader 104 ID (o) , target location, filtering criteria, aggregation indication, UP transmission indication, destination IP address of the APP, etc. Moreover, the URSP rule guidance information, and an AIoT traffic indication may also be provided by the AF / AS 134 / 138, either before the service request separately, or together with the service request.

[0209] The URSP rule guidance information may contain but not limited to: (1) APP ID of the AIoT application; (2) device ID or device group ID, which may be provided in the URSP rule guidance information or provided separately with the URSP guidance information; (3) the owner / operator / manufacturer information of the UE reader 104 (e.g. owner ID, operator ID, or manufacturer ID of the UE reader 104) ; and (4) owner / operator / manufacture information of the AIoT device. In some embodiments, the URSP rule guidance information may also include one or more sets of Route Selection parameters, such as DNN / S-NSSAI, requested PDU session type etc. Different sets of Route selection parameters indicate different sets of PDU Session information that can be associated with applications matching the application traffic descriptor.

[0210] After receiving the service request, which has been authorized and authenticated by the UDM / UDR / AUSF, at 514, the AIoTF 124 selects the serving UE  reader based on the target location information by checking the registration information of the UE reader locally, or from the AMF 120 or UDM / UDR 128 / 130. The AIoTF 124 can determine whether the UE 104 needs to be reconfigured / updated with the URSP rules by checking the PSI information provided by the UE 104. In addition, the AIoTF 124 may reject the AF / AS guidance if the S-NSSAI and DNN provided by the AF / AS guidance doesn’t comply with the UE subscription by checking the UE subscription data from the UDM / UDR 128 / 130.

[0211] At 516, the AIoTF 124 transmits the UE policy update request to the corresponding PCF 126, including UE ID, URSP rule guidance information. Optionally, the AIoTF 124 may transmit the AIoT traffic indication to the PCF 126 to indicate that the policy update is for AIoT traffic, and subscribe to the PCF 126 about the UE reader 104 policy update notification.

[0212] After receiving the AF / AS guidance from the AIoTF 124, at 306, the PCF 126 generates the URSP rules with AIoT related parameters associated with the UE reader 104, as shown in Table 2. Additionally, the PCF 126 may also determine and generate the URSP rules based on local operator configurations / policies.

[0213] At 518, the AIoTF 124 transmits the service request to the selected UE reader 104. The UP-transmission indication can be transmitted to the UE reader 104 to activate the User Plane PDU session transmission. At 308, the PCF 126 transmits the URSP rules to the UE 104 via the AMF 120.

[0214] Fig. 5B illustrates a signaling diagram illustrating an example process 500B that support generation of AIoT-related policy rules triggered by AIoT-related rule guidance information in accordance with aspects of the present disclosure, respectively. The processes 500B may be considered as example implementations of the steps 302 and 304 of the process 300. The same reference numerals are used to denote the elements or components described in Fig. 5B having the same operations as the elements or components described in Fig. 3 or Fig. 5A, and detailed description thereof will be omitted. It is to be understood that the steps and the order of the steps in Fig. 5B are merely for illustration, and not for limitation. It is to be understood that the process 500B may further include additional blocks not shown and / or omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

[0215] In the process 500B, the AF / AS 134 / 138 knows about the information of the  target UE reader 104 (e.g., UE ID) . Under this case, when receiving the information from the AF / AS 134 / 138, the NEF 132 may find the PCF 126 serving the UE 104 using the binding support function (BSF) and forward the URSP rule guidance information to the PCF 126. In some embodiments, the AF / AS guidance for URSP rules determination needs to be authorized by the UDM / UDR 128 / 130.

[0216] At 302, the UE reader 104 performs the registration procedure towards the AMF 120 or the AIoTF 124 in the 5GC and is authorized as the UE reader 104 after the AMF 120 or the AIoTF 124 checks the UE subscription data from the UDM / UDR 128 / 130. The UP transmission of the UE reader 104 can also be authorized. An example of the step 302 may be performed in the same manner as the steps 402, 404 and 406 in Fig. 4A, and detailed description thereof will be omitted.

[0217] If UE ID of the UE reader 104 (e.g., GPSI) is available at the AF / AS 134 / 138, the AF / AS 134 / 138 may transmit the guidance information to the AIoTF 124 firstly and then to the PCF 126 as in the process 500A in Fig. 5A. Alternatively, as shown in Fig. 5B, at 520, the AF / AS 134 / 138 may transmit the guidance information to the NEF 132 and then the NEF 132 may forward the message to the PCF 126 found based on the BSF. An optional AIoT traffic indication may be transmitted to indicate that this information is for the PCF 126 to generate the URSP rules related to AIoT traffic. The AIoT device information can also be transmitted to the PCF 126 together with the guidance information if the AIoT device information is available at the AF / AS 134 / 138. After receiving the AF / AS guidance from the AF / AS 134 / 138, at 306, the PCF 126 generates the URSP rules with AIoT related parameters associated with the UE reader 104, as shown in Table 2. Additionally, the PCF 126 may also determine and generate the URSP rules based on local operator configurations / policies.

[0218] At 518, the AIoTF 124 transmits the service request to the selected UE reader 104. The UP-transmission indication can be transmitted to the UE reader 104 to activate the User Plane PDU session transmission. At 308, the PCF 126 transmits the URSP rules to the UE 104 via the AMF 120.

[0219] Fig. 6 illustrates an example of a device 600 that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure. The device 600 may be an example of a network entity 102, a UE 104 or a network function in the core network 106 as described herein. The device 600 may support wireless  communication with one or more network entities 102, UEs 104, or any combination thereof. The device 600 may include components for bi-directional communications including components for transmitting and receiving communications, such as a processor 602, a memory 604, a transceiver 606, and, optionally, an I / O controller 6014. 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) .

[0220] The processor 602, the memory 604, the transceiver 606, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. For example, the processor 602, the memory 604, the transceiver 606, or various combinations or components thereof may support a method for performing one or more of the operations described herein.

[0221] In some implementations, the processor 602, the memory 604, the transceiver 606, or various combinations or components thereof may be implemented in hardware (e.g., in communications management circuitry) . The hardware may include a processor, a digital signal processor (DSP) , an application-specific integrated circuit (ASIC) , a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic, discrete hardware components, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure. In some implementations, the processor 602 and the memory 604 coupled with the processor 602 may be configured to perform one or more of the functions described herein (e.g., executing, by the processor 602, instructions stored in the memory 604) .

[0222] For example, the processor 602 may support wireless communication at the device 600 in accordance with examples as disclosed herein. The processor 602 may be configured to operable to support a means for receiving, from a second apparatus, ambient internet-of-things (AIoT) related information associated with a user equipment (UE) ; a means for determining at least one AIoT-related policy rule for the UE based on the AIoT related information; and a means for transmitting, to the UE, the at least one AIoT-related policy rule.

[0223] Alternatively, in some implementations, the processor 602 may be configured to operable to support a means for transmitting, to a first apparatus, ambient internet-of- things (AIoT) related information associated with a user equipment (UE) , wherein the AIoT related information is used to determine at least one AIoT-related policy rule for the UE.

[0224] Alternatively, in some implementations, the processor 602 may be configured to operable to support a means for receiving, from a first apparatus, at least one ambient internet-of-things (AIoT) -related policy rule for the UE; a means for receiving, from an AIoT device, a message carrying AIoT data; a means for determining a protocol data unit (PDU) session for the AIoT data based on the at least one AIoT-related policy rule and information of the AIoT data; and a means for transmitting, to a fifth apparatus, the AIoT data on the PDU session.

[0225] Alternatively, in some implementations, the processor 602 may be configured to operable to support a means for receiving, from a user equipment (UE) , ambient internet-of-things (AIoT) data on a protocol data unit (PDU) session, wherein the PDU session follows at least one AIoT-related policy rule for the UE; and a means for transmitting, to an AIoT function (AIoTF) or to a sixth apparatus, the AIoT data.

[0226] Alternatively, in some implementations, the processor 602 may be configured to operable to support a means for receiving, from a second apparatus, an identifier of a user equipment (UE) , and a means for transmitting, to the second apparatus, at least one of the following: subscription data of the UE, wherein the UE is authorized to act as an ambient internet-of-things (AIoT) intermediate node; subscription data of at least one AIoT application; subscription data of at least one AIoT device; an indication that the UE is authorized to act as an AIoT intermediate node; or information of at least one AIoT service associated with the UE.

[0227] The processor 602 may include an intelligent hardware device (e.g., a general-purpose processor, a DSP, a CPU, a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof) . In some implementations, the processor 602 may be configured to operate a memory array using a memory controller. In some other implementations, a memory controller may be integrated into the processor 602. The processor 602 may be configured to execute computer-readable instructions stored in a memory (e.g., the memory 604) to cause the device 600 to perform various functions of the present disclosure.

[0228] The memory 604 may include random access memory (RAM) and read-only memory (ROM) . The memory 604 may store computer-readable, computer-executable code including instructions that, when executed by the processor 602 cause the device 600 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. In some implementations, the code may not be directly executable by the processor 602 but may cause a computer (e.g., when compiled and executed) to perform functions described herein. In some implementations, the memory 604 may include, among other things, a basic I / O system (BIOS) which may control basic hardware or software operation such as the interaction with peripheral components or devices.

[0229] The I / O controller 6014 may manage input and output signals for the device 600. The I / O controller 6014 may also manage peripherals not integrated into the device M02. In some implementations, the I / O controller 6014 may represent a physical connection or port to an external peripheral. In some implementations, the I / O controller 6014 may utilize an operating system such as  or another known operating system. In some implementations, the I / O controller 6014 may be implemented as part of a processor, such as the processor 602. In some implementations, a user may interact with the device 600 via the I / O controller 6014 or via hardware components controlled by the I / O controller 6014.

[0230] In some implementations, the device 600 may include a single antenna 610. However, in some other implementations, the device 600 may have more than one antenna 610 (i.e., multiple antennas) , including multiple antenna panels or antenna arrays, which may be capable of concurrently transmitting or receiving multiple wireless transmissions. The transceiver 606 may communicate bi-directionally, via the one or more antennas 610, wired, or wireless links as described herein. For example, the transceiver 606 may represent a wireless transceiver and may communicate bi-directionally with another wireless transceiver. The transceiver 606 may also include a modem to modulate the packets, to provide the modulated packets to one or more antennas 610 for transmission, and to demodulate packets received from the one or more antennas 610. The transceiver 606 may include one or more transmit chains, one or more receive chains, or a combination thereof.

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

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

[0233] Fig. 7 illustrates an example of a processor 700 that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure. The processor 700 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 700 may include a controller 702 configured to perform various operations in accordance with examples as described herein. The processor 700 may optionally include at least one memory 704, such as L1 / L2 / L3 cache. Additionally, or alternatively, the processor 700 may optionally include one or more arithmetic-logic units (ALUs) 706. 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) .

[0234] The processor 700 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 700) 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) .

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

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

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

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

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

[0240] For example, the processor 700 may support wireless communication at the device 600 in accordance with examples as disclosed herein. The processor 700 may be  configured to operable to support a means for receiving, from a second apparatus, ambient internet-of-things (AIoT) related information associated with a user equipment (UE) ; a means for determining at least one AIoT-related policy rule for the UE based on the AIoT related information; and a means for transmitting, to the UE, the at least one AIoT-related policy rule.

[0241] Alternatively, the processor 700 may support wireless communication at the device 600 in accordance with examples as disclosed herein. The processor 700 may be configured to operable to support a means for transmitting, to a first apparatus, ambient internet-of-things (AIoT) related information associated with a user equipment (UE) , wherein the AIoT related information is used to determine at least one AIoT-related policy rule for the UE.

[0242] Alternatively, the processor 700 may support wireless communication at the device 600 in accordance with examples as disclosed herein. The processor 700 may be configured to operable to support a means for receiving, from a first apparatus, at least one ambient internet-of-things (AIoT) -related policy rule for the UE; a means for receiving, from an AIoT device, a message carrying AIoT data; a means for determining a protocol data unit (PDU) session for the AIoT data based on the at least one AIoT-related policy rule and information of the AIoT data; and a means for transmitting, to a fifth apparatus, the AIoT data on the PDU session.

[0243] Alternatively, the processor 700 may support wireless communication at the device 600 in accordance with examples as disclosed herein. The processor 700 may be configured to operable to support a means for receiving, from a user equipment (UE) , ambient internet-of-things (AIoT) data on a protocol data unit (PDU) session, wherein the PDU session follows at least one AIoT-related policy rule for the UE; and a means for transmitting, to an AIoT function (AIoTF) or to a sixth apparatus, the AIoT data.

[0244] Alternatively, the processor 700 may support wireless communication at the device 600 in accordance with examples as disclosed herein. The processor 700 may be configured to operable to support a means for receiving, from a second apparatus, an identifier of a user equipment (UE) , and a means for transmitting, to the second apparatus, at least one of the following: subscription data of the UE, wherein the UE is authorized to act as an ambient internet-of-things (AIoT) intermediate node; subscription data of at least one AIoT application; subscription data of at least one AIoT device; an indication  that the UE is authorized to act as an AIoT intermediate node; or information of at least one AIoT service associated with the UE.

[0245] Fig. 8 illustrates a flowchart of a method 800 that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure. The operations of the method 800 may be implemented by a device or its components as described herein. For example, the operations of the method 800 may be performed by a first apparatus (e.g., a PCF) as described herein. In some implementations, the device may execute a set of instructions to control the function elements of the device to perform the described functions. Additionally, or alternatively, the device may perform aspects of the described functions using special-purpose hardware.

[0246] At 805, the method may include receiving, from a second apparatus, ambient internet-of-things (AIoT) related information associated with a user equipment (UE) . The operations of 805 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 805 may be performed by a device as described with reference to Fig. 1A or 1B.

[0247] At 810, the method may include determining at least one AIoT-related policy rule for the UE based on the AIoT related information. The operations of 810 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 810 may be performed by a device as described with reference to Fig. 1A or 1B.

[0248] At 815, the method may include transmitting, to the UE, the at least one AIoT-related policy rule. The operations of 815 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 815 may be performed by a device as described with reference to Fig. 1A or 1B.

[0249] Fig. 9 illustrates a flowchart of a method 900 that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure. The operations of the method 900 may be implemented by a device or its components as described herein. For example, the operations of the method 900 may be performed by a second apparatus (e.g., an AMF, an AIoTF, a UDM, a UDR, an AF or an AS) as described herein. In some implementations, the device may execute a set of instructions to control the function elements of the device to perform the described functions. Additionally, or alternatively, the device may perform aspects of the described functions using special- purpose hardware.

[0250] At 905, the method may include transmitting, to a first apparatus, ambient internet-of-things (AIoT) related information associated with a user equipment (UE) , wherein the AIoT related information is used to determine at least one AIoT-related policy rule for the UE. The operations of 905 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 905 may be performed by a device as described with reference to Fig. 1A or 1B.

[0251] Fig. 10 illustrates a flowchart of a method 1000 that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure. The operations of the method 1000 may be implemented by a device or its components as described herein. For example, the operations of the method 1000 may be performed by a UE as described herein. In some implementations, the device may execute a set of instructions to control the function elements of the device to perform the described functions. Additionally, or alternatively, the device may perform aspects of the described functions using special-purpose hardware.

[0252] At 1005, the method may include receiving, from a first apparatus, at least one ambient internet-of-things (AIoT) -related policy rule for the UE. The operations of 1005 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1005 may be performed by a device as described with reference to Fig. 1A or 1B.

[0253] At 1010, the method may include receiving, from an AIoT device, a message carrying AIoT data. The operations of 1010 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1010 may be performed by a device as described with reference to Fig. 1A or 1B.

[0254] At 1015, the method may include determining a protocol data unit (PDU) session for the AIoT data based on the at least one AIoT-related policy rule and information of the AIoT data. The operations of 1015 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1015 may be performed by a device as described with reference to Fig. 1A or 1B.

[0255] At 1020, the method may include transmitting, to a fifth apparatus, the AIoT data on the PDU session. The operations of 1020 may be performed in accordance with  examples as described herein. In some implementations, aspects of the operations of 1020 may be performed by a device as described with reference to Fig. 1A or 1B.

[0256] Fig. 11 illustrates a flowchart of a method 1100 that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure. The operations of the method 1100 may be implemented by a device or its components as described herein. For example, the operations of the method 1100 may be performed by a fifth apparatus (e.g., a UPF) as described herein. In some implementations, the device may execute a set of instructions to control the function elements of the device to perform the described functions. Additionally, or alternatively, the device may perform aspects of the described functions using special-purpose hardware.

[0257] At 1105, the method may include receiving, from a user equipment (UE) , ambient internet-of-things (AIoT) data on a protocol data unit (PDU) session, wherein the PDU session follows at least one AIoT-related policy rule for the UE. The operations of 1105 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1105 may be performed by a device as described with reference to Fig. 1A or 1B.

[0258] At 1110, the method may include transmitting, to an AIoT function (AIoTF) or to a sixth apparatus, the AIoT data. The operations of 1110 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1110 may be performed by a device as described with reference to Fig. 1A or 1B.

[0259] Fig. 12 illustrates a flowchart of a method 1200 that supports policy rules for AIoT data transmission in accordance with aspects of the present disclosure. The operations of the method 1200 may be implemented by a device or its components as described herein. For example, the operations of the method 1200 may be performed by a third apparatus (e.g., a UDM or a UDR) as described herein. In some implementations, the device may execute a set of instructions to control the function elements of the device to perform the described functions. Additionally, or alternatively, the device may perform aspects of the described functions using special-purpose hardware.

[0260] At 1205, the method may include receiving, from a second apparatus, an identifier of a user equipment (UE) . The operations of 1205 may be performed in accordance with examples as described herein. In some implementations, aspects of the  operations of 1205 may be performed by a device as described with reference to Fig. 1A or 1B.

[0261] At 1210, the method may include transmitting, to the second apparatus, at least one of the following: subscription data of the UE, wherein the UE is authorized to act as an ambient internet-of-things (AIoT) intermediate node; subscription data of at least one AIoT application; subscription data of at least one AIoT device; an indication that the UE is authorized to act as an AIoT intermediate node; or information of at least one AIoT service associated with the UE. The operations of 1210 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1210 may be performed by a device as described with reference to Fig. 1A or 1B.

[0262] It shall be noted that implementations of the present disclosure which have been described with reference to Figs. 1 to 12 are also applicable to the device 600, the processor 700 and the methods 800, 900, 1000, 1100 and 1200.

[0263] It should be noted that the methods described herein describes possible implementations, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible. Further, aspects from two or more of the methods may be combined.

[0264] The various illustrative blocks and components described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a DSP, an ASIC, a CPU, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0265] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope of the disclosure and appended claims. For example,  due to the nature of software, functions described herein may be implemented using software executed by a processor, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions may also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations.

[0266] 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. By way of example, non-transitory computer-readable media may include RAM, ROM, electrically erasable programmable ROM (EEPROM) , flash memory, compact disk (CD) ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that may be used to carry or store desired program code means in the form of instructions or data structures and that may be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor.

[0267] As used herein, including in the claims, 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.

[0268] 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 first apparatus, comprising:at least one memory; andat least one processor coupled with the at least one memory and configured to cause the first apparatus to:receive, from a second apparatus, ambient internet-of-things (AIoT) related information associated with a user equipment (UE) ;determine at least one AIoT-related policy rule for the UE based on the AIoT related information; andtransmit, to the UE, the at least one AIoT-related policy rule.2.The first apparatus of claim 1, wherein the at least one AIoT-related policy rule comprises at least one AIoT-related traffic descriptor component, the at least one AIoT-related traffic descriptor component comprises one of the following:at least one AIoT device identifier; orat least one AIoT device group identifier.3.The first apparatus of claim 1, wherein the at least one AIoT-related policy rule comprises at least one AIoT-related traffic descriptor component, the at least one AIoT-related traffic descriptor component comprises at least one of the following:at least one operator identifier of at least one AIoT device;at least one manufacturer identifier of at least one AIoT device;at least one owner identifier of at least one AIoT device;an operator identifier of the UE;a manufacturer identifier of the UE;an owner identifier of the UE;at least one identifier of at least one AIoT application;a connection capability of AIoT communication; ora traffic category of AIoT communication.4.The first apparatus of claim 1, wherein the AIoT related information comprises at least one of the following:subscription data of the UE;subscription data of at least one AIoT application;subscription data of at least one AIoT device;an identifier of the UE;an AIoT-related indication;an indication of subscribing policy update notification associated with the UE; orlocation information of the UE.5.The first apparatus of claim 4, wherein the subscription data of the UE comprises at least one of the following:operator information of the UE;manufacturer information of the UE;owner information of the UE;information of at least one data network that the UE is subscribed to;information of at least one slice that the UE is subscribed to; orinformation of whether the UE is authorized to act as a reader.6.The first apparatus of claim 4, wherein the subscription data of the at least one AIoT application comprises at least one of the following:an indication of whether the at least one AIoT application is allowed to use a service provided by a network; ora credential for network layer security of the at least one AIoT application.7.The first apparatus of claim 6, wherein the at least one AIoT application is allowed to use the service provided by the network, and the indication of whether the at least one AIoT application is allowed to use the service provided by the network comprises at least one of the following:at least one application type of the at least one AIoT application; orat least one identifier of the at least one AIoT application.8.The first apparatus of claim 1, wherein the AIoT related information comprises at least one of the following:AIoT-related rule guidance information;an identifier of the UE;an AIoT-related indication; oran indication of subscribing policy update notification associated with the UE.9.The first apparatus of claim 8, wherein the AIoT-related rule guidance information comprises at least one of the following:at least one identifier of at least one AIoT application;at least one AIoT device identifier;at least one AIoT device group identifier.at least one operator identifier of at least one AIoT device;at least one manufacturer identifier of at least one AIoT device;at least one owner identifier of at least one AIoT device;operator information of the UE;manufacturer information of the UE;owner information of the UE;data network information; orslice information.10.The first apparatus of claim 1, wherein the at least one processor is configured to further cause the first apparatus to:receive, from the UE, a policy rule enforcement report, wherein the policy rule enforcement report comprises an indication of a connection capability of AIoT communication; andupdate the at least one AIoT related policy rule based on the policy rule enforcement report.11.The first apparatus of claim 10, wherein the policy rule enforcement report is received from the UE via an AIoT function (AIoTF) or via a session management function (SMF) .12.A second apparatus, comprising:at least one memory; andat least one processor coupled with the at least one memory and configured to cause the second apparatus to:transmit, to a first apparatus, ambient internet-of-things (AIoT) related information associated with a user equipment (UE) ;wherein the AIoT related information is used to determine at least one AIoT-related policy rule for the UE.13.The second apparatus of claim 12, wherein the AIoT related information comprises at least one of the following:subscription data of the UE;subscription data of at least one AIoT application;subscription data of at least one AIoT device; oran identifier of the UE;an AIoT-related indication;an indication of subscribing policy update notification associated with the UE; orlocation information of the UE.14.The second apparatus of claim 13, wherein at least one processor is configured to further cause the second apparatus to:transmit, to a third apparatus, at least one of the following:an identifier of the UE,at least one identifier of the at least one AIoT application,at least one AIoT device identifier of the at least one AIoT device, orat least one AIoT device group identifier associated with the at least one AIoT device; andreceive, from the third apparatus, at least one of the following:the subscription data of the UE;the subscription data of the at least one AIoT application;the subscription data of the at least one AIoT device;information of at least one AIoT service associated with the UE.15.The second apparatus of claim 12, wherein the AIoT related information comprises at least one of the following:AIoT-related rule guidance information;an identifier of the UE;an AIoT-related indication; oran indication of subscribing policy update notification associated with the UE,wherein at least one processor is configured to further cause the second apparatus to:receive, from a fourth apparatus, the AIoT-related rule guidance information.16.The second apparatus of claim 15, wherein the AIoT-related rule guidance information comprises at least one of data network information or slice information, and at least one processor is configured to further cause the second apparatus to:receive, from a third apparatus, subscription data of the UE; anddetermine whether to accept the AIoT-related rule guidance information based on the subscription data of the UE; andwherein the AIoT-related rule guidance information is rejected in the case that the at least one of data network information or slice information does not comply with the subscription data of the UE.17.The second apparatus of claim 12, wherein at least one processor is configured to further cause the second apparatus to:receive, from the UE, a policy selection identifier (PSI) ;receive, from a third apparatus, subscription data of the UE; anddetermine whether policy updating is needed for the UE at least based on the PSI and the subscription data of the UE; andwherein the AIoT related information is transmitted to the first apparatus in the case that policy updating is needed for the UE.18.A user equipment (UE) , comprising:a processor; anda transceiver coupled to the processor,wherein the processor is configured to:receive, via the transceiver from a first apparatus, at least one ambient internet-of-things (AIoT) -related policy rule for the UE;receive, via the transceiver from an AIoT device, a message carrying AIoT data;determine a protocol data unit (PDU) session for the AIoT data based on the at least one AIoT-related policy rule and information of the AIoT data; andtransmit, via the transceiver to a fifth apparatus, the AIoT data on the PDU session.19.The UE of claim 18, wherein the processor is further configured to:establish at least one PDU session based on the at least one AIoT-related policy rule;wherein determine the PDU session for the AIoT data comprises:determining whether the information of the AIoT data matches the at least one PDU session based on the at least one AIoT-related policy rule; andin the case that the information of the AIoT data matches the at least one PDU session, determine a matched PDU session among the at least one PDU session as the PDU session; orin the case that the information of the AIoT data does not match the at least one PDU session, establish a PDU session based on the information of the AIoT data, wherein the PDU session is the established PDU session.20.The UE of claim 18, wherein the at least one processor is configured to further cause the UE to:transmit, via the transceiver to a first apparatus, a policy rule enforcement report, wherein the policy rule enforcement report comprises an indication of a connection capability of AIoT communication.

Images