Apparatuses and registration methods for ambient IoT device

Abstract

A registration method for Ambient Internet of Things (AIoT) device includes registering, by an AIoT device, to a network through an AIoT reader and performing, by the AIoT device, communication with the AIoT reader through an air interface protocol. Further, another registration method for AIoT device includes determining, by an access and mobility management function (AMF), an AIoT reader managing an AIoT device through a subscription of a unified data management (UDM); and if the AIoT device is associated with the AIoT reader, the AIoT reader is reachable to assist the AIoT device to complete registration to a network; or otherwise, if the AIoT device is not associated with the AIoT reader, the AIoT device has not been registered, has not been provisioned, has not been activated, has not completed its initial registration to the network, or is inactive due to at least one reason.

Description

APPARATUSES AND REGISTRATION METHODS FOR AMBIENT IOT DEVICETECHNICAL FIELD

[0001] The present disclosure relates to the field of communication systems, and more particularly, to apparatuses and registration methods for Ambient Internet of Things (AIoT) device.BACKGROUND

[0002] Ambient Internet of Things (AIoT) devices are ambient power-enabled IoT devices, primarily powered through energy harvesting. The AIoT devices may either operate without batteries or possess limited energy storage capabilities, e.g., using capacitors. Most current devices in fifth generation (5G) networks are either battery-powered or connected to utility power. To seamlessly integrate the AIoT devices into an existing 5G framework, there is a need for more energy-efficient mechanisms, registration procedures, and / or an operational mode. This may ensure the AIoT devices can function even under extremely limited power supply conditions. Currently, no specific solutions have been disclosed to how to support AIoT devices in addressing the aforementioned aspects in third generation partnership project (3GPP) specifications.

[0003] Therefore, there is a need for apparatuses and registration methods for Ambient Internet of Things (AIoT) device, which can address the issues in the prior art and other issues.SUMMARY

[0004] An object of the present disclosure is to propose apparatuses and registration methods for Ambient Internet of Things (AIoT) device, which can address issues in the prior art and other issues, and / or provide energy-efficient mechanisms, registration procedures, and / or an operational mode.

[0005] In a first aspect of the present disclosue, an operational mode is disclosed. In this operational mode, a first entity is power-constrained, e.g., battery-less, drawing energy from harvesting methods and / or a limited energy storage elementsuch as capacitor. A second entity, for example termed the “reader” , “UE” , “terminal” , or “triggering device” , etc. supplies energy to the first entity. This energy transfer enables the previously dormant device (the first entity) to initiate bi-directional communications with the the second entity and other network components. Without this energy infusion from the second entity, the first entity remains dormant or inactive. However, once energized by the “second entity” , the entity facilitates two-way communications. Following energization, the first entity might continue being in this operational mode, or might transition to other modes.

[0006] In a second aspect of the present disclosure, a registration method for Ambient Internet of Things (AIoT) device includes registering, by an AIoT device, to a network through an AIoT reader and performing, by the AIoT device, communication with the AIoT reader through an air interface protocol.

[0007] In a third aspect of the present disclosure, a registration method for Ambient Internet of Things (AIoT) device includes determining, by an Access and Mobility Management Function (AMF) , an AIoT reader managing an AIoT device through a subscription of a unified data management (UDM) and if the AIoT device is associated with the AIoT reader, and the AIoT reader is reachable to assist the AIoT device to complete registration to a network; or otherwise, if the AIoT device is not associated with the AIoT reader, the AIoT  device has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network, or is inactive due to at least one reason. The at least one reason may be a reason why the AIoT device is inactive occurs. The at least one reason may be other reasons different from a condition where the AIoT device has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network. The network may be for example a 5G network.

[0008] In a fourth aspect of the present disclosure, a registration device for Ambient Internet of Things (AIoT) device includes a registrar configured to register an AIoT device to a network through an AIoT reader and an executor configured to perform communication between the AIoT device and the AIoT reader through an air interface protocol.

[0009] In a fifth aspect of the present disclosure, a registration device for Ambient Internet of Things (AIoT) device includes a determiner configured to determine an AIoT reader managing an AIoT device through a subscription of a unified data management (UDM) and if the AIoT device is associated with the AIoT reader, the AIoT reader is reachable to assist the AIoT device to complete registration to a network; or otherwise, if the AIoT device is not associated with the AIoT reader, the AIoT device has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network, or is inactive due to at least one reason. The at least one reason may be a reason why the AIoT device is inactive occurs. The at least one reason may be other reasons different from a condition where the AIoT device has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network. The network may be for example a 5G network.

[0010] In a sixth aspect of the present disclosure, a network device includes a memory, a transceiver, and a processor coupled to the memory and the transceiver. The network device is configured to perform the above method.

[0011] In a seventh aspect of the present disclosure, a non-transitory machine-readable storage medium has stored thereon instructions that, when executed by a computer, cause the computer to perform the above method.

[0012] In an eighth aspect of the present disclosure, a chip includes a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the above method.

[0013] In a ninth aspect of the present disclosure, a computer readable storage medium, in which a computer program is stored, causes a computer to execute the above method.

[0014] In a tenth aspect of the present disclosure, a computer program product includes a computer program, and the computer program causes a computer to execute the above method.

[0015] In an eleventh aspect of the present disclosure, a computer program causes a computer to execute the above method.BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to illustrate the embodiments of the present disclosure or related art more clearly, the following figures will be described in the embodiments are briefly introduced. It is obvious that the drawings are merely some embodiments of the present disclosure, a person having ordinary skill in this field can obtain other figures according to these figures without paying the premise.

[0017] FIG. 1 is a block diagram of a network device according to an embodiment of the present disclosure.

[0018] FIG. 2 is a flowchart illustrating a registration method for Ambient Internet of Things (AIoT) device according to an embodiment of the present disclosure.

[0019] FIG. 3 is a flowchart illustrating a registration method for AIoT device according to an embodiment of the present disclosure.

[0020] FIG. 4 is a block diagram of a registration device for AIoT device according to an embodiment of the present disclosure.

[0021] FIG. 5 is a block diagram of a registration device for AIoT device according to an embodiment of the present disclosure.

[0022] FIG. 6 is a block diagram of an AIoT device communication with 5G system configured to implement some embodiments presented herein.

[0023] FIG. 7A is a block diagram illustrating a 5G Ambient IoT architecture for AIoT device configured to implement some embodiments presented herein.

[0024] FIG. 7B is a block diagram illustrating a 5G Ambient IoT architecture for AIoT device configured to implement some embodiments presented herein.

[0025] FIG. 8A is a block diagram illustrating a 5G Ambient IoT architecture for AIoT device configured to implement some embodiments presented herein.

[0026] FIG. 8B is a block diagram illustrating a 5G Ambient IoT architecture for AIoT device configured to implement some embodiments presented herein.

[0027] FIG. 9 is a flowchart illustrating an AIoT tag paging procedure via an associated AIoT reader configured to implement some embodiments presented herein.

[0028] FIG. 10 is a flowchart illustrating an AIoT tag reachability management configured to implement some embodiments presented herein.

[0029] FIG. 11 is a block diagram of an example of a computing device according to an embodiment of the present disclosure.

[0030] FIG. 12 is a block diagram of a communication system according to an embodiment of the present disclosure.DETAILED DESCRIPTION OF EMBODIMENTS

[0031] Embodiments of the present disclosure are described in detail with the technical matters, structural features, achieved objects, and effects with reference to the accompanying drawings as follows. Specifically, the terminologies in the embodiments of the present disclosure are merely for describing the purpose of the certain embodiment, but not to limit the disclosure.

[0032] Ambient Internet of Things (AIoT) devices are ambient power-enabled IoT devices, primarily powered through energy harvesting. The AIoT devices may either operate without batteries or possess limited energy storage capabilities, e.g., using capacitors. Distinctively, the AIoT devices may be designed with low complexity and smaller size, reduced capabilities and power consumption compared to other third generation partnership project (3GPP) IoT devices such as narrowband IoT (NB-IoT) devices, enhanced machine type communication  (eMTC) devices, reduced capability (RedCap) devices, etc. and / or potential for being maintenance-free with a lifespan exceeding 10 years.

