Ambient internet of things (a-IOT) device id management

Abstract

Example embodiments of the present disclosure relate to Ambient Internet of Things (A-IoT) device ID management. According to example embodiments, a system may include an A-IoT reader that may be configured to determine a Device-to-Reader (D2R) transmission failure. Accordingly, the A-IoT device may determine whether a retransmission of a device identifier (ID) associated with an A-IoT device is required. Accordingly, based on determining that the retransmission of the device ID is not required, the A-IoT device may provide, to the A-IoT device and during a Reader-to-Device (R2D) transmission, a first R2D message indicating that the device ID can be reused. On the other hand, based on determining that the retransmission of the device ID is required, the A-IoT reader may provide, to the A-IoT device and during the R2D transmission, a second R2D message that requests the A-IoT device to retransmit the device ID during a next D2R transmission.

Description

AMBIENT INTERNET OF THINGS (A-IOT) DEVICE ID MANAGEMENTCROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. provisional application No. 63 / 703068, filed with the U.S. Patent and Trademark Office on October 3, 2024, the entire contents of which are incorporated herein by reference.TECHNICAL FIELD

[0002] The present disclosure relates to Ambient Internet of Things (A-IoT) device identifier (ID) management.BACKGROUND

[0003] The information disclosed in this background section is only for the enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgment or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0004] Ambient Internet of Things (A-loT) refer to technology in which devices may harvest energy from the ambient environment (e g., radio waves, light, heat, etc.), thereby enabling said devices to operate with low-power consumption without having a dedicated power source and reducing the complexity and form factor of said devices. As further described below, various types of devices, such as A-IoT readers and A-IoT devices, may be involved in an A-IoT-based network.

[0005] An A-IoT reader may communicate with an A-IoT device via a Reader-to-Device (R2D) transmission, while the A-IoT device may communicate with the A-IoT reader via a Device-to-Reader (D2R) transmission. During the D2R transmission, the A-IoT device may provide a device identifier (ID) to the A-IoT reader via one or more D2R messages, thereby enabling the A- loT reader to identify the A-IoT device and distinguish the A-IoT device from other devices that are communicating with the A-IoT reader.SUMMARY

[0006] Example embodiments of the present disclosure provide systems, methods, and the like, that effectively and efficiently implement A-IoT device ID management.

[0007] According to example embodiments, a system may include an A-IoT reader, and the A-IoT reader may be configured to determine a D2R transmission failure. Accordingly, the A- loT device may determine whether a retransmission of a device ID associated with an A-IoT device is required. Accordingly, based on determining that the retransmission of the device ID is not required, the A-IoT device may provide, to the A-IoT device and during an R2D transmission, a first R2D message indicating that the device ID can be reused. On the other hand, based on determining that the retransmission of the device ID is required, the A-IoT reader may provide, to the A-IoT device and during the R2D transmission, a second R2D message that requests the A- loT device to retransmit the device ID during a next D2R transmission.

[0008] According to example embodiments, a method may be performable by an A-IoT reader and may include determining, by an A-IoT reader, a D2R transmission failure. Further, the method may include determining, by the A-IoT reader and based on determining the D2R transmission failure, whether a retransmission of a device ID associated with an A-IoT device is required. Accordingly, the method may include based on determining that the retransmission of the device ID is not required, providing, by the A-IoT reader and to the A-IoT device during anR2D transmission, a first R2D message indicating that the device ID can be reused, and based on determining that the retransmission of the device ID is required, providing, by the A-IoT reader and to the A-IoT device during the R2D transmission, a second R2D message that requests the A- loT device to retransmit the device ID during a next D2R transmission.

[0009] According to example embodiments, a non-transitory computer-readable recording medium may have recorded thereon instructions executable by an A-IoT reader to cause the A- loT reader to perform a method. The method may include determining, by an A-IoT reader, a D2R transmission failure. Further, the method may include determining, by the A-IoT reader and based on determining the D2R transmission failure, whether a retransmission of a device ID associated with an A-IoT device is required. Accordingly, the method may include based on determining that the retransmission of the device ID is not required, providing, by the A-IoT reader and to the A- loT device during an R2D transmission, a first R2D message indicating that the device ID can be reused, and based on determining that the retransmission of the device ID is required, providing, by the A-IoT reader and to the A-IoT device during the R2D transmission, a second R2D message that requests the A-IoT device to retransmit the device ID during a next D2R transmission.

[0010] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0012] FIG. 1 illustrates a generic system configuration, according to one or more example embodiments;

[0013] FIG. 2A to FIG. 2D each illustrates an example connectivity topology, according to one or more example embodiments;

[0014] FIG. 3 and FIG. 4 illustrate various example methods and operations, according to one or more example embodiments;

[0015] FIG. 5 illustrates an example device / apparatus that may implement one or more example embodiments; and

[0016] FIG. 6 illustrates an example environment in which systems, devices, and / or methods, according to one or more example embodiments, may be implemented.DETAILED DESCRIPTION

[0017] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to one of the various embodiments. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part).

[0018] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the described implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0019] Even though particular combinations of features are disclosed in the claims and / or in the specification, these combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

[0020] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B]”, “[A] and / or [B]”, or “at least one of [A] or [B]”, are to be understood as including only A, only B, or both A and B.

[0021] Expressions such as “at least one processor,” where configured to implement a plurality of operations, execute a plurality of instructions, etc., are to be understood as a singleprocessor implementing the plurality of operations, etc., or each of plural processors implementing at least some (but not necessarily all) of the plurality of operations, etc.

[0022] Reference throughout this specification to “one embodiment,” “embodiment,” “non-limiting exemplary embodiment,” “example embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present solution. Thus, the phrases “in one embodiment”, “in an embodiment,” “in one non-limiting exemplary embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0023] Further, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more example embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the present disclosure can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0024] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the Open Radio Access Network (0-RAN) Alliance, the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, and the like. For instance, the terms “A-IoT,” “A-IoT reader,” “A-IoT device,” “device ID,” “R2D transmission,” “D2R transmission,” “R2D message,” “D2R message,” “inventory session,” “IE,” “CE,” and the like, as well as the associated features, operations,interfaces, and messages involved therein, are to be interpreted as consistent with those specified in one or more technical specifications, unless being described otherwise.

[0025] Generally, Ambient Internet of Things (A-IoT) may involve at least two types of devices, i.e., A-IoT devices and A-IoT readers. An A-IoT device may refer to a device that may harvest energy from the ambient environment (e.g., radio waves, light, heat, etc.), thereby operating with low-power consumption without having a dedicated power source and reducing the complexity and form factor thereof. On the other hand, an A-IoT reader may refer to a device that may interact with the A-IoT devices, receive data from the A-IoT devices, and allocate resources for uplink Device-to-Reader (D2R) transmissions and downlink Reader-to-Device (R2D) transmissions.

[0026] An A-IoT reader may communicate with an A-IoT device via the R2D transmissions, while the A-IoT device may communicate with the A-IoT reader via the D2R transmissions. For instance, the A-IoT reader may periodically (or continuously) perform an inventory operation (e.g., broadcasting one or more paging messages / inventory pollings, etc.) via the R2D transmissions, to thereby discover the A-IoT device(s) that are presented around the A- loT reader. In response to the inventory operation, the A-IoT device(s) may provide one or more inventory responses (e.g., provide one or more D2R messages such as a random access preamble / Msgl, etc.) to the A-IoT reader.

