Aiot data forwarding over intermediate node

Abstract

Example embodiments of the present disclosure provide solutions for ambient Internet of Things (AIoT) data forwarding over an intermediate node. In an example method, a terminal device receives receives, via an access and mobility management function (AMF), an AIoT configuration from an AIoT function (AIOTF), the AIoT configuration indicating forwarding mechanism for forwarding AIoT data received from at least one wireless device to a network entity or a data network (DN). The terminal device forwards the AIoT data to the network entity or the DN based on the AIoT configuration.

Description

AIOT DATA FORWARDING OVER INTERMEDIATE NODEFIELD

[0001] Example embodiments of the present disclosure generally relate to the field of communication, and in particular, to a terminal device, network devices, methods, apparatuses, and computer readable media for ambient Internet of Things (AIoT) data forwarding over an intermediate node.BACKGROUND

[0002] A communication network can be seen as a facility that enables communications between two or more communication devices, or provides communication devices access to a data network. A mobile or wireless communication network is one example of a communication network. Such communication networks operate in accordance with standards, such as those promulgated by 3 GPP (Third Generation Partnership Project) or ETSI (European Telecommunications Standards Institute). Examples of such standards include the so-called 5G (5th Generation) standard or other standards promulgated by 3GPP.

[0003] A new study item on solutions for ambient Internet of Things (AIoT) in new radio (NR) was recently approved. This study targets a further assessment at RAN WG-level of AIoT, a new 3 GPP loT technology, suitable for deployment in a 3 GPP system, which relies on ultra-low complexity devices with ultra-low power consumption for the very -low end loT applications. AIoT devices can communicate bidirectionally with an intermediate node between the devices and base station in some cases, however, some issues related to the intermediate node selection still need to be studied.SUMMARY

[0004] In general, example embodiments of the present disclosure provide solutions for AIoT data forwarding over an intermediate node.

[0005] In a first aspect, there is provided a terminal device. The terminal device comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the terminal device at least to: receive, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configurationfrom an AIoT function (AIOTF), the AIoT configuration indicating forwarding mechanism for forwarding AIoT data received from at least one wireless device to a network entity or a data network (DN); and forward the AIoT data to the network entity or the DN based on the AIoT configuration.

[0006] In a second aspect, there is provided a network device for performing an access and mobility management function (AMF), comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the terminal device at least to: maintain ambient Internet of Things (AIoT) context indicating an AIoT function (AIOTF) associated with a terminal device; receive the AIoT data from the terminal device; and forward, via the AIOTF, the AIoT data to a network entity or a data network (DN) requesting the AIoT data based on the AIoT context.

[0007] In a third aspect, there is provided a network device. The network device comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the network device at least to: transmit, via an access and mobility management function (AMF), an AIoT configuration to a terminal device, the AIoT configuration indicating forwarding mechanism for forwarding AIoT data from at least one wireless device to a network entity or a data network (DN).

[0008] In a fourth aspect, there is provided a method. The method comprises: receiving, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration from an AIoT function (AIOTF), the AIoT configuration indicating forwarding mechanism for forwarding AIoT data received from at least one wireless device to a network entity or a data network (DN); and forwarding, the AIoT data to the network entity or the DN based on the AIoT configuration.

[0009] In a fifth aspect, there is provided a method. The method comprises: maintaining, ambient Internet of Things (AIoT) context indicating an AIoT function (AIOTF) associated with a terminal device; receiving the AIoT data from the terminal device; and forwarding, via the AIOTF, the AIoT data to a network entity or a data network (DN) requesting the AIoT data based on the AIoT context.

[0010] In a sixth aspect, there is provided a method. The method comprise: transmitting, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration to a terminal device, the AIoT configuration indicating forwardingmechanism for forwarding AIoT data from at least one wireless device to a network entity or a data network (DN).

[0011] In a seventh aspect, there is provided an apparatus. The apparatus comprises: means for receiving, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration from an AIoT function (AIOTF), the AIoT configuration indicating forwarding mechanism for forwarding AIoT data received from at least one wireless device to a network entity or a data network (DN); and means for forwarding the AIoT data to the network entity or the DN based on the AIoT configuration.

[0012] In an eighth aspect, there is provided an apparatus. The apparatus comprises: means for maintaining ambient Internet of Things (AIoT) context indicating an AIoT function (AIOTF) associated with a terminal device; means for receiving the AIoT data from the terminal device; and means for forwarding, via the AIOTF, the AIoT data to a network entity or a data network (DN) requesting the AIoT data based on the AIoT context.

[0013] In a ninth aspect, there is provided an apparatus. The apparatus comprises: means for transmitting, at a network device and via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration to a terminal device, the AIoT configuration indicating forwarding mechanism for forwarding AIoT data from at least one wireless device to a network entity or a data network (DN).

[0014] In a tenth aspect, there is provided a non-transitory computer-readable storage medium comprising program instructions. The program instructions, when executed by an apparatus, cause the apparatus to perform at least the following: receiving, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration from an AIoT function (AIOTF), the AIoT configuration indicating forwarding mechanism for forwarding AIoT data received from at least one wireless device to a network entity or a data network (DN); and forwarding, the AIoT data to the network entity or the DN based on the AIoT configuration.

[0015] In a eleventh aspect, there is provided a non-transitory computer-readable storage medium comprising program instructions. The program instructions, when executed by an apparatus, cause the apparatus to perform at least the following: maintaining, ambient Internet of Things (AIoT) context indicating an AIoT function (AIOTF) associated with a terminal device; receiving the AIoT data from the terminal device; and forwarding, via theAIOTF, the AIoT data to a network entity or a data network (DN) requesting the AIoT data based on the AIoT context.

[0016] In a twelfth aspect, there is provided a non-transitory computer-readable storage medium comprising program instructions. The program instructions, when executed by an apparatus, cause the apparatus to perform at least the following: transmitting, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration to a terminal device, the AIoT configuration indicating forwarding mechanism for forwarding AIoT data from at least one wireless device to a network entity or a data network (DN).

[0017] In a thirteenth aspect, there is provided a computer program comprising instructions, which, when executed by an apparatus, cause the apparatus at least to: receive, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration from an AIoT function (AIOTF), the AIoT configuration indicating forwarding mechanism for forwarding AIoT data received from at least one wireless device to a network entity or a data network (DN); and forward the AIoT data to the network entity or the DN based on the AIoT configuration.

[0018] In a fourteenth aspect, there is provided a computer program comprising instructions, which, when executed by an apparatus, cause the apparatus at least to: maintain ambient Internet of Things (AIoT) context indicating an AIoT function (AIOTF) associated with a terminal device; receiving the AIoT data from the terminal device; and forwarding, via the AIOTF, the AIoT data to a network entity or a data network (DN) requesting the AIoT data based on the AIoT context.

[0019] In a fifteenth aspect, there is provided a computer program comprising instructions, which, when executed by an apparatus, cause the apparatus at least to: transmit, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration to a terminal device, the AIoT configuration indicating forwarding mechanism for forwarding AIoT data from at least one wireless device to a network entity or a data network (DN).

[0020] In a sixteenth aspect, there is provided a terminal device. The terminal device comprises: a receiving circuitry configured to receive, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration from an AIoT function (AIOTF), the AIoT configuration indicating forwarding mechanism forforwarding AIoT data received from at least one wireless device to a network entity or a data network (DN); and a forwarding circuitry configured to forward the AIoT data to the network entity or the DN based on the AIoT configuration.

