Identifier management for an ambient internet of things device in wireless communications

Abstract

Various techniques pertaining to assigning, storing, and maintaining access stratum identifiers between an ambient internet of things (AIoT) device and an AIoT reader are described. The techniques involve storing the identifiers in a variety of locations at the AIoT device and maintaining an awareness of an availability time of the device between the AIoT device and the AIoT reader.

Description

IDENTIFIER MANAGEMENT FOR AN AMBIENT INTERNET OF THINGS DEVICE IN WIRELESS COMMUNICATIONSCROSS REFERENCE TO RELATED PATENT APPLICATION

[0001] The present disclosure is part of a non-provisional patent application claiming the priority benefit of PCT Application No. PCT / CN2024 / 129310, filed 01 November 2024, the content of which herein being incorporated by reference in its entirety.TECHNICAL FIELD

[0002] The present disclosure is generally related to wireless communications and, more particularly, to management of device identifiers by a device and a reader in an ambient internet of things (AIoT) system.BACKGROUND

[0003] Unless otherwise indicated herein, approaches described in this section are not prior art to the claims listed below and are not admitted as prior art by inclusion in this section.

[0004] An AIoT system comprises a set of devices, which are intended to be low-cost and / or low-energy devices such as inventory tags, trackers, and so on, in correspondence with a set of readers, which are more sophisticated entities that communicate information to and / or from the devices. The devices and / or readers may be further controlled by nodes in a cellular network, including but not limited to an AIoT-enabled next-generation Node B (gNB) , an AIoT-enabled access and mobility management function (AMF) , an AIoT function (AIoTF) , and an application function (AF) . Data may be transmitted in the device-to-reader (D2R) and / or reader-to-device (R2D) directions, using an air interface that may be referred to as an AIoT interface. The AIoT interface may be distinct from a cellular air interface such as a Third Generation Partnership Project (3GPP) Uu interface, even if the same network that controls the AIoT devices / readers also operates a cellular system comprising a Uu interface. The readers may be embodied in user equipments (UEs) and / or gNBs, as well as in mobile devices and / or base stations of other cellular systems such as a 6th Generation (6G) system.

[0005] Data may be exchanged between a reader and a device in a device-terminated (DT) mode, a device-originated / device-terminated-triggered (DO-DTT) mode, and / or a device-originated / autonomous (DO-A) mode. In a DT mode, the reader originates a data transmission to the device, based, for instance, on receiving application data from a network node directed to the device. In a DO-DTT mode, the reader initiates communication with the device, thereby triggering the device to deliver a data transmission to the reader. In a DO-A mode, the device originates a data transmission to the reader without being triggered by prior contact from the reader as in a DO-DTT mode.

[0006] An AIoT device may typically have a so-called “permanent” identifier (ID) , which may be unique in a very large scope (for instance, globally unique) and identify the device for initial communication with a reader. The permanent identifier may or may not be literally permanent, but it is assumed to be a long-term identifier of the device that cannot be changed by an individual reader, for instance. Such a permanent ID may be comparatively large-for instance, on the order of 100 bits-and may therefore be inappropriate for frequent use over the air, especially on an interface such as an AIoT interface that may be characterised by limited capacity, limited data rate, low transmit power from the device, and / or other similar constraints. Furthermore, security considerations may militate for concealing the permanent ID, so that a specific device cannot be tracked by an attacker, for instance. Thus, it is advantageous to have some form of short temporary ID, which may not be unique in a very large scope, but which can be used in a local scope (for instance, by one reader, or by the set of readers in one physical installation such as a warehouse) to identify the device for communication on the AIoT interface. Therefore, there is a need for a solution of identifier management for AIoT devices in wireless communications.SUMMARY

[0007] The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce concepts, highlights, benefits and advantages of the novel and non-obvious techniques described herein. Select implementations are further described below in the detailed description. Thus, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

[0008] An objective of the present disclosure is to provide schemes, concepts, designs, techniques, methods and apparatuses pertaining to identifier management for AIoT devices in wireless communications. For instance, various proposed schemes in accordance with the present disclosure may enable assigning, storing, and maintaining of a short temporary ID for an AIoT device, taking into account the operating constraints of the device, which may affect the ability of the device to retain and use a specific value of a temporary ID over a long period.

[0009] In an aspect of the disclosure, a method of identifier management operable at an AIoT device is provided. The device generates a first access stratum (AS) ID as part of a random access procedure. The device stores the first AS ID. The device receives, from an AIoT reader, a first transmission addressed to the first AS ID and comprising an assignment of a second AS ID. The device stores the second AS ID. The device receives, from the reader, a second transmission addressed to the second AS ID.

[0010] In another aspect of the disclosure, a method of indicating an availability time of a stored AS ID, operable at an AIoT device, is provided. The device sends, to an AIoT reader, a D2R transmission comprising an indication of the availability time.

[0011] In a further aspect of the disclosure, a method of managing an AS ID for an AIoT device, operable at an AIoT reader, is provided. The reader transmits, to the device, an assignment of the AS ID. The reader receives, from the device, an indication of an availability time. The reader determines, from the indication, a value of a timer. The reader starts the timer.

[0012] To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The accompanying drawings are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of the present disclosure. The drawings illustrate implementations of the disclosure and, together with the description, serve to explain the principles of the disclosure. It is appreciable that the drawings are not necessarily in scale as some components may be shown to be out of proportion than the size in actual implementation to clearly illustrate the concept of the present disclosure.

[0014] FIG. 1 is a diagram illustrating a portion of an exemplary AIoT system.

[0015] FIG. 2 is a diagram illustrating an exemplary set of protocol stacks for the interfaces of an AIoT system.

[0016] FIG. 3 shows an exemplary message flow for communication of data in both the D2R and R2D directions on an AIoT interface.

[0017] FIG. 4 shows an exemplary message flow for communication of data on an AIoT interface, including identifier and scheduling information, for the case where an access stratum identifier (AS ID) is assigned in a so-called “Msg2” of a random access procedure.

[0018] FIG. 5 shows an exemplary message flow for communication of data on an AIoT interface, where an AS ID is assigned in an R2D transmission after the completion of a random access procedure.

[0019] FIG. 6 shows an exemplary message flow for communication of data on an AIoT interface, with the addition of the management of ID values at the device, in accordance with an embodiment of this invention.

[0020] FIG. 7 shows two possible formats for an R2D transmission, in accordance with an embodiment of this invention.

[0021] FIG. 8 shows two possible formats for a D2R transmission, in accordance with an embodiment of this invention.

