Mechanism for user plane-based data delivery for ambient IoT service

Abstract

In accordance with implementations, an Ambient Internet of Things (AIoT) management function (MF) entity in a network receives AIoT service information for an AIoT service and a group of AIoT devices associated with the AIoT service. The AIoT service information indicates at least one of first information for AIoT plane selection, second information for AIoT reader selection, or additional assistant information provided by an application function (AF) entity associated with the AIoT service used by the network. The AIoT MF entity transmits, to an AIoT reader device, the AIoT service information and an AIoT service instruction based on the AIoT service information.

Description

MECHANISM FOR USER PLANE-BASED DATA DELIVERY FOR AMBIENT IOT SERVICEPRIORITY CLAIM AND CROSS-REFERENCE

[0001] This patent application claims priority to U.S. Provisional Application No. 63 / 574,091, filed on April 3, 2024, and entitled “New Mechanism for User Plane-based Data Delivery’ for Ambient loT Service,” application of which is hereby incorporated by’ reference herein as if reproduced in its entirety.TECHNICAL FIELD

[0002] The present disclosure relates generally to wireless communications, and, in particular embodiments, to systems and methods for Ambient Internet of Things (loT) service.BACKGROUND

[0003] The 3rd Generation Partnership Project (3GPP) has started a study in both radio access network (RAN) and System Architecture Workgroup 2 (SA2) on introducing 5th generation (5G) Ambient loT (AIoT). 3GPP Release 19 study item description describes studying 2 topologies for Ambient loT as defined in TR38.848. FIG. 1 show s an example of Topology 1, w here the Ambient loT device 102 directly communicates with the base station 104. FIG. 2 shows an example of Topology 2, where the Ambient loT device 202 communicates with the base station 204 via the intermediate node 206. For topology 2, the intermediate node 206 can be a user equipment (UE) under the network control.

[0004] Currently, most of the proposed solutions in the SA2 study use the control plane (non-access stratum (NAS)) via the access management function (AMF) to the application function (AF) to deliver the AIoT reader to AIoT device (R2D) and AIoT device to AIoT reader (D2R) data from / to Ambient loT devices.

[0005] One potential solution proposes a user plane protocol data unit (PDU) session for AIoT data transfer. This solution reuses the existing heavy' duty PDU session mechanism initiated by the AIoT device. The PDU session is associated with the individual AIoT device.

[0006] Another potential solution proposes to use a PDU session but only for topology 2 and only between the RAN and the AMF. The control plane is still used for data transmission between the AMF and the AF.SUMMARY

[0007] Technical advantages are generally achieved, by implementations of this disclosure which describe methods, apparatus, and system.

[0008] In accordance w ith implementations, an AIoT MF entity in a network receives AIoT sendee information for an AIoT senice associated w ith a group of AIoT devices. The AIoT sen ice information indicates at least one of first information for AIoT plane selection, second information for AIoT reader selection, or additional assistant information provided by an application function (AF) entity associated with the AIoT sen ice used by the network. The AIoT MF entity transmits, to an AIoT reader device, the AIoT sen ice information and an AIoT sendee instruction based on the AIoT senice information.

[0009] In some implementations, the AIoT sendee information may indicate the first information for AIoT plane selection. The AIoT MF entity may select a plane for data delivery for the AIoT service based on a network status and the first information for AIoT plane selection. The plane may be one of a network control plane used for the AIoT service or a netw ork user plane being used for the AIoT service. Based on that the plane selected is the network user plane, the AIoT service instruction may indicate the AIoT reader device to establish an AIoT user plane session for the data delivery. Or, based on that the plane selected is the network control plane, the AIoT service instruction may indicate the AIoT reader device to use the network control plane for the data delivery.

[0010] In some implementations, the AIoT user plane session may include a protocol data unit (PDU) session.

[0011] In some implementations, the AIoT service information may indicate the second information for AIoT reader selection. The second information for AIoT reader selection may indicate at least one of target location information of the AIoT reader device or an identifier of the AIoT reader device.

[0012] In some implementations, the AIoT reader device may be a user equipment (UE) or a base station.

[0013] In some implementations, the AIoT service information may indicate the additional assistant information provided by the AF entity. The additional assistant information may indicate at least one of number information related to the AIoT service or size information related to the AIoT service.

[0014] In some implementations, the number information may indicate a number of AIoT services for one AIoT service or for the group of AIoT devices.

[0015] In some implementations, the size information may indicate a data size for one message being sent or received from one AIoT device or for the group of AIoT devices for one service request.

[0016] In some implementations, the additional assistant information provided by the AF entity may further include AIoT data granularity information. The AIoT data granularity information may be used by the AIoT MF entity or the AIoT reader device to aggregate collected data from the group of AIoT devices. The AIoT data granularity information may indicate an aggregation correlation identifier per AIoT reader, per AIoT service, per AIoT group, or per area.

[0017] In some implementations, the aggregation correlation identifier per area may include the aggregation correlation identifier per cell, per tracking area, or per other geographic unit.

[0018] In some implementations, the AIoT service information may be received from a unified data entity. The unified data entity may include a unified data management (UDM) entity or a unified data repositoiy (UDR) entity.

[0019] In some implementations, the AIoT service information may be received from a network exposure function (NEF) entity.

[0020] In accordance with implementations, an AIoT reader device receives, from an AIoT management (MF) entity, a first AIoT service instruction indicating to establish an AIoT user plane session for an AIoT service or a second AIoT service instruction indicating the AIoT reader device to use an AIoT control plane for data delivery. Based on receiving the first AIoT service instruction, the AIoT reader device establishes, with a network anchor function (UPF) entity, the AIoT user plane session for the AIoT service. Or, based on receiving the second AIoT service instruction, the AIoT reader device communicates, with the AIoT MF entity, using the AIoT control plane for the data delivery.

[0021] In some implementations, before receiving the first AIoT service instruction or the second AIoT service instruction, the AIoT reader device may transmit, to the AIoT MF entity, AIoT registration information associating the AIoT reader device with the AIoT service.

[0022] In some implementations, the AIoT user plane session may comprise a protocol data unit (PDU) session dedicated for the AIoT service.

[0023] In some implementations, to establish the AIoT user plane session, the AIoT reader device may transmit a PDU session establishment request message including an indication indicating that the PDU session is for the AIoT sendee.

[0024] In some implementations, the first AIoT service instruction or the second AIoT sen ice instruction may indicate an identifier of a dedicated network domain or a dedicated network slice for the AIoT service.

[0025] In some implementations, the AIoT reader device may receive user data from one or more AIoT devices. The AIoT reader device may transmit, to an application function (AF) entity, the user data via the AIoT user plane session.

[0026] In some implementations, the AIoT reader device may aggregate, based on the first AIoT senice instruction or the second AIoT senice instruction from the AIoT MF entity, AIoT user data from at least two AIoT devices to generate user data to be transmitted to the AIoT MF entity for the AIoT MF entity to fonvard the user data to an AF entity.

[0027] In some implementations, the AIoT reader device may receive, from an AF entity, user data via the AIoT user plane session. The AIoT reader device may transmit, to one or more AIoT devices, the user data.

[0028] In some implementations, the user data may include aggregated user data for at least two AIoT devices. The AIoT reader device may disaggregate the aggregated user data to generate disaggregated AIoT user data. The AIoT reader device may transmit, to the at least two AIoT devices, the disaggregated AIoT user data, respectively.