[0033] Most recently, AIoT has been identified as a release 19 (Rel-19) study item in 3GPP SA2 Work Group. AIoT devices primarily harness harvested energy to generate radio frequency (RF) signals for two-way information transmission over a 5G system. However, most current 5G devices are either battery-powered or connected to utility power. To seamlessly integrate the AIoT devices into an existing 5G framework, there is a need for more energy-efficient mechanisms, registration procedures, and / or an operational mode. This may ensure the AIoT devices can function even under extremely limited power supply conditions. In respond to these challenges, some embodiments of the present disclosure disclose an operational mode and procedures to register one or more AIoT devices to a 5G system.

[0034] The current mobile initiated connection only (MICO) mode defined in 3GPP specification does not apply to AIoT devices. When a UE is in the MICO mode, the UE won’t be continuously checking for incoming signals. However, the UE retains the ability to initiate outgoing connections. This contrasts with AIoT devices, which, being battery-less, often lack the inherent capability to initiate these connections independently.

[0035] AIoT device may also have to enroll with the 5G network to access services that may require registration. After successful registration, and when relevant, the AIoT device may periodically refresh its network registration, either due to movement or to communicate updated capabilities and renegotiate protocol parameters. Currently, no specific solutions have been disclosed to address how to support AIoT devices in the aforementioned aspects in 3GPP specifications.

[0036] FIG. 1 illustrates an example of a network device 100 according to an embodiment of the present disclosure. The network device 100 is configured to implement some embodiments of the disclosure. Some embodiments of the disclosure may be implemented into the network device 100 using any suitably configured hardware and / or software. The network device 100 may include a memory 101, a transceiver 102, and a processor 103 coupled to the memory 101 and the transceiver 102. The processor 103 may be configured to implement proposed functions, procedures and / or methods described in this description. Layers of radio interface protocol may be implemented in the processor 103. The memory 101 is operatively coupled with the processor 103 and stores a variety of information to operate the processor 103. The transceiver 102 is operatively coupled with the processor 103, and the transceiver 102 transmits and / or receives a radio signal. The processor 103 may include application-specific integrated circuit (ASIC) , other chipset, logic circuit and / or data processing device. The memory 101 may include read-only memory (ROM) , random access memory (RAM) , flash memory, memory card, storage medium and / or other storage device. The transceiver 102 may include baseband circuitry to process radio frequency signals. When the embodiments are implemented in software, the techniques described herein can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The modules can be stored in the memory 101 and executed by the processor 103. The memory 101 can be implemented within the processor 103 or external to the processor 103 in which case those can be communicatively coupled to the processor 103 via various means as is known in the art.

[0037] In some embodiments, the memory 101 stores executable instructions that when executed by the processor cause the processor 103 to effectuate operations including: registering, by an AIoT device, to a network  through an AIoT reader and performing, by the AIoT device, communication with the AIoT reader through an air interface protocol. This can address issues in the prior art and other issues, and / or provide energy-efficient mechanisms, registration procedures, and / or an operational mode. It is understood that, the terms, “AIoT tag” and “AIoT device” or or similar term are interchangeable and bear no difference in meaning. The terms, Ambient IoT node, Ambient IoT reader, AIoT node, AIoT reader, or similar term simply “reader” is interchangeable and bears no difference in meaning.

[0038] In some embodiments, the memory 101 stores executable instructions that when executed by the processor cause the processor 103 to effectuate operations including: determining, by an access and mobility management function (AMF) , an AIoT reader managing an AIoT device through a subscription of a unified data management (UDM) and if the AIoT device is associated with the AIoT reader, the AIoT reader is reachable to assist the AIoT device to complete registration to a network; or otherwise, if the AIoT device is not associated with the AIoT reader, the AIoT device has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network, or is inactive due to at least one reason. The at least one reason may be a reason why the AIoT device is inactive occurs. The at least one reason may be other reasons different from a condition where the AIoT device has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network. The network may be for example a 5G network. This can address issues in the prior art and other issues, and / or provide energy-efficient mechanisms, registration procedures, and / or an operational mode.

[0039] FIG. 2 illustrates a registration method for AIoT device according to an embodiment of the present disclosure. FIG. 2 is an example of a registration method 200 for AIoT device according to an embodiment of the present disclosure. The registration method 200 for AIoT device is configured to implement some embodiments of the disclosure. Some embodiments of the disclosure may be implemented into the registration method 200 for AIoT device using any suitably configured hardware and / or software. In some embodiments, the registration method 200 for AIoT device includes: an operation 201, registering, by an AIoT device, to a network through an AIoT reader, and an operation 202, performing, by the AIoT device, communication with the AIoT reader through an air interface protocol. This can address issues in the prior art and other issues, and / or provide energy-efficient mechanisms, registration procedures, and / or an operational mode.

[0040] In some embodiments, the AIoT device is activated through a carrier wave transmitted by a carrier wave generator, and the carrier wave generator is integrated or independent of the AIoT reader. In some embodiments, the air interface protocol is supported by an AIoT access point (AP) on the AIoT reader, and the AIoT AP is operatable on a layer 2, a layer 3, or higher layer protocols. In some embodiments, an AIoT gateway (GW) on the AIoT reader serves as a gateway, a bridge, or an interworking module between the AIoT reader and the network. In some embodiments, the AIoT AP on the AIoT reader supports a local mobility anchor. In some embodiments, when the AIoT device is energized by the AIoT reader, the AIoT device is in a reactive interactive connection only (RICO) or reader initiated connection only (RICO) mode, or the AIoT device transitions to a mobile initiated connection only (MICO) mode, a mobile terminated configuration, or a mobile original configuration from the RICO mode.

[0041] In some embodiments, when an accessand mobility management function (AMF) indicates the RICO mode to the AIoT device, the AMF determines wherein the AIoT device is only reachable via the the AIoT reader. In some embodiments, if the AIoT reader is reachable for the AMF, a request for downlink data delivery for the AIoT device in the RICO mode is notified from the AMF to the AIoT reader and / or relayed from the AIoT reader to the AIoT device; if the AIoT reader is not reachable for the AMF, the request for downlink data delivery for the AIoT device in the RICO mode is notified from the AMF to a network element. In some embodiments, the AIoT reader is configured to listen a paging targeted for the AIoT reader itself and / or a paging targeted for the AIoT device associated with the AIoT reader. In some embodiments, when the AIoT device is in the RICO mode, the network reaches the AIoT reader associated with the AIoT device.

[0042] In some embodiments, the AIoT reader is associated with the AIoT device during provisioning. In some embodiments, when the AMF or a radio access network (RAN) receives a paging request to reach the AIoT device, the AMF or the RAN requests a subscription information of the AIoT device from a unified data management (UDM) . In some embodiments, the UDM is configured to retrieve subscription information of the AIoT device and determine if the AIoT device is in the RICO mode. In some embodiments, if the AIoT device is in the RICO mode, the UDM reports a subscription information of the AIoT reader associated with the AIoT device to the AMF or the RAN to perform paging AIoT reader procedures.

[0043] In some embodiments, if the AIoT device is activated by the AIoT reader, the AIoT device performs AIoT reader discovery and authentication procedures, and reports information to the AIoT reader. In some embodiments, the AIoT reader and the AMF negotiate reachability characteristics of the AIoT device. In some embodiments, the AIoT reader is configured to respond to the paging, and / or the AMF is configured to update a status of the AIoT device and / or the AIoT reader at the UDM.

[0044] FIG. 3 illustrates a registration method for AIoT device according to an embodiment of the present disclosure. FIG. 3 is an example of a registration method 300 for AIoT device according to an embodiment of the present disclosure. The registration method 300 for AIoT device is configured to implement some embodiments of the disclosure. Some embodiments of the disclosure may be implemented into the registration method 300 for AIoT device using any suitably configured hardware and / or software. In some embodiments, the registration method 300 for AIoT device includes: an operation 301, determining, by an access and mobility management function (AMF) , an AIoT reader managing an AIoT device through a subscription of a unified data management (UDM) , and an operation 302, if the AIoT device is associated with the AIoT reader, the AIoT reader is reachable to assist the AIoT devcie to complete registration to the 5G network; or otherwise, if the AIoT device is not associated with the AIoT reader, the AIoT device has not been registered, has not been activated, has not been provisioned, has not completed its initial registration to the network, or is inactive due to at least one reason. The at least one reason may be a reason why the AIoT device is inactive occurs. The at least one reason may be other reasons different from a condition where the AIoT device has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network.. This can address issues in the prior art and other issues, and / or provide energy-efficient mechanisms, registration procedures, and / or an operational mode.

