Initial access in ambient internet-of-things communications

Abstract

One or more methods are provided. A method includes determining to perform an initial access between an Ambient Internet-of-Things (AIoT) reader and an AIoT device. The method includes transmitting a first message to the AIoT reader. The first message includes an identifier of the AIoT device. The method includes receiving a second message from the AIoT reader in response to the first message. The second message includes the identifier of the AIoT device. The method includes transmitting a third message to the AIoT reader in response to the second message. The third message includes completion of an AIoT access. Also provided are one or more processors, a non-transitory computer-readable medium, and an apparatus.

Description

INITIAL ACCESS IN AMBIENT INTERNET-OF-THINGS COMMUNICATIONSBACKGROUND

[0001] Wireless communication networks provide integrated communication platforms and telecommunication services to wireless user devices. Example telecommunication services include telephony, data (e.g., voice, audio, and / or video data) , messaging, and / or other services. The wireless communication networks have wireless access nodes that exchange wireless signals with the wireless user devices using wireless network protocols, such as protocols described in various telecommunication standards promulgated by the Third Generation Partnership Project (3GPP) . Example wireless communication networks include time division multiple access (TDMA) networks, frequency-division multiple access (FDMA) networks, orthogonal frequency-division multiple access (OFDMA) networks, Long Term Evolution (LTE) , and Fifth Generation New Radio (5G NR) . The wireless communication networks facilitate mobile broadband service using technologies such as OFDM, multiple input multiple output (MIMO) , advanced channel coding, massive MIMO, beamforming, and / or other features.

[0002] Internet-of-Things (IoT) technology allows a variety of devices to be wirelessly connected to an IoT reader via a communication network. For example, a radio frequency identification (RFID) tag may be wirelessly connected to an RFID reader such that the reader can obtain information from the tag and pass the information to a server for processing. The IoT reader can be a base station, e.g., a g-Node B (gNB) , that provides cellular services to communicate with the IoT device, or can be a user equipment (UE) that communicates with the IoT device in a wireless network provided by a base station.SUMMARY

[0003] In accordance with one aspect of the present disclosure, a method is provided. The method includes determining to perform an initial access between an Ambient Internet-of-Things (AIoT) reader and an AIoT device. The method includes transmitting a first message to the AIoT reader. The first message includes an identifier of the AIoT device. The method includes receiving a second message from the AIoT reader in response to the first message. The second message includes the identifier of the AIoT device. The method includes transmitting a third message to the AIoT reader in response to the second message. The third message includes completion of an AIoT access.

[0004] In some implementations, the identifier is a first identifier. The third message includes a second identifier of the AIoT device.

[0005] In some implementations, determining to perform the initial access includes: determining that a volume of data in an uplink data buffer exceeds a threshold.

[0006] In some implementations, determining to perform the initial access includes at least one of:determining a non-access stratum registration of the AIoT device, or obtaining of an access stratum layer control signal.

[0007] In some implementations, determining to perform the initial access includes: receiving a paging signal from the AIoT reader.

[0008] In some implementations, the paging signal includes a groupcast signal or a broadcast signal.

[0009] In some implementations, the paging signal includes at least one of: information about downlink timing acquisition, information about access time window, information for identifying an intended AIoT device to trigger access, a configured resource set, or an identifier of the paging signal.

[0010] In some implementations, the identifier includes at least one of: a temporary identifier generated by the AIoT device, or a permanent identifier preconfigured in a memory of the AIoT device.

[0011] In some implementations, the first message further includes at least one of: a type of the AIoT device, an energy status of the AIoT device, or a traffic priority indicator.

[0012] In some implementations, the method further includes activating a timer after transmitting the first message, wherein the second message is received before the timer expires.

[0013] In some implementations, the method further includes resetting the timer after receiving the second message.

[0014] In some implementations, determining to perform the initial access includes determining a failure of an earlier initial access.

[0015] In some implementations, the method further includes incrementing a failure counter in response to the failure.

[0016] In some implementations, the method further includes determining a wait time based on a value of the failure counter, wherein a duration between the earlier initial access and the initial access is equal to or greater than the wait time.

[0017] In some implementations, the second message is received in a resource corresponding to a resource used for transmitting the first message.

[0018] In some implementations, second message includes at least one of: a medium access control (MAC) address configured by a network, a timer that indicates a duration of validity of the MAC address, or an uplink grant.

[0019] In accordance with another aspect of the present disclosure, a method is provided. The method includes receiving a first message from an Ambient Internet-of-Things (AIoT) device, wherein the first message includes an identifier of the AIoT device. The method includes transmitting a second message to the AIoT device in response to the first message, wherein the second message includes the identifier of the AIoT device. The method includes receiving a third message from the AIoT device in response to the second message, wherein the third message indicates completion of an AIoT access.

[0020] In some implementations, the method further includes transmitting a paging signal to the AIoT device, wherein the paging signal includes a groupcast signal or a broadcast signal.

[0021] In some implementations, the method further includes: associating the identifier of the AIoT device with a medium access control (MAC) address configured by a network; obtaining an AIoT data protocol data unit (PDU) from the third message; and transmitting the AIoT data PDU to the network.

[0022] In some implementations, the method further includes transmitting an access cut-off signal to the AIoT device, wherein the access cut-off signal indicates a stop of receiving initial access messages from the AIoT device.

[0023] The above method can be implemented as instructions stored in a non-transitory computer-readable medium and executable by one or more processors of an apparatus.

[0024] The details of one or more implementations of these systems and methods are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of these systems and methods will be apparent from the description and drawings, and from the claims.

[0025] BRIEF DESCRIPTION OF THE FIGURES

[0026] FIG. 1 illustrates a wireless network, according to some implementations.

[0027] FIG. 2 is a table showing different types of Ambient Internet-of-Things (AIoT) devices, according to some implementations.

