METHOD AND APPARATUS OF SUPPORTING INTERNET OF THINGS (IoT)

Abstract

Various aspects of the present disclosure relate to a method and apparatus of support internet of things (IoT). An exemplary method performed by a CN entity for wireless communication may include: transmitting, to a first NE, a first command request associated with an AIoT device that connects with the first NE; and determining a second NE that the AIoT device connects with, in response to a failure of the first command request.

Description

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

[0001] The present disclosure relates to wireless communications, and more specifically to techniques of supporting internet of things (IoT) .BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, such as base stations, which may support wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE) , or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like) . Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G) ) .SUMMARY

[0003] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a, ” “at least one, ” “one or more, ” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of” or “one or more of” or “one or both of” ) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C) . Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is  described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0004] Some implementations of the methods and apparatuses described herein may further include a core network (CN) entity for wireless communication, which may include: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the CN entity to: transmit, to a first network equipment (NE) , a first command request associated with an ambient internet of things (AIoT) device that connects with the first NE; and determine a second NE that the AIoT device connects with, in response to a failure of the first command request.

[0005] In some implementations of the methods and apparatuses described herein, the first NE and the second NE are neighboring NEs supporting AIoT services, and the at least one processor is configured to cause the CN entity to: determine information on neighboring NEs supporting AIoT services within a coverage area of the CN entity; and transmit the information on neighboring NEs supporting AIoT services to NEs within the serving area, wherein the information includes IDs of neighboring NEs.

[0006] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: receive, from the first NE or the second NE, information indicating that an ID of the AIoT device is associated with an ID of the second NE separate from a command identified by a service ID in the first command request or together with the command response.

[0007] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: further receive, from the first NE or the second NE, one or more of an unreachability indication or a command failure indication associated with the AIoT device.

[0008] In some implementations of the methods and apparatuses described herein, in the case that the command response is received from the second NE after receiving the  information indicating that the ID of the AIoT device is associated with the ID of the second NE, the at least one processor is configured to cause the CN entity to: transmit, to the second NE, a second command request associated with the AIoT device, wherein the second command request indicates the command identified by the service ID.

[0009] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: receive, from the first NE, one or more of: an unreachability indication or a command failure indication associated with the AIoT device, an identifier (ID) of the AIoT device, an ID of the first NE, or a service ID identifying a command included in the first command request; and transmit an inventory request for the AIoT device to all NEs within a coverage area of the CN entity.

[0010] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: receive, from the second NE, an inventory response in response to the inventory request, indicating that an ID of the AIoT device is associated with an ID of the second NE.

[0011] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: transmit, to the second NE, a second command request associated with the AIoT device, wherein the second command request indicates the command identified by the service ID; and receive, from the second NE, a command response associated with the command identified by the service ID.

[0012] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: transmit, to the second NE, a second command request associated with the AIoT device, together with the inventory request or after receiving the inventory response, wherein the second command request indicates the command identified by the service ID; and receive, from the second NE, a command response associated with the command identified by the service ID.

[0013] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: transmit, to all NEs within a coverage area of the CN entity, information indicating an ID of the AIoT device together with the inventory request.

[0014] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: transmit, to the second NE, information indicating one or more of an ID of the first NE, the service ID or ID of the AIoT device so that the second NE will retrieve related command information from the first NE.

[0015] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the CN entity to: transmit, to the first NE, information indicating one or more of an ID of the second NE associated with the ID of the AIoT device, or the service ID; and receive, from the second NE, a command response associated with the command identified by the service ID.

[0016] Some implementations of the methods and apparatuses described herein may further include a NE for wireless communication, which may include: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the NE to: transmit a first command request associated with an AIoT device; and in response to a failure of the first command request, transmit information associated with the AIoT device to a CN entity or at least one other NE, to trigger a search of a second NE that the AIoT device connects with.

[0017] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the first NE to: determine the failure of the first command request after one or more times of retry sending the first command request to the AIoT device or after initiating an inventory procedure for the AIoT device and still failing to reach the AIoT device.

[0018] In some implementations of the methods and apparatuses described herein, in response to that the failure of the first command request, the at least one processor is configured to cause the first NE to: transmit, to neighboring NEs supporting AIoT services via Xn interface, the information associated with the AIoT device indicating an ID of the AIoT device based on received information on neighboring NEs supporting AIoT services, wherein the information on neighboring NEs supporting AIoT services includes IDs of the neighboring NEs.

[0019] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the first NE to: further transmit, to the neighboring NEs, one or more of: an unreachability indication associated with the AIoT device, or a time stamp associated with the failure of the first command request, or information associated with inventory for the AIoT device, or a context of the AIoT device.

[0020] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the first NE to: further transmit, to the neighboring NEs, command request associated information indicating one or more of an ID of the CN entity, a service ID or command configuration identified by the service ID for the AIoT device.

[0021] In some implementations of the methods and apparatuses described herein, the first NE and the second NE are served by the CN entity, and the at least one processor is configured to cause the first NE to: transmit, to the second NE, command request associated information after receiving information indicating that an ID of the AIoT device is associated with an ID of the second NE, wherein the command request associated information indicates one or more of the first command request or associated command configuration identified by a service ID.

[0022] In some implementations of the methods and apparatuses described herein, the first NE and the second NE are served by different CN entities, and the at least one processor is configured to cause the first NE to: transmit, to the CN entity, the information associated with the AIoT device indicating one or more of: an ID of the first NE, a time stamp associated with the failure of the first command request, an ID of the AIoT device, a service ID identifying a command included in the first command request, or location information of the first NE.

[0023] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the first NE to: receive, from the second NE, information indicating that an ID of the AIoT device is associated with an ID of the second NE after receiving the inventory response from the AIoT device.

[0024] In some implementations of the methods and apparatuses described herein, the at least one processor is configured to cause the first NE to: transmit, to the second NE, command request associated information in response to a request from the second NE, wherein the command request associated information indicates a service ID and command configuration identified by the service ID for the AIoT device.

[0025] Some implementations of the methods and apparatuses described herein may further include a method performed by a CN entity for wireless communication, which may include: transmitting, to a first NE, a first command request associated with an AIoT device that connects with the first NE; and determining a second NE that the AIoT device connects with, in response to a failure of the first command request.

[0026] Some implementations of the methods and apparatuses described herein may further include a method performed by a NE for wireless communication, which may include: transmitting a first command request associated with an AIoT device; and in response to a failure of the first command request, transmitting information associated with the AIoT device to a CN entity or at least one other NE, to trigger a search of a second NE that the AIoT device connects with.