[0045] In some embodiments, the AIoT device (s)  / tag (s) are associated with one or multiple AIoT readers, with timestamps showing the moment the AIoT reader (s) establishing an association with the tag (s) . Since the most recently associated AIoT reader is most likey still near the tag, it is called first to wake up the AIoT device. In some embodiments, an internal group identifier (ID) -list in the UDM is configured to manage a group of AIoT devices, and / or the internal group ID-list maintains a list of subscribed internal groups that the AIoT device belongs to. In some embodiments, the AIoT device is activated through a carrier wave transmitted by a carrier wave generator, and the carrier wave generator is integrated or independent of the AIoT reader.

[0046] In some embodiments, if the carrier wave generator is an integrated part of the AIoT reader, the AF instructs the AIoT reader to start carrier wave transmission or beacon signal transmission to the AIoT device; or otherwise, if the carrier wave generator is independent of the AIoT reader, the AF instructs the carrier wave generator to start energy transmission to the AIoT device. In some embodiments, a connection between the AIoT device and the AIoT reader is a layer 2 connection, a layer 3 connection, or a higher layer connection. In some embodiments, the method further includes performing, by an AIoT gateway (GW) , an extensible authentication protocol (EAP) -request / identity. In some embodiments, the AIoT GW or the AIoT reader is configured to derive a subscription concealed identifier (SUCI) of a subscription permanent identifier (SUPI) create registration request.

[0047] In some embodiments, the AIoT GW or the AIoT reader is configured to transmit registration request message including the SUCI, a serving network name, an AIoT device mode, and / or or a RICO mode. In some embodiments, an EAP mode for the AIoT device with the SUPI is pre-configured in the UDM at time of provisioning. In some embodiments, when the AMF indicates the RICO mode to the AIoT device, the AMF determines wherein the AIoT device is only reachable via the the AIoT reader. In some embodiments, if the AIoT reader is reachable for the AMF, a request for downlink data delivery for the AIoT device in the RICO mode is notified from the AMF to the AIoT reader and / or relayed from the AIoT reader to the AIoT device; if the AIoT reader is not reachable for the AMF, the request for downlink data delivery for the AIoT device in the RICO mode is notified from the AMF to a network element. In some embodiments, when the AMF receives a paging request to reach the AIoT device, the AMF requests a subscription information of the AIoT device from the UDM.

[0048] FIG. 4 illustrates a registration device for AIoT device according to an embodiment of the present disclosure. FIG. 4 illustrates that, in some embodiments, a registration device 400 for AIoT device includes a registrar 401 configured to register an AIoT device to a network through an AIoT reader and an executor 402 configured to perform communication between the AIoT device and the AIoT reader through an air interface protocol. This can address issues in the prior art and other issues, and / or provide energy-efficient mechanisms, registration procedures, and / or an operational mode. In some embodiments, the registration device 400 for AIoT device is configured to perform the above method.

[0049] FIG. 5 illustrates a registration device for AIoT device according to an embodiment of the present disclosure. FIG. 5 illustrates that, in some embodiments, a registration device 500 for AIoT device includes a determiner 501 configured to determine an AIoT reader managing an AIoT device through a subscription of a  unified data management (UDM) and if the AIoT device is associated with the AIoT reader, the AIoT reader is reachable to assist the AIoT device to complete registation to the network; or otherwise, if the AIoT device is not associated with the AIoT reader, the AIoT device has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network yet, or is inactive due to at least one reason. The at least one reason may be a reason why the AIoT device is inactive occurs. The at least one reason may be other reasons different from a condition where the AIoT device has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network.. This can address issues in the prior art and other issues, and / or provide energy-efficient mechanisms, registration procedures, and / or an operational mode. In some embodiments, the registration device 500 for AIoT device is configured to perform the above method.

[0050] Examples

[0051] Some embodiments of the present disclosure disclose methods to allow AIoT devices to register to a 5G network. In some examples, a registration method for AIoT device includes registering, by an AIoT device, to a 5G network through an AIoT reader. Some embodiments first introduce the concept of an operational mode. The operational mode may be a RICO (Reader-Initiated Connectivity Only, or Reactive Interactive Connection Only) . For example, in some embodiments of the present disclosue, an operational mode is disclosed. In this operational mode, a first entity is power-constrained, e.g., battery-less, drawing energy from harvesting methods and / or a limited energy storage elementsuch as capacitor. A second entity, for example termed the “reader” , “UE” , “terminal” , or “triggering device” , etc. supplies energy to the first entity. This energy transfer enables the previously dormant device (the first entity) to initiate bi-directional communications with the the second entity and other network components. Without this energy infusion from the second entity, the first entity remains dormant or inactive. However, once energized by the “second entity” , the entity facilitates two-way communications. Following energization, the first entity might continue being in this operational mode, or might transition to other modes. The registration procedures for AIoT devices may be disclosed in the following embodiments.

[0052] For clarify, throughout this document, the terms, “AIoT tag” and “AIoT device” are interchangeable and bear no difference in meaning. The terms, Ambient IoT node, Ambient IoT reader, AIoT node, AIoT reader, simply “reader” is interchangeable and bears no difference in meaning.

[0053] AIoT reader, RICO mode, and AIoT device reachability

[0054] FIG. 6 illuatrates an AIoT device communication with 5G system configured to implement some embodiments presented herein. FIG. 6 illuatrates that, in some embodiment, Ambient IoT device registers to a 5G network through Ambient IoT node or reader. The AIoT reader acts as an independent network element / network node or as a component hosted on a distinct entity, such as a user equipment (UE) , radio access network (RAN) , integrated access and backhaul (IAB) node, repeater, or relay, separated from the Ambient IoT device or tag. The communication between the Ambient IoT device (or tag) and the reader is facilitated by an air interface protocol. The air interface protocol could be a 3GPP access stratum protocol, or existing non-3GPP wireless communications protocol which is capable of supporting wireless communications between Ambient  IoT device or tag and the Ambient IoT reader or node. FIG. 6 further illuatrates that, in some embodiments the AIoT device is in communication with the rest of 5G system via the AIoT node.

[0055] FIG. 7A and FIG. 7B each illustrates a 5G Ambient IoT architecture for AIoT device without non-access-stratum (NAS) signaling capability configured to implement some embodiments presented herein. FIG. 8A and FIG. 8B each illustrates a 5G Ambient IoT architecture for AIoT device with NAS signaling capability configured to implement some embodiments presented herein. FIG. 7A to FIG. 8B illustrate that, in some embodiments, an AIoT reader may include a module designed to transmit a carrier wave to activate one or more AIoT tags. In some embodiments, the one or more AIoT tags are activated through the carrier wave transmitted by the carrier wave generator. In some examples, the carrier wave generator is an integrated part of the AIoT reader. In some examples, the carrier wave generator is independent of the AIoT reader. In details, in some embodiments, an independent carrier wave generator may be outside of the AIoT reader. The carrier wave generator may operate independently by sending the carrier wave for the AIoT tag performing energy harvesting or under the control of the AIoT reader via a defined communications interface to transmit the carrier wave to allow the AIoT device to perform energy harvesting.

[0056] FIG. 7A to FIG. 8B illustrate that, the air interface protocol is supported by an AIoT access point (AP) on the AIoT reader, and the AIoT AP is operatable on a layer 2, a layer 3, or higher layer protocols. In details, in some embodiments, an AIoT access point (AP) is used to support the communication protocol that ensures interaction between the AIoT reader and AIoT tag, operating primarily on Layer 2. In some embodiments, the communication protocol may operate at Layer 3 or other higher layers. The communication protocol may refer to the air interface protocol. The air interface protocol could be a 3GPP access stratum protocol, or existing non-3GPP wireless communications protocol which is capable of supporting wireless communications between Ambient IoT device or tag and the Ambient IoT reader or node.