[0028] FIG. 3 illustrates different topologies of AIoT communications, according to some implementations.

[0029] FIG. 4 illustrates example operation cycles of an AIoT device in communication with an AIoT reader in a network, according to some implementations.

[0030] FIGs. 5A and 5B each illustrate an initial access procedure between an AIoT device and an AIoT reader, according to some implementations.

[0031] FIGs. 6A and 6B each illustrate a flowchart of an example method, according to some implementations.

[0032] FIG. 7 illustrates an example user equipment (UE) , according to some implementations.

[0033] FIG. 8 illustrates an example access node, according to some implementations.DETAILED DESCRIPTION

[0034] An Ambient IoT (AIoT) device is an IoT device that supports harvesting energy from the environment, e.g., by backscattering carrier waves external to the AIoT device, to support its communications with an AIoT reader. Depending on the capacity to power wireless transmissions, there are multiple types of AIoT devices. Depending on the AIoT reader, an AIoT device can be implemented according to multiple topologies. Further, depending on the application of the AIoT device, there are multiple types of AIoT traffic.

[0035] For some AIoT applications, the AIoT device needs to be discovered by the AIoT reader and receive configurations from the AIoT reader before performing AIoT communications. The discovery and configurations usually take place during an initial access procedure. Given the variety of AIoT communication scenarios, it is desirable to have a unified scheme to perform the initial access.

[0036] This disclosure addresses one or more technical problems identified above. As descried in detail below, implementations of the present disclosure provide efficient and convenient approaches for an AIoT device to perform initial access with an AIoT reader. These approaches are based on exchanging of a relatively small number of messages between the AIoT reader and the AIoT device, while taking possible failure into consideration. With one or more features described below, the efficiency and reliability of AIoT communications can be advantageously improved.

[0037] FIG. 1 illustrates a wireless network 100, according to some implementations. The wireless network 100 includes a UE 102 and a base station 104 connected via one or more channels 106A, 106B across an air interface 108. The UE 102 and base station 104 communicate using a system that supports controls for managing the access of the UE 102 to a network via the base station 104.

[0038] In some implementations, the wireless network 100 may be a Non-Standalone (NSA) network that incorporates Long Term Evolution (LTE) and Fifth Generation (5G) New Radio (NR) communication standards as defined by the Third Generation Partnership Project (3GPP) technical specifications. For example, the wireless network 100 may be a E-UTRA (Evolved Universal Terrestrial Radio Access) -NR Dual Connectivity (EN-DC) network, or an NR-EUTRA Dual Connectivity (NE-DC) network. In some other implementations, the wireless network 100 may be a Standalone (SA) network that incorporates only 5G NR. Furthermore, other types of communication standards are possible, including future 3GPP systems (e.g.,  Sixth Generation (6G) ) , Institute of Electrical and Electronics Engineers (IEEE) 802.11 technology (e.g., IEEE 802.11a; IEEE 802.11b; IEEE 802.11g; IEEE 802.11-2007; IEEE 802.11n; IEEE 802.11-2012; IEEE 802.11ac; or other present or future developed IEEE 802.11 technologies) , IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc. ) , or the like. While aspects may be described herein using terminology commonly associated with 5G NR, aspects of the present disclosure can be applied to other systems, such as 3G, 4G, and / or systems subsequent to 5G (e.g., 6G) .

[0039] In the wireless network 100, the UE 102 and any other UE in the system may be, for example, any of laptop computers, smartphones, tablet computers, machine-type devices such as smart meters or specialized devices for healthcare, intelligent transportation systems, or any other wireless device. In network 100, the base station 104 provides the UE 102 network connectivity to a broader network (not shown) . This UE 102 connectivity is provided via the air interface 108 in a base station service area provided by the base station 104. In some implementations, such a broader network may be a wide area network operated by a cellular network provider, or may be the Internet. Each base station service area associated with the base station 104 is supported by one or more antennas integrated with the base station 104. The service areas can be divided into a number of sectors associated with one or more particular antennas. Such sectors may be physically associated with one or more fixed antennas or may be assigned to a physical area with one or more tunable antennas or antenna settings adjustable in a beamforming process used to direct a signal to a particular sector.

[0040] The UE 102 includes control circuitry 110 coupled with transmit circuitry 112 and receive circuitry 114. The transmit circuitry 112 and receive circuitry 114 may each be coupled with one or more antennas. The control circuitry 110 may include various combinations of application-specific circuitry and baseband circuitry. The transmit circuitry 112 and receive circuitry 114 may be adapted to transmit and receive data, respectively, and may include radio frequency (RF) circuitry and / or front-end module (FEM) circuitry.

[0041] In various implementations, aspects of the transmit circuitry 112, receive circuitry 114, and control circuitry 110 may be integrated in various ways to implement the operations described herein. The control circuitry 110 may be adapted or configured to perform various operations, such as those described elsewhere in this disclosure related to a UE. For instance, the control circuitry 110 can control the transmit circuitry 112 and receive circuitry 114 to read information from an AIoT device and pass the information to base station 104.

[0042] The transmit circuitry 112 may transmit using a plurality of multiplexed uplink physical channels. The plurality of uplink physical channels may be multiplexed, e.g., according to time division multiplexing (TDM) or frequency division multiplexing (FDM) along with carrier aggregation. The transmit circuitry 112 may be configured to receive block data from the control circuitry 110 for transmission across the air interface 108.

[0043] The receive circuitry 114 may receive a plurality of multiplexed downlink physical channels from the air interface 108 and relay the physical channels to the control circuitry 110. The plurality of downlink physical channels may be multiplexed, e.g., according to TDM or FDM along with carrier aggregation. The transmit circuitry 112 and the receive circuitry 114 may transmit and receive, respectively, both control data and content data (e.g., messages, images, video, etc. ) structured within data blocks that are carried by the physical channels.