[0027] Some implementations of the methods and apparatuses described herein may further include a CN entity for wireless communication, which may include: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the CN entity to: receive a device availability indication associated with an AIoT device, the device availability indication indicating an unavailability of the AIoT device; and in response to receiving the device availability indication, transmit to a second CN entity an inventory request associated with the AIoT device.

[0028] In some implementations of the methods and apparatuses described herein, transmitting the inventory request is event triggered, and the at least one processor is configured to cause the CN entity to further transmit to the second CN entity a command associated with the AIoT device.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0030] Figure 2 illustrates an example of RAN reader Xn based procedure in accordance with aspects of the present disclosure.

[0031] Figure 3 illustrates an example of CN entity based paging procedure in accordance with aspects of the present disclosure.

[0032] Figure 4 illustrates another example of CN entity based paging procedure in accordance with aspects of the present disclosure.

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

[0034] Figure 6 illustrates an example of a CN entity in accordance with aspects of the present disclosure.

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

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

[0037] IoT has attracted much attention in wireless communication world, where IoT devices usually have a smaller size, lower complexity, lower power consumption and huger number (e.g., tens or even hundreds of billion IoT devices) than existing UEs. The IoT devices are typically battery less devices with no energy storage capability, or devices with energy storage that do not need to be replaced or recharged manually, for which the energy may be provided through the harvesting of radio waves, light, motion, heat, or any other power sources that are suitable for providing energy for the devices. For simplicity, such kind of IoT devices may be referred to as AIoT devices (or tags) . In other words, an AIoT device may be an IoT device with limited energy storage capability and powered by energy harvesting.

[0038] There are two main types of AIoT devices to be studied for 3rd generation partnership program (3GPP) Release 19, including: device-terminated (DT) and device-originated -device-terminated triggered (DO-DTT) . Accordingly, the following two connectivity topologies are to be studied:

[0039] - Topology 1: BS (or the like) <--> AIoT Device;

[0040] - Topology 2: BS (or the like) <--> intermediate node <--> AIoT Device.

[0041] Moreover, two kinds of services are being considered: inventory and command. Regarding command, it may include read, write, enable and disable etc.

[0042] For topology 1 where a next generation-radio access network (NG-RAN) node or the like, e.g., gNB acts as the reader, an AIoT device (s) , which is reachable for a RAN reader after the inventory of the device is finished within the coverage area of the RAN reader, may be unreached due to the mobility of the AIoT device or obstacles blocking etc., which may cause the command from the RAN reader towards this device fails due to the unreachability. Thus, how to find the unreachable AIoT device and continue the unfinished / failed command needs to be addressed.

[0043] From the perspective of CN entity serving readers, e.g., AIoT function (AIoTF) or access and mobility management functions (AMF) , various aspects of the present disclosure propose that based on the result of the last inventory of AIoT devices, a CN entity serving readers may transmit, to a NE acting as a RAN reader (hereinafter, first NE) , a command request (hereinafter, first command request) associated with at least one AIoT device associated with the first NE. The first command request indicates a command identified by a service ID. After receiving the first command request, the first NE will initiate a command procedure to each associated AIoT device for the command. However, in some scenarios, the command procedure or the first command request to a specific AIOT device may fail due to the mobility of the AIoT device or obstacles blocking etc., factors. The AIoT device unreachable for the first NE may be found again by another NE acting a RAN reader (hereinafter, second NE) via a RAN reader Xn based procedure or a CN entity based paging procedure. Accordingly, the CN entity may determine a second NE that the AIoT device connects with.

[0044] From the perspective of RAN reader, various aspects of the present disclosure propose that a NE acting as a RAN reader (the first NE) may transmit a first command request associated with an AIoT device. The first command request indicates a command identified by a service ID. However, an initial command procedure associated with the command or the first command request to the AIoT device may fail due to the mobility of the AIoT device or obstacles blocking etc., factors. That is, the AIoT device is unreachable for the first NE. The AIoT device unreachable for the first NE may be found again by the second NE via a RAN reader Xn based procedure or a CN entity based paging procedure. The first NE may transmit information associated with the AIoT device to a CN entity serving the first NE (e.g., an AIoTF or AMF) or at least one other NE (e.g., neighboring RAN readers) , to trigger a search of a second NE that the AIoT device connects with.

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

[0046] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NE 102, one or more UE 104, and a core network (CN) 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE-Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G-Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi) , IEEE 802.16 (WiMAX) , IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA) , frequency division multiple access (FDMA) , or code division multiple access (CDMA) , etc.

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

[0048] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc. ) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN) . In some implementations, different geographic coverage areas 112 associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0049] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of-Things (IoT) device, an Internet-of-Everything (IoE) device, or machine-type communication (MTC) device, among other examples.

[0050] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link 114 may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0051] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., S1, N2, N3, or network interface) . In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g., via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC) . An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs) .

[0052] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC) , or a 5G core (5GC) , which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME) , an access and mobility management functions (AMF) ) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW) , a Packet Data Network (PDN) gateway (P-GW) , or a user plane function (UPF) ) . In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc. ) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.

[0053] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an S1, N2, N3, or another network interface) . The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session) . The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106) .

[0054] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers) ) to perform various operations (e.g., wireless communications) . In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures) . The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0055] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., μ=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., μ=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., μ=1) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., μ=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., μ=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., μ=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0056] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames) . Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0057] Additionally or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., μ=0, μ=1, μ=2, μ=3, μ=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols) . In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing) , a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., μ=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0058] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz –7.125 GHz) , FR2 (24.25 GHz –52.6 GHz) , FR3 (7.125 GHz –24.25 GHz) , FR4 (52.6 GHz –114.25 GHz) , FR4a or FR4-1 (52.6 GHz –71 GHz) , and FR5 (114.25 GHz –300 GHz) . In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data) . In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0059] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies) . For example, FR1 may be associated with a first numerology (e.g., μ=0) , which includes 15 kHz subcarrier spacing; a second numerology (e.g., μ=1) , which includes 30 kHz subcarrier spacing; and a third numerology (e.g., μ=2) , which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies) . For example, FR2 may be associated with a third numerology (e.g., μ=2) , which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., μ=3) , which includes 120 kHz subcarrier spacing.

[0060] Under topology 1 for AIoT devices, in the case that the inventory procedure towards an AIoT device has been done by a RAN reader (or referred to as a serving RAN reader) , the binding relationship between the AIoT device and the serving RAN reader will be reported and saved at the 5GC, e.g., in the AMF or AioTF, or UDM, UDR. The following command towards this AIoT device will be forwarded via the serving RAN reader. However, the reachability of the AIoT device within the coverage area of the serving RAN reader may change due to various factors. For example, due to the mobility of AIoT devices, the AIoT device associated with the serving RAN reader may move to other place (s) after the last inventory is finished, and may be out of the coverage area of the serving RAN reader. Accordingly, the serving RAN reader cannot reach this AIoT device to send certain command (s) , e.g., read and / or write etc. For another example, the radio transmission conditions between the serving RAN reader and the AIoT device may be changed due to some giant obstacles, such as a huge box or a temporarily parking car, blocking between the serving RAN reader and the AIoT device. Accordingly, the serving RAN reader cannot reach or page the AIoT device any more due to the blocking.