[0057] FIG. 7A to FIG. 8B illustrate that, an AIoT gateway (GW) on the AIoT reader serves as a gateway, a bridge, or an interworking module between the AIoT reader and the network. In some embodiments, the AIoT GW serves as a gateway, a bridge, or an interworking module between the AIoT reader and the rest of the 5G system. In some embodiments illustrated in FIG. 7A and FIG. 7B, for AIoT devices without NAS signaling capability, AIoT reader could process relevant N1, N2 and N3 interface functions and procedures on behalf of an individual AIoT tag / device or a group of AIoT tags / devices on AIoT GW. In some embodiments illustrated in FIG. 8 A and FIG. 8B, for AIoT devices with NAS signaling capability, N1 interface could be supported on AIoT device. The AIoT reader in FIG. 8A and FIG. 8B may process relevant N2 and N3 interface functions and procedures on AIoT GW. In yet another embodiment, as illustrated in FIG. 7B and FIG. 8B, the combination of the AIoT tag or device and the AIoT reader could be viewed as a 5G UE.

[0058] In some examples, the AIoT reader or one of its functions may also be responsible for access and mobility management function (AMF) selection procedure. In some embodiments, the AIoT reader supports a local mobility anchor. In some embodiments, the AIoT AP on AIoT reader could support local mobility anchor. In details, in some embodiments, the AIoT reader could be a local mobility anchor, which may terminate the  access to 5G Ambient IoT service at the AIoT reader, to provide services within the network enabled by AIoT AP.

[0059] The Ambient IoT device might not be able to initiate registration request itself. Instead, it waits passively for an external stimulus to kick off its operation. Once activated, the Ambient IoT device may be engaged in two-way communication or mutual action with other entities. Hence, the Ambient IoT device starts in a passive mode and transition into an active two-way communication mode upon receiving a stimulus.

[0060] The current mobile initiated connection only (MICO) mode defined in 3GPP specification does not apply to these Ambient IoT devices. When a UE is in the MICO mode, it won’t be continuously checking for incoming signals. However, it retains the ability to initiate outgoing connections. This contrasts with Ambient IoT devices, which, being battery-less, often lack the inherent capability to initiate these connections independently.

[0061] In some embodiments, when the AIoT device is energized by the AIoT reader, the AIoT device is in a reactive interactive connection only (RICO) or reader initiated connection only (RICO) mode, or the AIoT device transitions to a mobile initiated connection only (MICO) mode, a mobile terminated configuration, or a mobile original configuration from the RICO mode. In details, reactive interactive connection only (RICO) or reader initiated connection only (RICO) mode is a new type of connection mode, designed for Ambient IoT devices. It could be used for similar devices in the future when they emerge. Unlike the MICO mode, in the RICO mode, the setup typically involves two entities, be UEs, devices, mobile terminals, readers, tags, etc. Among them, the first entity is power-constrained, usually battery-less, drawing energy from harvesting methods and / or a limited energy storage element, usually capacitor. The second entity, often termed the “reader” , “UE” , “terminal” , or “triggering device” , etc. supplies energy to the first entity. This energy transfer enables the previously dormant device to initiate bi-directional communications with the reader and other network components. Without this energy infusion from the second entity, the first remains dormant or inactive. However, once energized by the “reader” , it facilitates two-way communications. Following energization, the first device might continue being in the RICO mode, or might transition to MICO mode, or optionally for MT-terminated or MO configurations. It is worth noting that in the MICO mode, the system may involve just one entity, be it a UE, device, or a mobile terminal. When set to the MICO mode, this entity does not monitor incoming communications, but solely initiates them.

[0062] In some examples, the AIoT reader and AMF may negotiate the reachability characteristics of the AIoT Tag. During the initial Registration or mobility registration update procedure, the AIoT Tag may express a preference for an operational mode. In this operational mode, a first entity (the AIoT Tag) is power-constrained, e.g., battery-less, drawing energy from harvesting methods and / or a limited energy storage elementsuch as capacitor. The operational mode may be a RICO mode. The AMF may then determine if the RICO mode is permitted for the tag, based on several factors. These include local configuration, expected UE behavior, network configuration parameters (if provided by the UDM) , UE-indicated preferences, UE subscription information, network policies, or any combination thereof. The AMF may then indicate it to the AIoT reader during registration procedure. When a network data analytics function (NWDAF) is in use, the AMF may also use  analytics concerning the tag mobility pattern and / or tag communication generated by the NWDAF to decide on RICO mode parameters. If neither the tag nor the reader expresses a preference for RICO mode during the registration procedure, the AMF may not activate the RICO mode for the tag.

[0063] In some embodiments, when an access and mobility management function (AMF) indicates the RICO mode to the AIoT device, the AMF determines wherein the AIoT device is only reachable via the the AIoT reader. In some embodiments, if the AIoT reader is reachable for the AMF, a request for downlink data delivery for the AIoT device in the RICO mode is notified from the AMF to the AIoT reader and / or relayed from the AIoT reader to the AIoT device; if the AIoT reader is not reachable for the AMF, the request for downlink data delivery for the AIoT device in the RICO mode is notified from the AMF to a network element.

[0064] In some examples, when the AMF indicates the operational mode such as the RICO mode to a first entity (such as an Ambient IoT device / tag) , the AMF considers the tag is only reachable via a second entity such as a reader. In this operational mode, the first entity (the Ambient IoT device / tag) is power-constrained, e.g., battery-less, drawing energy from harvesting methods and / or a limited energy storage elementsuch as capacitor. The second entity, for example termed the “reader” , “UE” , “terminal” , or “triggering device” , etc. supplies energy to the first entity. For the request for downlink data delivery for such device in the RICO mode, the AMF may try to reach the reader associated with the tag first. If the reader is reachable, the AMF may notify the reader, and reader relay the request to the tag. If the reader is not reachable, the AMF may notify other network elements.

[0065] In some embodiments, the AIoT reader is configured to listen a paging targeted for the AIoT reader itself and / or a paging targeted for the AIoT device associated with the AIoT reader. In details, in some examples, a tag in the RICO mode does not listen to a paging while in connection management-idle (CM-IDLE) . The reader may listen paging targeted for the reader itself, as well as the paging targeted for the tags which are associated with the reader. The paging message may be delivered to the reader, and the reader is used to activate the tag first, then interact (e.g. discovery and local authenciaion) with the tag to respond to the paging. Therefore, the AIoT reader listens on paging on behalf of one or more tags.

[0066] In some embodiments, at the time of 5G registration, the tag may be associated with the reader that wakes it up (e.g. human uses the reader to read the tag) , or the tag may be associated with the reader that it discovers if the tag is activated by other readers or carrier wave only devices. Initially, when the tag is provisioned, it may be associated with a reader device based on operator policies and configurations. One tag may be associated with one or multiple readers. In this case, each associated reader may be timestamped. The AMF may first page the most recently reader. If the list of the associated reader is empty, it could mean that either the tag has not been activated, registered, provisioned, completed its initial registration yet, or other reasons. In this case, the AIoT tag or AIoT device cannot be paged in the RICO mode while the tag is in the CM-IDLE. The AIoT tag or device has to wait until it is awakened or becomes associated with a reader.

[0067] In some embodiments, when the AIoT device is in the RICO mode, the network reaches the AIoT reader associated with the AIoT device. For example, the tag has its own SUPI, and its profile in UDM. Once the tag is in the RICO mode, the network may try to reach the reader associated with the tag, rather than the tag  itself. In some embodiments, the AIoT reader is associated with the AIoT device during provisioning. In details, during provisioning, the one or more tags may be associated with a reader specified by the operator.