[0044] FIG. 1 also illustrates the base station 104. In some implementations, the base station 104 may be a 5G radio access network (RAN) , a next generation RAN, a E-UTRAN, a non-terrestrial cell, or a legacy RAN, such as a UTRAN. As used herein, the term “5G RAN” or the like may refer to the base station 104 that operates in an NR or 5G wireless network 100, and the term “E-UTRAN” or the like may refer to a base station 104 that operates in an LTE or 4G wireless network 100. The UE 102 utilizes connections (or channels) 106A, 106B, each of which includes a physical communications interface or layer.

[0045] The base station 104 circuitry may include control circuitry 116 coupled with transmit circuitry 118 and receive circuitry 120. The transmit circuitry 118 and receive circuitry 120 may each be coupled with one or more antennas that may be used to enable communications via the air interface 108. The transmit circuitry 118 and receive circuitry 120 may be adapted to transmit and receive data, respectively, to any UE connected to the base station 104. The receive circuitry 120 may receive a plurality of uplink physical channels from one or more UEs, including the UE 102.

[0046] In FIG. 1, the one or more channels 106A, 106B are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a UMTS protocol, a 3GPP LTE protocol, an Advanced long term evolution (LTE-A) protocol, a LTE-based access to unlicensed spectrum (LTE-U) , a 5G protocol, a NR protocol, an NR-based access to unlicensed spectrum (NR-U) protocol, and / or any other communications protocol (s) . In implementations, the UE 102 may directly exchange communication data with another UE (not shown) via a ProSe interface. The ProSe interface  may alternatively be referred to as a sidelink (SL) interface and may include one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH) , a Physical Sidelink Discovery Channel (PSDCH) , and a Physical Sidelink Broadcast Channel (PSBCH) .

[0047] FIG. 2 is a table showing different types of AIoT devices, according to some implementations. As illustrated, there are three types of AIoT devices, Types 1, 2a, and 2b. All three types of AIoT devices can have energy storage, e.g., a battery, to provide power in addition to energy harvested from the environment. It is desirable that all three types are robust to frequency errors, which are likely common due to inferior oscillators equipped in AIoT devices. As described below, the MAC address and message designs according to some implementations can conveniently apply to these different types of AIoT devices, thereby resulting a harmonized AIoT air interface at the MAC layer..

[0048] As illustrated, the three types of AIoT devices differ in some parameters. For example, a Type 1 device can have a peak power consumption of about 1μW, whereas a Type 2a or 2b device can have a peak power consumption of up to a few hundred μW. Other parameters include: whether the device supports amplification of downlink or uplink signals, whether the device supports uplink transmission using backscattered carrier waves, and whether the device supports generating uplink transmission internally (e.g., without relying on external backscattered carrier waves) .

[0049] FIG. 3 illustrates different topologies of AIoT communications, 300A and 300B, according to some implementations. In both topologies 300A and 300B, base station 304 can be similar to base station 104 of FIG. 1. In topology 300B, UE 302 can be similar to UE 102 of FIG. 1. As described below, the MAC address and message designs according to some implementations can conveniently apply to different AIoT topologies, thereby simplifying the deployment cost in AIoT communications.

[0050] In topology 300A, base station 304 serves as the AIoT reader in communication with AIoT device 306. For example, base station 304 and AIoT device 306 can be both located indoor. Base station 304 can operate an indoor micro-cell to allow direct communication with AIoT device 306.

[0051] In topology 300B, UE 302 serves as the AIoT reader in communication with AIoT device 306. For example, UE 302 and AIoT device 306 can be both located indoor, while base station 304 can be located outdoor. Base station 304 can operate an outdoor-to-indoor (O2I)  macro-cell to cover the locations of UE 302 and AIoT device 306. In this scenario, UE 302 can function as an intermediate node under the control of base station 304.

[0052] AIoT communication can be classified into multiple types of traffic at the application layer. A first type is device-terminated (DT) traffic, which is often used to give commands to an AIoT device. A second type is device-originated-device-terminated-triggered (DO-DTT) traffic, which is often used in applications of inventory management. A third type is device-originated-autonomous (DO-A) traffic, which is often used for sensor devices. Depending on the type of traffic, some AIoT scenarios support communicating the traffic using internally stored energy, whereas some AIoT scenarios support communicating the traffic using energy from backscattered carrier wave.

[0053] FIG. 4 illustrates example operation cycles of an AIoT device in communication with an AIoT reader in a network, according to some implementations. The communication can take place in an AIoT system with a topology similar to topologies 300A or 300B of FIG. 3.

[0054] As illustrated, the AIoT device can harvest energy at 402. With the harvested energy, the AIoT device can transition to activated state 420 and become ready for communications. Conversely, as the energy depletes at 404, the AIoT device can transition to discharged / disabled state 410 and stop some or all AIoT communications. In these transitions, an activated AIoT reader can detect an AIoT device in the proximity, e.g., by detecting a downlink signal from the AIoT device, but the AIoT device cannot automatically detect an AIoT reader. To establish an AIoT communication session, the network, via the AIoT reader discovers the AIoT device through application layer transactions (e.g., inventory management signaling) . After discovery, the network does not store the context (e.g., type or identifier (ID) ) of the discovered AIoT device and does not reuse the information obtained from the discovery. Thus, the network needs to sweep its coverage area using carrier waves to activate and detect AIoT devices for new transactions. This model of AIoT operations is referred to as a simple model, as opposed to an advanced model described below.

[0055] For some AIoT applications that adopts the advanced model, the AIoT device becomes discovered by the AIoT reader and / or receives configurations from the AIoT reader. In these applications, the AIoT device can transition, at 406, to an intermediate state, such as configured / discovered state 430. By discovering and / or configuring the AIoT device, the AIoT reader can retain and reuse the context information from the AIoT device to distinguish the AIoT device from other AIoT devices. Correspondingly, the AIoT reader can provide the AIoT  device with continuous network visibility. In some implementations, the discovery and / or configuration of the AIoT device includes the network authenticating the AIoT device and / or authorizing the AIoT device access to network resources.