[0027] During the D2R transmissions (e.g., in the inventory response), the A-IoT device may provide a device identifier (ID) to the A-IoT reader via one or more D2R messages. The device ID serves as a key parameter for efficient and effective communication between the A-IoT reader and the A-IoT device, since the device ID may be utilized by the A-IoT reader to identify the A-IoT device and distinguish the A-IoT device from other devices that are communicating withthe A-IoT reader. In this regard, the related art lacks mechanisms or protocols that may efficiently and effectively manage the device ID of the A-IoT device, particularly when a D2R transmission failure occurs (e.g., failure during an inventory response, etc.).

[0028] Specifically, without clear mechanisms or protocols, when a D2R transmission failure occurs, it is unclear whether the A-IoT reader should request the A-IoT device to retransmit the associated device ID during the next D2R transmission, or whether the device ID has been successfully received in the past and can be reused by the A-IoT reader. As a result, unnecessary retransmissions of the device ID could introduce additional signaling overhead, while failing to retransmit the device ID when the device ID was not successfully received or cannot be reused could lead to misidentification and errors in subsequent communications and transmissions.

[0029] Example embodiments of the present disclosure, as described in the following, provide devices, systems, methods, and the like, that effectively and efficiently provide A-IoT device ID management, particularly when a D2R transmission failure occurs (e.g., during an inventory response, etc ). Specifically, example embodiments implement an A-IoT reader that may be configured to automatically determine a D2R transmission failure, and then determine whether a retransmission of a device ID associated with an A-IoT device is required when the D2R transmission failure is determined. Accordingly, the A-IoT reader may appropriately communicate with the A-IoT device to request the A-IoT device to retransmit the device ID (when the retransmission of the device ID is required) or to inform the A-IoT device that the previously provided device ID can be reused (i.e., the retransmission of the device ID is not required).

[0030] Advantageously, by implementing example embodiments, the A-IoT reader may trigger conditional retransmission, i.e., reusing a device ID that is successfully received in the past and not part of the D2R transmission failure thereby reducing unnecessary signaling overhead,while ensuring that the retransmission of the device ID is initiated when needed thereby reducing the risk of misidentification and errors in future communications and transmissions. Ultimately, example embodiments may appropriately manage the device ID of an A-IoT device, thereby optimizing the network performance.

[0031] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions of the features, components, configuration, operations, and implementations of the example embodiments of the present disclosure are provided in the following.Example System Architecture and Configurations

[0032] FIG. 1 illustrates a generic system configuration 100, according to one or more example embodiments. As illustrated in FIG. 1, the system configuration 100 includes an Ambient Internet of Things (A-IoT) reader 110 and an A-IoT device 120. The A-IoT reader 110 and the A- loT device 120 may communicatively couple to each other. It is contemplated that the configuration in FIG. 1 is merely an example provided for descriptive purposes, and the scope of the present disclosure is not limited thereto. For instance, in some example implementations, the A-IoT reader 110 may communicatively couple to multiple A-IoT devices, an A-IoT device 120 may communicatively couple to multiple A-IoT readers, and the like, without departing from the scope of the present disclosure.

[0033] The A-IoT reader 110 may refer to any suitable devices that may detect the A-IoT device 120, provide the carrier waves (e.g., for backscatter, etc.) to the A-IoT device 120, allocate uplink and / or downlink resources to the A-IoT device 120, and manage the transmissions and communications (e.g., Device-to-Reader (D2R) transmissions, Reader-to-Device (R2D)transmissions, etc.) with the A-IoT device 120. According to example embodiments, the A-IoT reader 110 may include at least one of: abase station (e.g., eNodeB, gNodeB, etc.), an intermediate or assisting node (e.g., a relay, an Integrated Access and Backhaul (IAB) node, a repeater, etc.), or a User Equipment (UE) (e g., a mobile phone, a computing device, etc. that uses the full transceiver and protocol stacks to communicate with an A-IoT device, etc ).

[0034] The A-IoT device 120 may refer to a low-power, low-complexity device that may harvest energy from the ambient environment, eliminating the need for a dedicated power source or battery replacement. For instance, the A-IoT device 120 may utilize ambient energy sources like radio waves, light, heat, or motion to power the associated operations. The A-IoT device 120 may implement low-end loT applications (e.g., inventory management, simple command, etc.) that may be implemented with an ultra-low complexity device with ultra-low power consumption and / or a small form factor. According to example embodiments, the A-IoT device may include at least one of: a Radio Frequency (RF) tag (e.g., a Near Field Communication (NFC) tag, an RF Identification (RFID) tag, a backscatter tag, etc.), a sensor (e.g., motion sensor, light sensor, environmental sensor, etc.), or a UE (e.g., a wearable device, a healthcare tracker, etc., that operates in low power mode).

[0035] According to example embodiments, the A-IoT reader 110 may be configured to periodically (or continuously) perform an inventory operation (e.g., broadcasting one or more paging messages / inventory polling that include the random access-related parameters such as access occasion, etc.) to the nearby A-IoT devices (e.g., for descriptive purposes, it may be assumed that A-IoT device 120 is located near the A-IoT reader 110). On the other hand, the A- loT device 120 may harvest energy from the ambient environment / energy sources (e.g., harvesting RF energy from the downlink signals broadcast by the A-IoT reader 110 during performing theinventory operation, etc.). Upon harvesting sufficient energy, the A-IoT device 120 may wake up and trigger a random access procedure to attempt access to the A-IoT reader 110 when applicable.

[0036] In this regard, the “random access procedure” described herein may refer to a contention-based random access process that enables the A-IoT reader 110 to interoperate with the A-IoT device 120 to establish uplink synchronization. The random access procedure may be similar to the random access channel (RACH) procedure as defined in one or more technical specifications of 3GPP. In this regard, in the first step of the random access procedure, the A-IoT device 120 may transmit a random access preamble (i.e., a first message in the random access procedure and thus may be referred to as “Msgl”) to the A-IoT reader 110, in response to the paging message / message polling from the A-IoT reader 110 during the inventory operation. Thus, the transmission of the random access preamble (Msgl) may also be considered as the inventory response. Upon receiving the random access preamble (Msgl), the A-IoT reader 110 may reply with a random access response (i.e., a second message in the random access procedure and thus may be referred to as “Msg2”) that contains the granted resources (e.g., timing advance, uplink grant, etc.). Accordingly, the A-IoT device 120 may then send a Radio Resource Control (RRC) message (e.g., RRC connection request, etc.) (i.e., a third message in the random access procedure and thus may be referred to as “Msg3”) to the A-IoT reader 110 based on the granted resources, and the A-IoT reader 110 may send another RRC message (e.g., RRC connection setup, etc.) (i.e., a fourth message in the random access procedure and thus may be referred to as “Msg4”) to the A-IoT device 120.