[0021] In a seventeenth aspect, there is provided a network device for performing an access and mobility management function (AMF). The network device comprises: a maintaining circuitry configured to maintain ambient Internet of Things (AIoT) context indicating an AIoT function (AIOTF) associated with a terminal device; a receiving circuitry configured to receive the AIoT data from the terminal device; and a forwarding circuitry configured to forward, via the AIOTF, the AIoT data to a network entity or a data network (DN) requesting the AIoT data based on the AIoT context.

[0022] In an eighteenth aspect, there is provided a network device for performing ambient Internet of Things function (AIOTF). The network device comprises: a transmitting circuitry configured to transmit, via an access and mobility management function (AMF), an AIoT configuration to a terminal device, the AIoT configuration indicating forwarding mechanism for forwarding AIoT data from at least one wireless device to a network entity or a data network (DN).

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

[0024] Some example embodiments will now be described with reference to the accompanying drawings, in which:

[0025] FIG. 1 illustrates an example network environment in which an intermediate node is deployed for communication between a base station and an AIoT device;

[0026] FIG. 2 illustrates a schematic diagram of an example communication network in which some embodiments of the present disclosure can be implemented;

[0027] FIG. 3 illustrates an example of a process flow for forwarding AIoT data from AIoT device to network in accordance with some example embodiments of the present disclosure;

[0028] FIG. 4 illustrates an example of a process flow for forwarding AIoT data based on control plane (CP) mechanism in accordance with some example embodiments of the present disclosure;

[0029] FIG. 5 illustrates an example of another process flow for forwarding AIoT data based on CP mechanism in accordance with some example embodiments of the present disclosure;

[0030] FIG. 6 illustrates an example of a process flow for forwarding AIoT data based on user plane (UP) mechanism in accordance with some example embodiments of the present disclosure;

[0031] FIG. 7 illustrates an example of another process flow for forwarding AIoT data based on UP mechanism in accordance with some example embodiments of the present disclosure;

[0032] FIG. 8 illustrates an example flowchart of a method implemented at a terminal device according to example embodiments of the present disclosure;

[0033] FIG. 9 illustrates an example flowchart of a method implemented at a network device for performing an AMF according to example embodiments of the present disclosure;

[0034] FIG. 10 illustrates an example flowchart of a method implemented at a network device for performing an AIOTF according to example embodiments of the present disclosure;

[0035] FIG. 11 illustrates an example simplified block diagram of a device that is suitable for implementing embodiments of the present disclosure; and

[0036] FIG. 12 illustrates an example block diagram of an example computer readable medium in accordance with some embodiments of the present disclosure.

[0037] Throughout the drawings, the same or similar reference numerals represent the same or similar elements.DETAILED DESCRIPTION

[0038] Principles of the present disclosure will now be described with reference to some example 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 thepresent disclosure, without suggesting any limitation as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below.

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

[0040] References in the present disclosure to “one embodiment,” “an embodiment,” “an example embodiment,” and the like indicate that the embodiment 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 are not necessarily referring to the same embodiment. 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.

[0041] It shall be understood that although the terms “first” and “second” etc. 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. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0042] 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. As used herein, “at least one of the following: ” and “at least one of ” and similar wording, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0043] As used in this application, the term “circuitry” may refer to one or more or all of the following:(a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and(b) combinations of hardware circuits and software, such as (as applicable):(i) a combination of analog and / or digital hardware circuit(s) with software / firmware and(ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and(c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor s), that requires software (for example, firmware) for operation, but the software may not be present when it is not needed for operation.

[0044] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0045] As used herein, the term “network”, “communication network” or “data network” refers to a network following any suitable communication standards, such as long term evolution (LTE), LTE-advanced (LTE-A), wideband code division multiple access (WCDMA), high-speed packet access (HSPA), wireless fidelity (Wi-Fi), narrow band Internet of things (NB-IoT), satellite, enhanced machine-type communication (eMTC), nonterrestrial communication, terrestrial communication, and so on. Furthermore, the communications between a terminal device and a network device / element in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the fourth generation (4G), 4.5G, the fifth generation (5G), the sixth generation (6G), new radio (NR), IEEE 802.11communication 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 of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

[0046] As used herein, the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP) or a transmission and reception point (TRP) in random access network (RAN), for example, a node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), a NR NB (also referred to as a gNB), a remote radio unit (RRU), a radio header (RH), a remote radio head (RRH), a WiFi device, a relay, a low power node such as a femto, a pico, and so forth, depending on the applied terminology and technology.

[0047] The network device may also refer to a network entity in a core network (CN) which performs or comprises one or more functions. The network entity may be a wireless device or node. In some embodiments, the network entity comprising a network function refers to an entity, a device or a node performing or configured to perform at least part of functionalities of the network function. The network function may include one or more of, for example, an access and mobility management function (AMF), a session management function (SMF), an AIoT function (AIOTF), network exposure function (NEF), an application function (AF), a user plane function (UPF), a policy control function (PCF), a unified data management (UDM), network function repository function (NRF), network slice selection function (NSSF), etc.