[0029] In this way, the disclosed mechanisms could provide significant technical advantages in managing AIoT communications. By introducing an AIoT management function entity that dynamically selects between control and user planes based on network conditions and / or policy, the technical solutions described in this application could achieve efficient data delivery while avoiding control plane congestion. The flexible reader selection between base stations and UEs, combined with data aggregation capabilities, could enable scalable handling of large AIoT deployments. Additionally, the policy-driven approach could allow optimizing resource utilization without requiring modifications to power-constrained AIoT devices, thereby providing an efficient solution for managing large-scale AIoT communications in the wireless networks.BRIEF DESCRIPTION OF THE DRAWINGS

[0030] For a more complete understanding of the present disclosure, and the advantages thereof, reference is now made to the following descriptions taken in conjunction w ith the accompanying drawings, in which:

[0031] FIG. 1 shows an example AIoT connectivity topology of Topology 1;

[0032] FIG. 2 shows an example AIoT connectivity topology of Topology 2;

[0033] FIG. 3 shows an example system architecture for Topology 1, in accordance with some implementations;

[0034] FIG. 4 shows an example system architecture for Topology 2, in accordance w ith some implementations;

[0035] FIGs. 5A-5B illustrate a procedure flow for dedicated PDU session establishment for a large group of AIoT devices for Topology 1, in accordance with some implementations;

[0036] FIGs. 6A-6B illustrate a procedure flow of the AIoT group inventory’ service for unknown group member(s) within a certain location for Topology 2, in accordance with some implementations;

[0037] FIG. 7 illustrates a flow- diagram of operations performed by an AIoT reader, according to some implementations;

[0038] FIG. 8A shows a flow chart of a method performed by an AIoT MF entity, in accordance with some implementations;

[0039] FIG. 8B shows a flow chart of a method performed by an AIoT reader device, in accordance with some implementations;

[0040] FIG. 9 illustrates an example wireless communication system, in accordance with some implementations;

[0041] FIG. 10 illustrates an example communication system, in accordance with some implementations;

[0042] FIGs. 11A and 11B illustrate example devices, in accordance with some implementations; and

[0043] FIG. 12 shows a block diagram of a computing system, in accordance with some implementations.

[0044] Corresponding numerals and symbols in the different figures generally refer to corresponding parts unless otherwise indicated. The figures are drawn to clearly illustrate the relevant aspects of the embodiments and are not necessarily drawn to scale.DETAILED DESCRIPTION

[0045] An ambient power-enabled Internet of Things device is an loT device powered by energy harvesting, being either battery-less or with limited energy storage capability (e.g., using a capacitor). Ambient loT (AIoT) devices, also known as ambient intelligence or ambient computing devices, are a subset of loT devices that operate in the background, using sensors, data analytics, and connectivity to create intelligent and adaptive environments. AIoT devices are often unobtrusive, embedded in our surroundings, and they provide a continuous flow of data that can be analyzed and acted upon to improve various aspects of our lives.

[0046] AIoT devices are characterized by their ability to collect data from their surroundings, process the collected data, and respond autonomously to changing conditions, making the AIoT devices well-suited for a variety of applications where automation and adaptability are important.

[0047] Ambient loT devices encompass a wide range of applications and can be found in various settings. This disclosure provides some non-limiting examples of AIoT devices. AIoT devices may be characterized according to their energy storage capacity, and capability of generating radio frequency (RF) signals for their transmissions. For example, AIoT devices may be characterized as no energy storage at all, or with limited energy storage.

[0048] Relying on these storage capacities, the 3GPP study considers the following set of AIoT devices:- Device A, having no energy storage, no independent signal generation / amplification (i.e. backscattering transmission);- Dev ice B, having energy storage, but no independent signal generation (i.e. backscattering transmission) (use of stored energy can include amplification for reflected signals); and- Device C: having energy storage, has independent signal generation (i.e., active RF components for transmission).

[0049] The vaiying energy storage and signal generation capabilities of these device ty pes may utilize different approaches to data delivei . While Dev ice A may use the most energy-efficient communication method due to its lack of energy storage, Devices B and C can support more complex protocols but still utilize certain levels of power management to maintain operational efficiency.

[0050] The limited energy storage can be different among implementations within Device B or implementations w ithin Device C, and different between Device B and Device C. Such storage is expected to be order(s) of magnitude smaller than a narrowband-IoT (NB-IoT) device would typically include.

[0051] Devices A, B, and C are able to demodulate control, data, etc. from the relevant entity in the RAN according to the connectivity topology.

[0052] Current solutions do not consider the future possibility of large volumes of AIoT data within one network, when the number of AIoT devices within one network can become very large. For example, within the considered density of 1.5 devices per square meter, a 10 meter cell could have nearly 500 devices, assuming the cell is circular in shape.

[0053] A control plane solution is suitable for a small volume of AIoT data from one or a limited number of AIoT devices. But when the number of AIoT devices is large, the amount of data transferred, which is usually proportional to the number of AIoT devices and data rate of each AIoT device (e.g. 5 kbps), can also be large. Using the control plane can significantly impact the overall system performance because the control plane is designed and implemented for control signaling but not for user data.

[0054] Topology 2 uses an intermediate node (e.g. UE) as a reader. For Topology 2, the aggregated data size from the UE to the gNB can be big, which may not be suitable for control plane.

[0055] Currently, there is no user plane (UP) or control plane (CP) selection mechanism based on network condition or policy except static configuration. One shared PDU session solution relies on the existing PDU session mechanism, which requires the AIoT device to initiate the PDU session establishment. However, this approach is not suitable for the AIoT device with limited power storage.

[0056] An AIoT device has no visibility of the user plane or the control plane, or knowing whether the reader is a UE or gNB. So, the decision by the network side to use the control plane or the user plane for the AIoT data delivery based on network conditions could be advantageous. But, there is no control plane or data plane selection mechanism being considered in 3GPP SA2. In short, current solutions are not suitable for large amounts of data transfer for AIoT services.

[0057] To address these challenges, this disclosure describes a novel network architecture that intelligently manages AIoT communications while considering device capabilities, network conditions, and / or service requirements. This disclosure provides a new mechanism for the network to select between a control plane and a user plane fordata delivery in AIoT transmission based on the policy and / or network conditions. The described mechanism enhances cellular user plane for AIoT communication.

[0058] FIG. 3 shows an example system architecture for Topology 1, in accordance w ith some implementations. In FIG. 3, an AIoT device (e.g., AIoT device 302) communicates data with the AF entity 308 that provides the AIoT service using the data plane (e.g., user plane) through the gNB (e.g., gNB 304) and the user plane function (UPF) entity 306. In Topology 1 of FIG. 3, gNB 304 can act as the AIoT reader for the AIoT device 302. A new function entity, AIoT management function (AIoT MF) entity 310 can be added to the network 300. AIoT MF entity 310 can communicate control signals w ith other network entities in network 300, such as the AMF entity 312, the session management function (SMF) entity 314, the unified data management (UDM) 316, and the network exposure function (NEF) 318. Details of the AIoT MF entity are further described below.

[0059] FIG. 4 shows an example system architecture for Topology 2, in accordance with some implementations. In FIG. 4, AIoT device(s) (e.g., AIoT devices 402a and / or 402b) can communicate, via the intermediate node (or assistant node) 420, data with the AF entity 408 that provides the AIoT service using the data plane through the gNB (e.g., gNB 404) and the user plane function (UPF) entity 406. In Topology 2 of FIG. 4, the assistant node 420 can act as the AIoT reader for the AIoT devices 402a and 402b. The AIoT MF entity 410 can be added to the network 400. AIoT MF entity 410 can communicate control signals with other network entities in network 400, such as the AMF entity 412, the SMF entity 414, the UDM 416, and the NEF 418. Details of the AIoT MF entity are further described below. For Topology 2, the intermediate node 420 can be considered as the AIoT reader. The intermediate node 420 can be a UE. The intermediate node 420 directly interacts with AIoT device(s) to receive D2R data from the AIoT device(s) and sends commands and R2D data from the AIoT MF to the AIoT device(s).