[0068] FIG. 9 illustrates an AIoT tag paging procedure via an associated AIoT reader configured to implement some embodiments presented herein. FIG. 10 is a flowchart illustrating an AIoT tag reachability management configured to implement some embodiments presented herein. FIG. 9 and FIG. 10 illustrate that, in some embodiments, when the AMF or a radio access network (RAN) receives a paging request to reach the AIoT device, the AMF or the RAN requests a subscription information of the AIoT device from a unified data management (UDM) . In some embodiments, the UDM is configured to retrieve subscription information of the AIoT device and determine if the AIoT device is in the RICO mode. In some embodiments, if the AIoT device is in the RICO mode, the UDM reports a subscription information of the AIoT reader associated with the AIoT device to the AMF or the RAN to perform paging AIoT reader procedures. In some embodiments, if the AIoT device is activated by the AIoT reader, the AIoT device performs AIoT reader discovery and authentication procedures, and reports information to the trusted AIoT reader. In some embodiments, the AIoT reader and the AMF may negotiate reachability characteristics of the AIoT device, e.g. transition to other operational modes. In some embodiments, the AIoT reader may be configured to respond to the paging, and / or the AMF may be configured to update status of the AIoT device and / or the AIoT reader at the UDM.

[0069] FIG. 9 illustrates procedures for an AIoT tag reachability when the AIoT tag is in the RICO mode. In some examples, when an AMF or RAN receives a paging request to reach an AIoT tag. The RAN or AMF may use proper identity to request subscription information of the tag from the UDM. The UDM retrieves the tag’s subscription information and determine if the tag is in the RICO mode. If the tag is in the RICO mode, the UDM may also report the subscription information of the AIoT reader associated with the tag. The UDM then sends these pieces of information to the AMF or RAN to perform paging AIoT reader procedures. If the AMF or RAN received a list of reader subscription information with timestamps, the AMF or RAN may perform paging for the reader with the most recently timestamp. If there is no AIoT reader currently associated with the tag, then the UDM may use the AIoT reader information while the tag is provisioned. If the AIoT reader information is empty in the tag’s provisioning profile, it means that the tag has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network, or is inactive due to at least one reason. The at least one reason may be a reason why the AIoT device is inactive occurs. The at least one reason may be other reasons different from a condition where the AIoT device has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network. The network may be for example a 5G network. The AMF or RAN may report paging rejection code.

[0070] FIG. 9 and FIG. 10 illustrate that, the AIoT reader once receives a RICO mode paging AIoT Device request, the AIoT reader may transmit carrier wave to activate the Ambient IoT device. Once the Ambient tag is activated, it may perform AIoT reader discovery and authentication procedures, and report its information to the trusted AIoT reader. In some examples, in the last step, the AIoT reader responds the paging, and AMF may update tag and reader status at the UDM. Among numerous possible implementations, FIG. 10 illustrates a possible embodiment of how to perform AIoT tag reachability management.

[0071] Registration procedures for Ambient IoT devices / Tags

[0072] The Ambient IoT reader or Ambient IoT node is a network node or an entity residing on a separate entity from the Ambient IoT device or tag. The Ambient IoT reader or Ambient IoT node could be hosted on UE, RAN, IAB node, repeater, or relay, etc. The Ambient IoT device or tag communicates with the reader via an air interface protocol. The registration of Ambient IoT devices / tags to 5G network may be initiated by an AIoT AF, an AIoT service provider, or an AIoT reader. The AIoT AF determines which AIoT reader manages a given AIoT tag through UDM subscription. If the tag is associated with a reader, it communicates with that reader, and requests the reader to register the Ambient IoT tag. If a tag has not been associated with any reader, it means that the tag has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network, or is inactive due to at least one reason. The at least one reason may be a reason why the AIoT device is inactive occurs. The at least one reason may be other reasons different from a condition where the AIoT device has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network. The network may be for example a 5G network.

[0073] When entering a new location and upon powering up, the tag performs mobility registration and reports its association with the discovered reader. It is possible for tags to be associated with multiple readers, with each association being recorded with a timestamp indicating when it was established. This informaiton is subsequently updated in the UDM.

[0074] In one embodiment, the AIoT service providers can initiate tag activation. The AIoT AF, possibly stationed at places like superstores, directs the reader to transmit carrier waves, thereby activating the AIoT tag. In addition to initiation by the AIoT AF, in a more specific embodiment, the AIoT service providers can initiate tag activation through AIoT AF. The AIoT Service Provider might leverage the interface exposed by AIoT network operators to request AIoT AF to perform this kind of activation. The AIoT service provider could for example deploy servers at customers’ service locations, warehouses, superstores, etc. The system administrators of such a server might want to get certain information from all the tags deployed in the field. Hence the system administrator could issue the command through a graphical user interface (GUI) of the sever, to direct the reader to transmit carrier waves, thereby activating all the AIoT tags deployed in the field. In yet another embodiment, depending on energy efficiency needs, an independent carrier wave generator / ignitor may be used to transmit energy. The energy transmission frequency, optimized for each tag, is coordinated via information from the UDM and communicated to readers by the AMF. In yet another embodiment, post energy harvesting, the AIoT tag can establish proper connection with the discovered reader.

[0075] In yet another embodiment, the registration process involves security process including a series of steps from tag identity request to mutual authentication between the AIoT tag and an authentication server function (AUSF) . In this process, both security anchor function (SEAF) and AIoT tag derive various encryption keys (Kseaf, Kamf) for secure communication. To ensure security, these keys are not directly sent to AIoT readers over the RAN. In yet another embodiment, the UDM authorizes and stores the authentication results, sends a registration response to the AMF. Finally, the AMF informs the AIoT reader that registration is accepted.

[0076] These embodiments and the detailed registration procedures are described as follows.

[0077] Step 0: AIoT AF, via subscription data in UDM, could determine / identify the AIoT reader responsible for managing and / or controlling within the coverage or communication range of the AIoT tag. If the tag is  associated with a reader, it can be accessed throught that reader. Otherwise, it may indicate that the tag has not been registered, provisioned, or completed its initial registration, or is inactive due to other reasons. In one embodiment, it should be noted that, while the AIoT activates and reads the tag, the combination of the AIoT reader and the tage could be regared as a 5G node, which could be a UE, Base Station, Relay, Repeater, IAB, or other 5G node. The UE itself (excluding the tag) should have already established connection with 5G core network (5GC) following the regular registration procedures, connection and service requests procedures. When an AIoT tag is in a new location, every time it is powered up, the AIoT tag may perform initial / mobility registration. After the reader is discovered during the initial registration, the AIoT tag might report to network its association with the reader. The tag can be associated with one or multiple readers. When the tag is associated with the reader, the timestamp that the reader has established association with the AIoT tag / device may be recorded and stored in UDM. In one embodiment, the most recently associated reader may be first called to wake up the tag. In the other embodiment, based on policy, multiple or all the readers assocated with the tag could be paged to wake up or activate the tag (s) they are associated with. The association of the tag with reader is updated after registration at UDM. It should be noted that the internal group ID-list in UDM could be used to manage a group of AIoT device. The group ID-list maintains the list of subscribed internal groups that the tag belongs to.

[0078] In a more specific embodiment, the AIoT service provider can initiate tag activation through AIoT AF. The AIoT service provider might leverage the interface exposed by AIoT network operators to request AIoT AF to perform this kind of activation. The AIoT service provider could for example deploy servers at customers’ service locations, for example, warehouses, superstores, etc. The system administrators of such a server might want to get certain information from all the tags deployed in the field. Hence the system administrator could issue the command on the GUI of the sever, to direct the reader to transmit carrier waves, thereby activating all the AIoT tags deployed in the field.

[0079] Steps 1-2: In one embodiment, AIoT reader, the carrier wave component may perform periodic energy transmission to the tag (s) . However, this might cause significant waste of energy, because most of time the tag might not need energy to transmit signal.

[0080] In yet another embodiment, besides the periodic transmission of carrier waves for AIoT tag activation by the reader, an AIoT service provider may initiate the activation / illumination / ignition of an AIoT tag or a group of AIoT tags on-demand. To do so, the AIoT service provider needs to know the location of the reader. The location of the reader might be managed by the AIoT AF, e.g., when the AF is located at a superstore. If the administrator wants to check the inventory, they only need to send the instructions to the AIoT AF. Then AIoT AF may instruct reader to start carrier wave transmission or beacon signal transmission on-demand. Ultimately, the AIoT reader, covering the area where the AIoT tag or the group of AIoT tags is located, may transfer carrier wave to the AIoT tag or the group of AIoT tags to ignite them.