[0048] The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE), a subscriber station (SS), a portable subscriber station, a mobile station (MS), a station (STA) or station device, or an access terminal (AT). The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA), portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminaldevices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), USB dongles, smart devices, 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 and applications (for example, remote surgery), an industrial device and applications (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 “station”, “station device”, “STA”, “terminal device”, “communication device”, “terminal”, “user equipment” and “UE” may be used interchangeably.

[0049] The term “transceiver” may refer to any device that may be coupled to one or more antennas or antenna ports to wirelessly transmit and / or receive communication signals. The antennas or antenna ports may be the same or different types. The antennas or antenna ports may be located in different positions of an apparatus. One or more transceivers allow the apparatus to communicate with other devices that may be wired and / or wireless. The one or more transceivers may include processors, controllers, radios, sockets, plugs, buffers, or the like circuits to form one or more communication channels to one or more radio frequency units. The one or more transceivers may be integrated in an apparatus or a system, for example a cellular communication apparatus or system, a satellite communication apparatus or system, a WLAN system, or a short ranging system for example Bluetooth system.

[0050] AIoT refers to loT devices powered by energy harvesting, making them either battery-less or equipped with limited energy storage capabilities (e.g., using a capacitor). AIoT is necessary to complement existing loT technologies like NB-IoT / eMTC and NR RedCap defined by 3GPP. It aims to cover additional use cases that demand more cost- effective, power-efficient, and particularly battery-less functionalities. By incorporating AIoT technology into the loT ecosystem, various use cases can be addressed while reducing the dependency on conventional power sources.

[0051] The number of loT devices is anticipated to be enormous in the future and the lifespan of them should be very long like more than 5 years. Charging or regularly replacing batteries for all these loT devices would be impractical, considering the significant consumption of manpower and materials. Some use cases leveraging AIoT devices include:ID tags (Replacing RFID with a wider range), sensors (e.g., temperature, humidity, etc.), healthcare devices (Monitoring personal medical information), logistics (Tracking objects).

[0052] Components of the system architecture for AIoT may include an activator (or illuminator), AIoT devices (radios), and a reader (or receiver). The activator sends an activation signal to wake up passive radios (AIoT devices) by providing energy that allows AIoT devices to transmit their messages. The AIoT devices are powered by energy harvesting. The reader listens and detects the passive radio signals. The reader may or may not be collocated with the activator.

[0053] The present disclosure introduces novel mechanisms for forwarding AIoT data received from AIoT device(s) to application (e.g., application function and / or data network).

[0054] For illustrative purposes, principles and example embodiments of the present disclosure will be described below with reference to FIG. 1 to FIG. 12. However, it is to be noted that these embodiments are given to enable the skilled in the art to understand inventive concepts of the present disclosure and implement the solution as proposed herein, and not intended to limit scope of the present application in any way.

[0055] Various topologies are supported by the 5G system, which include Topology 1 where a gNB and an AIoT device communicates with each other directly and Topology 2 where a terminal device (e.g., UE) acts as an intermediate node between the AIoT device and the gNB.

[0056] FIG. 1 illustrates an example schematic of Topology 2 in which an intermediate node is deployed for communication between the base station and the AIoT device. In Topology 2, the AIoT device communicates bidirectionally with an intermediate node between the device and the base station. In this topology, the intermediate node can be a relay, IAB node, UE, repeater, etc., which is capable of AIoT. The intermediate node transfers AIoT data and / or signalling between the base station and the AIoT device.

[0057] It is understandable that there may be multiple UEs within network coverage, in this case, which of them can serve as the intermediate nodes should be determined.

[0058] FIG. 2 illustrates a schematic diagram of an example communication network in which some embodiments of the present disclosure can be implemented. As shown in FIG.2, the communication network 200 may include a BS 210, multiple UEs 220-1 to 220-N (may be collectively or separately referred to as a UE 220), and multiple AIoT devices 230.

[0059] In FIG. 2, a core network (CN) entity 250 in CN is also shown, where the CN may be a 5GC or a 6G core network. The core network entity 250 may be implemented as one or more network functions (NFs) including, for example, an AIoT function (AIOTF), an access and mobility management function (AMF) of a 5GC, or an application function (AF), and the like. It would be appreciated that the CN may comprise multiple network entities having various network functions.

[0060] The multiple UEs 220 may be within coverage of the BS 210, for example each UE 220 can communicate with the BS 210. In some cases, a location of the BS 210 may be outdoor or indoor, a location of the UE 220 may be indoor, and a location of the AIoT device 230 is indoor. In some cases, the network 200 may be used in use cases such as inventory.

[0061] As shown the UE 220 may act as an intermediate node for (bidirectional) communication between the AIoT device 230 and the BS 210. In this disclosure, the UE 220 may also be interchangeably referred as an intermediate node (I-node).

[0062] It is to be understood that the numbers of UEs or AIoT devices or CN entities shown in FIG. 2 are only for the purpose of illustration only. The communication network 200 may include any suitable numbers of devices.

[0063] In the present disclosure, the BS 210 and the UE 220 may communicate with one or multiple AIoT devices, from AIoT device side, there may be no difference in physical layer design, that is, the AIoT device directly and bidirectionally communicates with a device (e.g. the BS 210 or the UE 220).

[0064] To enable the communications between an AF and an AIoT device over 5GC using the Topology 2, the following steps may be required in general: Step 1, the AF requests 5GC to communicate with the target AIoT devices by providing necessary information; Step 2, the 5GC selects the responsible intermediate node based on the information provided by the AF and information retrieved from relevant NFs; Step 3, 5GC determines the AIoT policy for the selected intermediate node and provisions the determined policies and configuration information to the UE; Step 4, the selected intermediate node communicates with the target AIoT devices and forwards the data received from them to the AIoT data requesting entity over 5GC. In the present disclosure, some embodiments are proposed for the intermediate node (I-node), such as a UE, to forward the AIoT data to the AF or data network (DN) over 5GC.

[0065] FIG. 3 illustrates an example of a process flow 300 for forwarding AIoT data from AIoT device to network in accordance with some example embodiments of the present disclosure. The process 300 involves a network entity or DN 310 which requests data from wireless device(s) 350. The network entity or DN 310 may comprise / be an AF in a CN. In some embodiments, the network entity or DN 310 refers to at least one of AF and DN. The process 300 further involves an ambient loT function (AIOTF) 320, an access and mobility management function (AMF) 330, and a terminal device 340. The network entity 310, the AIOTF 320 and the AMF 330 may be the CN entity 250 as discussed with reference to FIG. 2. The terminal device 340 acts as an intermediate node (I-node) between the AIoT device(s) 350 and the network. The terminal device 340 may be the UE(s) 220 in FIG. 2. The wireless device(s) 350 may be the AIoT device(s) 230 in FIG. 2. It would be appreciated that the process 300 may be applied to other communication scenarios, which will not be described in detail.

[0066] At 301, the AIOTF 320 provides / provisions / communicates the terminal device 340 via the AMF 330. In some embodiments, the AIOTF 320 may provision the terminal device 340 when / if / after the terminal device 340 is registered with 5GC or following / in response to a request from the network entity 310. To provision the terminal device 340, the AIOTF 320 may transmit an AIoT configuration to the AMF 330 associated with the terminal device 340, and the AMF 330 forwards the AIoT configuration to the terminal device 340. Accordingly, the terminal device 340 receives the AIoT configuration from the AIOTF 320 via the AMF 330.

[0067] The AIoT configuration may indicate forwarding mechanism(s) which specifies how to forward AIoT data received from the wireless device(s) 350 to the network entity or the DN 310. The forwarding mechanism may comprise a control plane (CP)-based mechanism or a user plane (UP)-based mechanism both including some variations. In some embodiments, the AIoT configuration may indicate at least one data aggregation rule. In some embodiments, the AIoT configuration may further indicate the destination to which the AIoT data should be forwarded.

[0068] At 302, the AMF 330 may store and maintain AIoT context. The AMF 330 may create new AIoT context based on the AIoT configuration received from the AIOTF 320. The AIoT context may indicate that the AIOTF 320 is associated with the terminal device 340. The AIoT context may further indicates network entity 310 is associated with a terminaldevice 340. In other words, the AIoT context may indicate which AIOTF is used for the network entity 310 and for the registered terminal device 340.

[0069] At 303, the terminal device 340 receives the AIoT data from the wireless device(s) 350. At 304, the terminal device 340 forwards the AIoT data to the network entity or the DN 301. Depending the forwarding mechanism(s) indicated in the AIoT configuration, the terminal device 340 may forward the AIoT data to the network entity or DN 310 via one or more network functions in the core network.

[0070] For a CP -based mechanism, the AIoT data may be forwarded to the network entity 310 (e.g., AF) via the AMF 330 and optionally one or more of a SMF (not shown), a UPF (not shown), and the AIOTF 320 (via NEF). For an UP -based mechanism, the AIoT data may be forwarded to the DN 310 via the UPF or the AIOTF (via NEF). In some embodiment, the AIoT data may be forwarded to the network entity (e.g., AF) 310 using the UP -based mechanism. Details of the forwarding mechanism will be described with reference to FIGS. 4 to 8.

[0071] In some embodiments, before forwarding the AIoT data, the terminal device 340 may aggregate at least part of the AIoT data received from the wireless device(s) 350 based on the data aggregation rule(s) as indicated in the AIoT configuration. The data aggregation rule(s) may indicate a number of AIoT devices to be reported together, latency requirements (e.g., report after every x millisecond), and / or a list of AIoT IDs that are expected to respond.

[0072] Depending the applied forwarding mechanism, the AMF 330 and the AIOTF 340 each may perform operator-controlled services for the AIoT data if it receives the AIoT data during the data forwarding. The operator-controlled services may comprise authentication, authorization checking, and / or device ID validation.

[0073] FIG. 4 illustrates an example of a process flow for forwarding AIoT data based on control plane (CP) mechanism in accordance with some example embodiments of the present disclosure. In FIG. 4, the AF or DN 410 is an implementation of the network entity or DN 310 as discussed with reference to FIG. 3, the AIOTF 420 is an implementation of the AIOTF 320, the AMF 430 is an implementation of the AMF 330, the I-node 440 is an implementation of the terminal device 340, and the AIoT device(s) 450 is an implementation of the wireless device(s) 350.

[0074] In general, the process flow shown in FIG. 4 relates to a CP -based forwarding mechanism, where the I-node (UE) 440 makes use of existing CP CIoT (Cellular-IoT) 5GSoptimization mechanism with some extension to forward the data received from the AIoT devices 450 to the AF or DN 410. In some embodiments, the forwarding mechanism shown in FIG. 4 may be used for transmitting a small volume of data and / or may enable 5GC to provide additional services for the received AIoT data such as security checking.

[0075] At step 1, the AF provides information necessary for 5GC (e.g., the AIOTF 420) to select and configure the UEs. Such information may be provided to the AIOTF 420, the PCF 480, and the UDM or UDR network functions 470. The AF may provide information to the AIOTF 420 and other entities via NEF which is responsible for any exposure functionalities. The AIOTF 420 may be an independent NF or a logical entity that can be implemented together with NEF.

[0076] At step 2, the UEs that may act as I-nodes 440 register with 5GC, indicating its capabilities for CP CIoT 5GS optimization. The I-node 440 may provide capability information to the UDM or UDR network functions 470.

[0077] At step 3, the AIOTF 420 determines the AIoT policies to be applied for the I-node 440 based on the information provided by the AF 410 and the network information about the UE that are maintained, for example, at the UDM or UDR network functions 470 . The AIOTF 420 may provision the configuration information (i.e., the AIoT configuration), including a new UE aggregation rule, to the registered I-node via AMF 430. This configuration information may include the destination to which the retrieved AIoT data should be forwarded, the forwarding mechanism, such as CP CIoT 5GS optimization, etc.

[0078] At step 4, the AMF 430 may store and maintain new AIoT context, indicating which AIOTF 420 is used for a specific AF 410 and for the registered I-node 440.

[0079] At step 5, the registered I-node 440 may establish a PDU session with / using CP CIoT 5GS optimization, targeting the AF or DN 410 over NEF or UPF 490 based on the information provisioned by the 5GC. After this procedure, the corresponding PDU session ID is known to the I-node 440 as well as the AMF 430.

[0080] At step 6, the AF 410 transmits an AIoT data request to the AIOTF 420. At step 7, the AIOTF 420 performs I-node selection (and corresponding AMF), and at step 8, the AIOTF 420 forwards the AF request to the selected I-node 440 via the AMF 430. The I-node 440 may communicate with the target AIoT devices as requested by the AF 410 over the 5GC which supports the I-node selection and forwarding the AF request.

[0081] At step 9, the I-node 440 applies the AIoT policy and the data aggregation rule(s). At step 10, when the I-node 440 receives the AIoT data from the AIoT devices 450, it may forward the data one by one or aggregate the data from multiple AIoT devices before forwarding. The I-node 440 may aggregate the data following a certain aggregate rule that may be provisioned by the AF 410 or 5GC. The aggregate rule may, for example, specify the number of AIoT devices to be reported together, latency requirements (i.e. report after every x millisecond), and a list of AIoT IDs that are expected to respond. The I-node 440 may then use this policy to determine how to aggregate the data before forwarding.

[0082] At step 12, the I-node 440 forwards the AIoT data along with the PDU session ID to the AMF 430 over non-access stratum signaling (NAS) message(s). In case the I-node 440 aggregated part of the AIoT data before forwarding, multiple NAS messages indicating the same PDU session ID may be used to convey the AIoT data from all the target AIoT devices 450. In some embodiments, an indication may be introduced by the I-node to indicate the first and last NAS message for the same session. The first NAS message may include a first indication to notify the AMF 430 that it is the first message carrying the requested AIoT data, and the last NAS message may include a last indication to notify the AMF 430 that it is the last message carrying the requested AIoT data.

[0083] At step 13, the AMF 430 or the AIOTF 420 may perform some operator-controlled services for the forwarded data, such as authentication, authorization checking, and device ID validation.

[0084] As shown, there are two forwarding paths for forwarding the AIoT data from the AMF 430 to SMF 460, i.e., the AMF 430 transmits the AIoT data directly to the SMF 460 (step 15a), or alternatively, via the AIOTF 420 (step 15b). There are also two paths for further forwarding the AIoT data from the SMF 460 to the AF or DN 410, i.e., over the UPF 490 (step 16a), or alternatively, over the NEF (step 16b).

[0085] At steps 14-16, in case the I-node 440 aggregates the AIoT data, the AMF 430 or the AIOTF 420 may wait until the indication for the last message is received, and then aggregate all the received AIoT data before forwarding the received AIoT data to the AF or DN 410 via SMF 460 and NEF or UPF. At step 14a, the AMF 440 may perform the final aggregation, or alternatively at step 14b, the AIOTF 420 may receive the AIoT data from the AMF 440 and perform the final aggregation.

[0086] FIG. 5 illustrates an example of another process flow for forwarding AIoT data based on CP mechanism in accordance with some example embodiments of the present disclosure. In FIG. 5, the AF 510 is an implementation of the network entity 310 as discussed with reference to FIG. 3, the AIOTF 520 is an implementation of the AIOTF 320, the AMF 530 is an implementation of the AMF 330, the I-node 540 is an implementation of the terminal device 340, and the AIoT device(s) 550 is an implementation of the wireless device(s) 350.

[0087] In general, the process flow shown in FIG. 5 relates to CP -based forwarding mechanism, where the I-node 540 makes use of a pure CP mechanism to forward the data received from the AIoT devices 550 to the 5GC. The 5GC then aggregates the information / data and forwards the received information / data to the AF 510. In some embodiments, the forwarding mechanism shown in FIG. 5 may be used for transmitting a small volume of data and / or may enable 5GC to provide additional services for the received AIoT data such as security checking. This forwarding mechanism shown in FIG. 5 is different from FIG. 4 in the sense that in FIG. 4, N3 data transfer over NAS (i.e., similar to CIoT 5GS optimization) procedure is used; whereas, in FIG. 5, a complete CP based method is provided (i.e., there is no PDU session).

[0088] At step 1, the AF 510 provides information necessary for 5GC(AIOTF) to select and configure the UEs. Such information may be provided to the AIOTF 520, the PCF 580, and the UDM or UDR network functions 570. The AF 510 may provide information to the AIOTF 520 and other entities via NEF which is responsible for any exposure functionalities. The AIOTF 520 may be an independent NF or a logical entity that can be implemented together with NEF.

[0089] At step 2, the UEs that may acts as I-nodes 540 register with 5GC, indicating its capabilities for CP based AIoT forwarding. The I-node 540 may provide capability information to the UDM or UDR network functions 470.

[0090] At step 3, the AIOTF 520 determines the AIoT policies to be applied for the I-node 540 based on the information provided by the AF 410 and the network information about the UE that are maintained, for example, at the UDM or UDR network functions 570. The AIOTF 520 may provision the configuration information (i.e., AIoT configuration), including a new UE aggregation rule, to the registered I-node via AMF 530. This configuration information includes the requested forwarding mechanism, i.e., “CP based”.

[0091] At step 4, the AMF 530 stores and maintains a new AIoT context, indicating which AIOTF 520 is used for a specific AF 510 and for the registered I-node 540.

[0092] At step 5, the AF 510 requests AIoT data to 5GC. The request is received by the AIOTF 520 (via NEF) and an “AIoT session ID” is associated with the request.

[0093] At steps 6-7, the AIOTF 520 selects the I-node(s) 540 for data collection and sends to AIoT Data Request to the AMF 530 serving the I-node(s) 540. The AMF 530 then triggers the I-node(s) 540 (via gNB) for data collection. The request is associated with the “AIoT Session ID”.

[0094] At steps 8-10, the I-node 540 communicates with the target AIoT devices 550. When / If the I-node 540 receives data from the AIoT devices 550, the I-node 540 may forward the AIoT data one by one or aggregate the data from multiple AIoT devices 550 before forwarding all of the received data. The I-node 540 may aggregate the data following a certain aggregate rule that can be provisioned by the AF 510 or 5GC. The aggregate policy may, for example, specify the number of AIoT devices to be reported together, latency requirements (i.e. report after every x millisecond), and a list of AIoT IDs that are expected to respond. The I-node can then use this policy to determine how to aggregate the data before forwarding.

[0095] At step 11, the I-node 540 forwards the AIoT data along with the AIoT session ID to the AMF 530 over NAS message(s). In case the I-node aggregated part of the data before forwarding, multiple NAS messages indicating the same AIoT session ID can be used to convey the data from all the target AIoT devices. And a new indication is introduced by the I-node to indicate the first and last NAS message for the same session.

[0096] At steps 12-13, the AMF 530 or the AIOTF 520 may perform some operator- controlled services for the forwarded data, such as authentication, authorization checking, and device ID validation. Based on the aggregation rule(s) provided to the I-node 440, steps 10-13 may be repeated to collect all requested AIoT data from the AIoT devices 550.

[0097] At steps 14-17, if the AMF 530 is configured to perform such action, when the AMF 530 receives the last NAS message from the I-node 540 for that AIoT session ID, it aggregates the data and then sends the aggregated data (step 15a) in a notify operation (notify for request received in step 7) to the AIOTF 520. The AIOTF 520 may forward the data to the AF (step 17) in a notify operation (notify operation for request received in step 5). If the AIOTF 520 is configured to perform such action, when the AMF 530 receives the last NASmessage from the I-node 540 for the AIoT session ID, it forwards the data to AIOTF (steps 12b, 15b) in a notify operation (notify for request received in step 7) to the AIOTF 520. The notify operation may include the AIoT Session ID, the first or last indication and the data received from the I-node 540. After the AIOTF 520 has received a notify operation for the AIoT Session ID with “last indication”, the AIOTF 520 aggregates the data and sends the aggregated data to the AF 510 (step 17) in a notify operation (notify operation for request received in step 5).

[0098] FIG. 6 illustrates an example of a process flow for forwarding AIoT data based on user plane (UP) mechanism in accordance with some example embodiments of the present disclosure. In FIG. 6, the AF 610 and the DN 611 are implementations of the network entity or DN 310 as discussed with reference to FIG. 3, the AIOTF 620 is an implementation of the AIOTF 320, the AMF 630 is an implementation of the AMF 630, the I-node 640 is an implementation of the terminal device 340, and the AIoT device(s) 650 is an implementation of the wireless device(s) 350.

[0099] In general, the process flow shown in FIG. 6 relates to an UP -based forwarding mechanism, where the I-node 640 forwards the AIoT data to the requested application URI over its UP PDU session in the DN 611 using the UP channel between the I-node 640 and the DN 611. In some embodiments, the forwarding mechanism shown in FIG. 6 may be used for sending a large amount of data.

[0100] At step 1, the AF 610 provides information necessary for 5GC (e.g., the AIOTF 620) to select and configure the UEs. Such information may be provided to the AIOTF 620, the PCF 680, and the UDM or UDR network functions 670. The AF 610 may provide information to the AIOTF 610 and other entities via NEF which is responsible for any exposure functionalities. The AIOTF 620 may be an independent NF or a logical entity that can be implemented together with NEF.

[0101] At step 2, the UEs that may acts as I-nodes 640 register with 5GC, indicating its capabilities to the UDM or UDR network functions 670.

[0102] At step 3, the AIOTF 620 determines the AIoT policies to be applied for the I-node 640 based on the information provided by the AF 610 and the network information about the UE. The AIOTF 620 may provision the configuration information, including a new UE aggregation rule, to the registered I-node 640 via the AMF 630. This configurationinformation includes the destination (e.g., application URI) to which the retrieved AIoT data should be forwarded, the forwarding mechanism, such as direct UP PDU session, etc.

[0103] At step 4, the registered I-node 640 establishes a PDU session, targeting the destination URI based on the information provisioned by the 5GC. The SMF 660 may provide management of the PDU session.

[0104] At steps 5-9, the I-node 640 may communicate with the target AIoT devices 650 as requested by the AF 610 over the 5GC. When it receives the AIoT data from the AIoT devices 650, the I-node 640 may forward the data one by one or aggregate the data received from multiple AIoT devices before forwarding the received data.

[0105] At step 10, the I-node 640 may aggregate the data following a certain aggregate rule that can be provisioned by the AF 610 or 5GC. The aggregate policy may, for example, specify the number of AIoT devices to be reported together, latency requirements, and a list of AIoT IDs that are expected to respond. The I-node 640 may then use this policy to determine how to aggregate the data before forwarding. At step 11, the I-node forwards the AIoT data over the established PDU session to the DN 611 via the UPF 690.

[0106] FIG. 7 illustrates an example of another process flow for forwarding AIoT data based on UP mechanism in accordance with some example embodiments of the present disclosure. In FIG. 7, the AF 710 is an implementation of the network entity or DN 310 as discussed with reference to FIG. 3, the AIOTF 720 is an implementation of the AIOTF 320, the AMF 730 is an implementation of the AMF 330, the I-node 740 is an implementation of the terminal device 340, and the AIoT device(s) 750 is an implementation of the wireless device(s) 350.

[0107] In general, the process flow shown in FIG. 7 relates to a further UP -based forwarding mechanism, using a new UP channel between the I-node and AIOTF in 5GC. In FIG. 7, the I-node 740 establishes an UP PDU session with AIOTF 720 in 5GC and forwards the AIoT data to the AIOTF 720 over the established PDU session. The forwarding mechanism shown in FIG. 7 may be used for transmitting a large volume of data and / or may enable 5GC to provide additional services for the received AIoT data such as security checking.

[0108] At step 1, the AF 710 provides information necessary for 5GC (e.g., AIOTF 720) to select and configure the UEs. Such information may be provided to the AIOTF 720, the PCF 780, and the UDM or UDR network functions 770. The AF 710 may provideinformation to the AIOTF 720 and other entities via NEF which is responsible for any exposure functionalities. The AIOTF 720 may be an independent NF or a logical entity that can be implemented together with NEF.

[0109] At step 2, the UEs that can be acting as I-nodes register with 5GC, indicating its capabilities for UP PDU session with AIOTF. The UEs may provide capability information to the UDM or UDR network functions 770.

[0110] At step 3, the AIOTF 720 determines the AIoT policies to be applied for the I-node 740 based on the information provided by the AF 710 and the network information about the UE. The AIOTF 720 provisions the configuration information, including a new UE aggregation rule, to the registered I-node 740 via the AMF 730. This configuration information includes the destination (e.g. AIOTF URJ) to which the retrieved AIoT data should be forwarded, the forwarding mechanism, such as UP PDU session with the AIOTF, etc.

[0111] At step 4, the registered I-node 740 establishes a PDU session for communication with the indicated AIOTF based on the information provisioned by the 5GC.

[0112] At steps 5-9, the I-node 740 communicates with the target AIoT devices 750 as requested by the AF 710 over the 5GC. When it receives the AIoT data from the AIoT devices 750, it may forward the data one by one or aggregate the data from multiple AIoT devices before forwarding.

[0113] At step 10, the I-node 740 may aggregate the data following a certain aggregate rule that may be provisioned by the AF 710 or 5GC. The aggregate policy may, for example, specify the number of AIoT devices to be reported together, latency requirements, and a list of AIoT IDs that are expected to respond. The I-node 740 may then use this policy to determine how to aggregate the data before forwarding.

[0114] At step 11, the I-node 740 forwards the AIoT data to the AIOTF 720 over the established PDU session. In case the I-node 740 aggregated part of the data before forwarding, an indication can be sent together with the data to indicate the first and last PDU message for the same session.

[0115] At step 12, the AIOTF may perform some operator-controlled services for the forwarded data, such as authentication, authorization checking, and device ID validation.

[0116] At steps 13-14, in case the I-node 740 aggregates the data, the AIOTF 720 may wait until the indication for the last message is received, then aggregate all the AIoT data before forwarding it to the AF 710.

[0117] FIG. 8 illustrates a flowchart of an example method 800 implemented at a terminal device (e.g., a UE) in accordance with some other embodiments of the present disclosure. For ease of understanding, the method 800 will be described from the perspective of the terminal device 340 with reference to FIG. 3.

[0118] At block 810, the terminal device 340 receives, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration from an AIoT function (AIOTF), the AIoT configuration indicating forwarding mechanism for forwarding AIoT data received from at least one wireless device to a network entity or a data network (DN). At block 820, the terminal device 340 forwards the AIoT data to the network entity or the DN based on the AIoT configuration.

[0119] In some embodiments, to forward AIoT data received from the at least one wireless device to the network entity or the DN based on the AIoT configuration, the terminal device 340 may establish, using CP CIoT 5GS optimization, a protocol data unit (PDU) session targeting the network entity or the DN; and transmit, over the established PDU session, the AIoT data received from the at least one wireless device together with a PDU session identity (ID) of the PDU session to the AMF (see, e.g., FIG. 4).

[0120] In some embodiments, to forward AIoT data received from the at least one wireless device to the network entity based on the AIoT configuration, the terminal device 340 may receive, from the AMF, an AIoT session ID that is associated with an AIoT data request from the network entity; and transmit the AIoT data received from the at least one wireless device together with the AIoT session ID to the AMF (see, e.g., FIG. 5).

[0121] In some embodiments, to forward AIoT data received from the at least one wireless device to the DN based on the AioT configuration, the terminal device 340 may establish a PDU session over UP targeting the DN; and transmit, over the established PDU session over UP, the AioT data received from the at least one wireless device to a user plane function (UPF) (see, e.g, FIG. 6).

[0122] In some embodiments, to forward AioT data received from the at least one wireless device to the network entity based on the AioT configuration, the terminal device 340 may establish a PDU session over UP for communication between the terminal device and theAIOTF; and transmit, over the established PDU session over UP, the AioT data received from the at least one wireless device to the AIOTF (see, e.g., FIG. 7).

[0123] In some embodiments, the AioT configuration may further indicate at least one data aggregation rule, and the terminal device 340 may aggregate, before forwarding the AioT data, at least part of the AioT data received from the at least one wireless device based on the data aggregation rule(s).

[0124] In some embodiments, the data aggregation rule(s) may indicate at least one of the following: a number of AioT devices to be reported; latency requirements; or a list of AioT IDs that are expected to respond.

[0125] In some embodiments, to forward the AioT data to the network entity or the DN, the terminal device 340 may forward, based on the data aggregation rule(s), the AioT data received from the at least one wireless device using multiple messages of a same session.

[0126] In some embodiments, the first one of the multiple messages may include a first indication and the last one of the multiple messages may include a last indication.

[0127] In some embodiments, the terminal device 340 is a user equipment (UE) as an intermediate node between the at least one wireless device and the network entity or the DN.

[0128] In some embodiments, the network entity comprises an application function (AF).

[0129] FIG. 9 illustrates a flowchart of an example method 900 implemented at a network device for performing an access and mobility management function (AMF) in accordance with some other embodiments of the present disclosure. For ease of understanding, the method 900 will be described from the perspective of the network device performing the AMF 330 with reference to FIG. 3.

[0130] At block 910, the network device maintains ambient Internet of Things (AioT) context indicating an AioT function (AIOTF) associated with a terminal device. At block 920, the network device receives the AioT data from the terminal device. At block 930, the network device forwards, via the AIOTF, the AioT data to a network entity or a data network (DN) requesting the AioT data based on the AioT context.

[0131] In some embodiments, the AioT data is received together with a PDU session ID of a PDU session targeting the network entity or the DN, and to forward the AioT data, the network device may transmit, over the PDU session, the AioT data to a session management function (SMF) or the AIOTF.

[0132] In some embodiments, the network device may forward an AIoT data request including an AIoT session ID to the terminal device.

[0133] In some embodiments, the AIoT data is received together with the AIoT session ID, and wherein, to forward the AIoT data to the network entity requesting the AIoT data, the network device may transmit the AIoT data together with the AIoT session ID to the AIOTF.

[0134] In some embodiments, the AIoT data is received in multiple messages of a same session, and the network device may perform data aggregation before forwarding the AIoT data to the network entity.

[0135] In some embodiments, to forward the AIoT data to the network entity, the network device may forward the AIoT data using multiple messages of a same session.

[0136] In some embodiments, the first one of the multiple messages may include a first indication and the last one of the multiple messages may include a last indication.

[0137] In some embodiments, the network device may perform operator-controlled services for the received AIoT data, the operator-controlled services including at least one of authentication, authorization checking, and device ID validation.

[0138] In some embodiments, the network entity may comprise an application function (AF).

[0139] FIG. 10 illustrates a flowchart of an example method 1000 implemented at a network device for performing an ambient Internet of Things function (AIOTF) in accordance with some other embodiments of the present disclosure. For ease of understanding, the method 1000 will be described from the perspective of the network device performing the AIOTF 320 with reference to FIG. 3.

[0140] At block 1010, the network device transmits, via an access and mobility management function (AMF), an AIoT configuration to a terminal device, the AIoT configuration indicating forwarding mechanism for forwarding AIoT data from at least one wireless device to a network entity or a data network (DN).

[0141] In some embodiments, the network device may receive the AIoT data from the AMF; and transmit the AIoT data to the network entity.

[0142] In some embodiments, the AIoT data may be received over a PDU session over CP targeting the network entity.

[0143] In some embodiments, the network device may receive an AIoT data request including AIoT session ID from the network entity, wherein the AIoT data may be received together with the AIoT session ID.

[0144] In some embodiments, the AIoT data may be received over a PDU session over UP for communication between the terminal device and the AIOTF.

[0145] In some embodiments, the AIoT data may be received in multiple messages of a same session, and the network device may perform data aggregation before transmitting the AIoT data to the network entity.

[0146] In some embodiments, the AIoT configuration may further indicate at least one data aggregation rule for the terminal device.

[0147] In some embodiments, the data aggregation rule(s) may indicate at least one of the following: a number of AIoT devices to be reported; latency requirements; and a list of AIoT IDs that are expected to respond.

[0148] In some embodiments, the network device is may perform operator-controlled services for the received AIoT data, the operator-controlled services including at least one of authentication, authorization checking, and device ID validation.

[0149] In some embodiments, the network entity may comprise an application function (AF).

[0150] In some embodiments, an apparatus capable of performing the method 800 (for example, the terminal device 340) may comprise means for performing the respective steps of the method 800. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[0151] In some example embodiments, the apparatus comprises: means for receiving, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration from an AIoT function (AIOTF), the AIoT configuration indicating forwarding mechanism for forwarding AIoT data received from at least one wireless device to a network entity or a data network (DN); and means for forwarding the AIoT data to the network entity or the DN based on the AIoT configuration.

[0152] In some embodiments, the apparatus further comprises means for performing other steps in some embodiments of the method 800. In some embodiments, the means comprises at least one processor and at least one memory including computer program code, the at leastone memory and computer program code configured to, with the at least one processor, cause the performance of the apparatus.

[0153] In some embodiments, an apparatus capable of performing the method 900 (for example, the network device for performing the AMF 330) may comprise means for performing the respective steps of the method 900. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[0154] In some example embodiments, the apparatus comprises: means means for maintaining ambient Internet of Things (AIoT) context indicating an AIoT function (AIOTF) associated with a terminal device; means for receiving the AIoT data from the terminal device; and means for forwarding, via the AIOTF, the AIoT data to a network entity or a data network (DN) requesting the AIoT data based on the AIoT context.

[0155] In some embodiments, the apparatus further comprises means for performing other steps in some embodiments of the method 900. In some embodiments, the means comprises at least one processor and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the apparatus.

[0156] In some embodiments, an apparatus capable of performing the method 1000 (for example, the network device for performing AIOTF 320) may comprise means for performing the respective steps of the method 1000. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[0157] In some example embodiments, the apparatus comprises: means for transmitting, at a network device and via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration to a terminal device, the AIoT configuration indicating forwarding mechanism for forwarding AIoT data from at least one wireless device to a network entity or a data network (DN).

[0158] In some embodiments, the apparatus further comprises means for performing other steps in some embodiments of the method 1000. In some embodiments, the means comprises at least one processor and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the apparatus.

[0159] FIG. 11 illustrates a simplified block diagram of a device 1100 that is suitable forimplementing some example embodiments of the present disclosure. The device 1100 may be provided to implement a communication device, for example, the terminal device or the network devices or entities as shown in FIG. 3. As shown, the device 1100 includes one or more processors 1110, one or more memories 1120 coupled to the processor 1110, and one or more communication modules 1140 coupled to the processor 1110.

[0160] The communication module 1140 is for bidirectional communications. The communication module 1140 has at least one antenna to facilitate communication. The communication interface may represent any interface that is necessary for communication with other network elements.

[0161] The processor 1110 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 1100 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

[0162] The memory 1120 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 1124, an electrically programmable read only memory (EPROM), a flash memory, a hard disk, a compact disc (CD), a digital video disk (DVD), and other magnetic storage and / or optical storage. Examples of the volatile memories include, but are not limited to, a random access memory (RAM) 822 and other volatile memories that will not last in the power-down duration.

[0163] A computer program 1130 includes computer executable instructions that are executed by the associated processor 1110. The program 1130 may be stored in the ROM 1124. The processor 1110 may perform any suitable actions and processing by loading the program 1130 into the RAM 1122.

[0164] The embodiments of the present disclosure may be implemented by means of the program 1130 so that the device 1100 may perform any process of the disclosure as discussed with reference to FIGS. 8 to 10. The embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[0165] In some example embodiments, the program 1130 may be tangibly contained in a computer-readable medium which may be included in the device 1100 (such as in thememory 1120) or other storage devices that are accessible by the device 1100. The device 1100 may load the program 1130 from the computer-readable medium to the RAM 1122 for execution. The computer-readable medium may include any types of tangible non-volatile storage, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like.

[0166] FIG. 12 illustrates a block diagram of an example of a computer-readable medium 600 in accordance with some example embodiments of the present disclosure. The computer- readable medium 1200 has the program 1130 stored thereon. It is noted that although the computer-readable medium 1200 is depicted in form of CD or DVD in FIG. 12, the computer-readable medium 1200 may be in any other form suitable for carry or hold the program 1130.

[0167] Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0168] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the process or method 800, 900, or 1000 as described above with reference to FIGS. 8 to 10. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

