Ambient internet of things

Abstract

Systems, methods, and apparatus for wireless communication are described. An example method includes receiving, by a wireless device, an ambient internet of things (AIoT) signaling or data. The method further includes performing, by the wireless device and based on the AIoT signaling or data, an AIoT service or operation. Another example method includes receiving, by a network device, a request for an ambient internet of things (AIoT) service or operation using a wireless device reader. The method further includes transmitting, by the network device and in response to the request, a response for an AIoT service or operation using a wireless device reader. The disclosed methods, among other benefits, improve the management of AIoT devices.

Description

AMBIENT INTERNET OF THINGSTECHNICAL FIELD

[0001] This patent document is directed generally to wireless communications.BACKGROUND

[0002] Mobile telecommunication technologies are moving the world toward an increasingly connected and networked society. In comparison with the existing wireless networks, next-generation systems and wireless communication techniques will need to support a much wider range of use-case characteristics and provide a more complex and sophisticated range of access requirements and flexibilities.

[0003] Long-Term Evolution (LTE) is a standard for wireless communication for mobile devices and data terminals developed by 3rd Generation Partnership Project (3GPP) . LTE Advanced (LTE-A) is a wireless communication standard that enhances the LTE standard. The 5th generation of wireless system, known as 5G, advances the LTE and LTE-Awireless standards and is committed to supporting higher data rates, large number of connections, ultra-low latency, high reliability, and other emerging business needs.SUMMARY

[0004] This patent document discloses methods where a user equipment (UE) performs ambient internet of things (AIoT) services or operations as a reader based on AIoT signaling or data. The methods provide both user plane (UP) and control plane (CP) solutions. The patent document also discloses requests and responses on inventory, cancellation, base station (BS) availability, A-Uu resources, de-authorization, etc. The disclosed methods, among other benefits, improve the management of AIoT devices.

[0005] A first example wireless communication method includes receiving, by a wireless device, an ambient internet of things (AIoT) signaling or data. The method further includes performing, by the wireless device and based on the AIoT signaling or data, an AIoT service or operation.

[0006] A second example wireless communication method includes receiving, by a network device, a request for an ambient internet of things (AIoT) service or operation using a wireless  device reader. The method further includes transmitting, by the network device and in response to the request, a response for an AIoT service or operation using a wireless device reader.

[0007] Note that where the patent document discloses a method of transmitting an information by a first device to a second device, it will be understood that a method of receiving the information by the second device from the first device is also disclosed. Similarly, where a method of receiving a message by a first device from a second device is disclosed, it will be understood that the message is transmitted by the second device to the first device.

[0008] In yet another example embodiment, a device that is configured or operable to perform the above-described methods is disclosed. The device includes at least one processor configured to cause the device to implement the above-described methods.

[0009] In yet another example embodiment, the above-described methods are embodied in the form of processor-executable code and stored in a non-transitory computer-readable storage medium. The code included in the computer-readable storage medium, when executed by at least one processor, causes the at least one processor to cause a device to implement the methods described in this patent document.

[0010] The above methods, device, and code, their implementations, and other aspects are described in greater detail in the drawings, the descriptions, and the claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 and FIG. 2 illustrate example topologies of ambient internet of things (AIoT) .

[0012] FIG. 3 illustrates an example AIoT system architecture.

[0013] FIG. 4 illustrates an example AIoT user plane (UP) protocol stack.

[0014] FIG. 5 illustrates an example AIoT control plane (CP) protocol stack.

[0015] FIGS. 6-9 illustrate example AIoT protocol stacks using a user equipment (UE) reader.

[0016] FIGS. 10-15 illustrate example AIoT device lists and command lists.

[0017] FIG. 16 and FIG. 17 illustrate example AIoT signaling or data transmissions.

[0018] FIG. 18 illustrates an example AIoT operation cancellation.

[0019] FIG. 19 illustrates an example base station (BS) availability check.

[0020] FIGS. 20-23 illustrate example UE reader de-authorization operations.

[0021] FIG. 24 is an example flowchart for performing an AIoT service or operation.

[0022] FIG. 25 is an example flowchart for responding to an AIoT service or operation request.

[0023] FIG. 26 illustrates an example block diagram of a hardware platform that may be a part of a network device or a wireless device.

[0024] FIG. 27 illustrates example wireless communication including a Base Station (BS) and User Equipment (UE) based on some implementations of the disclosed technology.DETAILED DESCRIPTION

[0025] The example headings for the various sections below are used to facilitate the understanding of the disclosed subject matter and do not limit the scope of the claimed subject matter in any way. Accordingly, one or more features of one example section can be combined with one or more features of another example section. Furthermore, 5G terminology is used for the sake of clarity of explanation, but the techniques disclosed in the present document are not limited to 5G technology only and may be used in wireless systems that implemented other protocols.

[0026] I.Introduction

[0027] The present patent document discloses methods where a user equipment (UE) performs Ambient Internet of Things (AIoT) services or operations as a reader based on AIoT signaling or data. The disclosed methods, among other benefits, improve the management of AIoT devices.

[0028] This patent document gives some enhancements on Topology 2 for Ambient Internet of Things (IoT) .

[0029] Recently, the study for necessary and feasible solutions for Ambient IoT (AIoT) are being performed in the 3rd Generation Partnership Project (3GPP) Radio Access Network (RAN1)  / RAN2 RAN3 / Service and System Aspects (SA2) , including decisions on which functions, procedures, etc. are needed and not needed, and ensuring at least the required functionalities in Section 6.2 of Technical Report (TR) 38.848. The study mainly focuses on the following Deployment Scenarios and the Topologies with the corresponding characteristics, referenced to the tables in Clause 4.2.2 of TR 38.848.

[0030] Deployment scenario 1 with Topology 1

[0031] Base station (BS) and coexistence characteristics: Micro-cell, co-site.

[0032] Deployment scenario 2 with Topology 2 and user equipment (UE) as intermediate node, under network control

[0033] Base station and coexistence characteristics: Macro-cell, co-site.

[0034] The location of intermediate node is indoor.

[0035] FIG. 1 and FIG. 2 illustrate example topologies of ambient internet of things (AIoT) . FIG. 1 and FIG. 2 and characteristics for Topology 1 and Topology 2 are cited from TR 38.848.