[0056] A challenge with operations under the advanced model is for the network to verify the legitimacy (e.g., validity) of the retained context of an AIoT device. For example, after the AIoT reader obtains context information from an AIoT device in a communication cycle, the AIoT device may move out of the covered area of the AIoT reader or may have energy depleted. This could cause the context information expire or become invalid when the same AIoT device is again discovered and / or configured by the network. Accordingly, an initial access procedure can be performed to establish context information when an AIoT device is discovered and / or configured.

[0057] For AIoT devices of Type 2b and possibly other types, initial access can be autonomously triggered. For example, an AIoT device can start initial access upon determining that the volume of uplink data in an uplink buffer exceeds a threshold (the threshold may be 0, which means initial access is triggered whenever uplink data is present in the buffer) . Alternatively or additionally, an AIoT device can start initial access upon determining a non-AS registration of the AIoT device. Alternatively or additionally, an AIoT device can start initial access upon generating an AS layer control message (as part of a device-initiated control procedure) , such as an uplink medium access control (MAC) control element (CE) or an uplink radio resource control (RRC) message.

[0058] For AIoT devices of Types 1, 2a, and 2b, initial access can be triggered by a downlink paging signal ( “Message 0” or “Msg0” ) , such as groupcast paging, broadcast paging, or RRC signaling that triggers cell-wide access attempts. Upon receiving a downlink groupcast or broadcast paging signal from an AIoT reader, the AIoT device can send application layer data in response. This trigger may be considered an autonomous trigger because the AS layer of the reader does not know the content and objective of the application layer message to be transmitted by the AIOT device in uplink, so the resulting transmission of uplink data by AIoT device is not the direct consequence of downlink groupcast / broadcast paging trigger transmitted by the AIoT reader. In some implementations, this downlink paging trigger may be also associated with an access window. The intended recipients (e.g., AIoT devices) of the paging trigger can access the AIoT reader within this access window, which can start upon the reception of Msg0.

[0059] In some implementations, Msg0 can include one or more of: information about downlink timing acquisition (e.g., for synchronization between the AIoT device and reader) for initial access, information for identifying one or more paging recipients (e.g., a paging mask) , which are expected to initiate access, a configured resource set for the AIoT device to access, or an identifier of the paging signal (e.g., a transaction ID or a counter value to differentiate the current Msg0 from prior Msg0 transmissions with the same content) . In particular, if a Msg0 is sent after one or more prior Msg0s that have already configured the AIoT device, then the network does not need to expect a response from the AIoT device to the current Msg0. In some implementations, a Msg0 transmitted after prior Msg0s is used as an access cut-off signal to indicate that the AIoT reader is to stop receiving further initial access messages (e.g., further Msg1s) from the AIoT device.

[0060] By way of the initial access, the network can provide initial configurations to the AIoT device. The initial configurations can include an uplink grant. If the initial access is not based on the AIoT device’s permanent / global ID (e.g., an ID preconfigured to uniquely identify the AIoT device among all AIoT devices) , then the initial configurations can include an access stratum (AS) layer ID, such as an address, to identify the AIoT device among a group of AIoT devices (e.g., those that are within a proximity of the AIoT reader) . Different from the permanent / global ID, which is often referred to as a device ID or a tag ID, the AS layer ID can be a temporary ID assigned by the network for a limited time and for a given communication session. For the purpose of this disclosure, the terms “tag ID, ” “device ID, ” “global ID, ” and “permanent ID” are used interchangeably to refer to the opposite of “temporary ID. ”

[0061] FIGs. 5A and 5B each illustrate an initial access procedure, 500A and 500B, respectively between an AIoT device 503 and an AIoT reader 501, according to some implementations. The two procedures differ in the ID used by AIoT device 503: AIoT device 503 uses procedure 500A

[0062] In procedure 500A of FIG. 5A, at 512, reader 501 sends Msg0 to one or more AIoT devices including device 503. In response, at 514, device 503 performs a Layer-one (L1) , e.g., physical layer, procedure to select a transmission resource (e.g., a slot) for responding to Msg0.

[0063] At 516, device 503 determines to perform initial access and sends an initial access message ( “Message 1” or “Msg1” ) to reader 501. When multiple AIoT devices receive Msg0 and perform initial access, Msg1 of device 503 can serve to bring device 503 in contention  against other responding AIoT devices. Msg1 can include a temporarily ID of device 503, the type of device 503, the energy status of device 503, and / or a priority level of device 503.

[0064] At 518, device 503 starts a timer ( “retry timer” ) . With the timer-based approach, an AIOT device can decide whether its initial access requested in Msg1 is successfully processed by the AIoT reader. In alternative implementations, the AIoT device does not need to use a retry timer if the AIoT device’s clock has a coarse quality, but can wait for the access cut-off signal from the AIoT reader to determine the end of access window. If the retry timer expires before device 503 receives an initial access response ( “Message 2” or “Msg 2” ) from reader 501, then device 503 can determine that the initial access has failed with an allowed access window. In response to the access failure, device 503 can determine to perform initial access again by re-executing the L1 procedure at 544 and resending Msg1 (e.g., move to 516) . In some implementations, device 503 can be configured to wait a period of time after a failure before resending Msg1. Upon receiving Msg2 before the retry timer expires, device 503 can stop the retry timer and / or reset the retry timer. Device 503 can associate the retry timer with its MAC address assigned by the network.

[0065] At 520, reader 501 sends Msg2 to reader 501 in response to the initial access message. If multiple AIoT devices have sent initial access messages to contend for initial access, reader 501 can send Msg2 to one or more of the AIoT devices that are granted initial access. Along with Msg2, reader 501 can send a grant of resource allocated for uplink transmissions to device 503 and each of the other AIoT devices granted initial access. Reader 501 can also send an address allocation, such as a temporary ID assigned to device 503 and each of the other AIoT devices granted initial access.