[0061] Such device unreachability situations may happen after an inventory of the AIoT device is finished and before a new inventory procedure of this device is conducted, reported and updated at the AIoTF or the like by other reader (s) . Thus, the command for the unreachable AIoT device will still be forwarded to the serving RAN reader which is determined based on the last inventory while cannot serve the AIoT device any more. Considering that, the serving reader may be referred to as an old or source or original reader or source serving reader for the AIoT device. Consequently, the associated command  procedure initiated by the source serving RAN reader may fail. In some cases, even after an inventory procedure (s) initiated by the source serving RAN reader, the source serving RAN reader may still fail to discover the AIoT device again. Then, the source serving RAN reader may determine that the AIoT device is unreachable and / or the command fails.

[0062] Various aspects of the present disclosure propose a RAN reader Xn based procedure and a CN entity based paging procedure to find the unreachable AIoT device (s) .

[0063] Regarding an exemplary RAN reader Xn based procedure, information on neighboring NEs supporting AIoT services (e.g., neighboring RAN readers) within the coverage area (or serving area or the like) of a CN entity (e.g., an AIoTF or AMF) serving RAN readers may be configured for RAN readers. Regarding the rule (s) on how to determine RAN readers are "neighboring, " it may be defined by the CN entity serving RAN readers, e.g., AIoTF or AMF, or configured by operations administration and maintenance (OAM) . Exemplary information on neighboring RAN readers may include a list of IDs of neighboring RAN readers. The exemplary information on neighboring RAN readers may further include locations of the RAN readers and other AIoT related configuration information and / or parameters, e.g., information for establishing Xn interface or tunnel between neighboring RAN readers etc.

[0064] The information on neighboring RAN readers may be configured or determined by various manners. In some implementations of the present disclosure, the information on neighboring RAN readers may be determined by the AIoTF or AMF in 5GC after RAN reader registration (e.g., establishing connections with the AIoTF via AMF) . For example, each RAN reader is supposed to register itself at the AMF or AIoTF by providing the AIoT related capability (e.g., mobile or stationary, supported frequency bands for AIoT transmission, range of communication etc. ) and location thereof, and establishes N2 interface or tunnel with the AMF or N2 like interface or tunnel with AIoTF. Regarding N2 like tunnel or interface established between the RAN reader and the AIoTF (for simplification, herein, N2 like also referred to as N2) , it may be the upgrade of the existing next generation-application protocol (NG-AP) interface or totally newly defined. After determining the information on neighboring RAN readers, the AIoTF or AMF may transmit it to all RAN readers within the coverage area thereof. In some other implementations of the present  disclosure, the information on neighboring RAN readers may be pre-configured for RAN readers by network mobile network operator (MNO) through OAM.

[0065] Based on the information on neighboring RAN readers, in the case that an AIoT device is unreachable and a command procedure to the AIoT device associated with a command identified by a service ID fails, the source serving RAN reader (e.g., the first NE) may send the ID of the unreachable AIoT device to all the neighboring RAN readers via Xn interface to trigger the neighboring RAN readers to initiate inventory procedures to find the unreachable AIoT device. The neighboring RAN reader (e.g., the second NE) that finds this AIoT device may initiate another command procedure to the AIoT device associated with the failed command, so that the command will be finished.

[0066] Regarding an exemplary CN entity based paging procedure, it may be an AMF or AIoTF based paging procedure. The AMF or AIoTF serving the first NE and that serving the second NE may the same or different. Different from the RAN reader Xn based procedure where the new serving RAN reader for the unreachable AIoT device is found based on the interaction among neighboring RAN readers via Xn interface, the unreachable AIoT device is found based on the inventory request triggered by a CN entity, e.g., the AIoTF or AMF.

[0067] In the case that the AMF or AIoTF serving the first NE and that serving the second NE are the same, after receiving from the first NE the unreachability indication and / or command failure indication associated with a command to an AIoT device, the AIoTF or AMF may send an inventory request for this AIoT device to all RAN readers within the coverage area thereof, so that the RAN readers to initiate inventory procedures to find the AIoT device. The neighboring RAN reader (e.g., the second NE) who finds the AIoT device unreachable for the first NE may initiate another command procedure to the AIoT device associated with the failed command, so that the command will be finished.

[0068] In the case that the AMF or AIoTF serving the first NE (hereinafter, first CN entity) and that serving the second NE (hereinafter, second CN entity) are different and served by the same unified data management (UDM) , after receiving from the first NE the unreachability indication and / or command failure indication associated with a command to an AIoT device, the first CN entity may send information related to the failed command and the unreachable AIoT device to the UDM serving the first CN entity and second CN entity.  Based on the received information, the UDM may start or initiate an inventory for the AIoT device by sending an inventory request to all AIoTFs or AMFs served by the UDM to find the AIoT device. Accordingly, each associated AIoTF or AMF including the second CN entity serving the second NE may trigger all RAN readers within the coverage area thereof to initiate an inventory procedure to find the AIoT device. After the second NE finds the AIoT device, the UDM may forward the locally stored device context information (e.g., last serving RAN reader and NF information, device status) to the second NE, together with the command configuration

[0069] In some cases of CN entity based paging procedure, UDM may periodically trigger an inventory for each associated AIoT device by itself. Regardless of whether the first and second NEs are served by the same CN entity or not, the first CN entity serving the first NE may wait for the periodic inventory in the case of a failed command procedure or failing to reach an AIoT device, reporting the information related to the failed command and the unreachable AIoT device to the UDM or not.

[0070] Detailed implementations of the present disclosure will be illustrated in the following respectively in view of an exemplary RAN reader Xn based procedure and exemplary CN entity based paging procedure. Persons skilled in the art should well know that although only AIoTF is used for illustrating the exemplary implementations, it may be replaced by AMF or other CN entity with the same or similar function. In addition, although only one first NE acting as a RAN reader, one second NE acting as a RAN reader, one AIoT device and one command are used to illustrate the exemplary implementations for conciseness and clearness, persons skilled in the art would well know how to apply the illustrated solutions in more complex scenarios involving more failed commands and / or more unreachable AIoT devices.

[0071] Figure 2 illustrates an example of RAN reader Xn based procedure in accordance with aspects of the present disclosure.