[0022] FIG. 9 shows an exemplary range of storage mechanisms for an AS ID at a device, in accordance with an embodiment of this invention.

[0023] FIG. 10 shows an exemplary message flow for maintaining reader knowledge of the availability at the device of a stored AS ID, based on the notion of an “availability time” and in accordance with an embodiment of this invention.

[0024] FIG. 11 shows an exemplary message flow for the life cycle of an AS ID assigned to a device, based on using an energy indication as an implicit measure of the availability time and in accordance with an embodiment of this invention.

[0025] FIG. 12 is a block diagram of an example communication system under a proposed scheme in accordance with the present disclosure.

[0026] FIG. 13 is a flowchart of an example process under a proposed scheme in accordance with the present disclosure.

[0027] FIG. 14 is a flowchart of an example process under a proposed scheme in accordance with the present disclosure.

[0028] FIG. 15 is a flowchart of an example process under a proposed scheme in accordance with the present disclosure. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0029] Detailed embodiments and implementations of the claimed subject matters are disclosed herein. However, it shall be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matters which may be embodied in various forms. The present disclosure may, however, be embodied in many different forms and should not be construed as limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided so that description of the present disclosure is thorough and complete and will fully convey the scope of the present disclosure to those skilled in the art. In the description below, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations. Overview

[0030] Implementations in accordance with the present disclosure relate to various techniques, methods, schemes and / or solutions pertaining to identifier management for AIoT devices in wireless communications. According to the present disclosure, a number of possible solutions may be implemented separately or jointly. That is, although these possible solutions may be described below separately, two or more of these possible solutions may be implemented in one combination or another.

[0031] Several aspects of telecommunication systems will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0032] FIG. 1 shows a portion of an exemplary AIoT system 100. The AIoT system 100 as shown involves at least two devices, namely a first device (denoted as ” Device 1” in FIG. 1) and a second device (denoted as “Device 2” in FIG. 1) , which are intended to be low-cost and low-power or even battery-less (for example, powering themselves via energy harvesting) , and the following network elements / nodes associated with a cellular / mobile communication network: (1) a user equipment (UE) -type reader, which communicates over an AIoT interface with the first device and which is embodied in a UE; (2) a base station (BS) such as a gNode B (gNB) that serves the UE-type reader over a Uu interface; (3) a BS-type reader, which communicates over an AIoT interface with the second device and which is embodied in a BS; (4) a controller, which communicates via an application protocol with the readers over a logical A-RC interface and which may, for example, be embodied at a node of a 5th Generation (5G) and / or 6th Generation (6G) core network (CN) ; and (5) an application function (AF) , which communicates via an application programming interface (API) with the controller over a logical A-CA interface to exchange application data with the devices and which may be embodied at a node of a 5G CN (5GC) . As shown in FIG. 1, the A-RC interface may traverse various other interfaces; in particular, for the UE-type reader, the A-RC interface must traverse the Uu interface as well as any network interfaces connecting the serving BS to the node that hosts the controller.

[0033] FIG. 2 shows an example scenario 200 of an exemplary set of protocol stacks for the interfaces of an AIoT system similar to that shown in FIG. 1. In scenario 200, a device and a reader communicate on an AIoT interface via an AIoT physical (PHY) layer and an AIoT medium access control (MAC) layer. The reader and a controller communicate via a reader application protocol (R-AP) on a logical A-RC interface, supported by network and / or Uu interfaces (indicated in FIG. 2 as “NW / Uu” ) , the details of which are outside the scope of this disclosure. The logical A-RC interface may traverse various network nodes and interfaces, and in the case of a UE-type reader, the A-RC interface may also traverse a Uu interface between a serving base station and a UE hosting the reader. The controller and an AF communicate via an AIoT API over a logical A-CA interface, supported by a service-based interface (SBI) protocol stack the details of which are outside the scope of this disclosure. Finally, the device and the AF communicate end-to-end via an AIoT protocol, which may, for example, include such operations as read and write commands with associated blocks of application data. It should be appreciated that other protocol stack designs are possible, but for purposes of the present disclosure, the important aspects are that the AIoT MAC and PHY layers connect the device and the reader, and that the MAC layer carries data blocks of an upper layer (e.g., application layer) between the AF and the device.

[0034] FIG. 3 shows an exemplary message flow for communication of data in both the D2R and R2D directions on an AIoT interface. In step 1, a reader sends to a device a first R2D message, which may be referred to as an AIoT paging message. The first R2D message may serve to locate the device and trigger a response from the device. Steps 2 through step 4 comprise a random access procedure, which may be a 2-step or a 3-step procedure (as step 4 may be optional) . In step 2, the device sends to the reader a first D2R message, labelled “Msg1” . Msg1 may be sent on radio resources identified in relation to the contents of the AIoT paging message in step 1. In some embodiments, Msg1 may include an identifier of the device, such as an upper-layer permanent identifier. In some embodiments, Msg1 may contain a random temporary identifier of the device, which may be referred to, for example, as a 16-bit random number (RN16) . In some embodiments, Msg1 may be sent on radio resources that are subject to contention, in which multiple devices may transmit on the same radio resources. In step 3, the reader sends to the device a second R2D message, labelled “Msg2” ; in case Msg1 was sent in a contention-based manner, Msg2 may serve to resolve contention by indicating which device’s transmission the reader successfully received. In some embodiments, Msg2 may contain an assignment of an access stratum identifier (AS ID) to the device, as further described below. For contention resolution, Msg2 may echo back the value of RN16 received in Msg1. In an optional step 4, the device sends to the reader a second D2R message, labelled “Msg3” , which may contain a first set of application data and / or an upper-layer identifier of the device. Step 4 (if it occurs; otherwise, step 3) may conclude the random access procedure. In step 5, the reader sends to the device a third R2D transmission, which may be referred to as “subsequent data” (e.g., subsequent to the completion of the random access procedure) and which may comprise data generated by the MAC layer, data provided from an application layer, data from an upper-layer message, or a combination thereof. In some embodiments, step 5 may comprise an assignment of an AS ID to the device, as further described below. In an optional step 6, the device sends to the reader a third D2R transmission, which may comprise data generated by the MAC layer, data provided from an application layer, data from an upper-layer message, or a combination thereof, and / or an acknowledgement of the transmission in step 5.