[0066] At 522, device 503 stops the retry timer upon receiving Msg2 before expiry of the retry timer. Device 503 can thus determine that the initial access to reader 501 has been granted and completed. Accordingly, at 524, device 503 sends a configuration / access complete message (“Message 3” or “Msg3” ) to reader 501. In Msg3, reader 501 can disclose its permanent ID (e.g., device ID or tag ID) , transmit AIoT data packets, and / or provide security-related parameters (e.g., authentication credentials for accessing the network) , to device 503.

[0067] At 526, reader 501 establishes context using the permanent ID, such as the tag ID, of device 503. The context can replace any existing context established in prior sessions that remain in the storage of reader 501.

[0068] At 528 and beyond, reader 501 continues the AIoT communication by, e.g., transmitting a downlink message with a command or inventory information. Alternatively or additionally, reader 501 can work with device 503 on security setup (e.g., updating authentication credentials) .

[0069] Procedure 500B of FIG. 5B has some operations similar to those of procedure 500A. For example, operations at 542, 544, 548, 552, 554, and 558 can be similar to operations at 512, 514, 518, 522, 524, and 528, respectively.

[0070] At 546 of procedure 500B, device 503 determines to perform initial access and sends Msg1 to reader 501. Here in Msg1, instead of including a temporarily ID, device 503 includes its permanent / global ID, such as its device ID or tag ID. Likewise, when reader 501 sends Msg2 to reader 501 at 550, reader 501 includes the permanent / global ID of device 503, such as the device ID or tag ID of device 503. Using this permanent / global ID, reader 501 establishes context at 556. In the event device 503 does not receive Msg2 before the expiry of the retry timer, device 503 can determine that the initial access has failed, similar to the operations described above with reference to procedure 500A.

[0071] Typically, Msg1 is a short message compared to other messages (e.g., Msg2) in AIoT communications. When Msg1 includes the temporary ID, the temporary ID can be randomly generated by device 503 and can have a value such as “NOUNCE. ” The generation of the temporary ID can use an algorithm (e.g., hash) based on the permanent / global ID of device 503.

[0072] In some implementations, Msg1 indicates the type of device 503, such as whether device 503 is of Types 1, 2a, or 2b.

[0073] In some implementations, Msg1 indicates the energy status of device 503, such as how long device 503 can keep operating based on its energy harvesting efficiency and / or storage balance. The energy status can be represented by a numeric value, such as an integer from 0 to 100, and / or can be classified into one of “Low, ” “Medium, ” and “High” categories. The energy status can be measured or estimated using a reference time before or after the transmission of Msg1.

[0074] In some implementations, Msg1 indicates the priority level of device 503. The priority level can be configured by an upper layer to indicate, e.g., the priority level of DO traffic, which can be measured on a per-packet basis.

[0075] In some implementations, the maximum value of the retry timer, which corresponds to the maximum time device 503 can wait for Msg2, can be predefined or pre-configured. The maximum value is typically set to be greater than the minimum processing time that reader 501 requires to process the uplink traffic received from device 503. Due to clock drifting in some AIoT devices, the maximum value is typically set to be relatively small such that device 503 has adequate time to redo initial access in the event of a failure. The setting of the maximum value can be dependent on, e.g., the priority level or the energy status. For example, the maximum value can be shorter for high priority data than for low priority data to allow quicker reattempt of initial access.

[0076] In some implementations, the retry timer is implemented as one or more registers of device 503. After the failure of initial access, device 503 can collect information from the registers and execute one or more algorithms to determine the cause of the failure and / or the reaction to the failure.

[0077] In some implementations, device 503 does not allow reattempt of initial access. For example, device 503 can give up its initial access attempt upon expiry of the retry timer for the first time. In these implementations, device 503 can be configured to restart an initial access attempt only upon receiving another Msg0. In some implementations, device 503 maintains a retry counter to track the number of attempts of initial access and stops initial access attempts once the retry counter reaches a threshold. The value of the threshold, which represents the maximum number of initial access attempts, can be fixed and stored in device 503 or can be configured and broadcast by the network as a parameter in Msg0.

[0078] The wait time can be a fixed value, a randomly generated value from within a range, or a value determined as a function of the number of failures. Device 503 can be configured to wait longer as the number of failure increases. For example, the wait time can increase linearly or exponentially as the number of access failure increases. The wait time can vary based on the priority level of the uplink traffic, which is to be transmitted in uplink after the initial access is successful. The wait time can also be configured as a timer whose maximum value is broadcast by the network as a parameter in Msg0.

[0079] In some implementations, device 503 expects Msg2 to be received using the same time or frequency resource as Msg1. For example, after transmitting Msg1 using a resource, device 503 can monitor the same resource for Msg2.

[0080] In some implementations, reader 501 does not immediately respond to a received Msg1. Instead, reader 501 waits a period for potential additional Msg1s from other AIoT devices that may contend for initial access. Additionally or alternatively, device 503 can transmit Msg1 using code division multiplexing (CDM) or frequency division multiplexing (FDM) schemes. In these scenarios, reader 501 may possibly receive multiple initial access requests from device 503 at about the same time.

[0081] In some implementations where device 503 uses a temporary ID in Msg1, reader 501 can convert the temporary ID to a network-configured ID or confirm the temporary ID as the network-configured ID, and use the network-configured ID as the MAC address of device 503 in Msg2. Alternatively or additionally, the network can assign a new MAC address to device 503 in Msg2 to reduce the risk of address collision due to multiple AIoT devices having the same temporary ID. The MAC address can be included in a header of Msg2. Reader 501 can use a timer or a counter ( “validity timer / counter” ) to track how long the MAC address can be used. For example, the timer or counter can indicate a duration of validity of the MAC address. The maximum value of the timer or counter can be dependent on the type and / or energy status of device 503, as provided in Msg1. Reader 501 can include the value of the counter or timer in Msg2.