[0036] FIG. 1 shows Topology 1: BS  Ambient IoT device.

[0037] In Topology 1, the Ambient IoT device directly and bidirectionally communicates with a base station. The communication between the base station and the ambient IoT device includes Ambient IoT data and / or signaling. This topology includes the possibility that the BS transmitting to the Ambient IoT device is different from the BS receiving from the Ambient IoT device.

[0038] FIG. 2 shows Topology 2: BS  intermediate node  Ambient IoT device.

[0039] In Topology 2, the Ambient IoT device communicates bidirectionally with an intermediate node between the device and base station. In this topology, the intermediate node can be a relay, Integrated Access Backhaul (IAB) node, UE, repeater, etc., which is capable of Ambient IoT. The intermediate node transfers Ambient IoT data and / or signaling between BS and the Ambient IoT device.

[0040] In the first stage study for Ambient IoT, for Topology 2, only a UE can act as an intermediate node which is under the network control.

[0041] In [23700-13-040] , typically, a solution for AIoT device’s data delivery via UE Reader user plane (UP) for Topology 2 is proposed. The system architecture and protocol stack based on user plane are shown in FIG. 3 and FIG. 4. FIG. 3 shows an ambient IoT system architecture for Topology 2. FIG. 4 shows a protocol stack between AIoT Device and Application Function for Topology 2.

[0042] In this solution, the Reader is co-located with a 3GPP UE and the communication between Reader and AIoT Controller uses a Packet Data Unit (PDU) Session. A new reader application protocol (R-AP) protocol (which is based on Service-based Interface (SBI) Protocol Stack) instead of reusing new generation AP (NGAP) is assumed with the justification that:

[0043] a) NGAP terminates on the Access and Mobility Management Function (AMF) , while AMF is not assumed to be used by this solution;

[0044] b) Most of the underlying concepts of NGAP (existence of UE contexts at RAN nodes, PDU Sessions, support of UE mobility, etc. ) do not apply to AIoT in this solution.

[0045] In [23700-13-040] , another solution for AIoT device’s data delivery via UE Reader control plane (CP) for Topology 2 is proposed. The protocol stack based on control plane is shown in FIG. 5.

[0046] In this solution, the UE performs the Reader functions to send AIoT service request (e.g., Inventory, Command) to the AIoT Devices and receive AIoT service response (e.g., Device ID, AIoT data) from the AIoT Devices. The UE also acts as an intermediate node which is under the network control. This solution proposes a control plane based solution for core network (CN) to select the UE and to transfer the AIoT service request / response between UE and Application Function (AF) .

[0047] The AF requests service operation for an AIoT Device or a group of AIoT Devices or all of AIoT Devices via the Network Exposure Function (NEF) , and the NEF forwards the requested service operation to the AMF. The AMF selects the UE and delivers the requested service operation to the UE. The UE performs service operation (e.g., Inventory, Command) with the AIoT Devices and transfers the AIoT information (e.g., Device ID, AIoT data) received from the AIoT Devices to the AMF. The AMF then sends the AIoT information to the AF via the NEF.

[0048] Common configuration and authorization for UE Reader / relay UE:

[0049] - The network node (e.g., gNodeB (gNB) ) could broadcast configuration information (frequency, bandwidth, time-domain resource, the indication whether to support the communication between relay UE (UE Reader) and device, the common configuration of IoT Layer1 / Layer2 / Layer3 / LayerB / data radio bearer (DRB) or resource block (RB) or Radio Link Control (RLC) channel for A-Uu between UE Reader and device) via System Information Block (SIB) or dedicated message. One or multiple dedicated configurations of A-Uu can be released or established or modified.

[0050] - A UE can be authorized to use IoT relay services. If the UE is authorized to use IoT relay services, the AMF shall include IoT relay authorized information (e.g., whether to support inventory procedure, whether to support energy supply, which relay architecture to support, IoT relay Aggregated Maximum Bit Rate (AMBR) and Quality of Service (QoS) parameters) in a NGAP message and send to the node.

[0051] - Relay UE could send some assistance information to the network node and help the node to trigger the communication between the relay UE and AIoT device. Relay UE could indicate the capability about the relay function for device in UE capability, and report it to the network.

[0052] - Relay UE may initiate the procedure to request assignment of dedicated configuration for IoT relay communication upon successful connection establishment or resuming, upon change of interest, upon changing QoS profile (s) , or upon change to a Primary Cell (PCell) providing the SIB including common configuration about IoT relay.

[0053] - The network node could trigger relay UE to wake up or inventory devices. The network node could trigger relay UE to supply energy for devices. The triggering signals could be Radio Resource Control (RRC) message / Media Access Control (MAC) control element (CE)  / Downlink Control Information (DCI) .

[0054] - The network node could allocate an identity for a relay UE, or for a device, or a rang of the identity for devices.

[0055] The protocol stacks between AIoT device and UE Reader and the network nodes are shown in FIGS. 6-9:

[0056] - In uplink, if the data packet from AIoT device needs to be transmitted to the network node, relay UE may be configured with a signaling radio bearer to transmit a RRC message carrying the data packet from AIoT device.

[0057] The relay UE may or may not have the capability of disassembling or assembling some parts (such as the source identifier (ID) , target ID, message type, identity of AIoT device, identity of network, identity of relay UE) of Layer 2 PDU.

[0058] - In uplink, if the data packet from AIoT device needs to be transmitted to the network node via user plane, relay UE may be configured with a DRB to process the data packet. If the data packet from AIoT device needs to be transmitted to the core network via user plane or control plane, or the data packet need to be encrypted, relay UE may be configured with a radio bearer to process the data packet. If the data packet from / to AIoT device need the function of the retransmission, but not the encryption, relay UE may be configured with a RLC channel to process the data packet.

[0059] The relay UE may or may not have the capability of disassembling or assembling some parts (such as the source ID, target ID, message type, identity of AIoT device, identity of network, identity of relay UE) of Layer 2 PDU.

[0060] - Layer B is introduced to realize the mapping function between Uu (UE Reader <-> Base station) protocol stack (DRB or RB or RLC channel in Uu) and A-Uu (AIoT device <-> Reader) protocol stack (Layer 1 or layer 2 or Layer 3) . Moreover, a Layer B could map data packets from multiple AIoT devices to a DRB or RB or RLC channel in uplink, and map the data packet from a DRB or RB or RLC channel to multiple AIoT devices.