[0035] For several steps in the procedure of FIG. 3, it may be necessary for the device and the reader to have a common concept of an identifier for the device. This identifier allows the reader to schedule transmissions in the R2D direction with addressing information or other metadata that indicates “this message is for device X” , and it may also allow the device to deliver transmissions in the D2R direction with source information or other metadata that indicates “this message is from device X” . In some embodiments, the identification of the device in the D2R direction may be implicit. For instance, the reader may know that certain radio resources are assigned to a certain device, and thus the reader may interpret any data received on those radio resources as being from that device. As indicated in the description above, some steps may rely on a short-term identifier (e.g., RN16 in Msg1 and Msg2) , while other steps may rely on a longer-term temporary identifier such as an AS ID (assigned, for instance, in step 3 or step 5) or even on an upper-layer long-term or permanent identifier. However, in general, a long-term or permanent identifier would be expected to be large, and therefore likely inconvenient for routine scheduling use on the AIoT interface. An analogy can be drawn to the different identifiers that can be used on the Uu interface of a cellular system. That is, an International Mobile Station Identifier (IMSI) is a substantially permanent identifier of a UE that is rarely used over the air because of its size and security concerns (as the IMSI should not be revealed because it can allow user tracking by an eavesdropper) , while an upper-layer temporary identifier such as a 5G System Architecture Evolution (SAE) temporary mobile station identifier (TMSI) (5G-S-TMSI) is assigned for a shorter period but still inconveniently long for scheduling use, and a cell radio network temporary identifier (C-RNTI) is assigned for a short period (e.g., the UE’s dwell time in one cell of the system or less) and is short enough to be used as a scheduling identifier on the Uu interface. The permanent ID of an AIoT device may be seen as analogous to the IMSI of a cellular UE, an upper-layer temporary ID of an AIoT device may be seen as analogous to the S-TMSI of a cellular UE, and an AS ID of an AIoT device may be seen as analogous to the C-RNTI of a cellular UE.

[0036] FIG. 4 shows an exemplary message flow similar to FIG. 3, but with the addition of identifier and scheduling information, and the procedure in FIG. 4 is specialized to the case where an AS ID is assigned in Msg2. In step 1, a reader sends to a device an AIoT paging message that indicates that it is for this device, identified by an upper-layer identifier (which may, for instance, be a permanent identifier of the device or a long-term temporary identifier assigned by upper layers) . In step 2, the device sends to the reader a Msg1 containing an RN16 (which may, for example, be generated by the device itself) ; at this step, the device must store the value of RN16 so that it can be used in the next step. In step 3, the reader sends to the device a Msg2 addressed to the device’s value of RN16, to resolve contention by confirming that Msg1 with this value of RN16 arrived successfully at the reader. In addition, as an option, Msg2 may contain an AS ID chosen by the reader and assigned to the device. In some embodiments, this AS ID may have the same value as RN16, i.e., the reader may assign to the device the same identifier that the device is already storing. At this step, the device must store the AS ID so that it can be used in the following steps, and as further described below, this storage may interact with the previous storage of RN16 at step 2. In step 4 (optional) , the device sends to the reader a Msg3, whose source may be indicated with the device’s value of the AS ID. In some embodiments, Msg3 may carry additional information such as a permanent identifier of the device, application data, and so on, and it may also serve to acknowledge Msg2 and confirm for the reader that the device has received the assignment of the AS ID. In step 5, the reader sends to the device a transmission of R2D data addressed to the device’s value of the AS ID. Any further communication between the device and the reader-such as the optional step 6, in which the device sends to the reader a transmission of D2R data and / or an acknowledgement for step 5-may use the AS ID as a locally-unique (for example, unique within the scope of this reader) identifier for the device, until the AS ID is invalidated.

[0037] FIG. 5 shows an exemplary message flow similar to FIG. 4 but with the AS ID assigned in step 5 instead of in step 3. Steps 1 and 2 are the same as in FIG. 4, but in step 3, Msg2 does not contain an assignment of an AS ID to the device. Instead, the device continues using RN16 as its identifier, so in step 4, Msg3 has its source given by RN16. In step 5, the reader sends to the device a transmission of R2D data, addressed by RN16 (since the device has no other temporary identifier at this stage) and containing an assignment of an AS ID. In the optional step 6, the device may send to the reader a transmission of D2R data and / or an acknowledgement of step 5, with the source being given by the device’s assigned value of the AS ID. In this flow, the device still needs to store the value of RN16 that it generated for step 2, and it further needs to store the assigned AS ID at step 5. It is noteworthy that, in both FIG. 4 and FIG. 5, the device only needs to remember one scheduling identifier at a time; in FIG. 4, the scheduling identifier is RN16 from step 2 to step 3 only, and the scheduling identifier is AS ID thereafter. In FIG. 5, the scheduling identifier is RN16 from step 2 to step 5, and the scheduling identifier is AS ID in step 6 (and for subsequent communication) . In a message flow of this type, the ID assignment in step 5 may be repeated in one or more subsequent messages. That is, the reader may assign a new AS ID at substantially any time during communication with the device.