[0082] In some implementations, reader 501 includes a handle that links Msg2 to Msg1. Accordingly, device 503 can determine whether the received Msg2 matches the initial access request sent in Msg1.

[0083] In some implementations, reader 501 includes an uplink grant in Msg2. Based on the uplink grant, device 503 can send the first uplink message (e.g., Msg3) , along with one or more uplink MAC CEs, to reader 501. The first uplink message can include one or more RRC messages and / or one or more upper layer data protocol data units (PDUs) .

[0084] In some implementations, device 503 stops the retry timer and / or resets the retry timer associated with the MAC address upon receiving Msg2. In some implementations, device 503 stops the retry timer when device 503 receives an access cut-off signal from reader 501. The access cut-off signal can be used by reader 501to indicate that Msg 1 from AIoT devices (including device 503) will no longer be admitted (e.g., accepted and processed) . In this case, device 503 can wait for new triggers to re-initiate access.

[0085] In some implementations, Msg3 is the first uplink message sent by device 503 after initial access is completed. Msg3 can include Layer 2 / Layer 3 payloads. Device 503 can use  an uplink transmission resource allocated by the uplink grant in Msg2 to transmit Msg3. If the uplink grant contains multiple uplink transmission resources, device 503 can transmit Msg3 multiple times using the multiple uplink transmission resources. AIoT transmissions usually do not involve hybrid automatic repeat request (HARQ) acknowledgement (ACK) or non-acknowledgement (NACK) .

[0086] In some implementations, Msg3 has a field of source ID. The source ID can be set according to the network-configured MAC address as indicated in Msg2.

[0087] In some implementations, Msg3 has a Result field that indicates the completion of configuration and / or initial access. The indication of Result can be used in cases where device 503 is not allowed (e.g., pursuant to System Aspect 2 or System Aspect 2 of the 3GPP standards) to disclose its device ID in an initial RRC message or not allowed to make its device ID transparent to the AS layer.

[0088] In some implementations, Msg3 includes the device ID of device 503 when the AS layer maintains the device ID in the AS device context.

[0089] As discussed above, in some implementations, Msg3 includes one or more upper layer AIoT data protocol data units (PDUs) , such as those for DO-A application layer traffic. The AIoT data PDUs may or may not be encapsulated in an RRC container of Msg3. Msg3 can also include one or more uplink MAC CEs to indicate, e.g., the energy status of device 503. Reader 501 can process any of these MAC CEs.

[0090] In some implementations, after receiving Msg3, reader 501 associates the device ID of device 503 with the NW-configured ID in the device context for device 503. Reader 501 maintains the validity timer / counter that indicates the validity period of the NW-configured ID.

[0091] In some implementations, reader 501 processes the received AIoT data PDUs and pass the processed AIoT data to an AIoT function, which may be implemented, e.g., as a network function of a core network (CN) .

[0092] FIG. 6A illustrates a flowchart of an example method 600A, according to some implementations. For clarity of presentation, the description that follows generally describes method 600A in the context of the other figures in this description. For example, method 600A can be performed by AIoT device 306 of FIG. 3. It will be understood that method 600A can be performed, for example, by any suitable system, environment, software, hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some  implementations, various steps of method 600A can be run in parallel, in combination, in loops, or in any order.

[0093] At 602, method 600A involves determining to perform an initial access between an AIoT reader and an AIoT device, such as between reader 501 and device 503 of FIGs. 5A or 5B.

[0094] At 604, method 600A involves transmitting a first message to the AIoT reader. The first message includes an ID of the AIoT device, which can be a temporary ID or a permanent ID. The first message can be similar to Msg1.

[0095] At 606, method 600A involves receiving a second message from the AIoT reader in response to the first message. The second message includes the ID of the AIoT device. The second message can be similar to Msg2.

[0096] At 608, method 600A involves transmitting a third message to the AIoT reader in response to the second message. The third message indicates completion of an AIoT access. The third message can be similar to Msg3.

[0097] FIG. 6B illustrates a flowchart of an example method 600B, according to some implementations. For clarity of presentation, the description that follows generally describes method 600B in the context of the other figures in this description. For example, method 600B can be performed by an AIoT reader of FIG. 3, such as base station 304 in topology 300A or UE 302 in topology 300B. It will be understood that method 600B can be performed, for example, by any suitable system, environment, software, hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of method 600B can be run in parallel, in combination, in loops, or in any order.

[0098] At 652, method 600B involves receiving a first message from an AIoT device. The first message includes an identifier of the AIoT device. The first message can be similar to Msg1.

[0099] At 654, method 600B involves transmitting a second message to the AIoT device in response to the first message. The second message includes the identifier of the AIoT device. The second message can be similar to Msg2.

[0100] At 656, method 600B involves receiving a third message from the AIoT device in response to the second message. The third message indicates completion of an AIoT access. The third message can be similar to Msg3.

[0101] FIG. 7 illustrates an example UE 700, according to some implementations. The UE 700 may be similar to and substantially interchangeable with UE 102 of FIG. 1.

[0102] The UE 700 may be any mobile or non-mobile computing device, such as, for example, mobile phones, computers, tablets, industrial wireless sensors (for example, microphones, pressure sensors, thermometers, motion sensors, accelerometers, inventory sensors, electric voltage / current meters, etc. ) , video devices (for example, cameras, video cameras, etc. ) , wearable devices (for example, a smart watch) , relaxed-IoT devices.