[0061] - Relay UE may send the RRC message carrying its legacy information and the RRC message carrying the information or data packet from AIoT device to the network node in two different SRBs.

[0062] - The relay UE may or may not have the capability of controlling the procedure (such as conflict resolution) in AIoT devices, disassembling or assembling Layer 2 PDU and optional Layer 3 PDU.

[0063] Resources allocation for A-Uu and coordination with legacy Uu:

[0064] - When the new radio (NR) UE acts as an AIoT reader, it is necessary to avoid wireless interference between the legacy NR Uu interface (the interface between the NR UE and gNB) and the A-Uu interface (the AIoT air interface between the AIoT device and the UE reader) . The alternatives for avoiding the mentioned interference can be (1) To avoid transmitting and receiving at the same time between the legacy Uu interface and the A-Uu interface, for example, time division transmission is used; (2) When the radio conditions of the NR UE are poor, AIoT reader function can be deactivated.

[0065] II. Embodiment 1

[0066] Embodiment 1 describes CP / UP solutions regarding how to deliver AIoT signaling / data to UE Reader.

[0067] Common assumption:

[0068] - The AIoT signaling / data mentioned in the above can be the signaling / data for one or multiple AIoT devices.

[0069] User Plane-based solution

[0070] - For a UE Reader in a connected mode, the AIoT signaling / data (e.g., inventory request or command) can be transferred via PDU session user plane (e.g., GPRS Tunnelling  Protocol User Plane (GTP-U) data) to the UE Reader from core network which can be transparent to the base station.

[0071] Control Plane plane-based solution

[0072] - The core network can explicitly indicate to the base station at least one of the following information to facilitate the base station to trigger the use of UE Reader to execute the AIoT services / AIoT operations. Such information generally can be put in a NGAP-like signaling which can be per-base station or per-device.

[0073] The indication of using UE Reader. If a UE-specific signaling is used, this information can be skipped.

[0074] The AIoT service / AIoT operation type which can be at least one of the following: Inventory, Command (read, write, disable, kill etc. )

[0075] The AIoT service / AIoT operation information which can be at least one of the following:

[0076] (1) AIoT device (s)  / AIoT device list (s) . Here AIoT device is generally represented by identity / identifier of AIoT device. Besides explicitly indicating way, the AIoT device (s) and AIoT device list (s) can also be indirectly provided with common device identifier and mask or filter rule (s) . The base station can acquire AIoT device (s)  / AIoT device list (s) via calculation based on the common device identifier and mask or filter rule (s) .

[0077] (2) UE Reader (s)  / UE Reader list (s) and the AIoT device (s) or AIoT device list (s) associated with each UE Reader. Here UE Reader is generally represented by identity / identifier of UE Reader. There is assumption that the CN node has prior information about the association among the base stations, the intermediate nodes (e.g., UE Readers) and the AIoT devices.

[0078] (3) Command (s)  / Command list (s) and the AIoT device (s) or AIoT device list (s) associated with each Command. Since Command (s) usually need to be encrypted, they may not be transmitted explicitly, that is, the AS layer of the base station may not be able to resolve the content of Command (s) . However, the base station can be aware of the content blocks of the Command (s) and the correspondence between the Command (s)  / Command list (s) and the AIoT device (s)  / AIoT device list (s) .

[0079] The presence of the indication of using UE Reader and the absence of UE Reader (s) ’ identifier can indicate that the base station can determine UE Reader (s) by itself.

[0080] - If the indicated UE Reader is in a connected mode, it’s possible for the base station to configure (e.g., via Radio Resource Control (RRC) reconfiguration procedure) additional Radio Bearer (s) (DRB or Signaling Radio Bearer (SRB) ) for the UE Reader with indication to indicate that the RB is for specifically delivering the AIoT signaling / data. If the UE reader cannot execute AIoT service / AIoT operation, e.g., due to low battery power, the UE reader may reject the configuration via an uplink signaling. The uplink signaling can be an explicit RRC reconfiguration failure signaling or RRC reconfiguration complete signaling with failure indication / reason.

[0081] - If the indicated UE Reader is in idle mode, the base station can page the UE Reader with indication that there are AIoT services / operations to reach the devices within the coverage of the UE. If the UE Reader sends response to the base station, base station will further setup the Radio Bearer (s) (DRB or SRB) with (optional) indication to indicate that the RB is for specifically delivering the AIoT signaling / data. The paging failure can be seen as an implicit rejection from the UE Reader for AIoT service / AIoT operation. The UE Reader can also send an explicit response to indicate the rejection reason for rejecting AIoT service / AIoT operation.

[0082] - The base station can indicate to the UE Reader at least one of the following via the allocated Uu interface resources and Radio Bearer (s) :

[0083] The AIoT service / AIoT operation type which can be at least one of the following: Inventory, Command (read, write, disable, kill etc. )

[0084] The AIoT services / AIoT operations information which can be at least one of the following:

[0085] (1) AIoT device (s)  / AIoT device list (s) . Besides explicitly indicating way, the AIoT device (s) and AIoT device list (s) can also be indirectly provided with common device identifier and mask or filter rule (s) . The UE Reader can acquire AIoT device (s)  / AIoT device list (s) via calculation based on the common device identifier and mask or filter rule (s) .

[0086] (2) The Command (s)  / Command list (s) and the AIoT device (s) or AIoT device list associated with each Command. Such provision may have different patterns as shown in FIGS. 10-12. FIGS. 10-12 illustrate example AIoT device lists and command lists.

[0087] (3) AIoT device (s)  / AIoT device list (s) and the Command or Command list associated with each AIoT device or AIoT device list. Such provision may have different patterns as shown in FIGS. 13-15. FIGS. 13-15 illustrate example AIoT device lists and command lists. For  example, for FIG. 15, that means at one time, an AIoT device can be provided with more than one Commands. And here the “Command” can be further generalized into “AIoT operation” .

[0088] (4) Since Command (s) usually need to be encrypted, they may not be transmitted explicitly. That means the AIoT device (s)  / AIoT device list (s) and the Command (s)  / Command list (s) may be encapsulated in different protocol layers, or in different fields of the same protocol layer, but at least their respective content blocks should have the same number of entries.