[0038] FIG. 6 shows an exemplary message flow based on the procedure of FIG. 4, with the addition of the management of ID values at the device, under a proposed scheme in accordance with the present disclosure. For purposes of FIG. 6, the terminology “AS ID” refers to a specific storage location in the device (as described below regarding how this storage may be implemented) , “RN16” refers to a (notionally 16-bit, though other sizes are technically feasible) random identifier chosen by the device during the random access procedure, and “New_ID” refers to an identifier value assigned by the reader to the device. In the device column, FIG. 6 distinguishes between assignment of a value (asingle equal sign, “=” ) and comparison of values (adouble equal sign, “==” ) . In step 1 of FIG. 6, a reader sends to a device an AIoT paging message, which may also be referred to as “Msg0” to clarify its relation to the messages in the following random access procedure. This paging message may, for example, identify the particular device in question using a permanent ID, a temporary upper-layer ID, a previously assigned AS ID, a group ID defined at any layer, and so on. In step 2, the device responds to the paging message with a so-called Msg1, i.e., the first message of a random access procedure, containing RN16 (which may, for example, be randomly generated by the device) . In step 3, the device stores RN16 as its current value of the AS ID. In step 4, the reader sends to the device a Msg2 of the random access procedure, directed to RN16 (for example, identifying RN16 as the current identifier of the device that “wins” a contention process in the random access procedure) and containing New_ID as a new value that should replace RN16 in the device’s AS ID. New_ID may, for example, be contained as a field of a medium access control (MAC) layer message comprising all or part of Msg2. Msg2 may be referred to as a contention resolution message, and it may be directed to a particular recipient by various signaling methods, such as indicating RN16 in the physical layer, including RN16 in a field of the message, and so on. In step 5, the device tests whether its stored AS ID is identical to the value of RN16 in Msg2, which may be characterized as an “is this message for me?” test, and in the example illustrated the test is successful, meaning that the message is directed to this device. In this step, matching the ID in the message also indicates that the device has won contention. In step 6, the device stores New_ID as its updated value of AS ID, according to the instructions in Msg2. From this point forward, the device can no longer be addressed by RN16 and must be addressed by New_ID. In step 7, the device optionally sends to the reader a Msg3 of the access procedure. As with previous figures, the existence of this message may depend on whether a 2-step or a 3-step access procedure is employed. If there is an explicit or implicit indication of the source of Msg3 (e.g., an identity of the device) , it would be expected that Msg3 is indicated as coming from the device identified by New_ID. In some embodiments, the order of steps 6 and 7 may be reversed, and Msg3 may be indicated as coming from the device identified by RN16 (because in such a case Msg3 is sent before the AS ID is overwritten with New_ID) . In some embodiments, Msg3 may not contain an explicit or implicit identification of its source, and it may, for instance, be recognized as coming from this particular device based on which radio resources Msg3 occupies (for example, a set of radio resources assigned by Msg2 in step 4 for the sole use of this device) . In step 8, the reader sends to the device a subsequent R2D transmission, addressed to New_ID. In step 9, the device tests to determine if its stored value of AS ID matches the New_ID that was received as the destination of the transmission in step 8. In this instance the test is successful, i.e., the message is addressed to this device and can be processed by this device. In step 10, the device sends to the reader a subsequent D2R transmission, which may, for instance, use radio resources that were assigned by the R2D transmission in step 8. If the transmission in step 10 contains an explicit or implicit indication of its source, the indicated source is New_ID (extracted from the AS ID storage location in the device) , but as described above for Msg3 in step 7, the transmission in step 10 may not contain an explicit or implicit identification of its source and may, for instance, instead be recognized as coming from this particular device based on which radio resources the transmission occupies. Further transmissions in the R2D and / or D2R directions may take place beyond those shown in the figure; in general, subsequent R2D transmissions will be addressed to New_ID, and subsequent D2R transmissions will be indicated (if there is any indication of a source, explicit or implicit) as coming from New_ID, until / unless the reader sends to the device a new assignment of a different value to be stored in the AS ID.

[0039] In some embodiments, a new value for the AS ID may be assigned in a subsequent R2D transmission rather than in Msg2, as shown in the flow of FIG. 5. In such a case, a procedure similar to FIG. 6 applies, but the New_ID is not stored until it is received in the subsequent R2D transmission (e.g., step 5 of FIG. 5) . The procedure is otherwise substantially unchanged. That is, when an R2D transmission is received, the device extracts the ID to which the transmission is addressed and compares the extracted ID to its stored AS ID, which initially is populated with RN16 and after the assignment of New_ID is populated with New_ID.

[0040] FIG. 7 shows two possible formats for an R2D transmission, under a proposed scheme in accordance with the present disclosure. It should be appreciated that these formats are exemplary, and the same or similar information may be structured in different arrangements. In the first format, the R2D transmission may include a destination address, a section of physical-layer (PHY) information (labelled “Other PHY data” in FIG. 7) , a payload comprising data to be interpreted by the receiving device, and a cyclic redundancy check (CRC) value. The destination address may include an AS ID (in the broader sense of the present disclosure, e.g., an identifier assigned and managed in the access stratum, rather than the narrower sense used in the description of FIG. 6 above) . The contents of the other PHY data may vary according to the needs of the physical layer, including, for example, modulation and coding state information, a length indicator, one or more format indicators, a preamble, midamble, or postamble, scheduling information for a subsequent D2R transmission, and so on. The payload may be seen as application-layer or upper-layer data and may include, for example, a command from an AIoT AF or an AIoTF to a recipient device. The CRC may be computed by the transmitter (in this case the reader) over all or a portion of the message. The CRC may be used by the receiver (in this case the device) to confirm accurate reception of the message.

[0041] The second format shown in FIG. 7 is substantially similar to the first format, except that there is no separate field for the destination address. Instead, the transmission may include PHY data (which may contain any of the same information described above for the first format) , a payload (which may contain the same types of information described above for the first format) , and a field in which a CRC is “masked” -by an exclusive OR operation (XOR or ^) , for example-with a destination address. In some embodiments, the information shown in FIG. 7 as individual fields may be distributed in multiple locations within the transmission. As one example, the “Other PHY data” (first format) or “PHY data” (second format) may be distributed into a combination of locations including some or all of a header, a preamble, one or more midambles, a postamble, and / or a trailing block. Additional fields not shown in FIG. 7 may be present, such as fields required for MAC layer transmission management, segmentation, acknowledgement, and so on.

[0042] FIG. 8 shows two possible formats for a D2R transmission, under a proposed scheme in accordance with the present disclosure. The formats are substantially similar to the R2D formats in FIG. 7, with the difference that the destination address (the device, in the R2D direction) is replaced by a source address (the device, in the D2R direction) . The formats and contained fields are similar to those used in the R2D direction, and the descriptions given under FIG. 7 apply to the analogous fields in FIG. 8 (with the difference that the PHY data will not contain scheduling information for a subsequent D2R transmission) . In addition to the information described above under FIG. 7, the information sent by the device in the D2R direction may include an energy indication, as further described below.

[0043] FIG. 9 shows an exemplary range of storage mechanisms for an AS ID at a device, under a proposed scheme in accordance with the present disclosure. FIG. 9 shows a device and a reader connected by an air interface. The reader transmits to the device, on the air interface, an assignment of an AS ID to be stored by the device (analogous to the value New_ID in FIG. 6, for instance) . The device receives the AS ID and may store it in any of a variety of locations, including, for instance, volatile random access memory (VRAM) , non-volatile random access memory (NVRAM) , and / or one or more registers. These storage locations may have different characteristics. For instance, VRAM may be cleared whenever the device runs out of energy (e.g., when a battery or capacitor is drained) , while NVRAM may persist even through a power-off state. A register may be volatile or non-volatile in this sense, and it may be viewed as a special region of hardware memory that may, for example, be optimized for low-latency and / or low-energy read and / or write operations. By contrast, NVRAM may be expensive in terms of energy to read and / or write. In some embodiments, write operations to NVRAM may be sufficiently expensive that the design goals of the device may include avoiding frequent NVRAM writing. Moreover, NVRAM locations may have limitations on the number of times they can be rewritten over the lifetime of the device (e.g., the memory may be rated for up to 100, 000 write operations) , meaning that NVRAM write operations should be infrequent to avoid the need to replace the memory or the entire device. For these reasons, storage in a register or VRAM may be preferred, but these locations may lack the ability of NVRAM to retain data through a power-off state. If an AS ID is stored in a volatile location and lost during power-off, the device can no longer be addressed by that AS ID, and therefore the reader may need to be aware of the potential loss of the AS ID information. Accordingly, an approach to maintaining reader knowledge of the validity of a stored AS ID is beneficial.