[0072] Referring to Figure 2, it is assumed that an inventory procedure, e.g., initiated by 5GC or AIoT application APP has been conducted and an AIoT device, e.g., AIoT device#1 was inventoried by a RAN reader, e.g., RAN reader#1 and reported to the AIoTF serving RAN reader#1. The ID of AIoT device#1 is exposed to the 3rd party APP, e.g., AIoT  application function (AF) . In some scenarios, it may also be assumed that RAN reader#1 with which AIoT device#1 is associated is also exposed to the AIoT AF. In addition, it is also assumed that the information on neighboring RAN readers and other information or message (s) or parameter (s) for establishing Xn interface between neighboring RAN readers has been configured for RAN readers, e.g., RAN reader#1 and RAN reader#2.

[0073] At step 201, the AIoTF (or AMF) may receive from the 3rd party AIoT AF (not shown) a command request, indicating a command (or service) to be performed. The command request may further include one or more of the following: a service ID (or transaction ID) identifying the command, the AIoT device ID (or target device ID) , aggregation indication, report configuration, reader ID, destination IP address, target location, APP ID (e.g., AIoT AF ID) , filtering and / or match information, etc. As legacy, the network exposure function (NEF) (not shown) may interact with the UDM (not shown) , unified data repository (UDR) (not shown) and / or authentication server function (AUSF) (not shown) to authorize the command request from the AIoT AF, authenticate the target device ID, and select the proper AIoTF based on one or more of the target location, or target device ID or RAN reader ID.

[0074] Regarding the target device (s) or AIoT device (s) on which the command will be performed, the command request (or service request) may indicate it in various manners. For example, in some cases, the command may be for one or more specific target device IDs, and the command request may at least indicate each target device ID. In some cases, the command may be for all AIoT devices within the coverage area of one or more RAN readers, and for simplification, the command request may not indicate each AIoT device ID while indicate related RAN reader IDs. Herein, for clearness, it is assumed that the command is for a specific AIoT device, e.g., AIoT device#1.

[0075] At least based on the command request and the last inventory result, the AIoTF will determine or select a proper RAN reader, e.g., RAN reader#1 with which the AIoT device, e.g., AIoT device#1 where the command is expected to be performed is associated. For example, the AIoTF may determine the RAN reader for the target device either based on the reader ID included in the received command request or based on locally stored last known reader information or binding information for the target device.

[0076] At step 203, the AIoTF may transmit a command request to the selected RAN reader (e.g., source RAN reader) , e.g., RAN reader#1. The command request to RAN reader#1 may be the same or updated based on the received command request from the AIoTF. For example, in the case of lacking service ID for the command in the command request received from the AIoT AF, the AIoTF may allocate a service ID, e.g., service ID#1 to the command so that there is a corresponding relationship between a service ID and the command received from the AIoT AF.

[0077] At step 205, RAN reader#1 may initiate a command procedure (hereinafter, initial command procedure or first command procedure for the command) to AIoT device#1 to indicate the command to AIoT device#1. For example, RAN reader#1 may interact with AIOT device#1, e.g., by sending paging information to AIoT device#1, which contains the information related to the command, e.g., command configuration (or service configuration) and the associated service ID etc. However, it is assumed that AIoT device#1 is unreachable currently due to moving out the coverage area of the source RAN reader, or the radio transmission path being blocked etc., and RAN reader#1 failed to receive any response from AIoT device#1.

[0078] At step 207, the source RAN reader, e.g., RAN reader#1 may determine that AIoT device#1 is unreachable and the command (or the command procedure for the command, or the first command request) to AIoT device#1 fails. For example, RAN reader#1 may directly determine that AIoT device#1 is unreachable and the command (or the command procedure for the command, or the first command request) to AIoT device#1 fails in response to not receiving any response from AIoT device#1. For another example, RAN reader#1 may make such decision after several times of retry sending the command to AIoT device#1. For yet another example, RAN reader#1 may make such decision after initiating an inventory procedure for AIoT device#1 by itself while still failing to reach AIoT device#1.

[0079] It is assumed that no new periodic inventory results have been reported to the AIoTF regarding this unreachable AIoT device. In response to the failure of the first command request, RAN reader#1 may transmit information associated with the AIoT device to a CN entity or at least one other NE, to trigger a search of a second NE that the AIoT device connects with. For example, at step 209, RAN reader#1 will send to its neighboring  RAN readers via Xn interface an ID of the AIoT device to trigger the neighboring RAN readers to initiate inventory procedures to find AIoT device#1.

[0080] Besides the ID of AIoT device#1, RAN reader#1 may also send other information to neighboring RAN readers to help the neighboring RAN readers understand the unreachable AIoT device, failed command and / or inventory performed on RAN reader#1 etc. For example, RAN reader#1 may transmit to the neighboring RAN readers one or more of: an unreachability indication associated with AIoT device#1, or a command failure indication, or a time stamp associated with the failure of the initial command procedure, or command configuration, or service ID identifying the command, or ID of the AIoTF, or a context of AIoT device#1 or information associated with inventory (s) for AIoT device#1 etc. Regarding the device context, it may include the device status (e.g., enable, disable) , the last known reader for the device etc. In the case that the device context is saved in reader level, the source RAN reader may indicate it to neighboring RAN readers (e.g., at step 209 or in a separate step) . However, in some scenarios, the device context may only be saved at the CN entity (e.g., AIoTF) for certain AIoT device (s) and not saved at the reader level, and RAN reader#1 cannot provide the device context.

[0081] At step 211, as a neighboring RAN reader of RAN reader#1, after receiving at least the ID of AIoT device#1, RAN reader#2 may initiate an inventory for AIoT device#1 within its coverage area by including the ID of AIoT device#1 in the paging message. In some scenarios, the inventory initiated by RAN reader#2 may be based on information associated with inventory configuration information received from RAN reader#1, which may indicate, e.g., inventory attempt times, and / or waiting period etc. In some other scenarios, the inventory initiated by RAN reader#2 may be based on the local configuration provided by 5GC, e.g., OAM or AIoTF or AF.

[0082] It is assumed that at step 213, RAN reader#2 will receive the inventory response from AIoT device#1. That is, AIoT device#1 is inventoried by RAN reader#2, which means that AIoT device#1 moves into the coverage of RAN reader#2, or the transmission path between AIoT device#1 and RAN reader#2 is functioning well.

[0083] After finding AIoT device#1, RAN reader#2 needs to initiate or start a command procedure to AIoT device#1 to transmit the failed or unfinished command, so that the  command will be performed in AIoT device#1. To achieve that, there are various manners in accordance with various aspects of the present disclosure, wherein, RAN reader#2 may receive the command request associated information, e.g., command configuration and service ID from one or more of the source RAN reader or AIoTF, and transmit the received command response to the source RAN reader or AIoTF.