[0089] For example, AIoT device (s)  / AIoT device list (s) can be encapsulated in RRC signaling and the Command (s)  / Command list (s) can be encapsulated in PDU of legacy NAS layer or new NAS layer for AIoT.

[0090] FIG. 16 shows an example for the signaling (e.g., AIoT signaling / data provision signaling) to deliver AIoT signaling / data.

[0091] III. Embodiment 2

[0092] Embodiment 2 describes a CP-gNB check of the inventory response.

[0093] For Control-plane-based solution, if Command (s)  / Command list (s) can be sent to UE Reader along with AIoT device (s)  / AIoT device list (s) , that may mean that UE Reader can directly perform Command (s) service. For example, UE Reader can firstly inventory an AIoT device and then send Command (s) service to it if UE Reader can receive successful response for the inventory request from the AIoT device.

[0094] Meanwhile, it’s also allowed that the base station doesn’t indicate the Command (s)  / Command list (s) to the UE Reader although it has received such information from core network. That may means the base station has the intention to check the inventory results by itself before sending the Command to the corresponding UE Reader / device (s) .

[0095] One of such cases may be that the base station sees the need to send the same AIoT device (s)  / AIoT device list (s) to more than one UE Readers. For example, the base station detects the mobility or location changes of some UE Readers by some way, so it feels that the correspondence between a UE Reader and the device (s) provided by the core network may no longer be accurate enough. Then the base station can consider expanding the range of UE Readers that the base station can send AIoT service / AIoT operation to it.

[0096] In this case, UE Reader needs to explicitly provide the inventory response / result for certain device (s) to the base station so that the base station can match and determine which device (s) successfully give inventory response / result. The explicit provision of inventory  response / result can be to provide inventory response / result in AS layer protocol PDU, e.g., in MAC PDU or RRC PDU. Furthermore, the base station will send Command (s)  / Command list (s) to only one UE Reader which feedback the inventory response / result for certain device (s) , for example, the first UE reader that returns the inventory response. In this case, even though the base station may only provide AIoT device (s)  / AIoT device list (s) to the UE Reader but no Command (s)  / Command list (s) is provided, in order to notify the UE Reader that there will be subsequent Command service and to avoid that the UE Reader release the A-Uu link for a certain device after receiving inventory response, the base station can provide an explicit indication that there will be subsequent Command service along with the provision of AIoT device (s)  / AIoT device list (s) to the UE Reader.

[0097] FIG. 17 shows another example for the signaling to deliver AIoT signaling / data.

[0098] IV. Embodiment 3

[0099] Embodiment 3 describes a CP-AIoT operation cancellation procedure.

[0100] For Control Plane plane-based solution, in some cases the base station may see the need to send the same AIoT device (s)  / AIoT device list (s) and / or the corresponding Command (s)  / Command list (s) to more than one UE Readers and it’s possible that more than one AIoT operation responses for a certain device will be returned to the base station by more than one UE Readers. In order to avoid the possible resources waste caused by multiple AIoT operation responses, an AIoT operation cancellation procedure can be introduced and the base station can use this procedure to cancel the AIoT operation for AIoT device (s) in one UE Reader if previously AIoT operation for one or more certain devices has been assigned to this UE Reader and later AIoT operation responses for some of the devices have been received from another UE Reader. An example procedure is shown in FIG. 18. FIG. 18 illustrates an example AIoT operation cancellation.

[0101] V. Embodiment 4

[0102] Embodiment 4 describes a UP check of the availability of base station before sending AIoT signaling / data via PDU session user plane.

[0103] For User Plane plane-based solution, the AIoT signaling / data (e.g., inventory request or command) can be transferred via PDU session user plane (e.g., GTP-U data) directly to the UE Reader from core network which can be transparent to the base station. However, since the subsequent AIoT service process still needs to obtain grant or control of resources by the base  station, it is recommended that the core network needs to check the availability of the base station before directly sending AIoT signaling / data to the UE Reader.

[0104] A Class 1 NGAP procedure is shown in FIG. 19. FIG. 19 illustrates an example base station (BS) availability check.

[0105] In the above procedure for CN node to check the availability of base station for performing AIoT service / operation, the base station can include at least one of the following information in the uplink response signaling:

[0106] - The response to the request of checking the availability of base station for performing AIoT service / operation: available, unavailable or reject;

[0107] - The reason for indicating unavailable or rejection;

[0108] - The base station can further indicate the possible time point when performing AIoT service / operation will be available or allowed;

[0109] - Detailed status information of the base station.

[0110] Specifically, the uplink response signaling for indicating unavailability or rejection can also be another uplink signaling, e.g., AIoT operation via UE reader Failure.

[0111] VI. Embodiment 5

[0112] Embodiment 5 describes a UP request from UE Reader for A-Uu resources.

[0113] For User Plane plane-based solution, if the UE Reader receives AIoT signaling / data in a way that the content of AIoT signaling / data is invisible to the base station, such as via GTP-U data, the UE Reader can request the radio resources from the serving base station for the communication on A-Uu interface between the UE Reader and AIoT device (s) .

[0114] UE Reader can include at least one of the following information in the uplink request for A-Uu resources which is sent via Uu interface and based on an evaluation of the scale of AIoT operations:

[0115] - The number of AIoT devices to be inventoried or commands to be sent to;

[0116] - The QoS requirements for the AIoT operations, such as the latency requirement for processing all the devices involved, or the data amount of the command service for all the devices;

[0117] - The status information of UE Reader, e.g., the remaining power of the battery, the mobility status,

[0118] - AIoT device (s)  / AIoT device list (s) . Besides explicitly indicating way, it’s also possible to indicate kind of common device identifier and mask or filter rule (s) .

[0119] The base station can respond to the A-Uu resources request via A-Uu resources allocation procedure, see the following Embodiment6 (which can be common for Control Plane-based solution and User Plane-based solution) . The base station also can reject the A-Uu resources request due to some reasons, e.g., network overload or inability to meet the QoS requirements of the AIoT operations. The base station can further indicate the following information in the rejection signaling to the UE Reader:

[0120] - The rejection reason (s) ;

[0121] - The backoff / waiting information for indicating how long the UE Reader needs to wait before sending the next request.