[0060] If the user plane is selected, an AIoT reader can aggregate the collected data from a group of AIoT devices or all the AIoT devices associated with the AIoT reader and send the aggregated collected data to the AF via the user plane (e.g., a dedicated PDU session).

[0061] The aggregation mechanism significantly reduces signaling overhead and improves network efficiency by consolidating multiple AIoT device transmissions into unified data packets. This is particularly beneficial in dense deployments where hundreds or thousands of AIoT devices may be active within a single cell.

[0062] The AIoT MF entity (e.g., entity 310 or 410) can be enhanced for AIoT reader and plane selection. The AIoT MF entity can interact with the AIoT service provider’s AF entity for Tag management (e.g., discovery, access, security, service trigger, and / or mobility), translate the service request from the AF entity to cellular internal service requests to other network functions, and conduct AIoT operation(s) within the cellular network system.

[0063] The AIoT MF entity can perform AIoT device group management, including group creation / modification / termination .

[0064] The AIoT MF entity may interact with a UE -based AIoT reader, which may use other non-3GPP radio access technology (RAT) technologies.

[0065] The AIoT MF entity may perform AIoT reader management, including registration and selection.

[0066] The AIoT MF entity can perform the user plane and control plane selection for AIoT device data. When the control plane is selected, the AIoT MF entity can retrieve AIoT user data via the AIoT reader and forw ard the AIoT user data to the AF entity, as well as conduct charging procedure.

[0067] The AIoT MF entity can perform the RAN and AIoT reader selection, which can be based on the location of the AIoT device(s), or other selection policy.

[0068] The implementations based on the user plane or control plane selection are described below.

[0069] A new policy (e.g., AIoT plane selection policy) may be utilized for the selection of a plane (e.g., the user plane or control plane) for the AIoT service. The policy- driven approach enables dynamic adaptation to changing network conditions and service requirements, ensuring optimal use of network resources while maintaining service quality. This flexibility can be beneficial in scenarios with varying numbers of active AIoT devices and different traffic patterns. The policy can be provided by the AIoT client or the mobile network operator. The policy can be provisioned into the mobile network function(s), such as the UDM entity, the AIoT MF entity, and the policy control function (PCF) entity. When the policy is provided by the AIoT client, the policy is transferred from the AIoT client’s AF entity to a network function (e.g., the UDM entity, the PCF entity) via the NEF entity. The AIoT MF entity retrieves the policy from the UDM entity or the PCF entity or other network operation, administration, and management (OAM) via the existing service-Based interface (SBI) protocol stack. The AIoT plane selection policy may include:• AIoT sendee characteristic (e.g., periodic or one time, frequency of the periodic operation);• AIoT group information, including: o group ID(s) associated w ith this AIoT service, o User data size per AIoT device for each group, and o Expected number of AIoT devices belonging to a group ID.

[0070] An AIoT client’s capability to support the user plane or the control plane may require the AIoT client (e.g., an AF entity) to use different interfaces w ith the mobile network. For example, the control plane uses N33 (reference point between the NEF entity and the AF entity) via the NEF entity, while the user plane uses N6 (reference point between the UPF entity and a data network) via the UPF entity. The AIoT client may only need to support one interface. Therefore, it is desirable for the AIoT client to indicate its capability to the mobile netw ork.

[0071] The AIoT client’s capability information may indicate AIoT client’s preference on using the user plane or the control plane for certain AIoT sen ice or AIoT groups. Examples of the preference may be preferring the user plane, preferring the control plane, or leaving for network decide the plane. Without the preference indication from the AIoT client, the default selection using control plane may be utilized.

[0072] The AIoT client’s capability information may indicate the user plane or the control plane selection criteria, such as the time (start or end time of AIoT sendee, duration for the AIoT operation), the location, the network condition threshold (e.g., AIoT sendee throughput, latency, packet error rate, network control plane traffic condition), the number of AIoT devices being detected, and so on.

[0073] The AIoT client’s capability information may indicate the IP address and port information for the control plane or user plane interface in the AF entity to receive the AIoT data. The control plane or the user plane may use different IP addresses and ports in the AIoT client end.

[0074] The AIoT client’s capability information may indicate AIoT application level specific data protocol information, w hich can be used when there is a dedicated AIoT application level protocol for the data delivery.

[0075] The AIoT client’s capability information may optionally indicate an AIoT reader selection policy. The AIoT reader selection policy may be provided by the mobile network OAM. The AIoT reader policy is used by the AIoT MF to select the AIoT reader w hich can be an intermediate node (such as a UE) or a gNB based on the plane selection policy. The AIoT reader selection policy may indicate:• selecting a gNB or a UE as the AIoT reader,• the AIoT reader ID (which can be a UE identifier or a gNB identifier) if it is preconfigured,• the AIoT reader type (intermediate node or gNB), and• AIoT selection criteria: based on time, location, type of service, the network or the intermediate node (UE) condition and status.

[0076] If the AIoT plane selection policy is included in a policy associated with theAIoT service, this AIoT plane selection policy can be used by the AIoT MF or other network function entity to make decisions on user plane or control plane selection.

[0077] The implementations based on the user plane or control plane selection can also include a new network data analytic function (NWDAF) analytic report (e.g., an AIoT sendee and traffic analytic report w ith an AIoT sen ice and traffic analytic report ID), which is provided by the NWDAF entity^ for the network condition and traffic status related to the AIoT sendee. The AIoT MF can use the NWDAF analytic report to make plane selection and meet the selection criteria defined in the AIoT plane selection policy if it exists. The AIoT sen ice and traffic analytic report can indicate:• the analytic report of the AIoT sendee operating in the network, such as the number of AIoT devices detected, the total AIoT data throughput, the error rate (the report can be per AIoT sendee, per AIoT group, per AIoT reader, or a defined operation area based);• the analytic report of the control plane utilization rate for the user plane traffic, control plane congestion status; and• the analytic report of dedicated user plane (e.g., PDU) sessions for the AIoT sendee.

[0078] The implementations based on the user plane or control plane selection may include allowing other network management other than AIoT MF, such as OAM function, AMF to select the AIoT reader, which can be an intermediate node (such as UE) or gNB based on the plane selection policy.

[0079] The implementations based on dedicated data plane establishment for AIoT data transmission are described below-.

[0080] The implementations based on dedicated data plane establishment include new indication and information of selection of user plane or control plane for an AIoT service which is delivered from AIoT MF to an AIoT reader. The AIoT reader can be an intermediate node (such as a UE) or a gNB. The selection indication and information can be conveyed via the AIoT control messages bet ween the AIoT MF and the gNB (N2 interface when the AIoT reader is or is in gNB), or between the AIoT MF and the UE (Ni interface when AIoT reader is in a UE acting as intermediate Node).[oo8i] The selection indication and information can include a user plane or control plane selection result indication. The AIoT reader creates a dedicated control or user plane for the AIoT user data based on the user plane or control plane selection result indication.

[0082] The selection indication and information can include AIoT plane information, such as the IP address and port information for the control plane or the user plane interface in the AF entity to receive the AIoT user data. The control plane and the user plane may use different IP addresses and ports in the AIoT client end. The AIoT plane information can include AIoT application protocol specific information, used by the AIoT reader, to exchange user data with the AF entity using an application specific protocol.