[0084] For example, in accordance with some aspects of the present disclosure (scheme 1) , at step 215a, after receiving the inventory response from AIoT device#1, RAN reader#2 may send information indicating that AIoT device#1 is associated with RAN reader#2 to RAN reader#1. In some implementations of the present disclosure, RAN reader#2 may also send a reachability acknowledgement indication to RAN reader#1.

[0085] Based on the information or message from RAN reader#2, RAN reader#1 may send information or indication to notify the AIoTF that AIoT device#1 is now under the coverage of RAN reader#2 or is reachable for RAN reader#2 at step 217a, which means that AIoT device#1 is associated with RAN reader#2. Besides the information indicating that the AIoT device#1 is associated with RAN reader#2, in some implementations of the present disclosure, RAN reader#1 may also send an unreachability indication associated RAN reader#1, a reachability indication associated with RAN reader#2, and / or a command failure indication etc., to the AIoTF.

[0086] After receiving the notification that AIoT device#1 is associated with RAN reader#2, the AIoTF will update the binding relationship between AIoT device#1 and RAN reader, e.g., changing from associating with RAN reader#1 to associating with RAN reader#2, and the serving RAN reader for AIoT device#1 will be RAN reader#2.

[0087] At step 219a, for AIoT device#1, the AIoTF may send a command request (hereinafter, the second command request) associated with the failed command, e.g., the command identified by service ID#1 to the new serving RAN reader, e.g., RAN reader#2.

[0088] In some implementations of the present disclosure, RAN reader#2 may obtain command request associated information from RAN reader#1. For example, at step 209, RAN reader#1 may transmit the command request associated information, e.g., the command configuration and service ID etc., to neighboring RAN readers including RAN reader#2. For  another example, if RAN reader#1 does not delete or release the command request associated information after sending inventory requests at step 209, at step 221a, RAN reader#1 may send the command configuration and service ID etc., for AIoT device#1 to RAN reader#2 after receiving from the RAN reader#2 the indication that AIoT device#1 is associated with RAN reader#2.

[0089] Based on the second command request received from the AIoTF, and / or the command request associated information received from RAN reader#1, at step 223, RAN reader#2 may initiate a second command procedure associated with the command identified by service ID#1 and receive the command response. The command response may include the command result and service ID, and may further include the ID of the AIoT device and / or ID of RAN reader etc.

[0090] In some cases, RAN readers may not be able to see the contents of the command request and the command response (e.g., being application layer encrypted) . Therefore, after receiving the service ID and the associated command configuration, RAN reader#2 will start a command procedure towards AIoT device#1 as a normal command procedure (no failure occurs) regardless of the history enforcement process at RAN reader#1 because the response content is blind to RAN readers.

[0091] RAN reader#2 will send the command response or results to the AIoTF at step 225, e.g., together with the service ID and / or AIoT device ID etc. The service ID can be identified by the AIoTF, and thus the AIoTF will know the related information, e.g., which AF sends the service request etc. The AIoTF may further transmit the command response or results to the 3rd AIoT APP, e.g., together with the service ID and / or the AIoT device ID etc. The command response or result transmission from the RAN reader to the AIoTF and then to the AIoT APP can either be done via user plane, or by control plane.

[0092] In accordance with some other aspects of the present disclosure (scheme 2) , at step 215b, after receiving the inventory response from AIoT device#1, RAN reader#2 may send information indicating that AIoT device#1 is associated with RAN reader#2 to the AIoTF rather than RAN reader#1.

[0093] Similarly, after receiving the notification that AIoT device#1 is associated with RAN reader#2, the AIoTF may update the binding relationship between AIoT device#1 and RAN reader, e.g., changing from associating with RAN reader#1 to associating with RAN reader#2, and the serving RAN reader for AIoT device#1 will be RAN reader#2.

[0094] It is assumed that at step 209, RAN reader#1 has transmitted the command request associated information, e.g., the command configuration and service ID etc., to neighboring RAN readers including RAN reader#2. Similarly, at step 223, based on the command request associated information received from RAN reader#1, RAN reader#2 may initiate a second command procedure associated with the command identified by service ID#1, and receive the command response. Then the command response will be transmitted from RAN reader#2 to the AIoTF at step 225, and then to the AIoT APP, and will not repeat.

[0095] Persons skilled in the art should well know that the illustrated schemes 1 and 2 for initiating a command procedure by the new serving RAN reader, e.g., RAN reader#2 for the unfinished or failed command towards AIoT device#1 are only used for help understand the technical solutions of the present disclosure. Based on the disclosure or teaching or suggestions of the present disclosure, persons skilled in the art would easily conceive of various feasible combination of manners for inventory response transmission, manners for obtaining the command request associated information (whole command request or only necessary information for performing the command, e.g., command configuration and service ID etc. ) and manners for command response transmission, which should also be covered by the protection scope of the present disclosure. For example, in the case of RAN reader#2 transmitting the inventory result to the AIoTF as in scheme 2, the AIoTF may transmit the second command request as illustrated in scheme 1, or RAN reader#1 may separate transmit the command request associated information to RAN reader#2 instead of at step 209 as illustrated at step 221a. In some implementations of the present disclosure, in the case that RAN reader#2 receives the command configuration and service ID etc., command request associated information at step 209, after receiving the inventory response from AIoT device#1, RAN reader#2 may initiate a command procedure associated with the failed command to AIoT device#1. After receiving the command response, RAN reader#2 may report the command response to RAN reader#1 and RAN reader#1 will transmit the  command response and information indicating that AIoT device#1 is associated with RAN reader#2 to the AIoTF, or RAN reader#2 may directly report the command response to the AIoTF, which implicitly indicates that AIoT device#1 is associated with RAN reader#2. After receiving the command response, the AIoTF may update the serving RAN reader of AIoT device#1 to be RAN reader#2.

[0096] Figure 3 illustrates an example of CN entity based paging procedure in accordance with aspects of the present disclosure.

[0097] Referring to Figure 3, similarly, it is assumed that an inventory procedure, e.g., initiated by 5GC or the 3rd party App, has been conducted and an AIoT device, e.g., AIoT device#1 was inventoried by a RAN reader, e.g., RAN reader#1 and reported to the AIoTF serving RAN reader#1. The ID of AIoT device#1 is exposed to the 3rd party APP, e.g., AIoT AF.In some scenarios, it may also be assumed that RAN reader#1 with which AIoT device#1 is associated is also exposed to the AIoT AF.