[0037] Upon completing the random access procedure, the A-IoT device 120 may enter the RRC CONNECTED state, where dedicated uplink and / or downlink resources are allocated to the A-IoT device 120 for further communications and transmissions. For instance, inRRC CONNECTED state, the A-IoT device 120 may use the allocated uplink resources to transmit data (e.g., sensor data, status report, etc.) to the A-IoT reader 110. On the other hand, the A-IoT reader 110 may transmit data (e.g., control commands, configuration updates, etc.) to the A-IoT device via the allocated downlink resources.

[0038] The communications and data transmissions from the A-IoT reader 110 to the A- loT device 120 (e.g., paging message broadcastings, Msg2 / Msg4 transmissions, downlink data transmissions via the allocated downlink resources, etc.) may be collectively referred to as the “R2D transmissions”, while the communications and data transmissions from the A-IoT device 120 to the A-IoT reader 110 (e.g., Msgl / Msg3 transmissions, uplink data transmissions via the allocated uplink resources, etc.) may be collectively referred to as the “D2R transmissions”. In this regard, although some example embodiments may be described herein with reference to the D2R transmission failure during the inventory response, it is contemplated that the example embodiments may be similarly applicable to any other D2R transmission failures that may involve the device ID, such as D2R transmission failure during the Msg3 transmissions and / or uplink data transmissions via the allocated uplink resources, without departing from the scope of the present disclosure.

[0039] According to example embodiments, the A-IoT reader 110 may interoperate with the A-IoT device 120 to manage a device ID of the A-IoT device 120. Various example operations (that may be implemented by the A-IoT reader 110 to manage the device ID of the A-IoT device120 when required) are described below with reference to FIG. 3. In this regard, the device ID may include any suitable types of parameters that enable the A-IoT reader 110 to identify and distinguish the A-IoT device 120 from other devices. By way of example, the device ID mayinclude an Electronic Product Code (EPC), a Cell-RNTI (C-RNTI), a Radio Frequency Identification (RFID) tag, a Media Access Control (MAC) address, and the like.

[0040] Generally, the A-IoT reader 110 may be configured to determine a D2R transmission failure. Based on determining the D2R transmission failure, the A-IoT reader 110 may be configured to determine whether a retransmission of a device ID associated with the A- loT device 120 is required. Various example operations (that may be implemented by the A-IoT reader 110 to determine whether the retransmission of the device ID is required) are described below with reference to FIG. 4. Accordingly, based on determining that the retransmission of the device ID is not required, the A-IoT reader 110 may provide a first R2D message (that indicates that the device ID can be reused) to the A-IoT device, during an R2D transmission (e.g., the R2D transmission subsequent to the failed D2R transmission). On the other hand, based on determining that the retransmission of the device ID is required, the A-IoT reader 110 may provide a second R2D message (that requests the A-IoT device to retransmit the device ID during a next D2R transmission) to the A-IoT device, during an R2D transmission (e g., the R2D transmission subsequent to the failed D2R transmission).

[0041] Further, example embodiments of the present disclosure may be implemented by the A-IoT reader 110 and / or the A-IoT device 120 in various scenarios. For example, the A-IoT reader 110 and / or the A-IoT device 120 may implement the example embodiments for managing A-IoT device ID (e.g., device ID of the A-IoT device 120, etc.) when a D2R transmission failure occurs during the inventory response, when a D2R transmission failure occurs during the Msg3 transmission, and / or when a D2R transmission failure occurs during the uplink data transmissions via the allocated uplink resources.

[0042] In addition, the A-IoT reader 110 and / or the A-IoT device 120 may be deployed in various locations, such as indoors, outdoors, or a combination thereof. Further, the A-IoT reader 110 and / or the A-IoT device 120 may be deployed on the same sites as an existing 3GPP deployment (e g., macro-cell-based deployment, micro-cell-based deployment, pico-cell-based deployment, etc ). Furthermore, the A-IoT reader 110 and / or the A-IoT device 120 may be deployed according to various connectivity topologies. Descriptions of several examples of connectivity topologies are provided below with reference to FIG. 2A to FIG. 2D.

[0043] FIG. 2A illustrates a first example connectivity topology 210, according to one or more example embodiments. In this example connectivity topology, a UE 211 is utilized as an example of the A-IoT reader 110. As illustrated in FIG. 2A, the A-IoT device 212 may communicate bidirectionally with the UE 211. The communication between the UE 211 and the A-IoT device 212 may include the transmission of user-plane A-IoT data and / or control-plane signaling

[0044] FIG. 2B illustrates a second example connectivity topology 220, according to one or more example embodiments. In this example connectivity topology, a base station 221 is utilized as an example of the A-IoT reader 110. As illustrated in FIG. 2B, the A-IoT device 222 may communicate directly and bidirectionally with the base station 221. The communication between the base station 221 and the A-IoT device 222 may include the transmission of user-plane A-IoT data and / or control-plane signaling. Further, this example connectivity topology may include a scenario in which the base station 221 is different from a base station that is receiving data from the A-IoT device 222.

[0045] FIG. 2C illustrates a third example connectivity topology 230, according to one or more example embodiments. In this example connectivity topology, a base station 231 and anintermediate network node 233 are utilized as an example of the A-IoT reader 110. As illustrated in FIG. 2C, the A-IoT device 232 may communicate bidirectionally with the intermediate network node 233 (e.g., a relay, an IAB node, a UE, a repeater, etc.) that may transfer user-plane A-IoT data and / or control-plane signaling between the base station 231 and the A-IoT device 232.

[0046] FIG. 2D illustrates a fourth example connectivity topology 240, according to one or more example embodiments. In this example connectivity topology, a base station 241 and an assisting network node 243 are utilized as an example of the A-IoT reader 110. As illustrated in FIG. 2D, the A-IoT device 242 may transmit data / signaling to the base station 241, and may receive data / signaling from the assisting network node 243. Additionally or alternatively, the A- loT device 242 may receive data / signaling from the base station 241, and may transmit data / signaling to the assisting network node 243. The assisting network node 243 may include a realy, an IAB node, a UE, a repeater, and the like, which is capable of receiving data from the A- loT device 242 and transmitting the data to the base station 241, and / or receiving data from the base station 241 and transmitting the data to the A-IoT device 242.

[0047] It is contemplated that any of the A-IoT readers (e.g., UE 211, base stations 221- 241, intermediate network node 233, assisting network node 243, etc.) in FIG. 2A to FIG. 2D may be configured to manage the device ID of the A-IoT device in a similar manner as described above with reference to FIG. 1. Further, it can be understood that the connectivity topologies in FIG. 2A to FIG. 2D are merely examples, and the scope of the present disclosure should not be limited thereto.

[0048] In view of the above, example embodiments of the present disclosure clarify and exemplify various system configurations and topologies for implementing A-IoT device ID management. Specifically, example embodiments implement a system that includes an A-IoTreader that may be configured and implemented according to various system configurations and connectivity topologies, as exemplified in FIG. 1 to FIG. 2D. The A-IoT reader may be configured to automatically and dynamically determine a D2R transmission failure, and then determine whether a retransmission of a device ID associated with an A-IoT device is required when the D2R transmission failure is determined. Accordingly, the A-IoT reader may appropriately communicate with the A-IoT device to request the A-IoT device to retransmit the device ID (when the retransmission of the device ID is required) or to inform the A-IoT device that the previously provided device ID can be reused in subsequent operations or communications (when the retransmission of the device ID is not required).