[0122] VII. Embodiment 6

[0123] Embodiment 6 describes CP / UP A-Uu resources allocation.

[0124] Besides the AIoT signaling / data delivery mentioned in Embodiment1, the base station can allocate A-Uu resources to the UE Reader proactively (for Control Plane-based solution) or according to the request from UE Reader (for User Plane-based solution) , for example, via RRC reconfiguration procedure. The following information may be provided in the signaling for A-Uu resources configuration / allocation:

[0125] - The dedicated time-domain, frequency-domain, or code-domain resources for random access for AIoT devices.

[0126] - The indication for indicating which parts of the common A-Uu resources can be used. The common A-Uu resources can be configured / allocated via SIB signaling. Such indication can be a set of multiple factors, e.g., the start point, the length or the periodicity of the time-domain, frequency-domain, or code-domain resources.

[0127] - The factors of the algorithm for avoiding or decreasing the collision for handling multiple devices in certain resources, e.g., Q selection algorithm, Binary Tree (BT) Algorithm.

[0128] - (For User Plane-based solution) AIoT device (s)  / AIoT device list (s) . Besides explicitly indicating way, it’s also possible to indicate kind of common device identifier and a mask or filter rules. If information of AIoT device (s)  / AIoT device list (s) is also present in the signaling for allocating A-Uu resources and it’s different from the corresponding information in the A-Uu resources request signaling, that means the base station modify / update the information  of AIoT device (s) to be served (to be inventoried or commands to be sent to) and UE Reader needs to follow the updated information.

[0129] - Whether and when to report the intermediate result of AIoT operations (Inventory or Command) . For example, a parameter indicating after how many devices are inventoried, or what percentage of devices are inventoried, the UE Reader needs to report the result of inventory.

[0130] VIII. Embodiment 7

[0131] Embodiment 7 describes CP / UP solutions on whether to differentiate "Read" or "Write" AIoT device operations.

[0132] In [23700-13-040] , in solution 17, there is an FFS that whether differentiation of "Read" or "Write" AIoT device operations is needed. And if needed, whether to design separate AIoT service operations for "Read" or "Write" AIoT device operations, or to use an explicit parameter in AIoT Command service operation to differ "Read" or "Write" AIoT device operations.

[0133] No matter for the Control Plane-based solution or User Plane-based solution, base station needs to allocate A-Uu resources to UE. Since different Command services may have very different resources requirements, for example, "Read" command may need large uplink resources allocation while "Write" command may need large downlink resources allocation, it’s assumed at least, it’s suggested that the base station needs to be aware of the exact type of AIoT operations:

[0134] - For control Plane-based solution, besides the AIoT service / AIoT operation type [Inventory, Command (read, write, disable, kill etc. ) ] which needs to be explicitly indicated to the base station by core network (as mentioned in Embodiment 1) , it’s suggested that core network can further explicitly indicate to the base station one of the following information:

[0135] If the type of Command is “Write” , the data amount / size of each Command;

[0136] If the type of Command is “Write” , the total data amount / size of the Commands for the concerned AIoT devices.

[0137] - If the type of Command is “Read” , as neither CN / the base station nor the UE Reader can in advance know the data amount / size of the subsequent response data of the “Read” operation from the device (s) , the base station may be not able to allocate suitable amount resources for A-Uu interface. But it still can allocate more uplink resources so that the segmentation of uplink transmission in A-Uu interface can be possibly reduced.

[0138] IX. Embodiment 8

[0139] Embodiment 8 describes control on A-Uu resources after UE reader is released.

[0140] In [23700-13-040] , in solution 4, there is an assumption that in topology2, when the UE out of Uu coverage in some blind area but the AIoT air coverage goes well, the AIoT operation at the UE reader will not stop and continue. The main issue for UE Reader to continue the AIoT operation is whether the UE Reader can keep using the previously allocated A-Uu resource (on licensed spectrum) . If yes, UE Reader can continue the AIoT operation. However, as the base station may detect disconnection of the UE Reader (e.g., UE_A) , release the resources allocated to it, and further allocate the resources to other UE or UE reader (e.g., UE_B) , if the UE_Acontinues to use the previously allocated resources, it is likely to cause interference between each other, causing both UE_A and UE_B to fail to operate properly. Therefore, some coordination on the usage of the A-Uu resources may be needed.

[0141] During or after A-Uu resource allocation procedure, the base station can further indicate the following information to the UE Reader:

[0142] - Whether the previously allocated A-Uu resources can be used after UE Reader disconnects from the base station, e.g., in normal release or abnormal release due to out of coverage.

[0143] - The time period in which UE Reader can keep using this previously allocated A-Uu resources.

[0144] Note: whether UE Reader can use the unlicensed spectrum to perform AIoT operations is not discussed in this patent document.

[0145] X. Embodiment 9

[0146] Embodiment 9 describes de-authorization of UE Reader.

[0147] Previously, it has been mentioned that the UE should be authorized to IoT relay service by the network. In the NAS procedure, such as Registration procedures, the UE could report its capability, and the core network could determine whether the UE is authorized to act as a UE Reader and if yes, the base station can further provide IoT relay services based on UE's capability.

[0148] As mentioned in Embodiment 1, when the core network indicates to the base station and facilitate the base station to trigger the use of UE Reader to execute the AIoT services / AIoT operations, the core network can provide UE Reader (s)  / UE Reader list (s) and the AIoT device (s)  or AIoT device list (s) associated with each UE Reader. Here the core network can ensure that the indicated UE Reader (s) are the authorized ones. As mentioned in Embodiment 2, based on its knowledge, the base station can consider expanding the range of UE Reader (s) that the base station can send AIoT service / AIoT operation to it. Here the base station can send AIoT service / AIoT operation to a UE Reader that may not be indicated by core network in the signaling (e.g., AIoT signaling / data provision signaling) but be known by the base station that it is an authorized UE Reader. Therefore, for a UE, if it has been as an authorized UE Reader, this information needs to be indicated from core network to the base station via a per-UE signaling or via a UE list in a pre-base station signaling.

[0149] In the following cases, due to mobility, the UE Reader may be de-authorized and can no longer act as UE Reader:

[0150] - Case1: At least when a UE Reader moves out the registration area, the UE Reader need to perform re-authorization with the core network and the core network may de-authorize the UE. The de-authorization of a UE Reader further needs to be informed to the base station via a per-UE signaling or via a UE list in a pre-base station signaling.

[0151] - Case 2: During the inventory procedure, when a device successfully sends to a UE Reader an inventory response which can be further inform to the core network, the network node (s) can record the association among the device and the UE Reader, and further with the base station and the core network node. Meanwhile, network can delineate a so-called inventory area which can correspond to one or more core network nodes (e.g., AIoT controllers) , one or more base stations, or one or more UE Readers or a geographic region. The network can explicitly or implicitly indicate this inventory area to base station (s) and UE Readers. Moreover, when a UE Reader moves out this this inventory area, the UE needs to report this information into the base station and further the core network. The core network can further de-authorize the UE Reader (s) . The possible procedures are shown in FIG. 20 and FIG. 21.

[0152] - It’s also allowed that the UE Reader proactively request to de-authorize its UE Reader status, e.g., in above Case 2 or due to low battery and other reasons. The possible procedures are shown in FIG. 22 and FIG. 23.

[0153] - In any of the stages of the de-authorization of the UE Reader (s) (e.g., after successful de-authorization of one UE Reader or after successful de-authorization of multiple UE Readers) , the CN node can update the association among [device, UE Reader, BS, CN] and can  further notify the base station to do the update accordingly. Or the base station can also do the update by itself. As one or more UE Reader (s) in the association are removed, the related devices can be marked as associated with some other authorized UE Reader (s) .

[0154] FIG. 24 is an example flowchart for performing an AIoT service or operation. Operation 2402 includes receiving, by a wireless device, an ambient internet of things (AIoT) signaling or data. Operation 2404 includes performing, by the wireless device and based on the AIoT signaling or data, an AIoT service or operation. In some embodiments, the method can be implemented according to Embodiments 1-9. In some embodiments, performing further steps of the method can be based on a better system performance than a legacy protocol.

[0155] In some embodiments, the wireless device is in an idle mode, where a network device pages the wireless device and indicates that an AIoT service or operation is to be performed by the wireless device.

[0156] In some embodiments, the method further includes transmitting, by the wireless device, at least one of the following: a response to a network device for the network device to configure a radio bearer (RB) or use an existing RB for transmitting the AIoT signaling or data; or an uplink signaling indicating that the wireless device rejects performing an AIoT service or operation, where the uplink signaling includes a radio resource control (RRC) configuration failure signaling or a RRC configuration complete signaling with a failure indication or reason.

[0157] In some embodiments, the AIoT signaling or data is contained in a signaling transmitted between a core network node and a network device, where the signaling is per-network-device or per-AIoT-device.

[0158] In some embodiments, the AIoT signaling or data includes at least one of the following: an indication to use the wireless device as a reader; an AIoT service or operation type; or an AIoT service or operation information including at least one of the following: an AIoT device or device list; a wireless device reader or reader list; an AIoT device or device list associated with each reader; a command or command list; or an AIoT device or device list associated with each command.

[0159] In some embodiments, the AIoT service or operation type is “write, ” where the AIoT signaling or data further includes at least one of the following: a data amount or size of each command; or a data amount or size of a command associated with an AIoT device or device list.

[0160] In some embodiments, the AIoT service or operation type is “read, ” where an uplink resource is allocated for an uplink transmission in an A-Uu interface.

[0161] In some embodiments, a command or command list and an AIoT device or device list are encapsulated in different protocol layers or in different fields of a same protocol layer.

[0162] In some embodiments, a network device checks one or more inventory results from one or more AIoT devices associated with the wireless device and transmits, based on the one or more inventory results, a command or command list to the wireless device or another wireless device.

[0163] In some embodiments, the method further includes receiving, by the wireless device, an indication for a subsequent command or command list associated with an AIoT device or device list.

[0164] In some embodiments, the method further includes receiving, by the wireless device, an AIoT service or operation cancellation request; and transmitting, by the wireless device and in response to the AIoT service or operation cancellation request, an AIoT service or operation cancellation response.

[0165] In some embodiments, the method further includes transmitting, by the wireless device, a request for an A-Uu resource for communicating with an AIoT device.

[0166] In some embodiments, the request for the A-Uu resource includes at least one of the following: a number of AIoT devices to be inventoried or to which a command is to be sent; a quality of service (QoS) requirement for an AIoT service or operation; a status information of the wireless device; or an AIoT device or device list.

[0167] In some embodiments, the method further includes receiving, by the wireless device, a rejection for the request for the A-Uu resource, where the rejection includes at least one of the following: a rejection reason; or a waiting information indicating a wait time before the wireless device can send a next request for the A-Uu resource.

[0168] In some embodiments, the method further includes receiving, by the wireless device, an A-Uu resource configuration.

[0169] In some embodiments, the A-Uu resource configuration includes at least one of the following: a dedicated time-domain, frequency-domain, or code-domain resource for a random access procedure for an AIoT device; an indication for which part of a common A-Uu resource can be used, where the indication is associated with a start point, a length, or a periodicity of a  time-domain, frequency-domain, or code-domain resource, and where the common A-Uu resource is provided via a system information signaling; a factor for avoiding or decreasing a collision for handling multiple AIoT devices in a resource; an AIoT device or device list; whether and when to report an operation result of an AIoT service or operation; whether a previously allocated A-Uu resource can be used after the wireless device disconnects from a network device; or a time period during which the wireless device can keep using a previously allocated A-Uu resource.

[0170] In some embodiments, the wireless device is an authorized wireless device reader as indicated via a per-wireless-device signaling or via a wireless device list in a per-network-device signaling.

[0171] In some embodiments, the method further includes receiving, by the wireless device, a de-authorization request associated with a wireless device reader; and transmitting, by the wireless device and in response to the de-authorization request, a de-authorization confirmation.

[0172] In some embodiments, the method further includes transmitting, by the wireless device, a de-authorization request associated with a wireless device reader; and receiving, by the wireless device and in response to the de-authorization request, a de-authorization response.

[0173] In some embodiments, the method further includes receiving, by the wireless device, a de-authorization request for the wireless device to remove itself as a wireless device reader; and transmitting, by the wireless device and in response to the de-authorization request, a de-authorization confirmation confirming that the wireless device has been removed as a wireless device reader.