[0103] The UE 700 may include processors 702, RF interface circuitry 704, memory / storage 706, user interface 708, sensors 710, driver circuitry 712, power management integrated circuit (PMIC) 714, one or more antenna (s) 716, and battery 718. The components of the UE 700 may be implemented as integrated circuits (ICs) , portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 7 is intended to show a high-level view of some of the components of the UE 700. However, some of the components shown may be omitted, additional components may be present, some components may physically be combined or further separated unto multiple components, and different arrangement of the components shown may occur in other implementations.

[0104] The components of the UE 700 may be coupled with various other components over one or more interconnects 720, which may represent any type of interface, input / output, bus (local, system, or expansion) , transmission line, trace, optical connection, etc. that allows various circuit components (on common or different chips or chipsets) to interact with one another.

[0105] The processors 702 may include processor circuitry such as, for example, baseband processor circuitry (BB) 722A, central processor unit circuitry (CPU) 722B, and graphics processor unit circuitry (GPU) 722C. The processors 702 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 706 to cause the UE 700 to perform operations as described herein.

[0106] In some implementations, the baseband processor circuitry 722A may access a communication protocol stack 724 in the memory / storage 706 to communicate over a 3GPP compatible network. In general, the baseband processor circuitry 722A may access the communication protocol stack to: perform user plane functions at a physical (PHY) layer, medium access control (MAC) layer, radio link control (RLC) layer, packet data convergence protocol (PDCP) layer, service data adaptation protocol (SDAP) layer, and PDU layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and a non-access stratum layer. In some implementations, the PHY layer operations may additionally / alternatively be performed by the components of the RF interface circuitry 704. The baseband processor circuitry 722A may generate or process baseband signals or waveforms that carry information in 3GPP-compatible networks. In some implementations, the waveforms for NR may be based cyclic prefix orthogonal frequency division multiplexing (OFDM) “CP-OFDM” in the uplink or downlink, and discrete Fourier transform spread OFDM “DFT-S-OFDM” in the uplink.

[0107] The memory / storage 706 may include one or more non-transitory, computer-readable media that includes instructions (for example, communication protocol stack 724) that may be executed by one or more of the processors 702 to cause the UE 700 to perform various operations described herein. The memory / storage 706 include any type of volatile or non-volatile memory that may be distributed throughout the UE 700. In some implementations, some of the memory / storage 706 may be located on the processors 702 themselves (for example, L1 and L2 cache) , while other memory / storage 706 is external to the processors 702 but accessible thereto via a memory interface. The memory / storage 706 may include any suitable volatile or non-volatile memory such as, but not limited to, dynamic random access memory (DRAM) , static random access memory (SRAM) , erasable programmable read only memory (EPROM) , electrically erasable programmable read only memory (EEPROM) , Flash memory, solid-state memory, or any other type of memory device technology.

[0108] The RF interface circuitry 704 may include transceiver circuitry and radio frequency front module (RFEM) that allows the UE 700 to communicate with other devices over a radio access network. The RF interface circuitry 704 may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0109] In the receive path, the RFEM may receive a radiated signal from an air interface via antenna (s) 716 and proceed to filter and amplify (with a low-noise amplifier) the signal. The signal may be provided to a receiver of the transceiver that downconverts the RF signal into a baseband signal that is provided to the baseband processor of the processors 702.

[0110] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier prior to the signal being radiated across the air interface via the antenna (s) 716. In various implementations, the RF interface circuitry 704 may be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0111] The antenna (s) 716 may include one or more antenna elements to convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. The antenna elements may be arranged into one or more antenna panels. The antenna (s) 716 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple input, multiple output communications. The antenna (s) 716 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. The antenna (s) 716 may have one or more panels designed for specific frequency bands including bands in FR1 or FR2.

[0112] The user interface 708 includes various input / output (I / O) devices designed to enable user interaction with the UE 700. The user interface 708 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (for example, a reset button) , a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position (s) , or other like information. Output device circuitry may include any number or combinations of audio or visual display, including, inter alia, one or more simple visual outputs / indicators (for example, binary status indicators such as light emitting diodes “LEDs” and multi-character visual outputs) , or more complex outputs such as display devices or touchscreens (for example, liquid crystal displays “LCDs, ” LED displays, quantum dot  displays, projectors, etc. ) , with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the UE 700.

[0113] The sensors 710 may include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information (sensor data) about the detected events to some other device, module, subsystem, etc. Examples of such sensors include, inter alia, inertia measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems including 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; temperature sensors (for example, thermistors) ; pressure sensors; image capture devices (for example, cameras or lensless apertures) ; light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like) ; depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other like audio capture devices; etc.

[0114] The driver circuitry 712 may include software and hardware elements that operate to control particular devices that are embedded in the UE 700, attached to the UE 700, or otherwise communicatively coupled with the UE 700. The driver circuitry 712 may include individual drivers allowing other components to interact with or control various input / output (I / O) devices that may be present within, or connected to, the UE 700. For example, driver circuitry 712 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of sensors 710 and control and allow access to sensors 710, drivers to obtain actuator positions of electro-mechanic components or control and allow access to the electro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

[0115] The PMIC 714 may manage power provided to various components of the UE 700. In particular, with respect to the processors 702, the PMIC 714 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0116] In some implementations, the PMIC 714 may control, or otherwise be part of, various power saving mechanisms of the UE 700. A battery 718 may power the UE 700, although in some examples the UE 700 may be mounted deployed in a fixed location, and may have a power supply coupled to an electrical grid. The battery 718 may be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and  the like. In some implementations, such as in vehicle-based applications, the battery 718 may be a typical lead-acid automotive battery.

[0117] FIG. 8 illustrates an example access node 800 (e.g., a base station or gNB) , according to some implementations. The access node 800 may be similar to and substantially interchangeable with base station 104. The access node 800 may include processors 802, RF interface circuitry 804, core network (CN) interface circuitry 806, memory / storage circuitry 808, and one or more antenna (s) 810.