[0049] Advantageously, by implementing example embodiments, the A-IoT reader may trigger conditional retransmission, i.e., reusing a device ID that is successfully received in the past and not part of the D2R transmission failure thereby reducing unnecessary signaling overhead, while ensuring that the retransmission of the device ID is initiated when needed thereby reducing the risk of misidentification and errors in future communications and transmissions. Ultimately, example embodiments may appropriately manage the device ID of an A-IoT device, thereby optimizing the network performance.

[0050] Further descriptions of example methods and operations of example embodiments are provided below with reference to FIG. 3 and FIG. 4, and the descriptions of an example device and an example environment for implementing one or more example embodiments are provided below with reference to FIG. 5 to FIG. 6, respectively.Example Methods and Operations

[0051] As described above with reference to FIG. 1 to FIG. 2D, the A-IoT reader may perform one or more methods and operations to appropriately manage the device ID of an A-IoTdevice. Several example methods and operations are described below with reference to FIG. 3 to FIG. 4. One or more features, parameters, and operations associated with FIG. 3 to FIG. 4 may be similar to those described above with reference to FIG. 1 and may be implemented via one or more connectivity topologies in FIG. 2A to FIG. 2D, thus redundant descriptions associated therewith may be omitted below for conciseness.

[0052] For descriptive purposes, the methods and operations may be mainly described herein as being performed by one or more specific network componenties, although it can be understood that, in actual implementations, another related network entity(s) may perform similar / related operations, without departing from the scope of the present disclosure. For instance, an operation of an A-IoT reader providing a data / message to an A-IoT device may suggest or indicate an operation of the A-IoT device receiving the data / message from the A-IoT reader, and the like.

[0053] According to example embodiments, one or more operations of an A-IoT reader may be implemented in one or more apparatuses or hardware components. For instance, the A-IoT reader may be implemented in an apparatus / device that includes a processor and a memory storage (or any other suitable storage medium), wherein the memory storage may include computerexecutable instructions which, when executed by the processor, cause the processor to perform one or more operations of the A-IoT reader.

[0054] FIG. 3 illustrates a first example method 300, according to one or more example embodiments. One or more operations in method 300 may be performed by at least one A-IoT reader (e.g., A-IoT reader 110, UE 211, at least one of base stations 221-241, intermediate network node 233, assisting network node 243, etc.).

[0055] As illustrated in FIG. 3, at operation S310, the A-IoT reader may be configured to determine a Device-to-Reader (D2R) transmission failure. As a non-limiting example, the A-IoT reader may determine whether the D2R transmission failure occurs during an inventory response. Specifically, upon providing the paging message / inventory polling, the A-IoT reader may monitor the access occasion assigned to the A-IoT device for the collection / reception of the random access preamble (Msgl) or an inventory response. In this regard, if the A-IoT reader does not detect the expected data (e.g., random access preamble, inventory response, a Medium Access Control (MAC)-layer acknowledgment (ACK) message, etc.) within the access occasion, and / or if the received data fails a Cyclic Redundancy Check (CRC) (e.g., an CRC value of the received data exceeds a predetermined threshold, etc.), the A-IoT reader may determine that the D2R transmission failure has occurred. It is contemplated that the A-IoT reader may be configured to determine the D2R transmission failure via any other suitable operations (e.g., during Msg3 transmission, during uplink data transmission via allocated uplink resources, etc.), without departing from the scope of the present disclosure.

[0056] Accordingly, based on determining the D2R transmission failure, at operation S320, the A-IoT reader 110 may be configured to determine whether a retransmission of a device identifier (ID) associated with an A-IoT device (e.g., A-IoT device 120, A-IoT device 212, A-IoT device 222, A-IoT device 232, A-IoT device 242, etc.) is required. As described above with reference to FIG. 1, the A-IoT reader may include at least one of: a network node or a first UE(e.g., a UE that implements a power source, etc.), while the A-IoT device may include at least one of: an RF tag, a sensor, or a second UE that is different from the first UE (e.g., a UE that does not implement a power source, etc.). Example of operations (that may be implemented by the A-IoTreader to determine whether the retransmission of the device ID is required) are described below with reference to FIG. 4.

[0057] Based on determining that the retransmission of the device ID is not required, method 300 may proceed to operation S330, at which the A-IoT reader may be configured to provide, to the A-IoT device and during a Reader-to-Device (R2D) transmission, a first R2D message indicating that the device ID can be reused (e.g., the device ID can be reused by the A- loT reader in further operations / transmissions). For instance, the A-IoT reader may provide the first R2D message during an R2D transmission subsequent to the D2R transmission that has failed.

[0058] The first R2D message may include one or more parameters indicating that the device ID can be reused. According to example embodiments, the first R2D message may include one or more Information Elements (IES) or Control Elements (CEs), each of which may include a bit flag (e.g., “0” indicates that the retransmission of the device ID is (or is not) required, “1” indicates that the device ID can be (or cannot be) reused, etc.), a Boolean value (e.g., “TRUE” indicates that the retransmission of the device ID is (or is not) required, “FALSE” indicates that the device ID can be (or cannot be) reused, etc.), and the like. By way of example, the first message may include an IE like “devicelDRetransmit: 0 bit”, “devicelDReuse: 1 bit”, “reuselDFlag: TRUE”, “retransmitIDFlag: FALSE”, and / or the like.

[0059] Based on determining that the retransmission of the device ID is required, method 300 may proceed to operation S340, at which the A-IoT reader may be configured to provide, to the A-IoT device and during the R2D transmission, a second R2D message that requests the A- loT device to retransmit the device ID during a next D2R transmission. For instance, the A-IoT reader may provide the second R2D message during an R2D transmission subsequent to the D2R transmission that has failed.

[0060] The second R2D message may include one or more parameters that indicate or request the A-IoT device to retransmit the associated device ID. According to example embodiments, the second R2D message may include one or more lEs or CEs, each of which may include a bit flag (e.g., “0” indicates that the retransmission of the device ID is (or is not) required, “1” indicates that the device ID can be (or cannot be) reused, etc.), a Boolean value (e.g., “TRUE” indicates that the retransmission of the device ID is (or is not) required, “FALSE” indicates that the device ID can be (or cannot be) reused, etc.), and the like. In addition, the IE(s) or CE(s) may include a slot index (or any other suitable parameters) that indicates the timing (e.g., which timefrequency slot in the next D2R transmission, etc.) in which the device ID should be retransmitted. By way of example, the second message may include an IE like “devicelDRetransmit: 1 bit”, “devicelDReuse: 0 bit”, “reuselDFlag: FALSE”, “retransmitIDFlag: TRUE”, “sloxlndex: 4 bits”, and / or the like.

[0061] According to example embodiments, upon providing the first R2D message (at operation S330) or the second R2D message (at S340) to the A-IoT device, method 300 may return to operation S310, such that the A-IoT reader may be configured to repeatedly perform method 300 for at least a predefined period of time to