[0044] FIG. 10 shows a message flow of one way of maintaining reader knowledge of the availability at the device of a stored AS ID, based on the notion of an “availability time” for the device, under a proposed scheme in accordance with the present disclosure. The availability time herein refers to a time for which the device expects (or guarantees) that it will remain powered and be able to retain stored volatile data, which may include a stored AS ID. FIG. 10 shows a device and a reader. In step 1, the reader assigns an AS ID to the device, using, for example, a method such as those described above. In step 2, the device stores the AS ID, for example, in VRAM or a register. In step 3, the device sends to the reader a D2R transmission comprising an indication of the device’s anticipated availability time. In some embodiments, this indication may comprise an explicit representation of time, such as a number of milliseconds for which the device expects to remain awake. In other embodiments, this indication may comprise an indirect representation, such as an estimate of remaining energy at the device (as described further below) . The reader may start an internal timer after this step, so that it can know when the availability time expires as described in a subsequent step. In step 4, while the availability time is still valid (e.g., the amount of time directly or indirectly indicated in step 3 has not yet elapsed) , the reader sends to the device a transmission of R2D data, addressed by the previously assigned AS ID. Since the availability time has not expired, the device still has the AS ID stored and can receive this transmission. In step 5, the availability time (as represented, for example, by the previously described internal timer in the reader) expires. Step 5 does not necessarily mean that the device powers off and / or forgets the AS ID (for example, the device may have underestimated its energy reserves when calculating the availability time) , but it means that the reader can no longer assume that the device retains the AS ID. Thus, in step 6, when new R2D data arrive at the reader for transmission to the device, the reader may trigger a new paging operation in step 7 to bring itself back into communication with the device. Step 7 offers the opportunity to assign a new AS ID to the device (using any of the methods heretofore described) and start the cycle of FIG. 10 over again by returning to step 1. In some embodiments, step 4 may be repeated and / or followed by one or more D2R transmissions, which, if they include an indication of a source ID, will be indicated as coming from (the device identified by) the AS ID. That is, until the expiration occurs at step 5, the reader and the device can exchange R2D and / or D2R data freely, using the AS ID as an identifier of the device. Here it should be understood that “freely” refers to the availability of the AS ID for communication; depending on the overlying use case, there may be restrictions on when the device and the reader can communicate. For example, in a device originated-device terminated triggered (DO-DTT) mode of operation, the device may not be permitted to send a D2R transmission unless the reader has previously requested such a transmission, while in a device originated-attach (DO-A) mode of operation, the device may be able to initiate an autonomous D2R transmission.

[0045] FIG. 11 shows an exemplary message flow for the life cycle of an AS ID assigned to a device, based on using an energy indication as an implicit representation of the availability time, under a proposed scheme in accordance with the present disclosure. In step 1, a reader assigns to a device an AS ID, using, for example, a method such as those described above. In step 2, the device stores the AS ID, for example, in VRAM or a register. In step 3, the device sends to the reader a D2R transmission comprising an energy indication, which may, for example, be a measured or estimated level of stored energy at the device. In some embodiments, the energy indication may be quantized to a number of levels corresponding to different energy thresholds. For instance, a 2-bit indicator might be used to indicate “not enough energy for any subsequent operation” (indicator value 00) , “enough energy for one receive action” (indicator value 01) , “enough energy for one receive / transmit cycle” (indicator value 10) , or “enough energy for more than one receive / transmit cycle” (indicator value 11) . Alternatively, the level of stored energy might be mapped to quanta of sustainable idle time, e.g., a time that the device can remain powered on without any reception or transmission. In step 4, the reader infers from the energy indication (and perhaps other information, e.g., knowledge configured by other elements of the system of the capabilities of the device) an availability time, e.g., a time during which it may safely assume that the device will remain powered on and retain the AS ID. In step 5, before the expiration of the availability time, the reader sends to the device an R2D transmission addressed by the AS ID. In step 6, the availability time expires. As in FIG. 10, this event may or may not mean that the device actually powers off, but it represents expiration of the reader’s expectation that the AS ID will be retained. In step 7, after the expiration of the availability time, the reader receives new R2D data for transmission to the device. In step 8, since the availability time has expired, the reader starts a new paging operation to establish contact with the device. As in FIG. 10, this procedure may cycle indefinitely, with each paging operation offering the opportunity to assign a new AS ID and communicate with the device. In some embodiments, step 5 may be repeated and / or followed by one or more D2R transmissions, which, if they include an indication of a source ID, will be indicated as coming from (the device identified by) the AS ID. That is, as in FIG. 10, until the expiration of the availability time at step 6, the device and reader can exchange R2D and / or D2R data freely (subject to potential use-case-specific limitations such as those described under FIG. 10) , using the AS ID as an identifier of the device. Feature Highlight

[0046] In view of the above, key features of various proposed schemes in accordance with the present disclosure are highlighted below.

[0047] In one aspect, a method of identifier management operable at an AIoT device may involve the AIoT device performing certain operations, including: (1) generating a first AS ID [RN16] as part of a random access procedure; (2) storing the first AS ID; (3) receiving, from an AIoT reader, a first transmission addressed to the first AS ID and comprising an assignment of a second AS ID [New_ID] ; (4) storing the second AS ID; and (5) receiving, from the AIoT reader, a second transmission addressed to the second AS ID.

[0048] In some implementations, at least one of the first AS ID and the second AS ID may be indicated in at least one of the first transmission and the second transmission in a destination address field.

[0049] In some implementations, at least one of the first AS ID and the second AS ID may be indicated in at least one of the first transmission and the second transmission by encoding with an operation together with a CRC value. In some implementations, the operation may be an exclusive OR (XOR) operation.

[0050] In some implementations, the method may further involve the AIoT device receiving, from the AIoT reader, a third transmission addressed to the second AS ID and comprising an assignment of a third AS ID.

[0051] In some implementations, the first transmission may be a Msg2 of an AIoT random access procedure.

[0052] In some implementations, the first transmission may be a subsequent R2D transmission following an AIoT random access procedure.

[0053] In some implementations, the first AS ID may be randomly generated by the AIoT device.