[0118] The components of the access node 800 may be coupled with various other components over one or more interconnects 812. The processors 802, RF interface circuitry 804, memory / storage circuitry 808 (including communication protocol stack 814) , antenna (s) 810, and interconnects 812 may be similar to like-named elements shown and described with respect to FIG. 7. For example, the processors 802 may include processor circuitry such as, for example, baseband processor circuitry (BB) 816A, central processor unit circuitry (CPU) 816B, and graphics processor unit circuitry (GPU) 816C.

[0119] The CN interface circuitry 806 may provide connectivity to a core network, for example, a 5th Generation Core network (5GC) using a 5GC-compatible network interface protocol such as carrier Ethernet protocols, or some other suitable protocol. Network connectivity may be provided to / from the access node 800 via a fiber optic or wireless backhaul. The CN interface circuitry 806 may include one or more dedicated processors or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 806 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0120] As used herein, the terms “access node, ” “access point, ” or the like may describe equipment that provides the radio baseband functions for data and / or voice connectivity between a network and one or more users. These access nodes can be referred to as BS, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs or TRPs, and so forth, and can include ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell) . As used herein, the term “NG RAN node” or the like may refer to an access node 800 that operates in an NR or 5G system (for example, a gNB) , and the term “E-UTRAN node” or the like may refer to an access node 800 that operates in an LTE or 4G system (e.g., an eNB) . According to various implementations, the access node 800 may be implemented as one or more of a dedicated physical device such as a macrocell base station,  and / or a low power (LP) base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0121] In some implementations, all or parts of the access node 800 may be implemented as one or more software entities running on server computers as part of a virtual network, which may be referred to as a CRAN and / or a virtual baseband unit pool (vBBUP) . In V2X scenarios, the access node 800 may be or act as a “Road Side Unit. ” The term “Road Side Unit” or “RSU” may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where an RSU implemented in or by a UE may be referred to as a “UE-type RSU, ” an RSU implemented in or by an eNB may be referred to as an “eNB-type RSU, ” an RSU implemented in or by a gNB may be referred to as a “gNB-type RSU, ” and the like.

[0122] Various components may be described as performing a task or tasks, for convenience in the description. Such descriptions should be interpreted as including the phrase “configured to.” Reciting a component that is configured to perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112 (f) interpretation for that component.

[0123] Although the implementations above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

[0124] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

Claims

1.A method comprising:determining to perform an initial access between an Ambient Internet-of-Things (AIoT) reader and an AIoT device;transmitting a first message to the AIoT reader, wherein the first message comprises an identifier of the AIoT device;receiving a second message from the AIoT reader in response to the first message, wherein the second message comprises the identifier of the AIoT device; andtransmitting a third message to the AIoT reader in response to the second message, wherein the third message indicates completion of an AIoT access.2.The method of claim 1, wherein the identifier is a first identifier, and wherein the third message comprises a second identifier of the AIoT device.3.The method of claim 1, wherein determining to perform the initial access comprises:determining that a volume of data in an uplink data buffer exceeds a threshold.4.The method of claim 1, wherein determining to perform the initial access comprises at least one of:determining a non-access stratum registration of the AIoT device, orobtaining of an access stratum layer control signal.5.The method of claim 1, wherein determining to perform the initial access comprises:receiving a paging signal from the AIoT reader.6.The method of claim 5, wherein the paging signal comprises a groupcast signal or a broadcast signal.7.The method of claim 5, wherein the paging signal comprises at least one of:information about downlink timing acquisition,information about access time window,information for identifying an intended AIoT device to trigger access,a configured resource set, oran identifier of the paging signal.8.The method of claim 1, wherein the identifier comprises at least one of: a temporary identifier generated by the AIoT device, or a permanent identifier preconfigured in a memory of the AIoT device.9.The method of claim 1, wherein the first message further comprises at least one of: a type of the AIoT device, an energy status of the AIoT device, or a traffic priority indicator.10.The method of claim 1, further comprising activating a timer after transmitting the first message, wherein the second message is received before the timer expires.11.The method of claim 10, further comprising resetting the timer after receiving the second message.12.The method of claim 1, wherein determining to perform the initial access comprises determining a failure of an earlier initial access.13.The method of claim 12, further comprising incrementing a failure counter in response to the failure.14.The method of claim 13, further comprising determining a wait time based on a value of the failure counter, wherein a duration between the earlier initial access and the initial access is equal to or greater than the wait time.15.The method of claim 1, wherein the second message is received in a resource corresponding to a resource used for transmitting the first message.16.The method of claim 1, wherein second message comprises at least one of: a medium access control (MAC) address configured by a network, a timer that indicates a duration of validity of the MAC address, or an uplink grant.17.A method comprising:receiving a first message from an Ambient Internet-of-Things (AIoT) device, wherein the first message comprises an identifier of the AIoT device;transmitting a second message to the AIoT device in response to the first message, wherein the second message comprises the identifier of the AIoT device; andreceiving a third message from the AIoT device in response to the second message, wherein the third message indicates completion of an AIoT access.18.The method of claim 17, further comprising transmitting a paging signal to the AIoT device, wherein the paging signal comprises a groupcast signal or a broadcast signal.19.The method of claim 17, further comprising:associating the identifier of the AIoT device with a medium access control (MAC) address configured by a network;obtaining an AIoT data protocol data unit (PDU) from the third message; andtransmitting the AIoT data PDU to the network.20.The method of claim 17, further comprising transmitting an access cut-off signal to the AIoT device, wherein the access cut-off signal indicates a stop of receiving initial access messages from the AIoT device.21.One or more processors comprising circuitry configured to execute instructions that cause an apparatus to perform the method of any of claims 1-20.22.A non-transitory computer-readable medium storing instructions that, when executed, cause one or more processors to perform the method of any of claims 1-20.23.An apparatus comprising one or more processors configured to perform the method of any of claims 1-20.

Images