[0062] FIG. 4 illustrates a second example method 400, according to one or more example embodiments. One or more operations in method 400 may be part of or similar to operation S320 in method 300. For instance, the A-IoT reader may be configured to perform one or more operations in method 400 to determine whether the retransmission of the device ID of the A-IoT device is required.

[0063] Referring to FIG. 4, at operation S410, the A-IoT reader may be configured to determine whether the device ID associated with the A-IoT device was successfully received in aD2R transmission prior to the D2R transmission failure (“the prior D2R transmission” herein). According to example embodiments, the A-IoT reader may be configured to determine whether the device ID was successfully received in the prior D2R transmission by determining whether the device ID is stored in a storage medium.

[0064] For instance, if the A-IoT reader has previously communicated with the A-IoT device in a past communication session (e.g., a communication session after which the A-IoT device entered into sleep mode and wake up for a new communication session that involves the D2R transmission failures, etc.), the A-IoT reader may have received and stored the device ID associated with the A-IoT device (along with other information associated therewith, such as the access occasion, the index of the random access preamble (Msgl), etc.) in a storage medium (e.g., a local database / storage device, a memory buffer, etc.). In this regard, at operation S410, the A- loT reader may access the storage medium and determine whether the device ID associated with the A-IoT device was stored therein. For instance, the A-IoT reader may utilize the information of the detected D2R transmission failure (e.g., obtained at operation S310 in method 300), such as the access occasion associated with the D2R transmission failure, an index of the random access preamble (Msgl) associated with the D2R transmission failure, and the like, as the lookup parameter(s) to query the storage medium. Accordingly, if a matching entry (e.g., a mapping of device ID and the associated information like the access occasion, etc.) is found or stored in the storage medium, the A-IoT reader may determine that the device ID is stored in the storage medium, and thus the device ID was successfully received in the prior D2R transmission. Otherwise, the A-IoT reader may determine that the device ID is not stored in the storage medium, and thus the device ID was not successfully received in the prior D2R transmission.

[0065] Referring to FIG. 4, if it is determined that the device ID was not successfully received, method 400 may proceed to operation S420, at which the A-IoT reader may be configured to determine that the retransmission of the device ID is required. On the other hand, if it is determined that the device ID was successfully received, method 400 may proceed to operation S430, at which the A-IoT reader may be configured to determine that the retransmission of the device ID is not required (i.e., the device ID can be reused).

[0066] In some example embodiments, upon determining that the device ID was successfully received (at operation S410), method 400 may proceed to optional operation S440, instead of proceeding directly to operation S430. Specifically, at operation S440, the A-IoT reader may be configured to determine whether the device ID (stored in the storage medium) was part of the D2R transmission failure (e g., detected at operation S310 in method 310). Accordingly, based on determining that the device ID was part of the D2R transmission failure, method 400 may proceed to operation S420, at which the A-IoT reader may be configured to determine that the retransmission of the device ID is required. On the other hand, based on determining that the device ID was not part of the D2R transmission failure, method 400 may proceed to operation S430, at which the A-IoT reader may be configured to determine that the retransmission of the device ID is not required.

[0067] For instance, the A-IoT reader may detect that the D2R transmission failure is due to ID collision (e.g., multiple A-IoT devices share the same scheduling ID and access the A-IoT reader at the same time). In this case, since the reassignment of the scheduling ID (or any other suitable resources) is required, the A-IoT reader may need to have an updated device ID to reassign the scheduling ID, and thus, the stored device ID may be considered as part of the D2R transmission failure and the retransmission of the device ID is required. As another example, theA-IoT reader may determine that the D2R transmission failure is due to an incomplete or corrupted device ID transmission. In this case, since the incomplete / corrupted device ID (which was part of the D2R transmission failure) may be an outdated device ID, the A-IoT reader may require the A- loT device to retransmit the device ID instead of simply reusing the stored device ID. It is contemplated that the A-IoT reader may be configured to perform any other suitable operations to determine whether or not the device ID was part of the D2R transmission failure, without departing from the scope of the present disclosure.

[0068] In view of the above, example embodiments provide methods and operations that effectively and efficiently provide A-IoT device ID management. Specifically, method and operations in FIG. 3 may be automatically implemented by an A-IoT reader to efficiently and effectively determine a D2R transmission failure and inform an A-IoT device whether the retransmission of the associated device ID is required or the device ID (previously provided by the A-IoT device) can be reused. Further, method and operations in FIG. 4 may be automatically implemented by an A-IoT reader to effectively and efficiently determine whether the retransmission of the device ID is required.

[0069] Advantageously, by implementing example embodiments, the A-IoT reader may trigger conditional retransmission, i.e., reusing a device ID that is successfully received in the past and not part of the D2R transmission failure thereby reducing unnecessary signaling overhead, while ensuring that the retransmission of the device ID is initiated when needed thereby reducing the risk of misidentification and errors in future communications and transmissions. Ultimately, example embodiments may appropriately manage the device ID of an A-IoT device, thereby optimizing the network performance.

[0070] It is contemplated that, the methods, operations, advantages, and significances described above with reference to FIG. 3 to FIG. 4 are merely examples and the scope of the present disclosure should not be limited thereto. Specifically, one or more operations in FIG. 3 to FIG. 4 may be performed differently, less or additional operations may be involved, the messages or commands involved therein may include less or additional parameters, additional advantages may be achieved, and the like, without departing from the scope of the present disclosure. Further, it can be understood that the example embodiments of FIG. 3 to FIG. 4 may achieve similar technical advantages and significance described above with reference to FIG. 1 to FIG. 2D, since the methods and operations in FIG. 3 and FIG. 4 may be implemented in the system configuration, device, and topology in FIG. 1 to FIG. 2D.Examples of Device

[0071] One or more components of the example embodiments (e.g., A-IoT reader, A-IoT device, etc.), as well as the operations associated therewith, may be implemented in one or more devices or hardware components. For instance, one or more components / operations of the network entity may be implemented in one or more devices like a server(s), and the like.

[0072] In the following, descriptions of a device in which the example embodiments may be implemented are provided. It is contemplated that one or more features, operations, and methods described above may be performed by the device. For instance, the one or more operations or methods associated with an A-IoT reader may be performed by at least one processor of the device upon executing machine-readable instructions or computer-readable instructions stored in a memory or a storage component of the device.

[0073] FIG. 5 illustrates an embodiment of a device 500. As shown in FIG. 5, the device500 may include a processor 510, a memory 520, a storage component 530, an input component540, an output component 550, a communication interface 560, and a bus 570.

[0074] The processor 510, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 510 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and / or one or more single core processors, a distributed processing system, or the like. The processor 510 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0075] Memory 520 includes a non-transitory computer readable medium. Memory 520 includes a random access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 510. The memory 520 comprises machine-readable instructions which are executable by the processor 510. These machine-readable instructions when executed by the processor 510 cause the processor 510 to perform one or more method steps of an embodiment described above.

[0076] Storage component 530 stores information and / or software related to the operation and use of the device 500. For example, storage component 530 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0077] Input component 540 is configured to receive information, such as user input. For example, the input component 540 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, or alternatively, the input component 540 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0078] Output component 550 is configured to provide output information from the device 500. For example, the output component 550 may be, but not limited to, a display, a speaker, instructions to an external device, and / or one or more light-emitting diodes (LEDs).