[0083] The selection indication and information can include AIoT data granularity information. For the user plane, the PDU session can be per AIoT reader, per AIoT service, per AIoT group, or per area (such as per cell, per tracking area, or other geographic units) based. For the control plane, the AIoT data received from the AIoT device(s) can be aggregated and sent to the AF entity together. The aggregation can be per AIoT reader, per AIoT sen ice, per AIoT group, or per area (such as per cell, per tracking area, or other geographic units) based.

[0084] The selection indication and information can include a NAS message which is prepared by the AIoT MF for the AIoT reader to put into the PDU session establishment request message.

[0085] The existing PDU session establishment is only initiated by the UE. To reuse the existing mechanism as much as possible and have less impact on the existing mechanism, the implementations based on dedicated data plane establishment can utilize a solution that the dedicated PDU establishment is initiated by the AIoT reader acting as a UE, no matter the AIoT reader is in the UE or gNB. The AIoT MF entity prepares the appropriate information for PDU session establishment and delivers to the AIoT reader as a prepared NAS message for AIoT reader to use to initiate the PDU session establishment as the UE.

[0086] In case the AIoT reader is the gNB, the selection indication and information are conveyed via an enhanced next generation application protocol (NGAP) message (between the gNB and the AMF) in order to trigger the gNB as an AIoT reader to establish a PDU session acting as a UE.

[0087] In case the AIoT reader is the UE, the selection indication and information are conveyed via an enhanced NAS message in order to trigger the UE to establish a PDU session establishment for the AIoT service.[oo88] During the PDU session establishment procedure, the PDU session establishment request message sent by the AIoT reader includes an indication that the PDU session is for an AIoT service. Therefore, the 5G core network can, based on this indication, differentiate with other PDU sessions and may conduct some AIoT specific operations.

[0089] For the dedicated AIoT data plane, the AIoT data can be del ivered via the N6 interface via the UPF entity.

[0090] FIGs. 5A-5B illustrate a procedure flow for dedicated PDU session establishment for a large group of AIoT devices for Topology 1, in accordance with some implementations.