[0169] Program code for carrying out methods of the present disclosure may be written inany combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0170] In the context of the present disclosure, the computer program codes or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer-readable medium, and the like.

[0171] The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer-readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. The term “non-transitory,” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).

[0172] Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, variousfeatures that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

[0173] Although the present disclosure has been described in languages specific to structural features and / or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

WHAT IS CLAIMED IS:

1. A terminal device comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the terminal device at least to: receive, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration from an AIoT function (AIOTF), the AIoT configuration indicating forwarding mechanism for forwarding AIoT data received from at least one wireless device to a network entity or a data network (DN); and forward the AIoT data to the network entity or the DN based on the AIoT configuration.

2. The terminal device of claim 1, wherein, to forward AIoT data received from the at least one wireless device to the network entity or the DN based on the AIoT configuration, the terminal device is caused to: establish, using CP CIoT 5GS optimization, a protocol data unit (PDU) session targeting the network entity or the DN; and transmit, over the established PDU session, the AIoT data received from the at least one wireless device together with a PDU session identity (ID) of the PDU session to the AMF.

3. The terminal device of claim 1, wherein, to forward AIoT data received from the at least one wireless device to the network entity based on the AIoT configuration, the terminal device is caused to: receive, from the AMF, an AIoT session ID that is associated with an AIoT data request from the network entity; and transmit the AIoT data received from the at least one wireless device together with the AIoT session ID to the AMF.