[0079] Communication interface 560 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 560 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the device 500 and other devices. In other words, the standard of the communication interface 560 is not limited.

[0080] The bus 570 acts as an interconnect between the processor 510, the memory 520, the storage component 530, the input component 540, the output component 550, and the communication interface 560 of the device 500. The bus 570 may include a wired interconnection or a wireless interconnection.

[0081] The number and arrangement of components shown in FIG. 5 are provided as an example. In practice, device 500 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 5. Additionally, or alternatively, a set of components (e.g., one or more components) of device 500 may perform one or more functions described as being performed by another set of components of device 500.Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 500 in communication with one another.Example Implementation Environment

[0082] Example embodiments of the present disclosure may be implemented in any suitable type of environment. In the following, an example environment (in which the example embodiments may be implemented) is described.

[0083] FIG. 6 illustrates a diagram of an example environment 600 in which systems and / or methods, described herein, may be implemented. The implementation environment 600 includes a UE (User equipment) 610, a service environment 620, and a network 630. The service environment 620 includes one or more sub-environments 621. To illustrate this, FIG. 6 shows, for convenience, examples of a 1st sub-environment 621-1, a 2nd sub -environment 621-2, and an N- th sub-environment 621-N (where N is any natural number).

[0084] The UE 610 is connected to the network 630, and the network 630 is connected to the service environment 620. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 610 and the service environment 620 are connected via the network 630.

[0085] The UE 610 is a device that communicates with the service environment 620. The UE 610 receives information from the service environment 620 and / or sends information to the service environment 620. Also, the UE 610 may generate and / or store information to be transmitted, as necessary. Also, the UE 610 may store and / or process information that is received, as necessary.

[0086] The example FIG. 6 refers to the “UE”. However, it should be understood by those skilled in the art that general terms such as “user device,” “terminal,” “terminal device,”“communication device,” and “communication terminal” can be used interchangeably with the term “UE ”

[0087] For example, the UE 610 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or a similar device.

[0088] The service environment 620 is an environment that communicates with the UE 610 to provide one or more services. The service environment 620 receives information from the UE 610 and / or sends information to the UE 610. Also, the service environment 620 may generate and / or store information to be transmitted, as necessary. Also, the service environment 620 may store and / or process information that is received, as necessary. For example, the service environment 620 may provide computing resources as one of the services. It should be noted that the service is not limited to being provided to the UE; it may also be provided to devices other than the UE. For example, based on communication from the UE, the service may perform processes such as anomaly detection or traffic analysis and notify the results to a predetermined destination.

[0089] The example FIG. 6 refers to the “service environment”. The term "service environment" is used to refer to the broader context within which services operate. For example, cloud environments, platforms, computing systems, network systems, and cloud systems generally represent the environments in which services are conducted, and these are included within the "service environment." However, the "service environment" is not limited to these examples. Additionally, the specific types of environments within the "service environment" are not restricted.For instance, cloud environments and cloud systems can be categorized as private cloud, public cloud, hybrid cloud, or multi-cloud, all of which are included within the "service environment."

[0090] The one or more services provided by the service environment 620 is not specifically limited and can be adjusted according to the embodiments. For example, the services may include a service that provides information to the UE 610, a service that stores information from the UE 610, or a service that performs processing based on information from the UE 610 and returns the results of the processing.

[0091] In an embodiment, the Service Environments 620 may also provide computing resources as the service. The computing resources can be hardware resources and / or software resources. For example, applications, processors, memory, and storage can be included in the provided computing resources. Each computing resource can communicate with other computing resources via wired connections, wireless connections, or a combination of wired and wireless connections.

[0092] The provided computing resources can be actual resources (also referred to as physical resources) and / or virtual resources. Furthermore, means of virtualization for virtual resources can be selected as appropriate. That is, in this disclosure, the use of adjectives such as "Virtual" or "Virtualized" to describe names does not imply that they are virtualized by a specific means of virtualization. For example, “virtual machine” refers to software that operates like an actual computer, realized through means of virtualization, and it is not intended to exclude those realized by specific means of virtualization such as Hypervisors or Containers. Conversely, when means of virtualization such as Hypervisors or containers are mentioned in this disclosure, it is merely cited as a general method of implementation. It should also be interpreted that embodimentsimplemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0093] The service environment 620 includes one or more devices, such as servers and network devices, which provide services or perform processes. The placement of these devices within the service environment 620 can be determined as appropriate. Additionally, if the service environment 620 includes one or more sub-environments 621, the placement of devices can be determined based on predetermined policies for each sub-environment 621. For example, devices related to the first service may be placed in the 1st sub-environment 621-1, and devices related to the second service may be placed in the 2nd sub -environment 621-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st subenvironment 621-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 621-2. In this way, specific devices can be placed in specific sub -environments 621. Conversely, each sub-environment 621 can be specialized for a particular purpose.

[0094] In an embodiment, all processes executed in a single service may run within a single service environment, or in multiple service environments. Multiple processes executed in a single service could be provided by different service environments.

[0095] The network 630 is a network that exchanges information between the UE 610 and the service environment 620. The network 630 includes one or more wired and / or wireless networks.

[0096] For example, the network 630 may include a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), alocal area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, or the like, a non-terrestrial network (NTN), and / or a combination of these or other types of networks.

[0097] The network 630 can be a part of a network. For example, in a 5G network that includes a RAN, a transport network, and a core network, the network 630 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 620 could be in the core network, in which case the network 630 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0098] The number and arrangement of devices and networks shown in FIG. 6 are provided as an example. It should be understood that any changes that may be implemented by those skilled in the art, such as the addition or rearrangement of well-known devices or networks at the time of implementation, are included in this disclosure.Various Aspects of Embodiments

[0099] Example embodiments introduces new mechanisms and features that supplement and enhance the disclosures of one or more standard specifications. As a non-limiting example, example embodiments supplement and enhance at least one technical specification associated with 3GPP (e.g., 3GPP TSG-RAN WG2, etc.), as detailed blow .

[0100] In view of the above, example embodiments introduce specified and standardized approaches for implementing the A-IoT device ID management. Specifically, example embodiments clarify the problems of device ID management in A-IoT and provide various proposals for addressing the problems. Accordingly, example embodiments may be implemented in the 3GPP -based networks in a clear and standardized manner to effective and efficiently manage the access occasion in A-IoT.

[0101] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely examples of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure.

[0102] Specifically, the foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired frompractice of the implementations.

[0103] Some embodiments may relate to a device, a system, a method, and / or a computer- readable medium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer- readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out operations.

[0104] The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), electrically erasable programmable read-only memory (EEPROM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through afiber-optic cable), or electrical signals transmitted through a wire.

[0105] Computer-readable program instructions described herein can be downloaded to respective computing / processing devices from a computer-readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0106] Computer-readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages.