[0098] Regarding step 301 to step 307, they are identical or similar to steps 201-207, and thus will not repeat herein. It is assumed that after RAN reader#1 determines that AIoT device#1 is unreachable and the command or the command procedure for the command to AIoT device#1 fails, no new periodic inventory results have been reported to the AIoTF regarding the unreachable AIoT device. In response to the failure of the command request, RAN reader#1 may transmit information associated with the AIoT device to a CN entity or at least one other NE, to trigger a search of a second NE that the AIoT device connects with.

[0099] At step 309, RAN reader#1, which is the source serving RAN reader for AIoT device#1, may send the ID of the unreachable device, e.g., AIoT device#1 to the AIoTF, with or without other related information, e.g., an unreachability indication, a command failure indication, service ID identifying the failed command, and / or the ID of RAN reader#1 etc. In the case that RAN reader#1 has conducted the inventory procedure for AIoT device#1 after several rounds of command retries and failures, RAN reader#1 may also send the inventory result (failed to find or inventory) to the AIoTF.

[0100] Based on the information or message received from RAN reader#1, at step 311, the AIoTF may send an inventory request for AIoT device#1 to all RAN readers within the  coverage area thereof, e.g., by including the ID of AIoT device#1 in the paging message. The AIoTF may also include other information or parameters in the paging message. For example, in some implementations of the present disclosure, the AIoTF may also send the service ID identifying the failed command and command configuration (or service configuration) for this command to the RAN readers together with the inventory request. In some scenarios, the AIoTF may further send the device context together with the inventory request.

[0101] It is assumed that RAN reader#2 is also under the coverage of the AIoTF. After receiving the inventory request from the AIoTF, at step 313, RAN reader#2 may trigger or initiate an inventory for AIoT device#1 within its coverage area by including the ID of AIoT device#1 in the paging message. It is also assumed that at step 315, RAN reader#2 will receive the inventory response from AIoT device#1. That is, AIoT device#1 is inventoried by RAN reader#2, which means that AIoT device#1 moves into the coverage of RAN reader#2, or the transmission path between AIoT device#1 and RAN reader#2 is functioning well.

[0102] At step 317, RAN reader#2 may send the inventory response (or inventory result) to the AIoTF, indicating that AIoT device#1 is associated with RAN reader#2. After receiving the notification that AIoT device#1 is associated with RAN reader#2, the AIoTF will update the binding relationship between AIoT device#1 and RAN reader, e.g., changing from associating with RAN reader#1 to associating with RAN reader#2, and the serving RAN reader for AIoT device#1 will be RAN reader#2.

[0103] Similarly, RAN reader#2 needs to initiate or start a command procedure to AIoT device#1 to transmit the failed or unfinished command, so that the command will be performed in AIoT device#1. To achieve that, there are various manners in accordance with various aspects of the present disclosure, wherein, RAN reader#2 may receive the command request associated information, e.g., command configuration and service ID from one or more of the source RAN reader or AIoTF.

[0104] For example, in some implementations of the present disclosure, at step 319a, the AIoTF may send a command request (the second command request) associated with the failed command, e.g., the command identified by service ID#1 to the new serving RAN reader, e.g., RAN reader#2 for AIoT device#1.

[0105] In some other implementations of the present disclosure, at step 319b, the AIoTF may send the last or old serving RAN reader ID, e.g., ID of RAN reader#1 to the new serving RAN reader, e.g., RAN reader#2. In some scenarios, the AIoTF may also send the ID of the AIoT device#1 and the service ID etc. to RAN reader#2. Based on the last serving RAN reader ID provided by the AIoTF, RAN reader#2 may retrieve the information related to the failed or unfinished command from the last or old serving RAN reader, e.g., RAN reader#1 at step 321b.

[0106] In some yet other implementations of the present disclosure, it is assumed that the old serving RAN reader will not delete or release the command request associated information before sending it to the new serving RAN reader. At step 319c, the AIoTF may send the new serving reader ID, e.g., RAN reader#2 associated with AIoT device#1 to the old serving RAN reader, e.g., RAN reader#1. Based on the information or message from the AIoTF, at step 321c, RAN reader#1 will transfer locally stored information related to the failed or unfinished command, e.g., service ID identifying the command and the command configuration etc., to RAN reader#2.

[0107] Based on the second command request received from the AIoTF, and / or the command request associated information (or command related information or the like) received from RAN reader#1, at step 323, RAN reader#2 may initiate a second command procedure associated with the command identified by service ID#1 and receive the command response. Then the command response will be transmitted from RAN reader#2 to the AIoTF at step 325, and then to the AIoT APP, and will not repeat.

[0108] Figure 4 illustrates another example of CN entity based paging procedure in accordance with aspects of the present disclosure.

[0109] Referring to Figure 4, similarly, it is assumed that an inventory procedure, e.g., initiated by 5GC or 3rd party APP has been conducted and an AIoT device, e.g., AIoT device#1 was inventoried by a RAN reader, e.g., RAN reader#1 and reported to the AIoTF#1 serving RAN reader#1. The ID of AIoT device#1 is exposed to the 3rd party APP, e.g., AIoT AF.In some scenarios, it may also be assumed that RAN reader#1 with which AIoT device#1 is associated is also exposed to the AIoT AF.

[0110] Regarding step 401 to step 407, they are identical or similar to steps 201-207, and thus will not repeat herein.

[0111] In some scenarios, e.g., AIoT device#1 is being moved from the coverage area of RAN reader#1 to the coverage area of RAN reader#2 served by AIoTF#2 or the transmission path between AIoT device#1 and RAN reader#2 served by AIoTF#2 functions well. The inventory strategies of the two RAN readers may be different due to belonging to different AIoTFs. For example, RAN reader#1 is configured to do inventory with target area, while RAN reader#2 is configured to do inventory with target device ID (s) . Then, RAN reader#2 may not be able to find the AIoT device moved into its coverage area from that of RAN reader#1, and cannot proceed with any potential following command to this AIoT device.