4. The terminal device of claim 1, wherein, to forward AIoT data received from the at least one wireless device to the DN based on the AIoT configuration, the terminal device is caused to: establish a PDU session over UP targeting the DN; andtransmit, over the established PDU session over UP, the AIoT data received from the at least one wireless device to a user plane function (UPF).

5. The terminal device of claim 1, wherein, to forward AIoT data received from the at least one wireless device to the network entity based on the AIoT configuration, the terminal device is caused to: establish a PDU session over UP for communication between the terminal device and the AIOTF; and transmit, over the established PDU session over UP, the AIoT data received from the at least one wireless device to the AIOTF.

6. The terminal device of any of claims 1 to 5, wherein the AIoT configuration further indicates a data aggregation rule, and wherein the terminal device is further caused to: before forwarding the AIoT data, aggregate at least part of the AIoT data received from the at least one wireless device based on the data aggregation rule.

7. The terminal device of claim 6, wherein the data aggregation rule indicates at least one of the following: a number of AIoT devices to be reported; latency requirements; or a list of AIoT IDs that are expected to respond.

8. The terminal device of claim 6 or 7, wherein, to forward the AIoT data to the network entity or the DN, the terminal device is caused to: forward, based on the data aggregation rule, the AIoT data received from the at least one wireless device using multiple messages of a same session.