[0081] In yet another embodiment, an independent carrier wave generator might perform energy transmission eitehr in a periodic manner or on-demand to the tag (s) around. In this case, carrier wave generator might be a simplified AIoT reader without the needs to support user plane signaling.

[0082] Step 3: After the energy is harvested, the Ambient IoT tag may perform network / reader selection, and establish a layer 2 connection with the reader or an Ambient IoT network element. It should be noted that at this moment there might not be an IP address assigned to the tag yet.

[0083] In another embodiment, the connection between AIoT Tag and AIoT Reader is a layer 3 or higher layer connection. In that case, the IP address can be allocated by the AIoT AP in the AIoT reader.

[0084] Step 4: AIoT gateway starts the EAP-Request / Identity. This can use the EAP protocol in AIoT Tag registration.

[0085] Step 5: The tag sends the NAI format of its SUPI, i.e., the EPC Pure Identity URI@realm. If the tag has the UICC and has sufficient capability, it can derive SUCI from the NAI format of the SUPI. Otherwise, the tag simply transmits the NAI format of the SUPI to the AIoT Reader, which is then processed by the AIoT GW to derive the SUCI in Step 6.

[0086] Step 6: AIoT GW or AIoT reader, on behalf of the AIoT tag, derives SUCI of the SUPI create registration request.

[0087] Step 7: AIoT reader, or the hosting instance of the AIoT reader, e.g. RAN, or the AIoT reader function on the hosting instance, or other relevant AIoT node then performs AMF selection.

[0088] Step 8: AIoT GW or AIoT reader performs a registration request on behalf of the tag. The AIoT GW or the AIoT reader is configured to transmit registration request message. This registration request message may include SUCI, serving network name, and / or AIoT tag mode or RICO mode

[0089] The AMF may then determine if RICO mode is permitted for the Tag, based on several factors. These include local configuration, Expected UE behavior, Expected AIoT device / tag behaviour, network configuration parameters (if provided by the UDM) , AIoT device / UE-indicated preferences, AIoT device / UE subscription information, network policies, or any combination thereof. The AMF may then indicate it to the AIoT reader during registration procedure. Should the NWDAF be in use, the AMF may also use analytics concerning the tag mobility pattern and / or tag communication generated by the NWDAF to decide on RICO mode parameters. If neither the tag nor the reader expresses a preference for RICO mode during the Registration procedure, the AMF may not activate the RICO mode for the Tag.

[0090] Step 9: SEAF forward the request to AUSF.

[0091] Step 10: AUSF send the info to UDM.

[0092] Step 11: UDM de-conceal the SUCI and start the EAP mode selection.

[0093] In one embodiment, to avoid too many interactions, the EAP mode for the specific tag with the SUPI could be pre-configured in UDM at the time of provisioning, via external parameter provisioning or through operation administration and maintenance (OAM) , 5GS mobility management (5GMM) , or policy and control charging (PCC) rules. The OAM may be a network management function group which provides network fault indication, performance information, and data and diagnostic functions.

[0094] Step 12: UDM lets AUSF know the EAP method.

[0095] Step 13: Authentication and key agreement is performed between AUSF and the tag.

[0096] In this step, authentication procedures or conversation take place between AIoT tag and AUSF. AIoT tag authenticates network, and the network authenticates AIOT tag. They conduct mutual authentication.

[0097] Steps 14-19: Complete EAP finish procedures.

[0098] Steps 20-23: AUSF may use the most significant 256 bits of EMSK as the Kausf, then calculate Kseaf from Kausf (derived Kausf) . Then AUSF sends an EAP-success message to SEAF and the derived anchor key. The UDM stores the authentication result accordingly.

[0099] Steps 24-25: SEAF derives Kseaf.

[0100] SEAF forwards the EAP-Success message to the AIoT reader, and the authentication procedure is finished. The SEAF derives the Kamf from Kseaf and sends the Kamf to the AMF. The SEAF forwards the EAP-Success message to the UE and the authentication procedure is finished. This message also includes the ngKSI and the ABBA parameter. The SEAF sets the ABBA parameter. Then the SEAF derives the Kamf from the Kseaf, the ABBA parameter and the SUPI, and provides the ngKSI and the Kamf to the AMF. Please be noted, for the sake of protecting crypto keys, SEAF or AMF may not send Kseaf and Kamf to AIoT reader via RAN.

[0101] Steps 26-27: Once the the tag receives the EAP-Success message, the tag derives the EMSK, and uses the most significant 256 bits of the EMSK as the Kausf, and then calculates Kseaf. The UE derives Kamf from the Kseaf. Tag derives the Kausf, e.g., by using cipher algorithms based on Diffie-Hellman (DH) , and this message contains the server's DH public key.

[0102] Step 28: UDM stores authentication status of the UE and authorizes registration request. The UDM authorizes the registration request based on authentication result stored in step 23 and other information (e.g., UE subscription profile) .

[0103] Step 29: UDM sends registration response to SEAF / AMF. The UDM sends a Nudm_UEContextManagement_Registration Response message to the AMF.

[0104] Step 30: AMF / SEAF notifies the AIoT reader that the registration is accepted.

[0105] On receiving the EAP-Success message, the AIoT tag derives EMSK and uses the most significant 256 bits of the EMSK as the Kausf and then calculates Kseaf in the same way as the AUSF. The UE derives the Kamf from the Kseaf, the ABBA parameter, and the SUPI. The AMF sends a registration accept message to the AIoT reader.

[0106] Commercial interests for some embodiments are as follows. 1. Solve issues in the prior art and other issues. 2. Help one or more tags to save power to start registration or data transmission only when the one or more tags are energized. 3. Enable one or more AIoT tags registration to a 5G system (5GS) and a reachability management of the one or more 5G AIoT Tags. 4. Some embodiments of the present disclosure can be used in many applications. Some embodiments of the present disclosure are used by chipset vendors, video system development vendors, automakers including cars, trains, trucks, buses, bicycles, moto-bikes, helmets, and etc., drones (unmanned aerial vehicles) , smartphone makers, communication devices for public safety use, AR / VR / MR device maker for example gaming, conference / seminar, education purposes. Some embodiments of the present disclosure are a combination of “techniques / processes” that can be adopted in video standards to create an end product. Some embodiments of the present disclosure propose technical mechanisms. The at least one proposed solution, method, system, and apparatus of some embodiments of the present disclosure may be  used for current and / or new / future standards regarding communication systems. Compatible products follow at least one proposed solution, method, system, and apparatus of some embodiments of the present disclosure. The proposed solution, method, system, and apparatus are widely used in a communication system. With the implementation of the at least one proposed solution, method, system, and apparatus of some embodiments of the present disclosure, at least one modification / improvement to methods and apparatus of energy-related based routing selection are considered for standardizing.

[0107] FIG. 11 is an example of a computing device 1100 according to an embodiment of the present disclosure. Any suitable computing device can be used for performing the operations described herein. For example, FIG. 11 illustrates an example of the computing device 1100 that can implement apparautes and / or methods illustrated in FIG. 1 to FIG. 10 using any suitably configured hardware and / or software. In some embodiments, the computing device 1100 can include a processor 1112 that is communicatively coupled to a memory 1114 and that executes computer-executable program code and / or accesses information stored in the memory 1114. The processor 1112 may include a microprocessor, an application-specific integrated circuit ( “ASIC” ) , a state machine, or other processing device. The processor 1112 can include any of a number of processing devices, including one. Such a processor can include or may be in communication with a computer-readable medium storing instructions that, when executed by the processor 1112, cause the processor to perform the operations described herein.