[0112] It is assumed that the UDM serving the two AIoTFs serving the two RAN readers is the same, and has stored AIoT device information (at least on the unreachable AIoT device, e.g., AIoT device#1) , including one or more of the following: the last serving reader's information or the binding relationship between the AIoT device and RAN reader, the device status (e.g., enable, disable, permanently disabled etc. ) , device location and serving network function (NF) of the AIoT device, or device security material (e.g., credential) etc. Therefore, the UDM can start or initiate the inventory for AIoT device (s) by sending the inventory request to each AIoTF or potential related AIoTF based on the report or indication from the source serving RAN reader via the serving AIoTF (referred to as "event triggered inventory" ) , or periodically start or initiate an inventory by itself (referred to as "periodic inventory" ) for all AIoT devices that it locally stores or based on the location information etc.

[0113] Herein, it is assumed that after RAN reader#1 determines that AIoT device#1 is unreachable and the command or the command procedure for the command to AIoT device#1 fails, no periodic inventory results have been reported to the AIoTFs or UDM regarding the unreachable AIoT device.

[0114] At step 409, RAN reader#1 may transmit information (e.g., a device availability indication indicating an unavailability of the AIoT device) indicating one or more of the following to AIoTF#1: the ID of the unreachable AIoT device, the service ID identifying the command, unreachability indication, command failure indication, the ID of the source serving RAN reader, time stamp for the command failure, or location information of the  source RAN reader, etc. AIoTF#1 may transmit the received information or updated information based on the received information to the UDM at step 411.

[0115] At step 413, the UDM may start or initiate the inventory for AIoT device#1 by sending the inventory request to each served AIoTF or potential related served AIoTF. Based on the inventory request received from the UDM, at step 415, AIoTF#2 may start or initiate the inventory for AIoT device#1 to all RAN readers within the coverage area thereof, e.g., by including the ID of AIoT device#1 in the paging message. Accordingly, at step 417, RAN reader#2 may initiate an inventory to all AIoT devices within the coverage area, and receive an inventory response from AIoT device#1. Then, RAN reader#2 will transmit the inventory response or result to AIoTF#2 at step 419, which may be further forwarded to the UDM at step 421. The UDM will update the AIoT device information based on the received information. In some scenarios, at step 413, the UDM may also forward the AIoT device information or context to the AIoTF, including one or more of: the device status, last serving NF and reader information of the device, either with the inventory request, or after receiving the inventory response from the AIoTF#2.

[0116] Similarly, RAN reader#2 may initiate or start a command procedure to AIoT device#1 to transmit the failed or unfinished command, so that the command will be performed in AIoT device#1, which is a normal command procedure and will not repeat. The command information is provided by the UDM either at step 413, or after UDM receives the inventory response from AIoTF#2.

[0117] Figure 5 illustrates an example of a NE 500 in accordance with aspects of the present disclosure. The NE 500 may include a processor 502, a memory 504, a controller 506, and a transceiver 508. The processor 502, the memory 504, the controller 506, or the transceiver 508, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0118] The processor 502, the memory 504, the controller 506, or the transceiver 508, or various combinations or components thereof may be implemented in hardware (e.g., circuitry) . The hardware may include a processor, a digital signal processor (DSP) , an  application-specific integrated circuit (ASIC) , or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0119] The processor 502 may include an intelligent hardware device (e.g., a general-purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof) . In some implementations, the processor 502 may be configured to operate the memory 504. In some other implementations, the memory 504 may be integrated into the processor 502. The processor 502 may be configured to execute computer-readable instructions stored in the memory 504 to cause the NE 500 to perform various functions of the present disclosure.

[0120] The memory 504 may include volatile or non-volatile memory. The memory 504 may store computer-readable, computer-executable code including instructions when executed by the processor 502 cause the NE 500 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 504 or another type of memory. Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0121] In some implementations, the processor 502 and the memory 504 coupled with the processor 502 may be configured to cause the NE 500 to perform one or more of the functions described herein (e.g., executing, by the processor 502, instructions stored in the memory 504) . For example, the processor 502 may support wireless communication at the NE 500 in accordance with examples as disclosed herein. The NE 500 may be configured to support a means for transmitting a first command request associated with an AIoT device; and a means for in response to a failure of the first command request, transmitting information associated with the AIoT device to a CN entity or at least one other NE, to trigger a search of a second NE that the AIoT device connects with.

[0122] The controller 506 may manage input and output signals for the NE 500. The controller 506 may also manage peripherals not integrated into the NE 500. In some implementations, the controller 506 may utilize an operating system such as  or other operating systems. In some implementations, the controller 506 may be implemented as part of the processor 502.

[0123] In some implementations, the NE 500 may include at least one transceiver 508. In some other implementations, the NE 500 may have more than one transceiver 508. The transceiver 508 may represent a wireless transceiver. The transceiver 508 may include one or more receiver chains 510, one or more transmitter chains 512, or a combination thereof.

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

[0125] A transmitter chain 512 may be configured to generate and transmit signals (e.g., control information, data, packets) . The transmitter chain 512 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM) , frequency modulation (FM) , or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM) . The transmitter chain 512 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 512 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0126] Figure 6 illustrates an example of a CN entity 600 in accordance with aspects of the present disclosure. The CN entity 600 may include a processor 602, a memory 604, a controller 606, and a transceiver 608. The processor 602, the memory 604, the controller 606, or the transceiver 608, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described  herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0127] The processor 602, the memory 604, the controller 606, or the transceiver 608, or various combinations or components thereof may be implemented in hardware (e.g., circuitry) . The hardware may include a processor, a digital signal processor (DSP) , an application-specific integrated circuit (ASIC) , or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

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

[0129] The memory 604 may include volatile or non-volatile memory. The memory 604 may store computer-readable, computer-executable code including instructions when executed by the processor 602 cause the CN entity 600 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 604 or another type of memory. Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0130] In some implementations, the processor 602 and the memory 604 coupled with the processor 602 may be configured to cause the CN entity 600 to perform one or more of the functions described herein (e.g., executing, by the processor 602, instructions stored in the memory 604) . For example, the processor 602 may support wireless communication at the CN entity 600 in accordance with examples as disclosed herein. The CN entity 600 may be configured to support a means for transmitting, to a first NE, a first command request associated with an AIoT device that connects with the first NE; and a means for determining  a second NE that the AIoT device connects with, in response to a failure of the first command request. For another example, the CN entity 600 may be configured to support a means for receiving a device availability indication associated with an AIoT device, the device availability indication indicating an unavailability of the AIoT device; and a means for in response to receiving the device availability indication, transmitting to a second CN entity an inventory request associated with the AIoT device.

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

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

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

[0134] A transmitter chain 612 may be configured to generate and transmit signals (e.g., control information, data, packets) . The transmitter chain 612 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM) , frequency modulation (FM) , or digital  modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM) . The transmitter chain 612 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 612 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

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

[0136] At step 701, the method may include transmitting a first command request associated with an AIoT device. The operations of step 701 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 701 may be performed by a NE as described with reference to Figure 5.

[0137] At step 703, the method may include in response to a failure of the first command request, transmitting information associated with the AIoT device to a CN entity or at least one other NE, to trigger a search of a second NE that the AIoT device connects with. The operations of step 703 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 703 may be performed by a NE as described with reference to Figure 5.

[0138] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0139] Figure 8 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a CN entity as described herein. In some implementations, the CN entity may execute a set of instructions to control the function elements of the NE to perform the described functions.