[0054] In some implementations, the method may further involve the AIoT device transmitting, to the AIoT reader, a fourth transmission comprising an indication of the first AS ID as the source of the fourth transmission. In some implementations, the first AS ID may be indicated in a source address field. Alternatively, or additionally, the first AS ID may be indicated by encoding with an operation together with a CRC value. In some implementations, the operation may be an XOR operation.

[0055] In some implementations, the method may further involve the AIoT device transmitting, to the AIoT reader, a fifth transmission comprising an indication of the second AS ID as the source of the fifth transmission. In some implementations, the second AS ID may be indicated in a source address field. Alternatively, or additionally, the second AS ID may be indicated by encoding with an operation together with a CRC value. In some implementations, the operation is an XOR operation.

[0056] In some implementations, in storing, the method may involve the AIoT device storing in a VRAM location. Alternatively, or additionally, in storing, the method may involve the AIoT device storing in a NVRAM location. Still alternatively, in storing, the method may involve the AIoT device storing in a register.

[0057] In another aspect, a method of indicating an availability time of a stored AS ID may involve an AIoT device sending, to an AIoT reader, a D2R transmission comprising an indication of the availability time.

[0058] In some implementations, the availability time may be indicated as a time span. In some implementations, the time span may include an idle time sustainable by the AIoT device.

[0059] In some implementations, the availability time may be indicated by an energy indication. In some implementations, the energy indication may include a representation of stored energy at the AIoT device. Alternatively, or additionally, the energy indication may include one or more quantized values indicating one or more operations that can be supported by the AIoT device’s stored energy.

[0060] In still another aspect, a method of managing an AS ID for an AIoT device may involve an AIoT reader performing certain operations, including: (1) transmitting, to the AIoT device, an assignment of the AS ID; (2) receiving, from the AIoT device, an indication of an availability time; (3) determining, from the indication, a value of a timer; and (4) starting the timer.

[0061] In some implementations, the method may further involve the AIoT reader sending, to the AIoT device prior to the expiration of the timer, a first R2D transmission addressed to the AS ID.

[0062] In some implementations, the method may further involve the AIoT reader sending, to the AIoT device subsequent to the expiration of the timer, an AIoT paging message.

[0063] In some implementations, the indication may include a time span. Alternatively, or additionally, the indication may include an energy indication. In some implementations, the energy indication may include a representation of stored energy at the AIoT device. Alternatively, or additionally, the energy indication may include a quantized value indicating one or more operations that can be supported by the AIoT device’s stored energy. Illustrative Implementations

[0064] FIG. 12 illustrates an example system 1200 having at least an example apparatus 1210 and an example apparatus 1220 in accordance with an implementation of the present disclosure. Each of apparatus 1210 and apparatus 1220 may perform various functions to implement schemes, techniques, processes and methods described herein pertaining to identifier management for AIoT devices in wireless communications, including the various schemes described above with respect to various proposed designs, concepts, schemes, systems and methods described above as well as processes described below. For instance, apparatus 1210 may be implemented in or as a device (e.g., AIoT device) and apparatus 1220 may be implemented in or as another device (e.g., a AIoT reader) , or vice versa.

[0065] In some implementations, each of apparatus 1210 and apparatus 1220 may be implemented in the form of one or more integrated-circuit (IC) chips such as, for example and without limitation, one or more single-core processors, one or more multi-core processors, one or more reduced-instruction set computing (RISC) processors, or one or more complex-instruction-set-computing (CISC) processors. In the various schemes described above, each of apparatus 1210 and apparatus 1220 may be implemented in or as a target UE or an anchor UE / positioning server UE. Each of apparatus 1210 and apparatus 1220 may include at least some of those components shown in FIG. 12 such as a processor 1212 and a processor 1222, respectively, for example. Each of apparatus 1210 and apparatus 1220 may further include one or more other components not pertinent to the proposed scheme of the present disclosure (e.g., internal power supply, display device and / or user interface device) , and thus, such component (s) of apparatus 1210 and apparatus 1220 are neither shown in FIG. 12 nor described below in the interest of simplicity and brevity.

[0066] In one aspect, each of processor 1212 and processor 1222 may be implemented in the form of one or more single-core processors, one or more multi-core processors, one or more RISC processors or one or more CISC processors. That is, even though a singular term “aprocessor” is used herein to refer to processor 1212 and processor 1222, each of processor 1212 and processor 1222 may include multiple processors in some implementations and a single processor in other implementations in accordance with the present disclosure. In another aspect, each of processor 1212 and processor 1222 may be implemented in the form of hardware (and, optionally, firmware) with electronic components including, for example and without limitation, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors and / or one or more varactors that are configured and arranged to achieve specific purposes in accordance with the present disclosure. In other words, in at least some implementations, each of processor 1212 and processor 1222 is a special-purpose machine specifically designed for identifier management for AIoT devices in wireless communications in accordance with various implementations of the present disclosure.

[0067] In some implementations, apparatus 1210 may also include a transceiver 1216 coupled to processor 1212. Transceiver 1216 may include a transmitter capable of wirelessly transmitting and a receiver capable of wirelessly receiving data. In some implementations, apparatus 1220 may also include a transceiver 1226 coupled to processor 1222. Transceiver 1226 may include a transmitter capable of wirelessly transmitting and a receiver capable of wirelessly receiving data. It is noteworthy that, although transceiver 1216 and transceiver 1226 are illustrated as being external to and separate from processor 1212 and processor 1222, respectively, in some implementations, transceiver 1216 may be an integral part of processor 1212 as a system on chip (SoC) , and transceiver 1226 may be an integral part of processor 1222 as a SoC.

[0068] In some implementations, apparatus 1210 may further include a memory 1214 coupled to processor 1212 and capable of being accessed by processor 1212 and storing data therein. In some implementations, apparatus 1220 may further include a memory 1224 coupled to processor 1222 and capable of being accessed by processor 1222 and storing data therein. Each of memory 1214 and memory 1224 may include a register and / or a type of random-access memory (RAM) such as dynamic RAM (DRAM) , static RAM (SRAM) , thyristor RAM (T-RAM) and / or zero-capacitor RAM (Z-RAM) . Alternatively, or additionally, each of memory 1214 and memory 1224 may include a type of read-only memory (ROM) such as mask ROM, programmable ROM (PROM) , erasable programmable ROM (EPROM) and / or electrically erasable programmable ROM (EEPROM) . Alternatively, or additionally, each of memory 1214 and memory 1224 may include a type of VRAM or NVRAM such as flash memory, solid-state memory, ferroelectric RAM (FeRAM) , magnetoresistive RAM (MRAM) and / or phase-change memory.