[0108] The memory 1114 can include any suitable non-transitory computer-readable medium. The computer-readable medium can include any electronic, optical, magnetic, or other storage device capable of providing a processor with computer-readable instructions or other program code. Non-limiting examples of a computer-readable medium include a magnetic disk, a memory chip, a read-only memory (ROM) , a random access memory (RAM) , an application specific integrated circuit (ASIC) , a configured processor, optical storage, magnetic tape or other magnetic storage, or any other medium from which a computer processor can read instructions. The instructions may include processor-specific instructions generated by a compiler and / or an interpreter from code written in any suitable computer-programming language, including, for example, C, C++, C#, visual basic, java, python, perl, javascript, and actionscript.

[0109] The computing device 1100 can also include a bus 1116. The bus 1116 can communicatively couple one or more components of the computing device 1100. The computing device 1100 can also include a number of external or internal devices such as input or output devices. For example, the computing device 1100 is illustrated with an input / output ( “I / O” ) interface 1118 that can receive input from one or more input devices 1120 or provide output to one or more output devices 1122. The one or more input devices 1120 and one or more output devices 1122 can be communicatively coupled to the I / O interface 1118. The communicative coupling can be implemented via any suitable manner (e.g., a connection via a printed circuit board, connection via a cable, communication via wireless transmissions, etc. ) . Non-limiting examples of input devices 1120 include a touch screen (e g., one or more cameras for imaging a touch area or pressure sensors for detecting pressure changes caused by a touch) , a mouse, a keyboard, or any other device that can be used to generate input events in response to physical actions by a user of a computing device. Non-limiting examples of output devices 1122  include a liquid crystal display (LCD) screen, an external monitor, a speaker, or any other device that can be used to display or otherwise present outputs generated by a computing device.

[0110] The computing device 1100 can execute program code that configures the processor 1112 to perform one or more of the operations described above with respect to some embodiments illustrated in FIG. 1 to FIG. 10. The program code may be resident in the memory 1114 or any suitable computer-readable medium and may be executed by the processor 1112 or any other suitable processor.

[0111] The computing device 1100 can also include at least one network interface device 1124. The network interface device 1124 can include any device or group of devices suitable for establishing a wired or wireless data connection to one or more data networks 1128. Non limiting examples of the network interface device 1124 include an Ethernet network adapter, a modem, and / or the like. The computing device 1100 can transmit messages as electronic or optical signals via the network interface device 1124.

[0112] FIG. 12 is a block diagram of an example of a communication system 1200 according to an embodiment of the present disclosure. Embodiments described herein may be implemented into the communication system 1200 using any suitably configured hardware and / or software. FIG. 12 illustrates the communication system 1200 including a radio frequency (RF) circuitry 1210, a baseband circuitry 1220, an application circuitry 1230, a memory / storage 1240, a display 1250, a camera 1260, a sensor 1270, and an input / output (I / O) interface 1280, coupled with each other at least as illustrated.

[0113] The application circuitry 1230 may include a circuitry such as, but not limited to, one or more single-core or multi-core processors. The processors may include any combination of general-purpose processors and dedicated processors, such as graphics processors, application processors. The processors may be coupled with the memory / storage and configured to execute instructions stored in the memory / storage to enable various applications and / or operating systems running on the system. The communication system 1200 can execute program code that configures the application circuitry 1230 to perform one or more of the operations described above with respect to FIG. 1 to FIG. 10. The program code may be resident in the application circuitry 1230 or any suitable computer-readable medium and may be executed by the application circuitry 1230 or any other suitable processor.

[0114] The baseband circuitry 1220 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processors may include a baseband processor. The baseband circuitry may handle various radio control functions that may enable communication with one or more radio networks via the RF circuitry. The radio control functions may include, but are not limited to, signal modulation, encoding, decoding, radio frequency shifting, etc. In some embodiments, the baseband circuitry may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry may support communication with an evolved universal terrestrial radio access network (EUTRAN) and / or other wireless metropolitan area networks (WMAN) , a wireless local area network (WLAN) , a wireless personal area network (WPAN) . Embodiments in which the baseband circuitry is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

[0115] In various embodiments, the baseband circuitry 1220 may include circuitry to operate with signals that are not strictly considered as being in a baseband frequency. For example, in some embodiments, baseband circuitry may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency. The RF circuitry 1210 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. In various embodiments, the RF circuitry 1210 may include circuitry to operate with signals that are not strictly considered as being in a radio frequency. For example, in some embodiments, RF circuitry may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency.

[0116] In various embodiments, the transmitter circuitry, control circuitry, or receiver circuitry discussed above with respect to apparatuses and / or methods illustrated in FIG. 1 to FIG. 10 may be embodied in whole or in part in one or more of the RF circuitry, the baseband circuitry, and / or the application circuitry. As used herein, “circuitry” may refer to, be part of, or include an application specific integrated circuit (ASIC) , an electronic circuit, a processor (shared, dedicated, or group) , and / or a memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and / or other suitable hardware components that provide the described functionality. In some embodiments, the electronic device circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, some or all of the constituent components of the baseband circuitry, the application circuitry, and / or the memory / storage may be implemented together on a system on a chip (SOC) . The memory / storage 1240 may be used to load and store data and / or instructions, for example, for system. The memory / storage for one embodiment may include any combination of suitable volatile memory, such as dynamic random access memory (DRAM) ) , and / or non-volatile memory, such as flash memory.

[0117] In various embodiments, the I / O interface 1280 may include one or more user interfaces designed to enable user interaction with the system and / or peripheral component interfaces designed to enable peripheral component interaction with the system. User interfaces may include, but are not limited to a physical keyboard or keypad, a touchpad, a speaker, a microphone, etc. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, and a power supply interface. In various embodiments, the sensor 1270 may include one or more sensing devices to determine environmental conditions and / or location information related to the system. In some embodiments, the sensors may include, but are not limited to, a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of, or interact with, the baseband circuitry and / or RF circuitry to communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite.

[0118] In various embodiments, the display 1250 may include a display, such as a liquid crystal display and a touch screen display. In various embodiments, the communication system 1200 may be a mobile computing device such as, but not limited to, a laptop computing device, a tablet computing device, a netbook, an Ultrabook,  a smartphone, an AR / VR glasses, etc. In various embodiments, system may have more or less components, and / or different architectures. Where appropriate, methods described herein may be implemented as a computer program. The computer program may be stored on a storage medium, such as a non-transitory storage medium.

[0119] A person having ordinary skill in the art understands that each of the units, algorithm, and steps described and disclosed in the embodiments of the present disclosure are realized using electronic hardware or combinations of software for computers and electronic hardware. Whether the functions run in hardware or software depends on the condition of application and design requirement for a technical plan. A person having ordinary skill in the art can use different ways to realize the function for each specific application while such realizations should not go beyond the scope of the present disclosure. It is understood by a person having ordinary skill in the art that he / she can refer to the working processes of the system, device, and unit in the above-mentioned embodiment since the working processes of the above-mentioned system, device, and unit are basically the same. For easy description and simplicity, these working processes will not be detailed.

[0120] It is understood that the disclosed system, device, and method in the embodiments of the present disclosure can be realized with other ways. The above-mentioned embodiments are exemplary only. The division of the units is merely based on logical functions while other divisions exist in realization. It is possible that a plurality of units or components are combined or integrated in another system. It is also possible that some characteristics are omitted or skipped. On the other hand, the displayed or discussed mutual coupling, direct coupling, or communicative coupling operate through some ports, devices, or units whether indirectly or communicatively by ways of electrical, mechanical, or other kinds of forms.

[0121] The units as separating components for explanation are or are not physically separated. The units for display are or are not physical units, that is, located in one place or distributed on a plurality of network units. Some or all of the units are used according to the purposes of the embodiments. Moreover, each of the functional units in each of the embodiments can be integrated in one processing unit, physically independent, or integrated in one processing unit with two or more than two units.

[0122] If the software function unit is realized and used and sold as a product, it can be stored in a readable storage medium in a computer. Based on this understanding, the technical plan proposed by the present disclosure can be essentially or partially realized as the form of a software product. Or, one part of the technical plan beneficial to the conventional technology can be realized as the form of a software product. The software product in the computer is stored in a storage medium, including a plurality of commands for a computational device (such as a personal computer, a server, or a network device) to run all or some of the steps disclosed by the embodiments of the present disclosure. The storage medium includes a USB disk, a mobile hard disk, a read-only memory (ROM) , a random access memory (RAM) , a floppy disk, or other kinds of media capable of storing program codes.