[0140] At step 801, the method may include transmitting, to a first NE, a first command request associated with an AIoT device that connects with the first NE. The operations of step 801 may be performed in accordance with examples as described herein. In some  implementations, aspects of the operations of step 801 may be performed by a CN entity as described with reference to Figure 6.

[0141] At step 803, the method may include determining a second NE that the AIoT device connects with, in response to a failure of the first command request. The operations of step 803 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 803 may be performed by a CN entity as described with reference to Figure 6.

[0142] In some other implementations, at step 801, the method may include receiving a device availability indication associated with an AIoT device, the device availability indication indicating an unavailability of the AIoT device. The operations of step 801 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 801 may be performed by a CN entity as described with reference to Figure 6.

[0143] At step 803, the method may include in response to receiving the device availability indication, transmitting to a second CN entity an inventory request associated with the AIoT device. The operations of step 803 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 803 may be performed by a CN entity as described with reference to Figure 6.

[0144] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0145] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

Claims

1.A core network (CN) entity for wireless communication, comprising:at least one memory; andat least one processor coupled with the at least one memory and configured to cause the CN entity to:transmit, to a first network equipment (NE) , a first command request associated with an ambient internet of things (AIoT) device that connects with the first NE; anddetermine a second NE that the AIoT device connects with, in response to a failure of the first command request.2.The CN entity of claim 1, wherein the first NE and the second NE are neighboring NEs supporting AIoT services, and the at least one processor is configured to cause the CN entity to:determine information on neighboring NEs supporting AIoT services within a coverage area of the CN entity; andtransmit the information on neighboring NEs supporting AIoT services to NEs within the serving area, wherein the information includes identifiers (IDs) of neighboring NEs.3.The CN entity of claim 2, wherein the at least one processor is configured to cause the CN entity to:receive, from the first NE or the second NE, information indicating that an ID of the AIoT device is associated with an ID of the second NE separate from a command response associated with a command identified by a service ID in the first command request or together with the command response.4.The CN entity of claim 3, wherein the at least one processor is configured to cause the CN entity to:further receive, from the first NE or the second NE, one or more of an unreachability indication or a command failure indication associated with the AIoT device.5.The CN entity of claim 3, wherein in the case that the command response is received from the second NE after receiving the information indicating that the ID of the AIoT device is associated with the ID of the second NE, the at least one processor is configured to cause the CN entity to:transmit, to the second NE, a second command request associated with the AIoT device, wherein the second command request indicates the command identified by the service ID.6.The CN entity of claim 1, wherein the at least one processor is configured to cause the CN entity to:receive, from the first NE, one or more of: an unreachability indication or a command failure indication associated with the AIoT device, an identifier (ID) of the AIoT device, an ID of the first NE, or a service ID identifying a command included in the first command request; andtransmit an inventory request for the AIoT device to all NEs within a coverage area of the CN entity.7.The CN entity of claim 6, wherein the at least one processor is configured to cause the CN entity to:receive, from the second NE, an inventory response in response to the inventory request, indicating that an ID of the AIoT device is associated with an ID of the second NE.8.The CN entity of claim 7, wherein the at least one processor is configured to cause the CN entity to:transmit, to the second NE, a second command request associated with the AIoT device, together with the inventory request or after receiving the inventory response, wherein the second command request indicates the command identified by the service ID; andreceive, from the second NE, a command response associated with the command identified by the service ID.9.The CN entity of claim 6, wherein the at least one processor is configured to cause the CN entity to:transmit, to all NEs within a coverage area of the CN entity, information indicating an ID of the AIoT device together with the inventory request.10.The CN entity of claim 8, wherein the at least one processor is configured to cause the CN entity to:transmit, to the second NE, information indicating one or more of an ID of the first NE, the service ID or ID of the AIoT device so that the second NE will retrieve related command information from the first NE.11.The CN entity of claim 7, wherein the at least one processor is configured to cause the CN entity to:transmit, to the first NE, information indicating one or more of an ID of the second NE associated with the ID of the AIoT device, or the service ID; andreceive, from the second NE, a command response associated with the command identified by the service ID.12.A first network equipment (NE) for wireless communication, comprising:at least one memory; andat least one processor coupled with the at least one memory and configured to cause the first NE to:transmit a first command request associated with an ambient internet of things (AIoT) device; andin response to a failure of the first command request, transmit information associated with the AIoT device to a core network (CN) entity or at least one other NE, to trigger a search of a second NE that the AIoT device connects with.13.A first NE of claim 12, wherein the at least one processor is configured to cause the first NE to:determine the failure of the first command request after one or more times of retry sending the first command request to the AIoT device or after initiating an inventory procedure for the AIoT device and still failing to reach the AIoT device.14.A first NE of claim 12, wherein in response to that the failure of the first command request, the at least one processor is configured to cause the first NE to:transmit, to neighboring NEs supporting AIoT services via Xn interface, the information associated with the AIoT device indicating an identifier (ID) of the AIoT device based on received information on neighboring NEs supporting AIoT services, wherein the information on neighboring NEs supporting AIoT services includes IDs of the neighboring NEs.15.A first NE of claim 14, wherein the at least one processor is configured to cause the first NE to:further transmit, to the neighboring NEs, one or more of: an unreachability indication associated with the AIoT device, or a time stamp associated with the failure of the first command request, or information associated with inventory for the AIoT device, or a context of the AIoT device.16.A first NE of claim 14, wherein the at least one processor is configured to cause the first NE to:further transmit, to the neighboring NEs, command request associated information indicating one or more of an ID of the CN entity, a service ID or command configuration identified by the service ID for the AIoT device.17.A first NE of claim 14, wherein the first NE and the second NE are served by the CN entity, and the at least one processor is configured to cause the first NE to:transmit, to the second NE, command request associated information after receiving information indicating that an ID of the AIoT device is associated with an ID of the second NE, wherein the command request associated information indicates one or more of the first command request or associated command configuration identified by a service ID.18.A first NE of claim 12, wherein the at least one processor is configured to cause the first NE to:transmit, to the second NE, command request associated information in response to a request from the second NE, wherein the command request associated information indicates a service ID and command configuration identified by the service ID for the AIoT device.19.A method performed by a core network (CN) entity for wireless communication, comprising:transmitting, to a first network equipment (NE) , a first command request associated with an ambient internet of things (AIoT) device that connects with the first NE; anddetermining a second NE that the AIoT device connects with, in response to a failure of the first command request.20.A method performed by a first network equipment (NE) for wireless communication, comprising:transmitting a first command request associated with an ambient internet of things (AIoT) device; andin response to a failure of the first command request, transmitting information associated with the AIoT device to a core network (CN) entity or at least one other NE, to trigger a search of a second NE that the AIoT device connects with.

Images