[0069] Each of apparatus 1210 and apparatus 1220 may be a communication entity capable of communicating with each other using various proposed schemes in accordance with the present disclosure. For illustrative purposes and without limitation, a description of capabilities of apparatus 1210, as a device, and apparatus 1220, as a UE reader, is provided below in the context of example processes 1300, 1400 and 1500. It is noteworthy that, although a detailed description of capabilities, functionalities and / or technical features of one of apparatus 1210 and apparatus 1220 is provided below, the same may be applied to the other of apparatus 1210 and apparatus 1220 although a detailed description thereof is not provided solely in the interest of brevity. It is also noteworthy that, although the example implementations described below are provided in the context of air interface communications in an AIoT system, the same may be implemented in other types of systems. Illustrative Processes

[0070] FIG. 13 illustrates an example process 1300 in accordance with an implementation of the present disclosure. Process 1300 may represent an aspect of implementing various proposed designs, concepts, schemes, systems and methods described above. More specifically, process 1300 may represent an aspect of the proposed concepts and schemes pertaining to identifier management for AIoT devices in wireless communications in accordance with the present disclosure. Process 1300 may include one or more operations, actions, or functions as illustrated by one or more of blocks as well as subblocks. Although illustrated as discrete blocks, various blocks of process 1300 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks / sub-blocks of process 1300 may be executed in the order shown in FIG. 13 or, alternatively, in a different order. Furthermore, one or more of the blocks / sub-blocks of process 1300 may be executed repeatedly or iteratively. Process 1300 may be implemented by or in apparatus 1210 and apparatus 1220 as well as any variations thereof. Solely for illustrative purposes and without limiting the scope, process 1300 is described below in the context of apparatus 1210 implemented in or as an AIoT device and apparatus 1220 implemented in or as an AIoT reader of a wireless network such as a mobile network in accordance with one or more of 3GPP standards. Process 1300 may begin at block 1310.

[0071] At 1310, process 1300 may involve processor 1212 of apparatus 1210 generating a first AS ID as part of a random access procedure. Process 1300 may proceed from 1310 to 1320.

[0072] At 1320, process 1300 may involve processor 1212 storing the first AS ID. Process 1300 may proceed from 1320 to 1330.

[0073] At 1330, process 1300 may involve processor 1212 receiving, via transceiver 1216, from an AIoT reader (e.g., apparatus 1220) a first transmission addressed to the first AS ID, with the first transmission comprising an assignment of a second AS ID to the AIoT device. Process 1300 may proceed from 1330 to 1340.

[0074] At 1340, process 1300 may involve processor 1212 storing the second AS ID. Process 1300 may proceed from 1340 to 1350.

[0075] At 1350, process 1300 may involve processor 1212 receiving, via transceiver 1216, from the AIoT reader a second transmission addressed to the second AS ID.

[0076] In some implementations, at least one of the first AS ID and the second AS ID may be indicated in a destination address field or encoded with a CRC value in the first transmission or the second transmission, respectively. In some implementations, the at least one of the first AS ID and the second AS ID may be encoded with the CRC value using an XOR operation.

[0077] In some implementations, the first transmission may include a Msg2 of an AIoT random access procedure or a subsequent R2D transmission following the AIoT random access procedure.

[0078] In some implementations, in storing either or both of the first AS ID and the second AS ID, process 1300 may involve processor 1212 storing at least one of the first AS ID and the second AS ID in a VRAM, NVRAM or register.

[0079] In some implementations, in generating the first AS ID, process 1300 may involve processor 1212 randomly generating the first AS ID.

[0080] In some implementations, process 1300 may further involve processor 1212 receiving, via transceiver 1216, from the AIoT reader a third transmission addressed to the second AS ID and comprising an assignment of a third AS ID to the AIoT device.

[0081] In some implementations, process 1300 may further involve processor 1212 transmitting, via transceiver 1216, to the AIoT reader a fourth transmission comprising an indication of the first AS ID as a source of the fourth transmission.

[0082] In some implementations, the first AS ID may be indicated in a source address field or encoded with a CRC value in the fourth transmission. In some implementations, the first AS ID may be encoded with the CRC value using an XOR operation.

[0083] In some implementations, process 1300 may further involve processor 1212 transmitting, via transceiver 1216, to the AIoT reader a fifth transmission comprising an indication of the second AS ID as a source of the fifth transmission.

[0084] In some implementations, the first AS ID may be indicated in a source address field or encoded with a CRC value in the fourth transmission. In some implementations, the first AS ID may be encoded with the CRC value using an XOR operation.

[0085] FIG. 14 illustrates an example process 1400 in accordance with an implementation of the present disclosure. Process 1400 may represent an aspect of implementing various proposed designs, concepts, schemes, systems and methods described above. More specifically, process 1400 may represent an aspect of the proposed concepts and schemes pertaining to identifier management for AIoT devices in wireless communications in accordance with the present disclosure. Process 1400 may include one or more operations, actions, or functions as illustrated by one or more of blocks as well as subblocks. Although illustrated as discrete blocks, various blocks of process 1400 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks / sub-blocks of process 1400 may be executed in the order shown in FIG. 14 or, alternatively, in a different order. Furthermore, one or more of the blocks / sub-blocks of process 1400 may be executed repeatedly or iteratively. Process 1400 may be implemented by or in apparatus 1210 and apparatus 1220 as well as any variations thereof. Solely for illustrative purposes and without limiting the scope, process 1400 is described below in the context of apparatus 1210 implemented in or as an AIoT device and apparatus 1220 implemented in or as an AIoT reader of a wireless network such as a mobile network in accordance with one or more of 3GPP standards. Process 1400 may begin at block 1410.

[0086] At 1410, process 1400 may involve processor 1212 of apparatus 1210 determining an availability time of a stored AS ID. Process 1400 may proceed from 1410 to 1420.

[0087] At 1420, process 1400 may involve processor 1212 transmitting, via transceiver 1216, to an AIoT reader (e.g., apparatus 1220) a D2R transmission comprising an indication of the availability time.

[0088] In some implementations, the availability time may be indicated as a time span comprising an idle time sustainable by the AIoT device.

[0089] In some implementations, the availability time may be indicated by an energy indication comprising a representation of a stored energy at the AIoT device. In some implementations, the energy indication may include one or more quantized values indicating one or more operations supported by the stored energy at the AIoT device.