[0107] The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet ServiceProvider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer-readable program instructions by utilizing state information of the computer- readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0108] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer- readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0109] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0110] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer-readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.[0U1] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the implementations. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code — it is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0112] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: A system comprising: an Ambient Internet of Things (A-IoT) reader configured to: determine a Device-to-Reader (D2R) transmission failure; based on determining the D2R transmission failure, determine whether a retransmission of a device identifier (ID) associated with an A-IoT device is required; based on determining that the retransmission of the device ID is not required, provide, to the A-IoT device and during a Reader-to-Device (R2D) transmission, a first R2D message indicating that the device ID can be reused; and based on determining that the retransmission of the device ID is required, provide, to the A-IoT device and during the R2D transmission, a second R2D message that requests the A-IoT device to retransmit the device ID during a next D2R transmission.Item [2]: The system according to item [1], wherein the A-IoT reader is configured to determine whether the retransmission of the device ID is required by: determining whether the device ID was successfully received in a D2R transmission prior to the D2R transmission failure; based on determining that the device ID was successfully received in the D2R transmission prior to the D2R transmission failure, determining that the retransmission of the device ID is not required; and based on determining that the device ID was not successfully received in the D2R transmission prior to the D2R transmission failure, determining that the retransmission of the device ID is required.Item [3]: The system according to item [2], wherein the A-IoT reader is further configured to determine whether the retransmission of the device ID is required by: based on determining that the device ID was successfully received in the D2R transmission prior to the D2R transmission failure, determining whether the device ID was part of the D2R transmission failure; based on determining that the device ID was part of the D2R transmission failure, determining that the retransmission of the device ID is required; andbased on determining that the device ID was not part of the D2R transmission failure, determining that the retransmission of the device ID is not required.Item [4]: The system according to one or more of items [2]-[3], wherein the A-IoT reader is configured to determine whether the device ID was successfully received in the D2R transmission prior to the D2R transmission failure by: determining whether the device ID is stored in a storage medium.Item [5]: The system according to one or more of items [l]-[4], wherein the first R2D message comprises a parameter indicating that the device ID can be reused, and wherein the second R2D message comprises a parameter indicating that the retransmission of the device ID is required.Item [6]: The system according to one or more of items [l]-[5], wherein the A-IoT reader is configured to determine the D2R transmission failure by: determining the D2R transmission failure during an inventory response.Item [7]: The system according to one or more of items [l]-[6], wherein the A-IoT reader comprises at least one of: a network node or a first user equipment (UE); and wherein the A-IoT device comprises at least one of: a Radio Frequency (RF) tag, a sensor, or a second UE different from the first UE.Item [8]: A method comprising: determining, by an Ambient Internet of Things (A- loT) reader, a Device-to-Reader (D2R) transmission failure; based on determining the D2R transmission failure, determining, by the A-IoT reader, whether a retransmission of a device identifier (ID) associated with an A-IoT device is required; based on determining that the retransmission of the device ID is not required, providing, by the A-IoT reader and to the A-IoT device during a Reader-to-Device (R2D) transmission, a first R2D messageindicating that the device ID can be reused; and based on determining that the retransmission of the device ID is required, providing, by the A-IoT reader and to the A- loT device during the R2D transmission, a second R2D message that requests the A-IoT device to retransmit the device ID during a next D2R transmission.Item [9]: The method according to item [8], wherein the determining whether the retransmission of the device ID is required comprises: determining whether the device ID was successfully received in a D2R transmission prior to the D2R transmission failure; based on determining that the device ID was successfully received in the D2R transmission prior to the D2R transmission failure, determining that the retransmission of the device ID is not required; and based on determining that the device ID was not successfully received in the D2R transmission prior to the D2R transmission failure, determining that the retransmission of the device ID is required.Item

[0010] : The method according to item [9], wherein the determining whether the retransmission of the device ID is required further comprises: based on determining that the device ID was successfully received in the D2R transmission prior to the D2R transmission failure, determining whether the device ID was part of the D2R transmission failure; based on determining that the device ID was part of the D2R transmission failure, determining that the retransmission of the device ID is required; and based on determining that the device ID was not part of the D2R transmission failure, determining that the retransmission of the device ID is not required.Item

[0011] : The method according to one or more of items [9]-

[0010] , wherein the A- loT reader is configured to determine whether the device ID was successfully received inthe D2R transmission prior to the D2R transmission failure by: determining whether the device ID is stored in a storage medium.Item

[0012] : The method according to one or more of items [8]-[l 1], wherein the first R2D message comprises a parameter indicating that the device ID can be reused, and wherein the second R2D message comprises a parameter indicating that the retransmission of the device ID is required.Item

[0013] : The method according to one or more of items [8]-

[0012] , wherein the determining the D2R transmission failure comprises: determining whether the D2R transmission failure occurs during an inventory response.Item

[0014] : The method according to one or more of items [8]-

[0013] , wherein the A- loT reader comprises at least one of: a network node or a first user equipment (UE); and wherein the A-IoT device comprises at least one of: a Radio Frequency (RF) tag, a sensor, or a second UE different from the first UE.Item

[0015] : A non-transitory computer-readable recording medium having recorded thereon instructions executable by an Ambient Internet of Things (A-IoT) reader to cause the A-IoT reader to perform a method comprising: determining, by an Ambient Internet of Things (A-IoT) reader, a Device-to-Reader (D2R) transmission failure; based on determining the D2R transmission failure, determining, by the A-IoT reader, whether a retransmission of a device identifier (ID) associated with an A-IoT device is required; based on determining that the retransmission of the device ID is not required, providing, by the A-IoT reader and to the A-IoT device during a Reader-to-Device (R2D) transmission, a first R2D message indicating that the device ID can be reused; and based on determining that the retransmission of the device ID is required, providing, by the A-IoT reader and tothe A-IoT device during the R2D transmission, a second R2D message that requests the A- loT device to retransmit the device ID during a next D2R transmission.Item

[0016] : The non-transitory computer-readable recording medium according to item

[0015] , wherein the determining whether the retransmission of the device ID is required comprises: determining whether the device ID was successfully received in a D2R transmission prior to the D2R transmission failure; based on determining that the device ID was successfully received in the D2R transmission prior to the D2R transmission failure, determining that the retransmission of the device ID is not required; and based on determining that the device ID was not successfully received in the D2R transmission prior to the D2R transmission failure, determining that the retransmission of the device ID is required.Item

[0017] : The non-transitory computer-readable recording medium according to item

[0016] , wherein the determining whether the retransmission of the device ID is required further comprises: based on determining that the device ID was successfully received in the D2R transmission prior to the D2R transmission failure, determining whether the device ID was part of the D2R transmission failure; based on determining that the device ID was part of the D2R transmission failure, determining that the retransmission of the device ID is required; and based on determining that the device ID was not part of the D2R transmission failure, determining that the retransmission of the device ID is not required.Item

[0018] : The non-transitory computer-readable recording medium according to one or more of items

[0016] -

[0017] , wherein the A-IoT reader is configured to determine whether the device ID was successfully received in the D2R transmission prior to the D2R transmission failure by: determining whether the device ID is stored in a storage medium.Item

[0019] : The non-transitory computer-readable recording medium according to one or more of items

[0015] -

[0018] , wherein the first R2D message comprises a parameter indicating that the device ID can be reused, and wherein the second R2D message comprises a parameter indicating that the retransmission of the device ID is required.Item

[0020] : The non-transitory computer-readable recording medium according to one or more of items

[0015] -