[0174] In some embodiments, the method further includes transmitting, by the wireless device, a de-authorization request for a network device or a core network node to remove the wireless device as a wireless device reader; and receiving, by the wireless device and in response to the de-authorization request, a de-authorization response confirming that the wireless device has been removed as a wireless device reader.

[0175] FIG. 25 is an example flowchart for responding to an AIoT service or operation request. Operation 2502 includes receiving, by a network device, a request for an ambient internet of things (AIoT) service or operation using a wireless device reader. Operation 2504 includes transmitting, by the network device and in response to the request, a response for an AIoT service or operation using a wireless device reader. In some embodiments, the method can  be implemented according to Embodiments 1-9. In some embodiments, performing further steps of the method can be based on a better system performance than a legacy protocol.

[0176] All the above embodiments that can be implemented by a wireless device can be implemented by a network device.

[0177] In some embodiments, the response includes at least one of the following: an availability of the network device for performing an AIoT service or operation; a reason for unavailability or rejection; a time point when the network device is available for performing an AIoT service or operation; or a status information of the network device.

[0178] In some embodiments, the method further includes updating, by the network device and based on an AIoT association update request, an association information on at least one of the following: an AIoT device; a wireless device reader; another network device; or a core network node.

[0179] In some embodiments, the method further includes transmitting, by the network device, a de-authorization request associated with a wireless device reader; and receiving, by the network device and in response to the de-authorization request, a de-authorization confirmation.

[0180] In some embodiments, the method further includes receiving, by the network device, a de-authorization request associated with a wireless device reader; and transmitting, by the network device and in response to the de-authorization request, a de-authorization response.

[0181] In some embodiments, the method further includes transmitting, by the network device, a de-authorization notification associated with a wireless device reader.

[0182] In some embodiments, the method further includes transmitting, by the network device, a de-authorization request for a wireless device to remove itself as associated with a wireless device reader; and receiving, by the network device and in response to the de-authorization request, a de-authorization confirmation confirming that the wireless device has been removed as a wireless device reader.

[0183] In some embodiments, the method further includes receiving, by the network device, a de-authorization request for the network device to remove a wireless device as a wireless device reader; and transmitting, by the network device and in response to the de-authorization request, a de-authorization response confirming that the wireless device has been removed as a wireless device reader.

[0184] In some embodiments, the method further includes transmitting, by the network device, a de-authorization notification notifying a core network node that a wireless device has been removed as a wireless device reader.

[0185] FIG. 26 shows an example block diagram of a hardware platform 2600 that may be a part of a network device (e.g., a base station (BS) , a transmission and reception point (TRP) , a radio access network (RAN) , or a core network (CN) node) or a wireless device (e.g., a user equipment (UE) ) . The hardware platform 2600 includes at least one processor 2610 and a memory 2605 having instructions stored thereupon. The instructions upon execution by the at least one processor 2610 configure the hardware platform 2600 to perform the operations described in FIGS. 1-25 and in the various embodiments described in this patent document. The transmitter 2615 transmits or sends information or data to another device. For example, a network device transmitter can send a message to a user equipment. The receiver 2620 receives information or data transmitted or sent by another device. For example, a user equipment can receive a message from a network device. For example, a UE, a wireless device, or a network device, as described in the present document, may be implemented using the hardware platform 2600.

[0186] The implementations as discussed above will apply to a wireless communication. FIG. 27 shows an example of a wireless communication system (e.g., a 5G or NR cellular network) that includes a base station 2720 and one or more user equipment (UE) 2711, 2712, and 2713. In some embodiments, the UE access the BS (e.g., the network) using a communication link to the network (sometimes called uplink direction, as depicted by dashed arrows 2731, 2732, 2733) , which then enables subsequent communication (e.g., shown in the direction from the network to the UE, sometimes called downlink direction, shown by arrows 2741, 2742, 2743) from the BS to the UE. In some embodiments, the BS sends information to the UE (sometimes called downlink direction, as depicted by arrows 2741, 2742, 2743) , which then enables subsequent communication (e.g., shown in the direction from the UE to the BS, sometimes called uplink direction, shown by dashed arrows 2731, 2732, 2733) from the UE to the BS. The UE may be, for example, a smartphone, a tablet, a mobile computer, a machine to machine (M2M) device, an Internet of Things (IoT) device, and so on. The UE described in the present document may be communicatively coupled to the base station 2720 depicted in FIG. 27.

[0187] It will be appreciated by one of skill in the art that the present patent document  discloses methods that, among other benefits, improve the management of AIoT devices. This patent document discloses methods where a user equipment (UE) performs Ambient Internet of Things (AIoT) services or operations as a reader based on AIoT signaling or data. The methods provide both user plane (UP) and control plane (CP) solutions. The patent document also discloses requests and responses on inventory, cancellation, base station (BS) availability, A-Uu resources, de-authorization, etc.

[0188] Some of the embodiments described herein are described in the general context of methods or processes, which may be implemented in one embodiment by a computer program product, embodied in a computer-readable medium, including computer-executable instructions, such as program code, executed by computers in networked environments. A computer-readable medium may include removable and non-removable storage devices including, but not limited to, Read Only Memory (ROM) , Random Access Memory (RAM) , compact discs (CDs) , digital versatile discs (DVD) , etc. Therefore, the computer-readable media can include a non-transitory storage media. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-or processor-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes.

[0189] Some of the disclosed embodiments can be implemented as devices or modules using hardware circuits, software, or combinations thereof. For example, a hardware circuit implementation can include discrete analog and / or digital components that are, for example, integrated as part of a printed circuit board. Alternatively, or additionally, the disclosed components or modules can be implemented as an Application Specific Integrated Circuit (ASIC) and / or as a Field Programmable Gate Array (FPGA) device. Some implementations may additionally or alternatively include a digital signal processor (DSP) that is a specialized microprocessor with an architecture optimized for the operational needs of digital signal processing associated with the disclosed functionalities of this application. Similarly, the various components or sub-components within each module may be implemented in software, hardware, or firmware. The connectivity between the modules and / or components within the modules may  be provided using any one of the connectivity methods and media that is known in the art, including, but not limited to, communications over the Internet, wired, or wireless networks using the appropriate protocols.