[0123] While the present disclosure has been described in connection with what is considered the most practical and preferred embodiments, it is understood that the present disclosure is not limited to the disclosed embodiments but is intended to cover various arrangements made without departing from the scope of the broadest interpretation of the appended claims.

Claims

1.A registration method for Ambient Internet of Things (AIoT) device, comprising:registering, by an AIoT device, to a network through an AIoT reader; andperforming, by the AIoT device, communication with the AIoT reader through an air interface protocol.2.The method of claim 1, wherein the AIoT device is activated through a carrier wave transmitted by a carrier wave generator, and the carrier wave generator is integrated or independent of the AIoT reader.3.The method of claim 1 or 2, wherein the air interface protocol is supported by an AIoT access point (AP) on the AIoT reader, and the AIoT AP is operatable on a layer 2, a layer 3, or higher layer protocols.4.The method of any one of claims 1 to 3, wherein an AIoT gateway (GW) on the AIoT reader serves as a gateway, a bridge, or an interworking module between the AIoT reader and the network.5.The method of any one of claims 1 to 4, wherein the AIoT AP on the AIoT reader supports a local mobility anchor.6.The method of any one of claims 1 to 5, wherein when the AIoT device is energized by the AIoT reader, the AIoT device is in a reactive interactive connection only (RICO) or reader initiated connection only (RICO) mode, or the AIoT device transitions to a mobile initiated connection only (MICO) mode, a mobile terminated configuration, or a mobile original configuration from the RICO mode.7.The method of any one of claims 1 to 6, wherein when an access and mobility management function (AMF) indicates the RICO mode to the AIoT device, the AMF determines wherein the AIoT device is only reachable via the the AIoT reader.8.The method of any one of claims 1 to 7, wherein if the AIoT reader is reachable for the AMF, a request for downlink data delivery for the AIoT device in the RICO mode is notified from the AMF to the AIoT reader and / or relayed from the AIoT reader to the AIoT device; if the AIoT reader is not reachable for the AMF, the request for downlink data delivery for the AIoT device in the RICO mode is notified from the AMF to a network element.9.The method of any one of claims 1 to 8, wherein the AIoT reader is configured to listen a paging targeted for the AIoT reader itself and / or a paging targeted for the AIoT device associated with the AIoT reader.10.The method of any one of claims 1 to 9, wherein when the AIoT device is in the RICO mode, the network reaches the AIoT reader associated with the AIoT device.11.The method of any one of claims 1 to 10, wherein the AIoT reader is associated with the AIoT device during provisioning.12.The method of any one of claims 1 to 11, wherein when the AMF or a radio access network (RAN) receives a paging request to reach the AIoT device, the AMF or the RAN requests a subscription information of the AIoT device from a unified data management (UDM) .13.The method of claim 12, wherein the UDM is configured to retrieve subscription information of the AIoT device and determine if the AIoT device is in the RICO mode.14.The method of claim 12 or 13, wherein if the AIoT device is in the RICO mode, the UDM reports a subscription information of the AIoT reader associated with the AIoT device to the AMF or the RAN to perform paging AIoT reader procedures.15.The method of claim 14, wherein if the AIoT device is activated by the AIoT reader, the AIoT device performs AIoT reader discovery and authentication procedures, and reports information to the AIoT reader.16.The method of claim 15, wherein the AIoT reader and the AMF negotiate reachability characteristics of the AIoT device.17.The method of claim 16, wherein the AIoT reader is configured to respond to the paging, and / or the AMF is configured to update a status of the AIoT device and / or the AIoT reader at the UDM.18.A registration method for Ambient Internet of Things (AIoT) device, comprising:determining, by an access and mobility management function (AMF) , an AIoT reader managing an AIoT device through a subscription of a unified data management (UDM) ; andif the AIoT device is associated with the AIoT reader, the AIoT reader is reachable to assist the AIoT device to complete registration to a network; or otherwise, if the AIoT device is not associated with the AIoT reader, the AIoT device has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network, or is inactive due to at least one reason.19.The method of claim 18, wherein the AIoT device is associated with one or more AIoT readers along with a timestamp that one AIoT reader has established association with another AIoT reader, where one most recently associated AIoT reader is called to wake up the AIoT device.20.The method of claim 18 or 19, wherein an internal group identifier (ID) -list in the UDM is configured to manage a group of AIoT devices, and / or the internal group ID-list maintains a list of subscribed internal groups that the AIoT device belongs to.21.The method of any one of claims 18 to 20, wherein the AIoT device is activated through a carrier wave transmitted by a carrier wave generator, and the carrier wave generator is integrated or independent of the AIoT reader.22.The method of claim 21, wherein if the carrier wave generator is an integrated part of the AIoT reader, the AF instructs the AIoT reader to start carrier wave transmission or beacon signal transmission to the AIoT device; or otherwise, if the carrier wave generator is independent of the AIoT reader, the AF instructs the carrier wave generator to start energy transmission to the AIoT device.23.The method of any one of claims 18 to 22, wherein a connection between the AIoT device and the AIoT reader is a layer 2 connection, a layer 3 connection, or a higher layer connection.24.The method of any one of claims 18 to 23, further comprising performing, by an AIoT gateway (GW) , an extensible authentication protocol (EAP) -request / identity.25.The method of claim 24, wherein the AIoT GW or the AIoT reader is configured to derive a subscription concealed identifier (SUCI) of a subscription permanent identifier (SUPI) create registration request.26.The method of claim 24 or 25, wherein the AIoT GW or the AIoT reader is configured to transmit registration request message comprising the SUCI, a serving network name, an AIoT device mode, and / or or a RICO mode.27.The method of claim 25 or 26, wherein an EAP mode for the AIoT device with the SUPI is pre-configured in the UDM at time of provisioning.28.The method of any one of claims 18 to 27, wherein when the AMF indicates the RICO mode to the AIoT device, the AMF determines wherein the AIoT device is only reachable via the the AIoT reader.29.The method of any one of claims 18 to 28, wherein if the AIoT reader is reachable for the AMF, a request  for downlink data delivery for the AIoT device in the RICO mode is notified from the AMF to the AIoT reader and / or relayed from the AIoT reader to the AIoT device; if the AIoT reader is not reachable for the AMF, the request for downlink data delivery for the AIoT device in the RICO mode is notified from the AMF to a network element.30.The method of any one of claims 18 to 29, wherein when the AMF receives a paging request to reach the AIoT device, the AMF requests a subscription information of the AIoT device from the UDM.31.A registration device for Ambient Internet of Things (AIoT) device, comprising:a registrar configured to register an AIoT device to a network through an AIoT reader; andan executor configured to perform communication between the AIoT device and the AIoT reader through an air interface protocol.32.A registration device for Ambient Internet of Things (AIoT) device, comprising:a determiner configured to determine an AIoT reader managing an AIoT device through a subscription of a unified data management (UDM) ; andif the AIoT device is associated with the AIoT reader, the AIoT reader is reachable to assist the AIoT device to complete registration to the network; or otherwise, if the AIoT device is not associated with the AIoT reader, the AIoT device has not been registered, has not been provisioned, has not been activated, has not completed initial registration to the network, or is inactive due to at least one reason.33.A network device, comprising:a memory;a transceiver; anda processor coupled to the memory and the transceiver;wherein the network device is configured to perform the method of any one of claims 1 to 30.34.A non-transitory machine-readable storage medium having stored thereon instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 30.35.A chip, comprising:a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the method of any one of claims 1 to 30.36.A computer readable storage medium, in which a computer program is stored, wherein the computer program causes a computer to execute the method of any one of claims 1 to 30.37.A computer program product, comprising a computer program, wherein the computer program causes a computer to execute the method of any one of claims 1 to 30.38.A computer program, wherein the computer program causes a computer to execute the method of any one of claims 1 to 30.

Images