[0090] FIG. 15 illustrates an example process 1500 in accordance with an implementation of the present disclosure. Process 1500 may represent an aspect of implementing various proposed designs, concepts, schemes, systems and methods described above. More specifically, process 1500 may represent an aspect of the proposed concepts and schemes pertaining to identifier management for AIoT devices in wireless communications in accordance with the present disclosure. Process 1500 may include one or more operations, actions, or functions as illustrated by one or more of blocks as well as subblocks. Although illustrated as discrete blocks, various blocks of process 1500 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks / sub-blocks of process 1500 may be executed in the order shown in FIG. 15 or, alternatively, in a different order. Furthermore, one or more of the blocks / sub-blocks of process 1500 may be executed repeatedly or iteratively. Process 1500 may be implemented by or in apparatus 1210 and apparatus 1220 as well as any variations thereof. Solely for illustrative purposes and without limiting the scope, process 1500 is described below in the context of apparatus 1210 implemented in or as an AIoT device and apparatus 1220 implemented in or as an AIoT reader of a wireless network such as a mobile network in accordance with one or more of 3GPP standards. Process 1500 may begin at block 1510.

[0091] At 1510, process 1500 may involve processor 1222 of apparatus 1220 transmitting, via transceiver 1226, to an AIoT device (e.g., apparatus 1210) an assignment of an AS ID. Process 1500 may proceed from 1510 to 1520.

[0092] At 1520, process 1500 may involve processor 1222 receiving, via transceiver 1226, from the AIoT device an indication of an availability time. Process 1500 may proceed from 1520 to 1530.

[0093] At 1530, process 1500 may involve processor 1222 determining a value of a timer based on the indication. Process 1500 may proceed from 1530 to 1540.

[0094] At 1540, process 1500 may involve processor 1222 storing the value of the timer. Process 1500 may proceed from 1540 to 1550.

[0095] At 1550, process 1500 may involve processor 1222 transmitting, via transceiver 1226and prior to expiration of the timer, to the AIoT device a first R2D transmission addressed to the AS ID.

[0096] In some implementations, the indication may include a time span or an energy indication comprising a representation of a stored energy at the AIoT device.

[0097] In some implementations, the energy indication may include one or more quantized values indicating one or more operations supported by the stored energy at the AIoT device.

[0098] In some implementations, process 1500 may further involve processor 1222 transmitting, via transceiver 1226 and subsequent to expiration of the timer, to the AIoT device an AIoT paging message. Additional Notes

[0099] It is understood that the specific order or hierarchy of blocks in the processes  / flowcharts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes  / flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order and are not meant to be limited to the specific order or hierarchy presented.

[0100] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more. ” The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” include any combination of A, B, and / or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module, ” “mechanism, ” “element, ” “device, ” and the like may not be a substitute for the word “means. ” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for.”

Claims

1.A method of identifier management in an ambient Internet of Things (AIoT) system, comprising:generating, by an AIoT device of the AIoT system, a first access stratum (AS) identifier (ID) as part of a random access procedure;storing, by the AIoT device, the first AS ID;receiving, by the AIoT device, from an AIoT reader of the AIoT system a first transmission addressed to the first AS ID, the first transmission comprising an assignment of a second AS ID to the AIoT device;storing, by the AIoT device, the second AS ID; andreceiving, by the AIoT device, from the AIoT reader a second transmission addressed to the second AS ID.2.The method of claim 1, wherein at least one of the first AS ID and the second AS ID is indicated in a destination address field or encoded with a cyclic redundancy check (CRC) value in the first transmission or the second transmission, respectively.3.The method of claim 2, wherein the at least one of the first AS ID and the second AS ID is encoded with the CRC value using an exclusive OR (XOR) operation.4.The method of claim 1, wherein the first transmission comprises a message 2 (Msg2) of an AIoT random access procedure or a subsequent reader-to-device (R2D) transmission following the AIoT random access procedure.5.The method of claim 1, wherein the storing of either or both of the first AS ID and the second AS ID comprises storing at least one of the first AS ID and the second AS ID in a volatile random access memory (VRAM) , non-volatile random access memory (NVRAM) or register.6.The method of claim 1, further comprising:receiving, by the AIoT device, from the AIoT reader a third transmission addressed to the second AS ID and comprising an assignment of a third AS ID to the AIoT device.7.The method of claim 1, further comprising:transmitting, by the AIoT device, to the AIoT reader a fourth transmission comprising an indication of the first AS ID as a source of the fourth transmission.8.The method of claim 7, wherein the first AS ID is indicated in a source address field or encoded with a cyclic redundancy check (CRC) value in the fourth transmission.9.The method of claim 8, wherein the first AS ID is encoded with the CRC value using an exclusive OR (XOR) operation.10.The method of claim 1, further comprising:transmitting, by the AIoT device, to the AIoT reader a fifth transmission comprising an indication of the second AS ID as a source of the fifth transmission.11.The method of claim 10, wherein the second AS ID is indicated in a source address field or encoded with a cyclic redundancy check (CRC) value in the fifth transmission.12.The method of claim 11, wherein the second AS ID is encoded with the CRC value using an exclusive OR (XOR) operation.13.A method of availability indication in an ambient Internet of Things (AIoT) system, comprising:determining, by an AIoT device of the AIoT system, an availability time of a stored access stratum (AS) identifier (ID) ; andtransmitting, by the AIoT device, to an AIoT reader of the AIoT system a device-to-reader (D2R) transmission comprising an indication of the availability time.14.The method of claim 13, wherein the availability time is indicated as a time span comprising an idle time sustainable by the AIoT device.15.The method of claim 13, wherein the availability time is indicated by an energy indication comprising a representation of a stored energy at the AIoT device.16.The method of claim 15, wherein the energy indication comprises one or more quantized values indicating one or more operations supported by the stored energy at the AIoT device.17.A method of identifier management in an ambient Internet of Things (AIoT) system, comprising:transmitting, by an AIoT reader of the AIoT system, to an AIoT device of the AIoT system an assignment of an access stratum (AS) identifier (ID) ;receiving, by the AIoT reader, from the AIoT device an indication of an availability time;determining, by the AIoT reader, a value of a timer based on the indication;storing, by the AIoT reader, the value of the timer; andtransmitting, by the AIoT reader and prior to expiration of the timer, to the AIoT device a first reader-to-device (R2D) transmission addressed to the AS ID.18.The method of claim 17, wherein the indication comprises a time span or an energy indication comprising a representation of a stored energy at the AIoT device.19.The method of claim 18, wherein the energy indication comprises one or more quantized values indicating one or more operations supported by the stored energy at the AIoT device.20.The method of claim 17, further comprising:transmitting, by the AIoT reader and subsequent to expiration of the timer, to the AIoT device an AIoT paging message.

Images