9. The terminal device of claim 8, wherein the first one of the multiple messages includes a first indication and the last one of the multiple messages includes a last indication.

10. The terminal device of any of claims 1 to 9, wherein the terminal device is a user equipment (UE) as an intermediate node between the at least one wireless device and the network entity or the DN.

11. The terminal device of claim 1, wherein the network entity comprises an application function (AF).

12. A network device for performing an access and mobility management function (AMF), comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the terminal device at least to: maintain ambient Internet of Things (AIoT) context indicating an AIoT function (AIOTF) associated with a terminal device; receive the AIoT data from the terminal device; and forward, via the AIOTF, the AIoT data to a network entity or a data network (DN) requesting the AIoT data based on the AIoT context.

13. A network device of claim 12, wherein the AIoT data is received together with a PDU session ID of a PDU session targeting the network entity or the DN, and wherein, to forward the AIoT data, the network device is caused to: transmit, over the PDU session, the AIoT data to a session management function (SMF) or the AIOTF.

14. The network device of claim 12, wherein the network device is further caused to: forward an AIoT data request including an AIoT session ID to the terminal device.

15. The network device of claim 14, wherein the AIoT data is received together with the AIoT session ID, and wherein, to forward the AIoT data to the network entity requesting the AIoT data, the network device is caused to: transmit the AIoT data together with the AIoT session ID to the AIOTF.

