Identifier management for ambient IoT device

Abstract

This disclosure describes methods of assigning, storing, and maintaining access stratum identifiers between an ambient internet of things (AIoT) device and an AIoT reader. The methods include 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 AMBIENT IOT DEVICEFIELD

[0001] This disclosure relates to wireless communications, and specifically to the management of device identifiers by a device and a reader in an ambient internet of things (AIoT) system.BACKGROUND

[0002] An ambient internet of things (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 sixth-generation (6G) system.

[0003] 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-Amode, the device originates a data transmission to the reader without being triggered by prior contact from the reader as in a DO-DTT mode.

[0004] 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.

[0005] This disclosure is directed to methods of assigning, storing, and maintaining 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.SUMMARY

[0006] The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

[0007] 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.

[0008] 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 device-to-reader (D2R) transmission comprising an indication of the availability time.

[0009] 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.

[0010] 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

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

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

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

[0014] 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.

[0015] 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.

[0016] 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.

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

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

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

[0020] 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.

[0021] 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.DETAILED DESCRIPTION

[0022] The detailed description set forth below in connection with the appended drawings  is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

[0023] 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.

[0024] Figure 1 shows a portion of an exemplary AIoT system. The system as shown comprises two devices, which are intended to be low-cost and low-power or even batteryless (for example, powering themselves via energy harvesting) ; a UE-type reader, which communicates over an AIoT interface with the first device and which is embodied in a user equipment (UE) ; a base station (BS) such as a gNode B (gNB) that serves the UE-type reader; a BS-type reader, which communicates over an AIoT interface with the second device and which is embodied in a BS; a controller, which communicates via an application protocol with the readers and which may, for example, be embodied at a node of a 5G core network (CN) ; and an application function (AF) , which communicates application data to the devices and which may be embodied at a node of a 5G CN (5GC) . In some embodiments, one or more additional nodes such as an AIoT-enabled AMF, an AIoTF, and so on may be present. The AIoT interface is assumed to be consistent between the two types of readers, and in some embodiments a device may be unaware of whether it communicates with a UE-type reader or a BS-type reader. The logical interface between the controller and the readers is labelled A-RC ( “AIoT reader-controller” ) in the figure, and the logical interface between the controller and the application function is labelled A-CA ( “AIoT controller-application” ) in the figure, but it should be understood that these interfaces may be realised over various forms of available transport in the system, and that they may or may not be considered as independently defined interfaces.

[0025] Figure 2 shows an exemplary set of protocol stacks for the interfaces of an AIoT system similar to that shown in figure 1. The device and the reader communicate on an AIoT interface via an AIoT physical (PHY) layer and an AIoT medium access control (MAC) layer. The reader and the controller communicate via a reader application protocol (R-AP) on a logical  A-RC interface, supported by a network protocol stack whose details 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 the UE hosting the reader. The controller and the AF communicate via an AIoT application programming interface (API) over a logical A-CA interface, supported by a service-based interface (SBI) protocol stack whose details 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, comprise 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 this 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 between the AF and the device.

[0026] Figure 3 shows an exemplary message flow for communication of data in both the D2R and R2D directions on an AIoT interface. In step 1, the reader sends to the device a first R2D message, which may be referred to as an AIoT paging message, and which serves to locate the device and trigger a response. Steps 2 through 4 comprise a random access procedure, which may be a 2-step or a 3-step procedure (step 4 is 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, and 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) concludes 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.

[0027] For several steps in the procedure of figure 3, it is 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 reader-to-device (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 device-to-reader (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 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: An International Mobile Station Identifier (IMSI) is a substantially permanent identifier of a user equipment (UE) that is rarely used over the air because of its size and security concerns (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 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.

[0028] Figure 4 shows an exemplary message flow similar to figure 3, but with the addition of identifier and scheduling information, and specialized to the case where an AS ID is assigned in Msg2. In step 1, the reader sends to the 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, Msg2 contains 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.

[0029] Figure 5 shows an exemplary message flow similar to figure 4, but where the AS ID is assigned in step 5 instead of in step 3. Steps 1 and 2 are the same as in figure 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 should be noted that, in both figures 4 and 5, the device only needs to remember one scheduling identifier at a time; in figure 4, the scheduling identifier is RN16 from step 2 to step 3 only and the AS ID thereafter, and in figure 5, the scheduling identifier is RN16 from step 2 to step 5 and the 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.

[0030] Figure 6 shows an exemplary message flow based on the procedure of figure 4, with the addition of the management of ID values at the device, in accordance with an embodiment of  this invention. For purposes of this figure, the terminology “AS ID” refers to a specific storage location in the device (we will discuss below 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, the figure distinguishes between assignment of a value (asingle equal sign, “=” ) and comparison of values (adouble equal sign, “==” ) . In step 1 of figure 6, the reader sends to the 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 signalling 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 (i.e., an identity of the device) , it would be expected that Msg3 is indicated as coming from the device identified by New_ID; however, 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  it 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 it 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.

[0031] 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 figure 5. In such a case, a procedure similar to figure 6 applies, but the New_ID is not stored until after it is received in the subsequent R2D transmission (step 5 of figure 5) . The procedure is otherwise substantially unchanged; 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.

[0032] Figure 7 shows two possible formats for an R2D transmission, in accordance with an embodiment of this invention. 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 transmission comprises a destination address, a section of physical-layer information (labelled “Other PHY data” in the figure) , a payload comprising data to be interpreted by the receiving device, and a cyclic redundancy check (CRC) value. The destination address may comprise an AS ID (in the broader sense of this disclosure, i.e., an identifier assigned and managed in the access stratum, rather than the narrower sense used in the description of figure 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 comprise,  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, and according to well-known methods, the CRC may be used by the receiver (in this case the device) to confirm accurate reception of the message. The second format is substantially similar to the first, except that there is no separate field for the destination address. Instead, the transmission comprises 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 the figure 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 the figure may be present, such as fields required for MAC layer transmission management, segmentation, acknowledgement, and so on.

[0033] Figure 8 shows two possible formats for a D2R transmission, in accordance with an embodiment of this invention. The formats are substantially similar to the R2D formats in figure 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 figure 7 apply to the analogous fields in figure 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 figure 7, the information sent by the device in the D2R direction may include an energy indication, which will be further described below.

[0034] Figure 9 shows an exemplary range of storage mechanisms for an AS ID at a device, in accordance with an embodiment of this invention. The figure 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 figure 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.

[0035] Figure 10 shows a message flow for 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 and in accordance with an embodiment of this invention. The availability time is a time for which the device expects (or guarantees) that it will remain powered and retain stored volatile data, which may include a stored AS ID. The figure 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 measure 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 measure, such as an estimate of remaining energy at the device (this possibility will be 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 (i.e., the amount of time 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 figure 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 DO-DTT mode of operation, the reader may not be permitted to send a D2R transmission unless the reader has previously requested such a transmission, while in a DO-Amode of operation, the reader may be able to initiate an autonomous D2R transmission. )

[0036] Figure 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. In step 1, the reader assigns to the 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 figure 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, and in step 8, since the availability time has expired, the reader starts a new paging operation to establish contact with the device. As in figure 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 figure 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 figure 10) , using the AS ID as an identifier of the device.

[0037] Status after RAN2#127bis. RAN2 reached a set of conclusions about the AS ID in RAN2#127bis:

[0038] Agreements on AS ID

[0039] RAN2 assumes that if “AS ID” is defined it is used at least for purpose of D2R scheduling and R2D reception. Up to RAN1 to decide whether a “AS ID” is defined.

[0040] RAN2 assumes this “AS ID” should be a short AS layer ID, rather than the full upper layer device ID. FFS on the length. FFS if AS ID can be based on partial upper layer device ID.

[0041] From RAN2 perspective, following options are possible for “AS ID” :

[0042] Option 1: a random ID if used in Msg1 can be reused;

[0043] Option 2: reader assigns this “AS ID” . FFS via which R2D message.

[0044] RAN2 will aim to define one common design for all RA procedures (if technically possible)

[0045] We understand that the RAN1 status is that such an ID will be used for D2R scheduling and R2D reception, and it may be possible to strengthen the second bullet as follows.

[0046] Proposal 1: From RAN2 perspective, take as a conclusion of the SI that any ID used for D2R scheduling and R2D reception (with the exception of paging) should be a short ID assigned in AS layers. The definition of “short” can be determined in normative work.

[0047] The rationale here is that RAN1 are likely to conclude formally that an ID is used, but it is not in RAN1 remit to determine what that ID is, and there should be clear guidance for normative work to avoid repeating discussions. We consider it obvious that a permanent ID long enough to be globally unique cannot be used for scheduling in a practical way (especially if RAN1 use an implicit mechanism like masking the CRC, where the permanent ID must be far larger than any practical CRC size) .

[0048] Of the two options suggested in the third bullet, as indicated in [1] , we prefer option 2 (assignment by the reader) . In case the AS ID is used over several successive transmissions (e.g., segments of a large write command, or a succession of commands for the same device) , the possibility of collision between two devices’ RN16 values grows continuously, and in such a situation the advantage of coordinated assignment by the reader cannot really be contested. We understand that the main related questions are (1) whether continuing use of the AS ID is a valid use case, and (2) whether there is a complexity burden to the device in storing an assigned identifier.  We address these issues in the following section.

[0049] ID assignment by the reader

[0050] The protocol aspects of ID assignment by the reader are not complex: Some R2D message (Msg2 and / or a subsequent message in the R2D direction) contains an ID assignment, most likely in a format similar to a MAC CE. For the device implementation, perhaps the most important concern for avoiding complexity is that the device should never have two AS IDs at the same time; it should be able to recognise a transmission addressed to it in a completely automatic way, by extracting the ID from PHY and matching it against a specific piece of stored information.

[0051] Proposal 2: The device should never be required to store more than one AS ID at a time.

[0052] Figure 6 shows a simple procedure for ID management using a single storage location. This example shows the assignment of an AS ID taking place in Msg2, but it should also be possible to use RN16 throughout the access procedure and have a reader-assigned ID in a subsequent R2D transmission (the equivalent of step 8) .

[0053] In the left-hand column, “AS ID” refers to a particular storage location in the device-depending on implementation, the ID could be stored in RAM, NVRAM, a register, etc., but the point is that the location used for steps 3 / 5 / 6 / 9 should be unitary. (Note that these steps use the C syntax convention of “=” for assignment and “==” for comparison. ) If needed, later R2D transmissions could rewrite the AS ID with a new value in the same manner as step 4.

[0054] Observation 1: The implementation burden on the device of maintaining a single AS ID, with the ability for the reader to reassign it, is minimal.

[0055] Regarding the validity of multiple transmissions to the same device, the most obvious use case is a large command that requires multiple MAC transmissions, irrespective of where segmentation takes place-i.e., the command may be broken into multiple upper-layer messages or segmented in MAC, but either way results in a series of MAC-level R2D transmissions for the same command. Writing a large block (afirmware update, for example) may not be practical in a single TB, even in good radio conditions and with ample device energy.

[0056] Similarly, a large read command like a log file or sensor readings may require multiple D2R transmissions, each of which needs to be scheduled and / or acknowledged by a corresponding R2D transmission.

[0057] Observation 2: Within the “command” use case, operations can be envisaged that would require multiple R2D / D2R exchanges between the reader and the device.

[0058] It seems clear that such multiple exchanges should not require paging and access for the same device over and over. As long as any PHY conditions for communication are met (e.g., timing for D2R transmissions) and the AS ID is valid, the device should be able to receive an R2D  transmission and respond without going through access.

[0059] Observation 3: In case of multiple R2D / D2R exchanges between reader and device, there is no clear reason to repeat the paging / access process for each exchange.

[0060] Considering proposal 1 and observations 2 and 3, it follows that it should be possible to address the same device repeatedly using an AS ID and that the “usability period” of a device’s AS ID is somewhat unpredictable. Accordingly, it makes sense to minimize the risk of collision by allowing the reader to assign an AS ID as shown in figure 1 above.

[0061] Proposal 3: Support repeated addressing of the device using an AS ID assigned by the reader, without repeating the paging and access procedures.

[0062] Validity of a stored ID and energy indication

[0063] Proposal 3 requires consideration of the expected validity period of an assigned AS ID. The reader should only use a previously assigned AS ID for a device if it has high confidence that the device has not “forgotten” the ID. If the ID is stored in NVRAM, the device’s memory should not be a problem, and we understand that this may be feasible for implementations. (Writing to NVRAM should be infrequent, but reading from NVRAM should be less expensive and might be expected to be feasible at the time granularity of R2D scheduling. ) However, it may not be reasonable to specify that all devices store the AS ID in NVRAM and remember it indefinitely, so a mechanism for determining the validity of a stored ID would be useful.

[0064] This problem may be addressable by piggybacking on an energy indication from the device. When the device makes a D2R transmission, if it includes some indication of its future availability time, the reader should be able to assume that the current AS ID (whether it is inherited from RN16 or assigned by the reader) is valid for that availability time.

[0065] Proposal 4: The stored AS ID at the device may be assumed valid for the availability time implied by the device’s energy status indication.

[0066] Some devices may have limited ability to predict their availability time, and such devices should be conservative in their energy indications (this is a more general issue than just the ID validity, as the reader needs to know when it can address a transmission to the device) . The general principle as we understand it is that the device should indicate a confident lower bound on the availability time; if the device can stay awake longer, that may be possible to indicate in a later D2R transmission, but if the device falls asleep early it will miss transmissions and lose its stored ID.

[0067] Proposal 5: The energy status indication should have sufficient granularity to imply a high-confidence lower bound on the device’s availability time.

[0068] Proposal 5 is not strictly incompatible with the decision of RAN2#127bis to capture (the option of) a 1-bit indication. However, a 1-bit indication would mean that a fixed availability  time must be specified; the device could either indicate “going to sleep immediately” (implying inability to perform any immediately following operation) or “awake for the expected availability time” . The details of the energy indication can be further discussed in normative work, but we suggest that the possibility of using a finer-grained indication to reflect the availability time should also be captured in the TR.

[0069] Proposal 6: Capture in the TR the possibility of inferring an availability time from the device’s energy indication, which might require more than 1 bit for the indication.

[0070] It follows from the proposals above that a device that does not support an energy status indication cannot usefully store an AS ID (even RN16) . Such a device might be able to perform the paging / access procedure for inventory only, and nothing else, which could be appropriate for a simple inventory tag that cannot accept any command (even “disable” ) . It can be discussed in normative work if the system caters to such devices.

[0071] Proposal 7: Discuss in normative work if the system supports devices that do not send an energy status indication and do not store an AS ID beyond the access procedure.

[0072] 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.

[0073] 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 operable at an ambient internet of things (AIoT) device, comprising:generating, by the device, a first access stratum (AS) identifier (ID) [RN16] as part of a random access procedure;storing the first AS ID;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] ;storing the second AS ID; andreceiving, 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 at least one of the first transmission and the second transmission in a destination address field.3.The method of claim 1, wherein at least one of the first AS ID and the second AS ID is indicated in at least one of the first transmission and the second transmission by encoding with an operation together with a cyclic redundancy check (CRC) value.4.The method of claim 3, wherein the operation is an exclusive OR (XOR) operation.5.The method of claim 1, further comprising receiving, from the AIoT reader, a third transmission addressed to the second AS ID and comprising an assignment of a third AS ID.6.The method of claim 1, wherein the first transmission is a Msg2 of an AIoT random access procedure.7.The method of claim 1, wherein the first transmission is a subsequent reader-to-device (R2D) transmission following an AIoT random access procedure.8.The method of claim 1, wherein the first AS ID is randomly generated by the AIoT device.9.The method of claim 1, further comprising transmitting, to the AIoT reader, a fourth transmission comprising an indication of the first AS ID as the source of the fourth transmission.10.The method of claim 9, wherein the first AS ID is indicated in a source address field.11.The method of claim 9, wherein the first AS ID is indicated by encoding with an operation together with a CRC value.12.The method of claim 11, wherein the operation is an XOR operation.13.The method of claim 1, further comprising transmitting, to the AIoT reader, a fifth transmission comprising an indication of the second AS ID as the source of the fifth transmission.14.The method of claim 13, wherein the second AS ID is indicated in a source address field.15.The method of claim 13, wherein the second AS ID is indicated by encoding with an operation together with a CRC value.16.The method of claim 15, wherein the operation is an XOR operation.17.The method of claim 1, wherein the storing steps comprise storing in a volatile random access memory (RAM) location.18.The method of claim 1, wherein the storing steps comprise storing in a non-volatile random access memory (NVRAM) location.19.The method of claim 1, wherein the storing steps comprise storing in a register.20.A method of indicating an availability time of a stored AS ID, operable at an AIoT device and comprising sending, to an AIoT reader, a D2R transmission comprising an indication of the availability time.21.The method of claim 20, wherein the availability time is indicated as a time span.22.The method of claim 21, wherein the time span comprises an idle time sustainable by the AIoT device.23.The method of claim 20, wherein the availability time is indicated by an energy indication.24.The method of claim 23, wherein the energy indication comprises a measure of stored energy at the AIoT device.25.The method of claim 23, wherein the energy indication comprises one or more quantized values indicating one or more operations that can be supported by the AIoT device’s stored energy.26.A method of managing an AS ID for an AIoT device, operable at an AIoT reader and comprising:transmitting, to the AIoT device, an assignment of the AS ID;receiving, from the AIoT device, an indication of an availability time;determining, from the indication, a value of a timer; andstarting the timer.27.The method of claim 26, further comprising sending, to the AIoT device prior to the expiration of the timer, a first R2D transmission addressed to the AS ID.28.The method of claim 26, further comprising sending to the AIoT device subsequent to the expiration of the timer, an AIoT paging message.29.The method of claim 26, wherein the indication comprises a time span.30.The method of claim 26, wherein the indication comprises an energy indication.31.The method of claim 30, wherein the energy indication comprises a measure of stored energy at the AIoT device.32.The method of claim 30, wherein the energy indication comprises a quantized value indicating one or more operations that can be supported by the AIoT device’s stored energy.

Images