[0091] At the operation 551, the AIoT service policy associated with the AIoT service subscription is provisioned from the AF entity 508 to the UDM entity 516 using the existing policy provisioning mechanism. The AIoT service policy contains the AIoT serv ice type, operation characteristics (such as periodic or one time transaction, operation interval if it is a periodic operation), group information (e.g., Group 1), as well as new implementations related to traffic plane selection (including: control plane or data plane data deliveiy preference and capability (e.g. support for the user plane and / or the control plane, the IP address / port for the user plane or the control plane in the AF entity for AIoT data), plane selection criteria (e.g., upto network decision), the expected total number of device within a group ( e.g., 1000 devices within Group 1), the maximum data size for each AIoT device (e.g., 125 bytes), and the data rate (e.g., 5 kbps).

[0092] At the operation 552, the AF entity 508 sends an AIoT service request to theAIoT MF entity 510 via the NEF entity 518 to start the AIoT sendee for the group (e.g., Group 1). The AIoT service request includes the sendee start time (X). The AIoT MF entity 510 may be a part of the AMF entity 512. In some implementations, the AIoT MF entity 510 may be a separate network entity from the AMF entity 512.

[0093] At the operation 553, the AIoT MF entity 510 retrieves the AIoT service policy from the UDM entity 516.

[0094] At the operation 554, the AIoT MF entity 510 may collect the network condition and traffic information related to the AIoT service from the NWDAF entity 530, if the selection policy includes the network condition criteria.

[0095] At the operation 555, the AIoT MF entity 510, based on the size of potential data for the group, the AIoT ser ice policy, and the network condition, selects a dedicated PDU session for the group (e.g., Group 1) and selects an AIoT reader in the gNB 504 as a reader based on the location criteria.

[0096] At the operation 556, the AIoT MF entity 510 sends an AIoT service request message to the AIoT reader in the gNB 504 via the N2 interface between the gNB 504 and the AMF entity 512. The AIoT service request message includes the user plane indication, the IP address / port in the AF entity 508 for the user plane delivery, the AIoT service policy, the NAS message for PDU session establishment used by AIoT reader.

[0097] There can be another option for AIoT MF entity 510 to send the AIoT service request message to the AIoT reader in the gNB 504 without using the N2 interface. This option treats the AIoT reader in the gNB 504 as a UE with a specially allocated UE ID, so the AIoT MF entity 510 sends the AIoT service request message using the NASt message with the UE ID to the gNB 504. With the UE ID, the gNB 504 knows the UE is its AIoT reader.

[0098] At the operation 557, acting like a UE, the AIoT reader in the gNB 504 initiates the PDU session establishment for the group (e.g., Group 1) traffic and establishes a PDU session between the reader in the gNB 504 and the UPF entity 506 (using the NAS message from the operation 556) using the existing PDU session establishment mechanism. In the PDU session establishment request message, an AIoT PDU session indication is included. So, the 5G core network can differentiate this PDU session from the normal PDU session establishment.

[0099] At the operation 558, after the PDU session establishment completes, the AIoT MF entity 510 sends the AIoT service response message to the AF entity 508 via the NEF entity 518. The AIoT service response message includes the indication of the user plane selection.

[0100] At the operation 559, when the sendee start time (X) is up, the AIoT reader in the gNB 504 starts to communicate with the AIoT devices (e.g., AIoT device 502) in the group to collect data from those AIoT devices.

[0101] At the operation 560, the AIoT reader in the gNB 504 aggregates all the data from the AIoT devices in the group (e.g., Group 1) for each operation cycle and creates an aggregated AIoT data packet for the aggregated AIoT data using the AF entity 508’s user plane IP address / port as the IP packet’s destination IP address / port.

[0102] At the operation 561, the AIoT reader in the gNB 504 sends the aggregated AIoT data via a dedicated PDU session to the AF entity 508.

[0103] At the operation 562, the AF entity 508 sends the AIoT data for AIoT devices in the group (e.g., Group 1) via the dedicated PDU session to the AIoT reader in the gNB 504-

[0104] At the operation 563, the AIoT reader in the gNB 504 transmits the AIoT data from the AF entity 508 to AIoT devices (e.g., AIoT device 502) in the group (e.g., Group 1). The AF entity 508 may send an aggregated packet which contains different data for different AIoT devices within the group (e.g., Group 1). The AIoT reader in the gNB 504 can disaggregate the packet and send the data to the respective individual AIoT devices accordingly.

[0105] FIGs. 6A-6B illustrate a procedure flow of the AIoT group inventory service for unknown group member(s) within a certain location for Topology 2, in accordance w ith some implementations. The procedure flow for Topology 2 in FIGs. 6A-6B is similar to the procedure flow for Topology 1 in FIGs. 5A-5B, except that the AIoT service request message at the operation 656 is carried over the Nt interface instead.

[0106] At the operation 651, the AIoT sen ice policy associated with the AIoT service subscription is provisioned from the AF entity 608 to the UDM entity 616 using the existing policy provisioning mechanism. The AIoT service policy contains the AIoT service type, operation characteristics (such as periodic or one time transaction, operation interval if it is a periodic operation), group information (e.g., Group 1), as well as new implementations related to traffic plane selection (including: control plane or data plane data deliveiy preference and capability (e.g. support for the user plane and / or the control plane, the IP address / port for the user plane or the control plane in the AF entity for AIoT data), plane selection criteria (e.g., up to network decision), the expected total number of device within a group ( e.g., 1000 devices within Group 1), the maximum data size for each AIoT device (e.g., 125 bytes), and the data rate (e.g., 5 kbps).

[0107] At the operation 652, the AF entity 608 sends an AIoT service request to the AIoT MF entity 610 via the NEF entity 618 to start the AIoT service for the group (e.g., Group 1). The AIoT service request includes the service start time (X). The AIoT MF entity 610 may be a part of the AMF entity 612. In some implementations, the AIoT MF entity 610 may be a separate network entity from the AMF entity 612.

[0108] At the operation 653, the AIoT MF entity 610 retrieves the AIoT sendee policy from the UDM entity 616.

[0109] At the operation 654, the AIoT MF entity 610 may collect the network condition and traffic information related to the AIoT sendee from the NWDAF entity 630, if the selection policy includes the network condition criteria.

[0110] At the operation 655, the AIoT MF entity 610, based on the size of potential data for the group, the AIoT senice policy, and the network condition, selects a dedicatedPDU session for the group (e.g., Group 1) and selects an AIoT reader in the UE 620 as a reader based on the location criteria.

[0111] At the operation 656, the AIoT MF entity 610 sends an AloT service request message to the AIoT reader in the UE 620 via the Nt interface between the UE 620 and the AMF entity 612. The AIoT sendee request message includes the user plane indication, the identity of the AIoT traffic destination (e.g., the IP address / port / data network name (DNN) / associated network slice information) in the AF entity 608 for the user plane delivery, the AIoT sendee policy, the NAS message for PDU session establishment used by AIoT reader.

[0112] At the operation 657, the AIoT reader in the UE 620 initiates the PDU session establishment for the group (e.g., Group 1) traffic and establishes a PDU session between the reader in the UE 620 and the UPF entity 606 (using the NAS message from the operation 656) using the existing PDU session establishment mechanism. In the PDU session establishment request message, an AIoT PDU session indication is included. So, the 5G core network can differentiate this PDU session from the normal PDU session establishment.

[0113] At the operation 658, after the PDU session establishment completes, the AIoT MF entity 610 sends the AIoT service response message to the AF entity 608 via the NEF entity 618. The AIoT service response message includes the indication of the user plane selection.

[0114] At the operation 659, when the sendee start time (X) is up, the AIoT reader in the UE 620 starts to communicate w ith the AIoT devices (e.g., AIoT device 602) in the group to collect data from those AIoT devices.

[0115] At the operation 660, the AIoT reader in the UE 620 aggregates all the data from the AIoT devices in the group (e.g., Group 1) for each operation cycle and creates an aggregated AIoT data packet for the aggregated AIoT data using the AF entity 608’s user plane IP address / port as the IP packet’s destination IP address / port.

[0116] At the operation 661, the AIoT reader in the UE 620 sends the aggregated AIoT data via a dedicated PDU session to the AF entity 608.

[0117] At the operation 662, the AF entity 608 sends the AIoT data for AIoT devices in the group (e.g., Group 1) via the dedicated PDU session to the AIoT reader in the UE 620.

[0118] At the operation 663, the AIoT reader in the UE 620 transmits the AIoT data from the AF entity 608 to AIoT devices (e.g., AIoT device 602) in the group (e.g., Group1). The AF entity 608 may send an aggregated packet which contain different data for different AIoT devices within the group (e.g., Group 1). The AIoT reader in the UE 620 can disaggregate the packet and send the data to the respective individual AIoT devices accordingly.

[0119] FIG. 7 illustrates a flow diagram of operations performed by an AIoT reader, according to some implementations. The AIoT reader may be in the UE or in the gNB. At the operation 702, the AIoT reader receives an AIoT service request from the AIoT MF entity. At the operation 704, the AIoT reader determines whether the AIoT service request indicates the user plane selection. If the determination at the operation 704 is “No” (no user plane selection), at the operation 706, the AIoT reader delivers AIoT data from the AIoT device(s) to the AIoT MF entity via the control plane. If the determination at operation 704 is “Yes” (user plane selection), the flow proceeds to the operation 708, where the AIoT reader initiates establishment of a dedicated AIoT PDU session for the AIoT sendee. At the operation 710, the AIoT reader starts the AIoT sendee and retrieves user data from the AIoT device(s). At the operation 712, the AIoT reader aggregates the user data from the AIoT device(s). At the operation 714, the AIoT reader sends the aggregated AIoT user data to the AF entity via the dedicated AIoT PDU session.

[0120] FIG. 8A shows a flow chart of a method 800 performed by an AIoT MF entity, in accordance with some implementations. The AIoT MF entity may include computer- readable code or instructions executing on one or more processors of the AIoT MF entity. Coding of the software for carrying out or performing the method 800 is well within the scope of a person of ordinary' skill in the art having regard to the present disclosure. The method 800 may include additional or fewer operations than those shown and described and may be carried out or performed in a different order. Computer-readable code or instructions of the software executable by the one or more processors may be stored on at least one non-transitoiy computer-readable medium, such as for example, at least one memory of the AIoT MF entity. In some embodiments, the method 800 may be performed by one or more of units or modules (e.g., an integrated circuit) of the AIoT MF entity, such as field programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

[0121] The method 800 starts at the operation 802, where the AIoT MF entity in a network receives AIoT service information for an AIoT service or a group of AIoT devices, where the group of AIoT devices are associated with the AIoT service. The AIoT service information indicates at least one of first information for AIoT plane selection, second information for AIoT reader selection, or additional assistant information provided by an application function (AF) entity associated with the AIoT service used bythe network. At the operation 804, the AIoT MF entity transmits, to an AIoT reader device, the AIoT service information and an AIoT sendee instruction based on the AIoT sendee information.

[0122] In some implementations, the AIoT sendee information may indicate the first information for AIoT plane selection. The AIoT MF entity may select a plane for data delivery for the AIoT service based on a network status and the first information for AIoT plane selection. The plane may be one of a network control plane used for the AIoT service or a network user plane being used for the AIoT service. Based on that the plane selected is the network user plane, the AIoT service instruction may indicate the AIoT reader device to establish an AIoT user plane session for the data delivery. Or, based on that the plane selected is the network control plane, the AIoT service instruction may indicate the AIoT reader device to use the network control plane for the data delivery.

[0123] In some implementations, the AIoT user plane session may include a protocol data unit (PDU) session.

[0124] In some implementations, the AIoT service information may indicate the second information for AIoT reader selection. The second information for AIoT reader selection may indicate at least one of target location information of the AIoT reader device or an identifier of the AIoT reader device.

[0125] In some implementations, the AIoT reader device may be a user equipment (UE) or a base station.

[0126] In some implementations, the AIoT service information may indicate the additional assistant information provided by the AF entity. The additional assistant information may indicate at least one of number information related to the AIoT service or size information related to the AIoT service.

[0127] In some implementations, the number information may indicate a number of AIoT services for one AIoT service or for the group of AIoT devices.

[0128] In some implementations, the size information may indicate a data size for one message being sent or received from one AIoT device or for the group of AIoT devices for one service request.

[0129] In some implementations, the additional assistant information provided by the AF entity may further include AIoT data granularity information. The AIoT data granularity information may be used by the AIoT MF entity or the AIoT reader device to aggregate collected data from the group of AIoT devices. The AIoT data granularityinformation may indicate an aggregation correlation identifier per AIoT reader, per AIoT sendee, per AIoT group, or per area.

[0130] In some implementations, the aggregation correlation identifier per area may include the aggregation correlation identifier per cell, per tracking area, or per other geographic unit.

[0131] In some implementations, the AIoT service information may be received from a unified data entity. The unified data entity may include a unified data management (UDM) entity or a unified data repository (UDR) entity.

[0132] In some implementations, the AIoT service information may be received from a network exposure function (NEF) entity.

[0133] FIG. 8B shows a flow chart of a method 850 performed by an AIoT reader device, in accordance with some implementations. The AIoT reader device may include computer-readable code or instructions executing on one or more processors of the AIoT reader device. Coding of the software for carrying out or performing the method 850 is well within the scope of a person of ordinary skill in the art having regard to the present disclosure. The method 850 may include additional or fewer operations than those shown and described and may be carried out or performed in a different order. Computer-readable code or instructions of the software executable by the one or more processors may be stored on at least one non-transitoiy computer-readable medium, such as for example, at least one memory of the AIoT reader device. In some embodiments, the method 850 may be performed by one or more of units or modules (e.g., an integrated circuit) of the AIoT reader device, such as field programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

[0134] The method 850 starts at the operation 852, where the AIoT reader device receives, from an AIoT management (MF) entity, a first AIoT service instruction indicating to establish an AIoT user plane session for an AIoT service or a second AIoT service instruction indicating the AIoT reader device to use an AIoT control plane for data delivery. At the operation 854, based on receiving the first AIoT sendee instruction, the AIoT reader device establishes, with a network anchor function (UPF) entity, the AIoT user plane session for the AIoT service. Or, at the operation 856, based on receiving the second AIoT service instruction, the AIoT reader device communicates, with the AIoT MF entity, using the AIoT control plane for the data delivery.

[0135] In some implementations, before receiving the first AIoT service instruction or the second AIoT service instruction, the AIoT reader device may transmit, to the AIoTMF entity, AIoT registration information associating the AIoT reader device w ith the AIoT service.

[0136] In some implementations, the AIoT user plane session may comprise a protocol data unit (PDU) session dedicated for the AIoT service.

[0137] In some implementations, to establish the AIoT user plane session, the AIoT reader device may transmit a PDU session establishment request message including an indication indicating that the PDU session is for the AIoT service.

[0138] In some implementations, the first AIoT service instruction or the second AIoT service instruction may indicate an identifier of a dedicated network domain or a dedicated network slice for the AIoT service.

[0139] In some implementations, the AIoT reader device may receive user data from one or more AIoT devices. The AIoT reader device may transmit, to an application function (AF) entity, the user data via the AIoT user plane session.

[0140] In some implementations, the AIoT reader device may aggregate, based on the first AIoT service instruction or the second AIoT service instruction from the AIoT MF entity, AIoT user data from at least two AIoT devices to generate user data to be transmitted to the AIoT MF entity for the AIoT MF entity to forward the user data to an AF entity.

[0141] In some implementations, the AIoT reader device may receive, from an AF entity, user data via the AIoT user plane session. The AIoT reader device may transmit, to one or more AIoT devices, the user data.

[0142] In some implementations, the user data may include aggregated user data for at least two AIoT devices. The AIoT reader device may disaggregate the aggregated user data to generate disaggregated AIoT user data. The AIoT reader device may transmit, to the at least two AIoT devices, the disaggregated AIoT user data, respectively.

[0143] The following references are incorporated by reference in their entireties.[1] TR22.840 (vo.4.0): Study on Ambient power-enabled Internet of Things[2] TR38.848: Study on Ambient loT (Internet of Things) in RAN[3] TR23.700-13: Study on Architecture support of Ambient power-enabled Internet of Things

[0144] FIG. 9 illustrates an example communications system 900. Communications system 900 includes an access node 910 serving user equipments (UEs) with coverage 901, such as UEs 920. In a first operating mode, communications to and from a UEpasses through access node 910 w ith a coverage area 901. The access node 910 is connected to a backhaul network 915 for connecting to the internet, operations and management, and so forth. In a second operating mode, communications to and from a UE do not pass through access node 910, however, access node 910 typically allocates resources used by the UE to communicate when specific conditions are met. Communications between a pair of UEs 920 can use a sidelink connection (shown as two separate one-way connections 925). In FIG. 9, the sidelink communication is occurring between two UEs operating inside of coverage area 901. However, sidelink communications, in general, can occur when UEs 920 are both outside coverage area 901, both inside coverage area 901, or one inside and the other outside coverage area 901. Communication between a UE and access node pair occur over uni-directional communication links, where the communication links between the UE and the access node are referred to as uplinks 930, and the communication links between the access node and UE is referred to as downlinks 935.

[0145] Access nodes may also be commonly referred to as Node Bs, evolved Node Bs (eNBs), next generation (NG) Node Bs (gNBs), master eNBs (MeNBs), secondary eNBs (SeNBs), master gNBs (MgNBs), secondary gNBs (SgNBs), network controllers, control nodes, base stations, access points, transmission points (TPs), transmission-reception points (TRPs), cells, carriers, macro cells, femtocells, pico cells, and so on, while UEs may also be commonly referred to as mobile stations, mobiles, terminals, users, subscribers, stations, and the like. Access nodes may provide wireless access in accordance with one or more wireless communication protocols, e.g., the Third Generation Partnership Project (3GPP) long term evolution (LTE), LTE advanced (LTE- A), 5G, 5G LTE, 5G NR, sixth generation (6G), High Speed Packet Access (HSPA), the IEEE 802.11 family of standards, such as 802.na / b / g / n / ac / ad / ax / ay / be, etc. While it is understood that communications systems may employ multiple access nodes capable of communicating with a number of UEs, only one access node and two UEs are illustrated for simplicity.

[0146] FIG. 10 illustrates an example communication system 1000. In general, the system 1000 enables multiple wireless or wired users to transmit and receive data and other content. The system 1000 may implement one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), or non-orthogonal multiple access (NOMA).

[0147] In this example, the communication system 1000 includes electronic devices (ED) toioa-ioioc, radio access networks (RANs) !020a-i020b, a core network 1030, apublic sw itched telephone network (PSTN) 1040, the Internet 1050, and other networks 1060. While certain numbers of these components or elements are shown in FIG. 10, any number of these components or elements may be included in the system 1000.

[0148] The EDs lotoa-toioc are configured to operate or communicate in the system 1000. For example, the EDs toioa-ioioc are configured to transmit or receive via w ireless or wired communication channels. Each ED toioa-ioioc represents any suitable end user device and may include such devices (or may be referred to) as a user equipment or device (UE), wireless transmit or receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular telephone, personal digital assistant (PDA), smartphone, laptop, computer, touchpad, wireless sensor, or consumer electronics device.

[0149] The RANs i020a-i020b here include base stations to oa-io ob, respectively. Each base station lo oa-io ob is configured to wirelessly interface with one or more of the EDs toioa-ioioc to enable access to the core network 1030, the PSTN 1040, the Internet 1050, or the other networks 1060. For example, the base stations to oa-io ob may include (or be) one or more of several well-known devices, such as a base transceiver station (BTS), a Node-B (NodeB), an evolved NodeB (eNB), a Next Generation (NG) NodeB (gNB), a gNB centralized unit (gNB-CU), a gNB distributed unit (gNB-DU), a Home NodeB, a Home eNodeB, a site controller, an access point (AP), or a wireless router. The EDs toioa-ioioc are configured to interface and communicate with the Internet 1050 and may access the core network 1030, the PSTN 1040, or the other networks 1060.

[0150] In the embodiment shown in FIG. to, the base station 1070a forms part of the RAN 1020a, which may include other base stations, elements, or devices. Also, the base station 1070b forms part of the RAN 1020b, which may include other base stations, elements, or devices. Each base station iO7Oa-iO7Ob operates to transmit or receive wireless signals within a particular geographic region or area, sometimes referred to as a “cell.” In some embodiments, multiple-input multiple-output (MIMO) technology may be employed having multiple transceivers for each cell.

[0151] The base stations iO7Oa-iO7Ob communicate with one or more of the EDs loioa-ioioc over one or more air interfaces 1090 using wireless communication links. The air interfaces 1090 may utilize any suitable radio access technology.

[0152] It is contemplated that the system 1000 may use multiple channel access functionality, including such schemes as described above. In particular embodiments,the base stations and EDs implement 5G New Radio (NR), LTE, LTE-A, or LTE-B. Of course, other multiple access schemes and w ireless protocols may be utilized.

[0153] The RANs !020a-i020b are in communication with the core network 1030 to provide the EDs toioa-ioioc with voice, data, application, Voice over Internet Protocol (VoIP), or other services. Understandably, the RANs i020a-i020b or the core network 1030 may be in direct or indirect communication with one or more other RANs (not shown). The core network 1030 may also sene as a gateway access for other networks (such as the PSTN 1040, the Internet 1050, and the other networks 1060). In addition, some or all of the EDs toioa-ioioc may include functionality for communicating with different w ireless networks over different wireless links using different wireless technologies or protocols. Instead of wireless communication (or in addition thereto), the EDs may communicate via wired communication channels to a service provider or switch (not shown), and to the Internet 1050.

[0154] Although FIG. 10 illustrates one example of a communication system, various changes may be made to FIG. 10. For example, the communication system 1000 could include any number of EDs, base stations, networks, or other components in any suitable configuration.

[0155] FIGs. 11A and 11B illustrate example devices that may implement the methods and teachings according to this disclosure. In particular, FIG. nA illustrates an example ED 1110, and FIG. 11B illustrates an example base station 1170. These components could be used in the system 1000 or in any other suitable system.

[0156] As shown in FIG. 11A, the ED 1110 includes at least one processing unit 1100. The processing unit 1100 implements various processing operations of the ED 1110. For example, the processing unit 1100 could perform signal coding, data processing, power control, input / output processing, or any other functionality enabling the ED 1110 to operate in the system 1000. The processing unit 1100 also supports the methods and teachings described in more detail above. Each processing unit 1100 includes any suitable processing or computing device configured to perform one or more operations. Each processing unit 1100 could, for example, include a microprocessor, microcontroller, digital signal processor, field programmable gate array, or application specific integrated circuit.

[0157] The ED 1110 also includes at least one transceiver 1102. The transceiver 1102 is configured to modulate data or other content for transmission by at least one antenna or NIC (Network Interface Controller) 1104. The transceiver 1102 is also configured to demodulate data or other content received by the at least one antenna 1104. Eachtransceiver 1102 includes any suitable structure for generating signals for w ireless or w ired transmission or processing signals received w irelessly or by w i re. Each antenna 1104 includes any suitable structure for transmitting or receiving wireless or wired signals. One or multiple transceivers 1102 could be used in the ED 1110, and one or multiple antennas 1104 could be used in the ED 1110. Although shown as a single functional unit, a transceiver 1102 could also be implemented using at least one transmitter and at least one separate receiver.

[0158] The ED 1110 further includes one or more input / output devices 1106 or interfaces (such as a wired interface to the Internet 1050). The input / output devices 1106 facilitate interaction with a user or other devices (network communications) in the network. Each input / output device 1106 includes any suitable structure for providing information to or receiving information from a user, such as a speaker, microphone, keypad, keyboard, display, or touch screen, including network interface communications.

[0159] In addition, the ED 1110 includes at least one memory 1108. The memory 1108 stores instructions and data used, generated, or collected by the ED 1110. For example, the memoiy 1108 could store software or firmware instructions executed by the processing unit(s) 1100 and data used to reduce or eliminate interference in incoming signals. Each memory 1108 includes any suitable volatile or non-volatile storage and retrieval device(s). Any suitable type of memory may be used, such as random access memoiy (RAM), read only memoiy (ROM), hard disk, optical disc, subscriber identity module (SIM) card, memoiy stick, secure digital (SD) memoiy card, and the like.

[0160] As shown in FIG. 11B, the base station 1170 includes at least one processing unit 1150, at least one transceiver 1152, which includes functionality for a transmitter and a receiver, one or more antennas 1156, at least one memoiy 1158, and one or more input / output devices or interfaces 1166. A scheduler, which would be understood by one skilled in the art, is coupled to the processing unit 1150. The scheduler could be included within or operated separately from the base station 1170. The processing unit 1150 implements various processing operations of the base station 1170, such as signal coding, data processing, power control, input / output processing, or any other functionality. The processing unit 1150 can also support the methods and teachings described in more detail above. Each processing unit 1150 includes any suitable processing or computing device configured to perform one or more operations. Each processing unit 1150 could, for example, include a microprocessor, microcontroller, digital signal processor, field programmable gate array, or application specific integrated circuit.

[0161] Each transceiver 1152 includes any suitable structure for generating signals for wireless or wired transmission to one or more EDs or other devices. Each transceiver1152 further includes any suitable structure for processing signals received wirelessly or by wire from one or more EDs or other devices. Although shown combined as a transceiver 1152, a transmitter and a receiver could be separate components. Each antenna 1156 includes any suitable structure for transmitting or receiving wireless or wired signals. While a common antenna 1156 is shown here as being coupled to the transceiver 1152, one or more antennas 1156 could be coupled to the transceiver(s) 1152, allowing separate antennas 1156 to be coupled to the transmitter and the receiver if equipped as separate components. Each memoiy 1158 includes any suitable volatile or non-volatile storage and retrieval device(s). Each input / output device 1166 facilitates interaction with a user or other devices (network communications) in the network. Each input / output device 1166 includes any suitable structure for providing information to or receiving / providing information from a user, including network interface communications.

[0162] FIG. 12 is a block diagram of a computing system 1200 that may be used for implementing the devices and methods disclosed herein. For example, the computing system can be any entity of UE, access network (AN), mobility management (MM), session management (SM), user plane gateway (UPGW), or access stratum (AS). Specific devices may utilize all of the components shown or only a subset of the components, and levels of integration may van from device to device. Furthermore, a device may contain multiple instances of a component, such as multiple processing units, processors, memories, transmitters, receivers, etc. The computing system 1200 includes a processing unit 1202. The processing unit includes a central processing unit (CPU) 1214, memory 1208, and may further include a mass storage device 1204, a video adapter 1210, and an I / O interface 1212 connected to a bus 1220.

[0163] The bus 1220 may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus, or a video bus. The CPU 1214 may comprise any type of electronic data processor. The memoiy 1208 may comprise any type of non-transitory system memory such as static random access memoiy (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or a combination thereof. In an embodiment, the memoiy 1208 may include ROM for use at boot-up, and DRAM for program and data storage for use w hile executing programs.

[0164] The mass storage 1204 may comprise any type of non-transitory storage device configured to store data, programs, and other information and to make the data, programs, and other information accessible via the bus 1220. The mass storage 1204 maycomprise, for example, one or more of a solid state drive, hard disk drive, a magnetic disk drive, or an optical disk drive.

[0165] The video adapter 1210 and the I / 0 interface 1212 provide interfaces to conple external input and output devices to the processing unit 1202. As illustrated, examples of input and output devices include a display 1218 coupled to the video adapter 1210 and a mouse, keyboard, or printer 1216 coupled to the I / O interface 1212. Other devices may be coupled to the processing unit 1202, and additional or fewer interface cards may be utilized. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide an interface for an external device.

[0166] The processing unit 1202 also includes one or more network interfaces 1206, which may comprise wired links, such as an Ethernet cable, or wireless links to access nodes or different networks. The network interfaces 1206 allow the processing unit 1202 to communicate with remote units via the networks. For example, the network interfaces 1206 may provide wireless communication via one or more transmitters / transmit antennas and one or more receivers / receive antennas. In an embodiment, the processing unit 1202 is coupled to a local-area network 1222 or a wide-area network for data processing and communications with remote devices, such as other processing units, the Internet, or remote storage facilities.

[0167] It should be appreciated that one or more steps of the embodiment methods provided herein may be performed by corresponding units or modules. For example, a signal may be transmitted by a transmitting unit or a transmitting module. A signal may be received by a receiving unit or a receiving module. A signal may be processed by a processing unit or a processing module. Other steps may be performed by a performing unit or module, a generating unit or module, an obtaining unit or module, a setting unit or module, an adjusting unit or module, an increasing unit or module, a decreasing unit or module, a determining unit or module, a modifying unit or module, a reducing unit or module, a removing unit or module, or a selecting unit or module. The respective units or modules may be hardware, software, or a combination thereof. For instance, one or more of the units or modules may be an integrated circuit, such as field programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

[0168] Although the description has been described in detail, it should be understood that various changes, substitutions and alterations can be made without departing from the spirit and scope of this disclosure as defined by the appended claims. Moreover, the scope of the disclosure is not intended to be limited to the particular embodiments described herein, as one of ordinary skill in the art will readily appreciate from this disclosure that processes, machines, manufacture, compositions of matter, means,methods, or steps, presently existing or later to be developed, may perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.

Claims

WHAT IS CLAIMED IS:

1. A method, comprising: receiving, by an Ambient Internet of Things (AIoT) management function (MF) entity in a network, AIoT service information for an AIoT service associated with a group of AIoT devices, the AIoT service information indicating at least one of: first information for AIoT plane selection, second information for AIoT reader selection, or additional assistant information provided by an application function (AF) entity associated with the AIoT service used by the network; and transmitting, by the AIoT MF entity to an AIoT reader device, the AIoT service information and an AIoT service instruction based on the AIoT service information.

2. The method of claim 1, the AIoT sendee information indicating the first information for AIoT plane selection, the method further comprising: selecting, by the AIoT MF entity, a plane for data deliveiy for the AIoT sendee based on a network status and the first information for AIoT plane selection, the plane being one of a network control plane used for the AIoT sendee or a network user plane being used for the AIoT sendee, wherein, based on that the plane selected is the network user plane, the AIoT service instruction indicates the AIoT reader device to establish an AIoT user plane session for the data delivery, or wherein, based on that the plane selected is the network control plane, the AIoT sendee instruction indicates the AIoT reader device to use the network control plane for the data deliveiy7.

3. The method of claim 2, the AIoT user plane session includes a protocol data unit (PDU) session.

4. The method of any of claims 1-3, the AIoT service information indicating the second information for AIoT reader selection, the second information for AIoT reader selection indicating at least one of target location information of the AIoT reader device or an identifier of the AIoT reader device.

5. The method of claim 4, wherein the AIoT reader device is a user equipment (UE) or a base station.

6. The method of any of claims 1-5, the AIoT sen ice information indicating the additional assistant information provided by the AF entity, the additional assistantinformation indicating at least one of number information related to the AIoT service or size information related to the AIoT sendee.

7. The method of claim 6, the number information indicating a number of AIoT sen ices for one AIoT service or for the group of AIoT devices.

8. The method of claim 6, the size information indicating a data size for one message being sent or received from one AIoT device or for the group of AIoT devices for one service request.

9. The method of any of claims 1-8, the additional assistant information provided by the AF entity further including AIoT data granularity information, the AIoT data granularity information used by the AIoT MF entity or the AIoT reader device to aggregate collected data from the group of AIoT devices, the AIoT data granularity information indicating an aggregation correlation identifier per AIoT reader, per AIoT service, per AIoT group, or per area.

10. The method of claim 9, the aggregation correlation identifier per area including the aggregation correlation identifier per cell, per tracking area, or per other geographic unit.

11. The method of any of claims 1-10, wherein the AIoT service information is received from a unified data entity.

12. The method of claim 11, wherein the unified data entity includes a unified data management (UDM) entity or a unified data repository’ (UDR) entity.

13. The method of any of claims 1-12, wherein the AIoT service information is received from a network exposure function (NEF) entity.

14. A method, comprising: receiving, by an Ambient Internet of Things (AIoT) reader device from an AIoT management (MF) entity, a first AIoT service instruction indicating to establish an AIoT user plane session for an AIoT service or a second AIoT service instruction indicating the AIoT reader device to use an AIoT control plane for data delivery; and(1) based on receiving the first AIoT service instruction, establishing, by the AIoT reader device with a network anchor function (UPF) entity, the AIoT user plane session for the AIoT service; or (2) based on receiving the second AIoT service instruction, communicating, by the AIoT reader device with the AIoT MF entity, using the AIoT control plane for the data delivery.15- The method of claim 14, further comprising: before the receiving, transmitting, by the AIoT reader device to the AIoT MF entity, AIoT registration information associating the AIoT reader device with the AIoT service.

16. The method of any of claims 14-15, wherein the AIoT user plane session comprises a protocol data unit (PDU) session dedicated for the AIoT service.

17. The method of claim 16, the establishing the AIoT user plane session comprising: transmitting, by the AIoT reader device, a PDU session establishment request message including an indication indicating that the PDU session is for the AIoT service.

18. The method of claim 16, the first AIoT service instruction or the second AIoT service instruction indicating an identifier of a dedicated network domain or a dedicated network slice for the AIoT service.

19. The method of any of claims 14-18, further comprising: receiving, by the AIoT reader device, user data from one or more AIoT devices; and transmitting, by the AIoT reader device to an application function (AF) entity, the user data via the AIoT user plane session.

20. The method of any of claims 14-19, further comprising: aggregating, by the AIoT reader device based on the first AIoT service instruction or the second AIoT service instruction from the AIoT MF entity, AIoT user data from at least two AIoT devices to generate user data to be transmitted to the AIoT MF entity for the AIoT MF entity to forward the user data to an AF entity.

21. The method of any of claims 14-20, further comprising: receiving, by the AIoT reader device from an AF entity, user data via the AIoT user plane session; and transmitting, by the AIoT reader device to one or more AIoT devices, the user data.

22. The method of claim 21, the user data includes aggregated user data for at least two AIoT devices, the method further comprising: disaggregating the aggregated user data to generate disaggregated AIoT user data, the transmitting the user data comprising: transmitting, by the AIoT reader device to the at least two AIoT devices, the disaggregated AIoT user data, respectively.

23. A management function (MF) entity, comprising: at least one processor; andat least one non-transitory computer readable storage medium storing programming, the programming including instructions that, when executed by the at least one processor, cause the MF entity to perform a method according to any of claims 1-13- 24. An Ambient Internet of Things (AIoT) reader device, comprising: at least one processor; and at least one non-transitory computer readable storage medium storing programming, the programming including instructions that, when executed by the at least one processor, cause the AIoT reader device to perform a method according to any of claims 14-22.

25. A non-transitory computer-readable medium having instructions stored thereon that, when executed by an Ambient Internet of Things (AIoT) management function (MF) entity, cause the AIoT MF entity to perform a method according to any of claims 1- 13- 26. A non-transitoiy computer-readable medium having instructions stored thereon that, when executed by an Ambient Internet of Things (AIoT) reader device, cause the AIoT reader device to perform a method according to any of claims 14-22.

Images