16. The network device of claim 14, wherein the AIoT data is received in multiple messages of a same session, and the network device is further caused to: perform data aggregation before forwarding the AIoT data to the network entity.

17. The network device of claim 14, wherein, to forward the AIoT data to the network entity, the network device is caused to: forward the AIoT data using multiple messages of a same session.

18. The network device of claim 17, wherein the first one of the multiple messages includes a first indication and the last one of the multiple messages includes a last indication.

19. The network device of claim 12, wherein the network device is further caused to: perform operator-controlled services for the received AIoT data, the operator- controlled services including at least one of authentication, authorization checking, and device ID validation.

20. The network device of claim 12, wherein the network entity comprises an application function (AF).

21. A network device for performing ambient Internet of Things function (AIOTF), comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the terminal device at least to: transmit, via an access and mobility management function (AMF), an AIoT configuration to a terminal device, the AIoT configuration indicating forwarding mechanism for forwarding AIoT data from at least one wireless device to a network entity or a data network (DN).

22. The network device of claim 21, wherein the network device is further caused to: receive the AIoT data from the AMF; and transmit the AIoT data to the network entity.

23. The network device of claim 22, wherein the AIoT data is received over a PDU session over CP targeting the network entity.

24. The network device of claim 22, wherein the network device is further caused to: receive an AIoT data request including AIoT session ID from the network entity, wherein the AIoT data is received together with the AIoT session ID.