[0019] , wherein the determining the D2R transmission failure comprises: determining whether the D2R transmission failure occurs during an inventory response.

[0113] It can be understood that numerous modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.

Claims

What is claimed is:

1. A system comprising: an Ambient Internet of Things (A-IoT) reader configured to: determine a Device-to-Reader (D2R) transmission failure; based on determining the D2R transmission failure, determine whether a retransmission of a device identifier (ID) associated with an A-IoT device is required; based on determining that the retransmission of the device ID is not required, provide, to the A-IoT device and during a Reader-to-Device (R2D) transmission, a first R2D message indicating that the device ID can be reused; and based on determining that the retransmission of the device ID is required, provide, to the A-IoT device and during the R2D transmission, a second R2D message that requests the A-IoT device to retransmit the device ID during a next D2R transmission.

2. The system according to claim 1, wherein the A-IoT reader is configured to determine whether the retransmission of the device ID is required by: determining whether the device ID was successfully received in a D2R transmission prior to the D2R transmission failure; based on determining that the device ID was successfully received in the D2R transmission prior to the D2R transmission failure, determining that the retransmission of the device ID is not required; and based on determining that the device ID was not successfully received in the D2R transmission prior to the D2R transmission failure, determining that the retransmission of the device ID is required.

3. The system according to claim 2, wherein the A-IoT reader is further configured to determine whether the retransmission of the device ID is required by: based on determining that the device ID was successfully received in the D2R transmission prior to the D2R transmission failure, determining whether the device ID was part of the D2R transmission failure; based on determining that the device ID was part of the D2R transmission failure, determining that the retransmission of the device ID is required; and based on determining that the device ID was not part of the D2R transmission failure, determining that the retransmission of the device ID is not required.

4. The system according to claim 2, wherein the A-IoT reader is configured to determine whether the device ID was successfully received in the D2R transmission prior to the D2R transmission failure by: determining whether the device ID is stored in a storage medium.

5. The system according to claim 1, wherein the first R2D message comprises a parameter indicating that the device ID can be reused, and wherein the second R2D message comprises a parameter indicating that the retransmission of the device ID is required.

6. The system according to claim 1, wherein the A-IoT reader is configured to determine the D2R transmission failure by: determining the D2R transmission failure during an inventory response.

7. The system according to claim 1, wherein the A-IoT reader comprises at least one of: a network node or a first user equipment (UE); and wherein the A-IoT device comprises at least one of: a Radio Frequency (RF) tag, a sensor, or a second UE different from the first UE.

8. A method comprising: determining, by an Ambient Internet of Things (A-IoT) reader, a Device-to-Reader (D2R) transmission failure; based on determining the D2R transmission failure, determining, by the A-IoT reader, whether a retransmission of a device identifier (ID) associated with an A-IoT device is required; based on determining that the retransmission of the device ID is not required, providing, by the A-IoT reader and to the A-IoT device during a Reader-to-Device (R2D) transmission, a first R2D message indicating that the device ID can be reused; and based on determining that the retransmission of the device ID is required, providing, by the A-IoT reader and to the A-IoT device during the R2D transmission, a second R2D message that requests the A-IoT device to retransmit the device ID during a next D2R transmission.

9. The method according to claim 8, wherein the determining whether the retransmission of the device ID is required comprises: determining whether the device ID was successfully received in a D2R transmission prior to the D2R transmission failure;based on determining that the device ID was successfully received in the D2R transmission prior to the D2R transmission failure, determining that the retransmission of the device ID is not required; and based on determining that the device ID was not successfully received in the D2R transmission prior to the D2R transmission failure, determining that the retransmission of the device ID is required.

10. The method according to claim 9, wherein the determining whether the retransmission of the device ID is required further comprises: based on determining that the device ID was successfully received in the D2R transmission prior to the D2R transmission failure, determining whether the device ID was part of the D2R transmission failure; based on determining that the device ID was part of the D2R transmission failure, determining that the retransmission of the device ID is required; and based on determining that the device ID was not part of the D2R transmission failure, determining that the retransmission of the device ID is not required.

11. The method according to claim 9, wherein the A-IoT reader is configured to determine whether the device ID was successfully received in the D2R transmission prior to the D2R transmission failure by: determining whether the device ID is stored in a storage medium.

12. The method according to claim 8, wherein the first R2D message comprises a parameter indicating that the device ID can be reused, and wherein the second R2D message comprises a parameter indicating that the retransmission of the device ID is required.

13. The method according to claim 8, wherein the determining the D2R transmission failure comprises: determining whether the D2R transmission failure occurs during an inventory response.

14. The method according to claim 8, wherein the A-IoT reader comprises at least one of: a network node or a first user equipment (UE); and wherein the A-IoT device comprises at least one of: a Radio Frequency (RF) tag, a sensor, or a second UE different from the first UE.

15. A non-transitory computer-readable recording medium having recorded thereon instructions executable by an Ambient Internet of Things (A-IoT) reader to cause the A-IoT reader to perform a method comprising: determining, by an Ambient Internet of Things (A-IoT) reader, a Device-to-Reader (D2R) transmission failure; based on determining the D2R transmission failure, determining, by the A-IoT reader, whether a retransmission of a device identifier (ID) associated with an A-IoT device is required;based on determining that the retransmission of the device ID is not required, providing, by the A-IoT reader and to the A-IoT device during a Reader-to-Device (R2D) transmission, a first R2D message indicating that the device ID can be reused; and based on determining that the retransmission of the device ID is required, providing, by the A-IoT reader and to the A-IoT device during the R2D transmission, a second R2D message that requests the A-IoT device to retransmit the device ID during a next D2R transmission.

16. The non-transitory computer-readable recording medium according to claim 15, wherein the determining whether the retransmission of the device ID is required comprises: determining whether the device ID was successfully received in a D2R transmission prior to the D2R transmission failure; based on determining that the device ID was successfully received in the D2R transmission prior to the D2R transmission failure, determining that the retransmission of the device ID is not required; and based on determining that the device ID was not successfully received in the D2R transmission prior to the D2R transmission failure, determining that the retransmission of the device ID is required.

17. The non-transitory computer-readable recording medium according to claim 16, wherein the determining whether the retransmission of the device ID is required further comprises: based on determining that the device ID was successfully received in the D2R transmission prior to the D2R transmission failure, determining whether the device ID was part of the D2R transmission failure;based on determining that the device ID was part of the D2R transmission failure, determining that the retransmission of the device ID is required; and based on determining that the device ID was not part of the D2R transmission failure, determining that the retransmission of the device ID is not required.

18. The non-transitory computer-readable recording medium according to claim 16, wherein the A-IoT reader is configured to determine whether the device ID was successfully received in the D2R transmission prior to the D2R transmission failure by: determining whether the device ID is stored in a storage medium.

19. The non-transitory computer-readable recording medium according to claim 15, wherein the first R2D message comprises a parameter indicating that the device ID can be reused, and wherein the second R2D message comprises a parameter indicating that the retransmission of the device ID is required.

20. The non-transitory computer-readable recording medium according to claim 15, wherein the determining the D2R transmission failure comprises: determining whether the D2R transmission failure occurs during an inventory response.

Images