[0190] While this document contains many specifics, these should not be construed as limitations on the scope of an invention that is claimed or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination. Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results.

[0191] Only a few implementations and examples are described, and other implementations, enhancements and variations can be made based on what is described and illustrated in this patent document.

Claims

1.A method of wireless communication, comprising:receiving, by a wireless device, an ambient internet of things (AIoT) signaling or data; andperforming, by the wireless device and based on the AIoT signaling or data, an AIoT service or operation.2.The method of claim 1, wherein the wireless device is in an idle mode, and wherein a network device pages the wireless device and indicates that an AIoT service or operation is to be performed by the wireless device.3.The method of claim 1 or 2, further comprising transmitting, by the wireless device, at least one of the following:a response to a network device for the network device to configure a radio bearer (RB) or use an existing RB for transmitting the AIoT signaling or data; oran uplink signaling indicating that the wireless device rejects performing an AIoT service or operation, wherein the uplink signaling comprises a radio resource control (RRC) configuration failure signaling or a RRC configuration complete signaling with a failure indication or reason.4.The method of any of claims 1-3, wherein the AIoT signaling or data is contained in a signaling transmitted between a core network node and a network device, and wherein the signaling is per-network-device or per-AIoT-device.5.The method of any of claims 1-4, wherein the AIoT signaling or data comprises at least one of the following:an indication to use the wireless device as a reader;an AIoT service or operation type; oran AIoT service or operation information comprising at least one of the following:an AIoT device or device list;a wireless device reader or reader list;an AIoT device or device list associated with each reader;a command or command list; oran AIoT device or device list associated with each command.6.The method of claim 5, wherein the AIoT service or operation type is “write, ” and wherein the AIoT signaling or data further comprises at least one of the following:a data amount or size of each command; ora data amount or size of a command associated with an AIoT device or device list.7.The method of claim 5, wherein the AIoT service or operation type is “read, ” and wherein an uplink resource is allocated for an uplink transmission in an A-Uu interface.8.The method of any of claims 1-7, wherein a command or command list and an AIoT device or device list are encapsulated in different protocol layers or in different fields of a same protocol layer.9.The method of any of claims 1-8, wherein a network device checks one or more inventory results from one or more AIoT devices associated with the wireless device and transmits, based on the one or more inventory results, a command or command list to the wireless device or another wireless device.10.The method of any of claims 1-9, further comprising receiving, by the wireless device, an indication for a subsequent command or command list associated with an AIoT device or device list.11.The method of any of claims 1-10, further comprising:receiving, by the wireless device, an AIoT service or operation cancellation request; andtransmitting, by the wireless device and in response to the AIoT service or operation cancellation request, an AIoT service or operation cancellation response.12.The method of any of claims 1-11, further comprising transmitting, by the wireless device, a request for an A-Uu resource for communicating with an AIoT device.13.The method of claim 12, wherein the request for the A-Uu resource comprises at least one of the following:a number of AIoT devices to be inventoried or to which a command is to be sent;a quality of service (QoS) requirement for an AIoT service or operation;a status information of the wireless device; oran AIoT device or device list.14.The method of claim 12 or 13, further comprising receiving, by the wireless device, a rejection for the request for the A-Uu resource, wherein the rejection comprises at least one of the following:a rejection reason; ora waiting information indicating a wait time before the wireless device can send a next request for the A-Uu resource.15.The method of any of claims 1-14, further comprising receiving, by the wireless device, an A-Uu resource configuration.16.The method of claim 15, wherein the A-Uu resource configuration comprises at least one of the following:a dedicated time-domain, frequency-domain, or code-domain resource for a random access procedure for an AIoT device;an indication for which part of a common A-Uu resource can be used, wherein the indication is associated with a start point, a length, or a periodicity of a time-domain, frequency-domain, or code-domain resource, and wherein the common A-Uu resource is provided via a system information signaling;a factor for avoiding or decreasing a collision for handling multiple AIoT devices in a resource;an AIoT device or device list;whether and when to report an operation result of an AIoT service or operation;whether a previously allocated A-Uu resource can be used after the wireless device disconnects from a network device; ora time period during which the wireless device can keep using a previously allocated A-Uu resource.17.The method of any of claims 1-16, wherein the wireless device is an authorized wireless device reader as indicated via a per-wireless-device signaling or via a wireless device list in a per-network-device signaling.18.The method of any of claims 1-17, further comprising:receiving, by the wireless device, a de-authorization request associated with a wireless device reader; andtransmitting, by the wireless device and in response to the de-authorization request, a de-authorization confirmation.19.The method of any of claims 1-17, further comprising:transmitting, by the wireless device, a de-authorization request associated with a wireless device reader; andreceiving, by the wireless device and in response to the de-authorization request, a de-authorization response.20.A method of wireless communication, comprising:receiving, by a network device, a request for an ambient internet of things (AIoT) service or operation using a wireless device reader; andtransmitting, by the network device and in response to the request, a response for an AIoT service or operation using a wireless device reader.21.The method of claim 20, wherein the response comprises at least one of the following:an availability of the network device for performing an AIoT service or operation;a reason for unavailability or rejection;a time point when the network device is available for performing an AIoT service or operation; ora status information of the network device.22.The method of claim 20 or 21, further comprising updating, by the network device and based on an AIoT association update request, an association information on at least one of the following:an AIoT device;a wireless device reader;another network device; ora core network node.23.The method of any of claims 20-22, further comprising:transmitting, by the network device, a de-authorization request associated with a wireless device reader; andreceiving, by the network device and in response to the de-authorization request, a de-authorization confirmation.24.The method of any of claims 20-22, further comprising:receiving, by the network device, a de-authorization request associated with a wireless device reader; andtransmitting, by the network device and in response to the de-authorization request, a de-authorization response.25.The method of any of claims 20-24, further comprising transmitting, by the network device, a de-authorization notification associated with a wireless device reader.26.An apparatus for wireless communication, comprising at least one processor, wherein the at least one processor is configured to cause the apparatus to implement a method recited in any one or more of claims 1 to 25.27.A computer readable program storage medium having code stored thereon, the code, when executed by at least one processor, causing the at least one processor to cause an apparatus to implement a method recited in any one or more of claims 1 to 25.

Images