25. The network device of claim 22, wherein the AIoT data is received over a PDU session over UP for communication between the terminal device and the AIOTF.

26. The network device of claim 22, wherein the AIoT data is received in multiple messages of a same session, and the network device is further caused to: perform data aggregation before transmitting the AIoT data to the network entity.

27. The network device of claim 21, wherein the AIoT configuration further indicates a data aggregation rule for the terminal device.

28. The network device of claim 27, wherein the data aggregation rule indicates at least one of the following: a number of AIoT devices to be reported; latency requirements; and a list of AIoT IDs that are expected to respond.

29. The network device of claim 22, wherein the network device is further caused to: perform operator-controlled services for the received AIoT data, the operator- controlled services including at least one of authentication, authorization checking, and device ID validation.

30. The network device of claim 21, wherein the network entity comprises an application function (AF).

31. A method comprising: receiving, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration from an AIoT function (AIOTF), the AIoT configuration indicating forwarding mechanism for forwarding AIoT data received from at least one wireless device to a network entity or a data network (DN); andforwarding, the AIoT data to the network entity or the DN based on the AIoT configuration.

32. A method comprising: maintaining ambient Internet of Things (AIoT) context indicating an AIoT function (AIOTF) associated with a terminal device; receiving the AIoT data from the terminal device; and forwarding, via the AIOTF, the AIoT data to a network entity or a data network (DN) requesting the AIoT data based on the AIoT context.

33. A method comprising: transmitting, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration to a terminal device, the AIoT configuration indicating forwarding mechanism for forwarding AIoT data from at least one wireless device to a network entity or a data network (DN).

34. An apparatus comprising: means for receiving, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration from an AIoT function (AIOTF), the AIoT configuration indicating forwarding mechanism for forwarding AIoT data received from at least one wireless device to a network entity or a data network (DN); and means for forwarding the AIoT data to the network entity or the DN based on the AIoT configuration.

35. An apparatus comprising: means for maintaining ambient Internet of Things (AIoT) context indicating an AIoT function (AIOTF) associated with a terminal device; means for receiving the AIoT data from the terminal device; and means for forwarding, via the AIOTF, the AIoT data to a network entity or a data network (DN) requesting the AIoT data based on the AIoT context.

36. An apparatus comprising: means for transmitting, at a network device and via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration to a terminal device, the AIoT configuration indicating forwarding mechanism for forwarding AIoT data from at least one wireless device to a network entity or a data network (DN).

37. A non-transitory computer readable medium comprising program instructions that, when executed by an apparatus, cause the apparatus to perform at least: receiving, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration from an AIoT function (AIOTF), the AIoT configuration indicating forwarding mechanism for forwarding AIoT data received from at least one wireless device to a network entity or a data network (DN); and forwarding, the AIoT data to the network entity or the DN based on the AIoT configuration.

38. A non-transitory computer readable medium comprising program instructions that, when executed by an apparatus, cause the apparatus to perform at least: maintaining, ambient Internet of Things (AIoT) context indicating an AIoT function (AIOTF) associated with a terminal device; receiving the AIoT data from the terminal device; and forwarding, via the AIOTF, the AIoT data to a network entity or a data network (DN) requesting the AIoT data based on the AIoT context.

39. A non-transitory computer readable medium comprising program instructions that, when executed by an apparatus, cause the apparatus to perform at least: transmitting, via an access and mobility management function (AMF), an ambient Internet of Things (AIoT) configuration to a terminal device, the AIoT configuration indicating forwarding mechanism for forwarding AIoT data from at least one wireless device to a network entity or a data network (DN).

Images