Ambient internet of things (a-IOT) scheduling identifier (ID) management

Abstract

Example embodiments of the present disclosure relate to Ambient Internet of Things (A-IoT) scheduling identifier (ID) management. According to example embodiments, a system may include an A-IoT reader, and the A-IoT reader may be configured to determine a requirement to perform a scheduling for establishing a communication with an A-IoT device, and then provide a scheduling ID to the A-IoT device based on the determined requirement.

Description

AMBIENT INTERNET OF THINGS (A-IOT) SCHEDULING IDENTIFIER (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) scheduling 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-IoT) may refer to a 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] On the other hand, a scheduling may refer to the process in which a network communicates with a device to allocate resources (e.g., bandwidth, transmission timing information, etc.) to the device, thereby establishing and enabling a communication between the network and the device. In this regard, a scheduling identifier (ID) may refer to the parameter that the network assigns to the device during the scheduling procedure. By leveraging the scheduling ID, the network may accurately identify the device when communicating with the device. In terms of A-IoT, the scheduling ID of an A-IoT reader may be decided by an A-IoT reader.SUMMARY

[0006] Example embodiments of the present disclosure provide systems, methods, and the like, that effectively and efficiently implement A-IoT scheduling 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 requirement to perform a scheduling for establishing a communication with an A-IoT device, and then provide a scheduling ID to the A- loT device based on the determined requirement.

[0008] According to example embodiments, a method may be performable by an A-IoT reader and may include determining a requirement to perform a scheduling for establishing a communication with an A-IoT device, and providing a scheduling ID to the A-IoT device based on the determined requirement.

[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 including determining a requirement to perform a scheduling forestablishing a communication with an A-IoT device, and providing a scheduling ID to the A-IoT device based on the determined requirement.

[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 to FIG. 6 illustrate various example methods and operations, according to one or more example embodiments;

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

[0016] FIG. 8 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 directlydepend 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 single processor 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. Oneskilled 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,” “scheduling ID,” “random ID,” “random access procedure,” “CBRA,” “CRFRA,” 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 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) and downlink Reader-to-Device (R2D) transmissions.

[0026] In A-IoT, a scheduling may refer to the process in which an A-IoT reader communicates with an A-IoT device to allocate resources (e.g., bandwidth, transmission timing information, etc.) to the A-IoT device, thereby establishing and enabling a communication betweenthe A-IoT reader and the A-IoT device. In this regard, a scheduling identifier (ID) may refer to the parameter that the A-IoT reader assigns to the A-IoT device during the scheduling procedure. By leveraging the scheduling ID, the A-IoT reader may accurately identify the A-IoT device when communicating with the A-IoT device. Proper management of the scheduling ID is essential in order to ensure that each A-IoT device can be uniquely identified during the D2R and R2D transmissions in high-density environments and achieve resource optimizations. Nevertheless, as described below, the specific mechanisms for managing the scheduling ID for A-IoT devices in various scenarios (e.g., Contention-Based Random Access (CBRA), Contention-Free Random Access (CFRA), group-based access, etc.) remain unspecified and non-standardized in the related art, leading to various problems in the operations of the A-IoT-based network.

[0027] To begin with, in the CBRA scenario, a device may initiate access to a network via performing a random access procedure (RACH), where the device provides a random ID in a random access preamble (Msgl) to the network and the network may then reuse the random ID as the scheduling ID to perform scheduling and allocate resources to the device. Such an approach of reusing the random ID, while may reduce signaling overhead in low-density environments, may be suboptimal in high-density environments like A-IoT (where the density and / or number of A- loT devices is significant), since multiple A-IoT devices may generate the same random ID, substantially increasing the risk of ID collisions.

[0028] Similarly, in the group-based access scenario, multiple A-IoT devices may be triggered simultaneously by an A-IoT reader (e.g., the A-IoT reader may provide a broadcast trigger that may wake multiple A-IoT devices at the same time, etc.), substantially increasing the risk of ID collisions if the multiple A-IoT devices generate the same random ID and the random ID is reused as the scheduling ID for multiple A-IoT devices. Further, the related art lacks specificmechanisms and approaches that enable the A-IoT reader to uniquely identify each A-IoT device within the group, resulting in complexity and difficulty in managing multiple A-IoT devices simultaneously (e.g., allocating resources to multiple A-IoT devices, establishing communication with multiple A-IoT devices, etc.).

[0029] On the other hand, in the CFRA scenario, the network may assign an ID to the device and enable the device to use the assigned ID during the RACH. Namely, in CFRA where the device does not generate a random ID and provide a random access preamble as in the CBRA scenario, the network may need to appropriately assign a scheduling ID to the device. Nevertheless, in A-IoT, the specific mechanisms and approaches for configuring an A-IoT reader to appropriately and reliably assign a scheduling ID to an A-IoT device are not specified in the related art, which may lead to conflicts between the A-IoT devices, particularly when the A-IoT reader is managing a large number of devices.

[0030] Further, the validity of the scheduling ID is time-sensitive and may impact the network performance if the validity duration of the scheduling ID is not properly configured. For instance, the scheduling ID may be desired for a short duration in some scenarios, and may be desired for a long duration in some other scenarios. In this regard, the scheduling ID that persists too long may waste the network resources and increase the burden of long-term ID management, while the scheduling ID that expires too quickly may interrupt the ongoing communications and sessions. Thus, proper management of the duration of the scheduling ID is critical to avoid resource exhaustion and ID collisions. Nevertheless, in A-IoT, the specific mechanisms and approaches for managing the duration of the scheduling ID are not specified in the related art.

[0031] Example embodiments of the present disclosure, as described in the following, provide devices, systems, methods, and the like, that effectively and efficiently provide A-IoTscheduling ID management for various scenarios. Specifically, example embodiments implement an A-IoT reader that may be configured to automatically and dynamically determine a scheduling requirement based on real-time conditions (e.g., device density, network resource utilization, etc.) and then appropriately provide a scheduling ID to an A-IoT device based on the determined requirement.

[0032] For instance, under the CBRA scenario, the A-IoT reader may implement example embodiments to dynamically decide whether to reuse a random ID or assign a new ID as the scheduling ID of at least one A-IoT device. Advantageously, by implementing the example embodiments, the A-IoT reader may effectively reduce signaling overhead (e.g., by reusing the random ID(s) whenever the collision risk is low) and reduce risk of ID collisions (e.g., by assigning new ID(s) as the scheduling ID(s) whenever the collision risk is high).

[0033] Further, under the CFRA scenario, the A-IoT reader may implement example embodiments to proactively assign a unique ID to an A-IoT device that is involved in the CFRA- based communication before any transmissions, thereby ensuring that the device can be uniquely identifiable from the beginning and eliminating the risk of ID collisions due to misidentification of the A-IoT device. Similarly, under the group-based access scenario, the A-IoT reader may implement example embodiments to proactively assign a unique ID to each of the devices involved in the group-based access, thereby ensuring that no ID collisions between the A-IoT devices within the group and enabling the A-IoT reader to effectively identify each device and manage multiple devices simultaneously, and eventually allocating resources and establishing communications (e.g., D2R transmission, R2D transmission, etc.) with multiple devices in an efficient and effective manner.

[0034] Furthermore, the A-IoT reader may implement example embodiments to provide a session-specific ID(s) as the scheduling ID(s) of an A-IoT device(s) under various scenarios (e.g., CBRA, CFRA, group-based access, etc.), thereby ensuring that the scheduling ID(s) is consistent throughout the session while ensuring efficient resource utilization and reducing the risk of ID collisions due to long-term ID validity.

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

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

[0037] 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 andcommunications (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: a base 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.).

[0038] 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).

[0039] According to example embodiments, the A-IoT device 120 may be configured to continuously (or periodically) harvest energy from the ambient environment / energy sources. Upon harvesting sufficient energy, the A-IoT device 120 may wake and monitor for a scheduling trigger (e.g., a broadcast trigger, etc.) from the A-IoT reader 110, and then signal access to the A-IoT reader 110 when applicable. In this regard, the A-IoT reader 110 may determine a requirement toperform a scheduling for establishing a communication with the A-IoT device 120, and then provide a scheduling ID to the A-IoT device 120 based on the determined requirement.

[0040] For instance, if the communication is a CBRA-based communication, the A-IoT device 120 may transmit a random-access preamble (Msgl) that includes a random ID to the A- loT reader 110 to signal or request access thereto. In this regard, the A-IoT reader 110 may determine whether the random ID received from the A-IoT device 120 may be reused as the scheduling ID of the A-IoT device.

[0041] As an example, the A-IoT reader 110 may determine whether a risk of collision (i.e., a risk or probability that the random ID received from the A-IoT device is identical to another random ID received from another A-IoT device and / or identical to an ID assigned to another A- loT device) is below a predefined threshold. The threshold may be predefined by the network operator and / or the vendor, or may be predefined by the A-IoT reader 110 based on real-time (or near-real-time) network conditions (e.g., device density, resource utilization status, etc.). Accordingly, the A-IoT reader 110 may determine that the random ID received from the A-IoT device 120 may be reused as the scheduling ID of the A-IoT device 120 if it is determined that the risk of collision is below the predefined threshold, or may determine that the random ID received from the A-IoT device 120 may not be reused as the scheduling ID of the A-IoT device 120 if it is determined that the risk of collision is equal to or exceeds the predefined threshold. Accordingly, based on determining that the random ID received from the A-IoT device may be reused as the scheduling ID, the A-IoT reader 110 may reuse the random ID as the scheduling ID of the A-IoT device 120. On the other hand, based on determining that the random ID received from the A-IoT device 120 may not be reused as the scheduling ID, the A-IoT reader 110 may assign a new ID as the scheduling ID of the A-IoT device 120. Upon deciding the scheduling ID (e g., reusing therandom ID or assigning a new ID), the A-IoT reader 110 may provide information associated with the scheduling ID to the A-IoT device 120 in a random access response (Msg2).

[0042] In this way, the A-IoT reader 110 may dynamically decide whether to reuse the random ID or assign a new ID as the scheduling ID of the A-IoT device 120 based on real-time collision detection, thereby reducing signaling overhead and preventing ID collisions in high- density networks. It is contemplated that the A-IoT reader 110 may also dynamically decide whether to reuse the random ID or assign a new ID as the scheduling ID of the A-IoT device 120 based on any other suitable factors or network conditions, such as the device density, without departing from the scope of the present disclosure.

[0043] As another example, if the communication is a CFRA-based communication, the A-IoT reader 110 may determine a unique ID that is different from scheduling IDs assigned to other A-IoT devices (including those random IDs reused as the scheduling IDs), and then assign the unique ID as the scheduling ID of the A-IoT device 120. Accordingly, the A-IoT reader 110 may provide the information associated with the scheduling ID (i.e., the assigned unique ID) to the A-IoT device during a first transmission between the A-IoT reader 110 and the A-IoT device 120 (e.g., first R2D transmission, etc.). In this way, the A-IoT reader 110 can ensure that the A- loT device 120 may be uniquely identified during the transmission sessions (e.g., D2R transmission, R2D transmission, etc.) in the CFRA scenario.

[0044] Further, in the group-based access scenario (e.g., when the A-IoT device 120 includes a plurality of A-IoT devices), the A-IoT reader 110 may determine a plurality of unique IDs (each of which is different from one another), and then assign the plurality of unique IDs as the respective scheduling ID to the group of A-IoT devices (e.g., each of the plurality of A-IoT devices within the same group may be assigned with the different unique IDs). Accordingly, theA-IoT reader 110 may provide information associated with the respective scheduling ID to each of the plurality of A-IoT devices and during a first transmission between the A-IoT reader and each of the plurality of the A-IoT devices (e.g., during the first R2D transmission with each of the plurality of A-IoT devices, etc.). In this way, the A-IoT reader 110 can ensure that the A-IoT device in the group may be uniquely identified and efficiently managed during the transmission sessions (e.g., D2R transmission, R2D transmission, etc.) in the group-based access scenario.

[0045] According to example embodiments, the scheduling ID (e.g., the reused random ID, the newly assigned ID, etc.) is valid for a session (e g., a session that includes one or more communications between the A-IoT reader and the A-IoT device) and expires when the session ends. For example, the scheduling ID may be session-specific and expire once one or more D2R transmissions and / or one or more R2D transmissions are completed. In this case, if further communication or a further session is required, the A-IoT reader 110 may assign another scheduling ID (e.g., again reuse the random ID, assign a new ID, etc.). In this way, the A-IoT reader 110 can provide efficient ID management, optimize network resource allocation, and reduce the risk of ID conflicts due to long-term ID.

[0046] It is contemplated that the “scheduling ID” may be replaced with any other suitable terminology, without departing from the scope of the present disclosure. For instance, in some example implementations, the scheduling is an Access Stratum (AS) Scheduling procedure as defined in one or more technical specifications of one or more standard organizations (e.g., 3GPP). In this case, the scheduling ID managed by the A-IoT reader 110 may be referred to as an “AS Scheduling ID”.

[0047] According to example embodiments, the A-IoT reader 110 and / or the A-IoT device120 may be deployed in various scenarios. For instance, the A-IoT reader 110 and / or the A-IoTdevice 120 may be deployed indoors, outdoors, or a combination thereof. Further, the A-IoT reader110 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.

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

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

[0050] 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 an intermediate network node 233 are utilized as an example of the A-IoT reader 110. As illustratedin 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.

[0051] 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 relay, 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.

[0052] 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 scheduling ID (e.g., determine a requirement to perform a scheduling for establishing a communication with the respective A-IoT device, provide a scheduling ID to the A-IoT device based on the determined requirement, etc.) 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.

[0053] In view of the above, example embodiments of the present disclosure clarify and exemplify various system configurations and topologies for implementing A-IoT scheduling IDmanagement. Specifically, example embodiments implement an A-IoT reader 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 scheduling requirement based on real-time conditions (e.g., device density, network resource utilization, etc.) and then appropriately provide a scheduling ID to an A-IoT device based on the determined requirement.

[0054] For instance, under the CBRA scenario, the A-IoT reader may implement example embodiments to dynamically decide whether to reuse a random ID or assign a new ID as the scheduling ID of at least one A-IoT device. Advantageously, by implementing the example embodiments, the A-IoT reader may effectively reduce signaling overhead (e.g., by reusing the random ID(s) whenever the collision risk is low) and reduce risk of ID collisions (e.g., by assigning new ID(s) as the scheduling ID(s) whenever the collision risk is high).

[0055] Further, under the CFRA scenario, the A-IoT reader may implement example embodiments to proactively assign a unique ID to an A-IoT device that is involved in the CFRA- based communication before any transmissions from the A-IoT device, thereby ensuring that the device can be uniquely identifiable from the beginning of the transmissions and eliminating the risk of ID collisions due to misidentification of the A-IoT device. Similarly, under the group-based access scenario, the A-IoT reader may implement example embodiments to proactively assign a unique ID to a group of A-IoT devices involved in the group-based access, thereby ensuring that no ID collisions between the A-IoT devices within the group and enabling the A-IoT reader to effectively identify each device and manage multiple A-IoT devices simultaneously, and eventually allocating resources and establishing communications (e.g., D2R transmission, R2D transmission, etc.) with multiple A-IoT devices in an efficient and effective manner.

[0056] Furthermore, the A-IoT reader may implement example embodiments to provide a session-specific ID(s) as the scheduling ID(s) of an A-IoT device(s) under various scenarios (e.g., CBRA, CFRA, group-based access, etc.), thereby ensuring that the scheduling ID(s) is consistent throughout the session while ensuring efficient resource utilization and reducing the risk of ID collisions due to long-term ID validity.

[0057] Further descriptions of example methods and operations of example embodiments are provided below with reference to FIG. 3 to FIG. 6, 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. 7 to FIG. 8, respectively.Example Methods and Operations

[0058] 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 scheduling ID of an A- loT device. Several example methods and operations are described below with reference to FIG. 3 to FIG. 6. One or more features, parameters, and operations associated with FIG. 3 to FIG. 6 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.

[0059] For descriptive purposes, the methods and operations may be mainly described herein as being performed by one or more specific network entities, 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.

[0060] 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 mediums), wherein the memory storage may include computerexecutable instructions which, when being executed by the processor, cause the processor to perform one or more operations of the A-IoT reader.

[0061] 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.).

[0062] As illustrated in FIG. 3, at operation S310, the A-IoT reader may be configured to determine a requirement to perform a scheduling (“scheduling requirement” herein) for establishing a communication with at least one A-IoT device (e.g., at least one of A-IoT devices 120-242). As described above with reference to FIG. 1, the A-IoT reader may include at least one of a network node (e.g., a base station, an intermediate network node, an assisting network node, etc.) or a first UE, while the A-IoT device may include at least one of an RF tag, a sensor, or a second UE different from the first UE (e.g., the first UE may operates in full radio protocol stacks and implement a dedicated power source, while the second UE may operate in low-power mode without requiring a dedicated power source, etc.). In the group-based access scenario, the A-IoT device may include a plurality of A-IoT devices (e.g., A-IoT devices that request access to the A- loT reader at the same time).

[0063] According to example embodiments, the communication may include at least one of a CBRA-based communication, a CFRA-based communication, or a group-based accesscommunication (i.e., where the communication involves a plurality of A-IoT devices). In this regard, at operation S310, the A-IoT reader may be configured to determine the type of the communication (e.g., CBRA, CFRA, and / or group-based access) and determine the requirement to perform the scheduling for establishing the specific type of communication with the A-IoT device(s).

[0064] Referring still to FIG. 3, at operation S320, the A-IoT reader may be configured to provide, based on the determined requirement and to the A-IoT device, a scheduling ID. For instance, the A-IoT reader may assign the scheduling ID to the A-IoT device according to the determined requirement (e.g., reuse random ID received from the A-IoT device as the scheduling ID if applicable, assign new ID as the scheduling ID of the A-IoT device, etc.) and provide the information associated with the assigned scheduling ID to the A-IoT device (e.g., provide the information in a random access response (Msg2) in the CBRA scenario, provide the information in a first R2D transmission in the CFRA scenario, etc.). According to example embodiments, the scheduling ID may be valid for a session (e.g., one or more communications between the A-IoT reader and the A-IoT device, such as one or more D2R transmissions and / or one or more R2D transmissions) and may expire when the session ends.

[0065] Descriptions of several example methods associated with several implementation scenarios are provided below with reference to FIG. 4 to FIG. 6. Specifically, FIG. 4 and FIG. 5 illustrate example methods associated with the CBRA scenario, while FIG. 6 illustrates an example method associated with the CFRA and group-based access scenarios. One or more operations in the methods of FIG. 4 to FIG. 6 may be part of or similar to one or more operations in the method of FIG. 3.

[0066] Referring first to FIG. 4, which 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 one or more operations in method 300. For instance, operations S410 and S420 may be part of operation S310, and operations S430 to S450 may be part of operation S320. Thus, it can be understood that, similar to method 300, one or more operations in method 400 may also be performed by at least one A-IoT reader.

[0067] Further, one or more operations in method 400 may be performed by the A-IoT reader to manage the scheduling ID associated with at least one A-IoT device in the CBRA scenario (i.e., when a scheduling is to be performed for establishing a CBRA-based communication with the A-IoT device). In this regard, it may be assumed that the A-IoT reader has received a random access preamble (Ms l) that contains a random ID from the A-IoT device, prior to the operations of method 400.

[0068] As illustrated in FIG. 4, at operation S410, the A-IoT reader may be configured to determine whether a random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device. Example operations associated therewith are provided below with reference to FIG. 5.

[0069] Based on determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device, method 400 may proceed to operation S420, at which the A-IoT reader may be configured to determine a new ID different from the random ID received from the A-IoT device. For instance, the A-IoT reader may determine the random ID received from the A-IoT device and any other IDs (e.g., reused IDs, newly assigned IDs, etc.) associated with other A-IoT devices, and then generate the new ID that is unique and different from any other IDs known to the A-IoT reader. Accordingly, at operation S440, the A-IoT readermay be configured to assign the new ID as the scheduling ID of the A-IoT device. On the other hand, based on determining that the random ID can be reused as the scheduling ID of the A-IoT device, method 400 may proceed to operation S430, at which the A-IoT reader may reuse the random ID received from the A-IoT device as the scheduling ID of the A-IoT device.

[0070] Accordingly, at operation S450, the A-IoT reader may be configured to provide information associated with the scheduling ID to the A-IoT device. According to example embodiments, the A-IoT reader may include the information associated with the scheduling ID in a random access response (Msg2) and provide the random access response (Msg2) to the A-IoT device. For instance, in case the random ID is reused as the scheduling ID, the A-IoT reader may include a notification and / or the value of the random ID in the random access response. As another example, in case a new ID is assigned as the scheduling ID, the A-IoT reader may include the value of the new ID in the random access response and request the A-IoT device to utilize the new ID as the scheduling ID. According to example embodiments, the information of the assigned scheduling ID (e g., the reused random ID or the newly assigned ID) may be included in a dedicated Information Element (IE) or field in the random access response (Msg2).

[0071] According to example embodiments, the assigned scheduling ID (e.g., the reused random ID or the newly assigned ID) may be session-specific, i.e., the assigned scheduling ID may be valid for the duration of a session (thereby ensuring that the A-IoT device can be uniquely identified during the R2D and D2R transmissions in the session) and may expire once the session ends (thereby optimizing the resource utilization, reduce the burden of long-term ID management, and reducing the risk of ID conflicts or collisions due to long-term ID validity).

[0072] Referring next to FIG. 5, which illustrates a third example method 500, according to one or more example embodiments. One or more operations in method 500 may be part of orsimilar to operation S410 in method 400. For instance, one or more operations in method 500 may also be performed by at least one A-IoT reader to determine whether a random ID received from an A-IoT device can be reused as the scheduling ID of the A-IoT device (in the CBRA scenario). In this regard, it may be assumed that the A-IoT reader has received a random access preamble (Msgl) that contains a random ID from the A-IoT device, prior to the operations of method 500.

[0073] As illustrated in FIG. 5, at operation S510, the A-IoT device may be configured to determine whether a risk of collision is below a predefined threshold. In this regard, the risk of collision may indicate a probability that the random ID received from the A-IoT device is identical to another ID associated with another A-IoT device (e.g., a random ID received from another A- loT device, an ID assigned to another A-IoT device, etc.). Further, the threshold may be predefined by one or more authorized personnel (e.g., a network operator, network manager, vendor, service provider, etc.) and / or may be defined dynamically by the A-IoT reader (or any other suitable network node) based on real-time network conditions (e.g., device density, network resource utilization, etc.).

[0074] Based on determining that the risk of collision is below the predefined threshold (e.g., the risk or probability of ID collision is low or is within an acceptable level), method 500 may proceed to operation S520, at which the A-IoT reader may determine that the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device. Conversely, based on determining that the risk of collision is equal to or exceeds the predefined threshold (e.g., the risk or probability of ID collision is high or exceeds an acceptable level), method 500 may proceed to operation S530, at which the A-IoT reader may determine that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device.

[0075] It is contemplated that, although the methods and operations in FIG. 4 and FIG. 5 are described with reference to “an A-IoT device” in the CBRA scenario, similar methods and operations are also applicable to the group-based scenario, i.e., when a plurality of A-IoT devices are involved in the CBRA-based communication. For instance, assuming that two A-IoT devices A and B are involved in the CBRA-based communication, the A-IoT device may perform operations of method 500 to determine whether the random IDs received from each of the A-IoT devices A and B can be reused as the scheduling ID of the respective A-IoT device. By way of example, assuming that the A-IoT reader determines that a first random ID received from the A- loT device A can be reused as the scheduling ID of the A-IoT device A and a second random ID received from the A-IoT device B cannot be reused as the scheduling ID of the A-IoT device B, the A-IoT reader may reuse the first random ID as the scheduling ID of the A-IoT device A and assign a new ID as the scheduling ID of the A-IoT device B (as detailed in method 400).

[0076] Referring next to FIG. 6, which illustrates a fourth example method 600, according to one or more example embodiments. One or more operations in method 600 may be part of or similar to one or more operations in method 300. For instance, operation S610 may be part of operation S310, and operations S620 to S630 may be part of operation S320. Thus, it can be understood that, similar to method 300, one or more operations in method 600 may also be performed by at least one A-IoT reader.

[0077] Further, one or more operations in method 600 may be performed by the A-IoT reader to manage the scheduling ID associated with at least one A-IoT device in the CFRA scenario and / or the group-based access scenario (i.e., when a scheduling is to be performed for establishing a CFRA-based communication with one or more A-IoT devices).

[0078] As illustrated in FIG. 6, at operation S610, the A-IoT reader may be configured to determine a unique ID that is different from scheduling IDs assigned to other A-IoT devices (e.g., IDs reused for other A-IoT devices, IDs newly generated and assigned to other A-IoT devices, etc.). In the group-based access scenario where the A-IoT device includes a plurality of A-IoT devices, the A-IoT reader may determine a plurality of unique IDs, each of which may be different from one another.

[0079] At operation S620, the A-IoT reader may be configured to assign the unique ID (determined at step S610) as the scheduling ID of the A-IoT device. In the group-based access scenario, the A-IoT reader may assign, to each of the plurality of A-IoT devices, a respective one of the plurality of unique IDs as the respective scheduling ID, such that each of the plurality of A- loT devices may be assigned a unique ID that is different from one another.

[0080] At operation S630, the A-IoT reader may be configured to provide information associated with the scheduling ID to the A-IoT device. For instance, the A-IoT reader may provide the information associated with the scheduling ID (i.e., the newly assigned, unique ID) to the A- loT device during a first transmission between the A-IoT reader and the A-IoT device (e.g., a first R2D transmission, etc.). Similarly, in the group-based access scenario, the A-IoT reader may provide, to each of the plurality of devices and during a first transmission between the A-IoT reader and each of the plurality of A-IoT devices, information associated with the respective scheduling ID. By way of example, assuming that two A-IoT devices A and B are involved, the A-IoT reader may assign a first unique ID to the A-IoT device A and a second unique ID to the A-IoT device B. Subsequently, the A-IoT reader may provide the information associated with the first unique ID to the A-IoT device A during a first R2D transmission (i.e., the first R2D transmission between theA-IoT reader and the A-IoT device A) and provide the information associated with the secondunique ID to the A-IoT device B during a second R2D transmission (i.e., the first R2D transmission between the A-IoT reader and the A-IoT device B). According to example embodiments, the information of the assigned unique ID(s) may be included in a dedicated IE or field in a message or signal of the first R2D transmission.

[0081] According to example embodiments, the assigned ID(s) may be session-specific, i.e., the assigned ID(s) may be valid for the duration of a session (thereby ensuring that the A-IoT device(s) can be uniquely identified during the R2D and D2R transmissions in the session) and may expire once the session ends (thereby optimizing the resource utilization, reduce the burden of long-term ID management, and reducing the risk of ID conflicts or collisions due to long-term ID validity).

[0082] In view of the above, example embodiments provide methods and operations that effectively and efficiently provide A-IoT scheduling ID management under various scenarios. Advantageously, method and operations in FIG. 3 may be automatically implemented by an A- loT reader to efficiently and effectively manage a scheduling ID for one or more A-IoT devices based on the real-time (or near-real-time) scheduling requirement.

[0083] Further, method and operations in FIG. 4 may be automatically implemented by the A-IoT reader to dynamically decide whether to reuse a random ID or assign a new ID as the scheduling ID of at least one A-IoT device, under the CBRA scenario. Furthermore, method and operations in FIG. 5 may be automatically implemented by the A-IoT reader to dynamically decide a risk of ID collision based on the real-time conditions (e.g., device density, network resource utilization, etc.) and accurately decide whether the random ID(s) received from the A-IoT device(s) can be reused. Advantageously, by leveraging the methods and operations in FIG. 4 and FIG. 5, the A-IoT reader may effectively reduce signaling overhead (e.g., by reusing the random ID(s)whenever the collision risk is low) and reduce risk of ID collisions (e.g., by assigning new ID(s) as the scheduling ID(s) whenever the collision risk is high).

[0084] On the other hand, method and operations in FIG. 6 may be automatically implemented by the A-IoT reader to proactively assign one or more unique IDs to one or more A- loT devices under the CFRA scenario and / or the group-based-access scenario. Advantageously, by leveraging the method and operations in FIG. 6, the A-IoT reader may proactively assign a unique ID to an A-IoT device that is involved in the CFRA-based communication before any transmissions, thereby ensuring that the device can be uniquely identifiable from the beginning and eliminating the risk of ID collisions due to misidentification of the A-IoT device. In addition, by leveraging the method and operations in FIG. 6, the A-IoT reader may proactively assign a unique ID to each of the devices involved in the group-based access, thereby ensuring that no ID collisions between the A-IoT devices within the group and enabling the A-IoT reader to effectively identify each device and manage multiple devices simultaneously, and eventually allocating resources and establishing communications (e.g., D2R transmission, R2D transmission, etc.) with multiple devices in efficient and effective manner.

[0085] In addition, by leveraging the methods and operations in FIG. 3 to FIG. 6, the A- loT reader may provide a session-specific ID(s) as the scheduling ID(s) of an A-IoT device(s) under various scenarios (e.g., CBRA, CFRA, group-based access, etc.), thereby ensuring that the scheduling ID(s) is consistent throughout the session while ensuring efficient resource utilization and reducing the risk of ID collisions due to long-term ID validity.

[0086] It is contemplated that, the methods, operations, advantages, and significances described above with reference to FIG. 3 to FIG. 6 are merely examples and the scope of the present disclosure should not be limited thereto. Specifically, one or more operations in FIG. 3 toFIG. 6 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. 6 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. 6 may be implemented in the system configuration, device, and topology in FIG. 1 to FIG. 2D.Examples of Device

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

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

[0089] FIG. 7 illustrates an embodiment of a device 700. As shown in FIG. 7, the device 700 may include a processor 710, a memory 720, a storage component 730, an input component 740, an output component 750, a communication interface 760, and a bus 770.

[0090] The processor 710, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 710 may be embodied asa 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 710 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.

[0091] Memory 720 includes a non-transitory computer readable medium. Memory 720 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 710. The memory 720 comprises machine-readable instructions which are executable by the processor 710. These machine-readable instructions when executed by the processor 710 cause the processor 710 to perform one or more method steps of an embodiment described above.

[0092] Storage component 730 stores information and / or software related to the operation and use of the device 700. For example, storage component 730 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.

[0093] Input component 740 is configured to receive information, such as user input. For example, the input component 740 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 740 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

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

[0095] Communication interface 760 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 760 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 700 and other devices. In other words, the standard of the communication interface 760 is not limited.

[0096] The bus 770 acts as an interconnect between the processor 710, the memory 720, the storage component 730, the input component 740, the output component 750, and the communication interface 760 of the device 700. The bus 770 may include a wired interconnection or a wireless interconnection.

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

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

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

[0100] The UE 810 is connected to the network 830, and the network 830 is connected to the service environment 820. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 810 and the service environment 820 are connected via the network 830.

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

[0102] The example FIG. 8 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 .”

[0103] For example, the UE 810 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.

[0104] The service environment 820 is an environment that communicates with the UE 810 to provide one or more services. The service environment 820 receives information from the UE 810 and / or sends information to the UE 810. Also, the service environment 820 may generate and / or store information to be transmitted, as necessary. Also, the service environment 820 may store and / or process information that is received, as necessary. For example, the service environment 820 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.

[0105] The example FIG. 8 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."

[0106] The one or more services provided by the service environment 820 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 810, a service that stores information from the UE 810, or a service that performs processing based on information from the UE 810 and returns the results of the processing.

[0107] In an embodiment, the Service Environments 820 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.

[0108] 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 embodiments implemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0109] The service environment 820 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 820 can be determined as appropriate. Additionally, if the service environment 820 includes one or more sub-environments 821, the placement of devices can be determined based on predetermined policies for each sub-environment 821. For example, devices related to the first service may be placed in the 1st sub-environment 821-1, and devices related to the second service may be placed in the 2nd sub -environment 821-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st subenvironment 821-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 821-2. In this way, specific devices can be placed in specific sub -environments 821. Conversely, each sub-environment 821 can be specialized for a particular purpose.

[0110] 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.[0U1] The network 830 is a network that exchanges information between the UE 810 and the service environment 820. The network 830 includes one or more wired and / or wireless networks.

[0112] For example, the network 830 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), a local 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, anad 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.

[0113] The network 830 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 830 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 820 could be in the core network, in which case the network 830 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0114] The number and arrangement of devices and networks shown in FIG. 8 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

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

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

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

[0118] 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 from practice of the implementations.

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

[0120] 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 discread-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 a fiber-optic cable), or electrical signals transmitted through a wire.

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

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

[0123] 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 Service Provider). 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.

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

[0125] 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 operationalsteps 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.

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

[0127] 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 systemsand / 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.

[0128] 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 requirement to perform a scheduling for establishing a communication with an A-IoT device; and provide, based on the determined requirement and to the A-IoT device, a scheduling identifier (ID).Item [2]: The system according to item [1], wherein the communication is a Contention-Based Random Access (CBRA)-based communication, and wherein the A-IoT reader is configured to determine the requirement by: determining whether a random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device; and based on determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device, determining a new ID different from the random ID received from the A-IoT device.Item [3]: The system according to item [2], wherein the A-IoT reader is configured to determine whether the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device by: determining whether a risk of collision is below a predefined threshold, wherein the risk of collision indicates a probability that the random ID received from the A-IoT device is identical to another ID associated with another A- loT device; based on determining that the risk of collision is below the predefined threshold, determining that the random ID received from the A-IoT device can be reused as thescheduling ID of the A-IoT device; and based on determining that the risk of collision is equal to or exceeds the predefined threshold, determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device.Item [4]: The system according to one or more of items [2]-[3], wherein the A-IoT reader is configured to provide the scheduling ID by: based on determining that the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device, reusing the random ID received from the A-IoT device as the scheduling ID of the A-IoT device; based on determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device, assigning the new ID as the scheduling ID of the A-IoT device; and providing, to the A-IoT device, information associated with the scheduling ID.Item [5]: The system according to item [1], wherein the communication is a Contention-Free Random Access (CFRA)-based communication, wherein the A-IoT reader is configured to determine the requirement by: determining a unique ID that is different from scheduling IDs assigned to other A-IoT devices; and wherein the A-IoT reader is configured to provide the scheduling ID by: assigning the unique ID as the scheduling ID of the A-IoT device; and providing, to the A-IoT device and during a first transmission between the A-IoT reader and the A-IoT device, information associated with the scheduling ID.Item [6]: The system according to item [1], wherein the A-IoT device comprises a plurality of A-IoT devices, wherein the A-IoT reader is configured to determine the requirement by: determining a plurality of unique IDs each of which is different from one another; and wherein the A-IoT reader is configured to provide the scheduling ID by:assigning, to each of the plurality of A-IoT devices, one of the plurality of unique IDs as the respective scheduling ID; and providing, to each of the plurality of A-IoT devices and during a first transmission between the A-IoT reader and each of the plurality of the A-IoT devices, information associated with the respective scheduling ID.Item [7]: The system according to one or more of items [l]-[6], wherein the scheduling ID is valid for a session and expires when the session ends, and wherein the session comprises one or more communications between the A-IoT reader and the A-IoT deviceItem [8]: The system according to one or more of items [l]-[7], 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 [9]: A method comprising: determining, by an Ambient Internet of Things (A- loT) reader, a requirement to perform a scheduling for establishing a communication with an A-IoT device; and providing, by the A-IoT reader based on the determined requirement and to the A-IoT device, a scheduling identifier (ID).Item

[0010] : The method according to item [9], wherein the communication is a Contention-Based Random Access (CBRA)-based communication, and wherein the determining the requirement comprises: determining whether a random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device; and based on determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device, determining a new ID different from the random ID received from the A-IoT device.Item

[0011] : The method according to item

[0010] , wherein the determining whether the random ID received from the A-IoT device can be reused as the scheduling ID of the A- loT device comprises: determining whether a risk of collision is below a predefined threshold, wherein the risk of collision indicates a probability that the random ID received from the A-IoT device is identical to another ID associated with another A-IoT device; based on determining that the risk of collision is below the predefined threshold, determining that the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device; and based on determining that the risk of collision is equal to or exceeds the predefined threshold, determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device.Item

[0012] : The method according to one or more of items

[0010] -[l 1], wherein the providing the scheduling ID comprises: based on determining that the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device, reusing the random ID received from the A-IoT device as the scheduling ID of the A-IoT device; based on determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device, assigning the new ID as the scheduling ID of the A- loT device; and providing, to the A-IoT device, information associated with the scheduling ID.Item

[0013] : The method according to item [9], wherein the communication is a Contention-Free Random Access (CFRA)-based communication, wherein the determining the requirement comprises: determining a unique ID that is different from scheduling IDs assigned to other A-IoT devices; and wherein the providing the scheduling ID comprises: assigning the unique ID as the scheduling ID of the A-IoT device; and providing, to the A-loT device and during a first transmission between the A-IoT reader and the A-IoT device, information associated with the scheduling ID.Item

[0014] : The method according to item [9], wherein the A-IoT device comprises a plurality of A-IoT devices, wherein the determining the requirement comprises: determining a plurality of unique IDs each of which is different from one another; and wherein the providing the scheduling ID comprises: assigning, to each of the plurality of A-IoT devices, one of the plurality of unique IDs as the respective scheduling ID; and providing, to each of the plurality of A-IoT devices and during a first transmission between the A-IoT reader and each of the plurality of the A-IoT devices, information associated with the respective scheduling ID.Item

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

[0014] , wherein the scheduling ID is valid for a session and expires when the session ends, and wherein the session comprises one or more communications between the A-IoT reader and the A-IoT device.Item

[0016] : The method according to one or more of items [9]-[l 5], 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

[0017] : 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 a requirement to perform a scheduling for establishing a communication with an A-IoT device; and providing, based on the determined requirement and to the A-IoT device, a scheduling identifier (ID).Item

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

[0017] , wherein the communication is a Contention-Based Random Access (CBRA)- based communication, and wherein the determining the requirement comprises: determining whether a random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device; and based on determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device, determining a new ID different from the random ID received from the A-IoT device.Item

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

[0018] , wherein the determining whether the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device comprises: determining whether a risk of collision is below a predefined threshold, wherein the risk of collision indicates a probability that the random ID received from the A-IoT device is identical to another ID associated with another A-IoT device; based on determining that the risk of collision is below the predefined threshold, determining that the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device; and based on determining that the risk of collision is equal to or exceeds the predefined threshold, determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device.Item

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

[0018] -

[0019] , wherein the providing the scheduling ID comprises: based on determining that the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device, reusing the random ID received from the A-IoT device as the scheduling ID of the A-IoT device; based on determining that the random IDreceived from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device, assigning the new ID as the scheduling ID of the A-IoT device; and providing, to the A- loT device, information associated with the scheduling ID.

[0129] 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 requirement to perform a scheduling for establishing a communication with an A-IoT device; and provide, based on the determined requirement and to the A-IoT device, a scheduling identifier (ID).

2. The system according to claim 1, wherein the communication is a Contention-Based Random Access (CBRA)-based communication, and wherein the A-IoT reader is configured to determine the requirement by: determining whether a random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device; and based on determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device, determining a new ID different from the random ID received from the A-IoT device.

3. The system according to claim 2, wherein the A-IoT reader is configured to determine whether the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device by: determining whether a risk of collision is below a predefined threshold, wherein the risk of collision indicates a probability that the random ID received from the A-IoT device is identical to another ID associated with another A-IoT device;based on determining that the risk of collision is below the predefined threshold, determining that the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device; and based on determining that the risk of collision is equal to or exceeds the predefined threshold, determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device.

4. The system according to claim 2, wherein the A-IoT reader is configured to provide the scheduling ID by: based on determining that the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device, reusing the random ID received from the A-IoT device as the scheduling ID of the A-IoT device; based on determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device, assigning the new ID as the scheduling ID of the A-IoT device; and providing, to the A-IoT device, information associated with the scheduling ID.

5. The system according to claim 1, wherein the communication is a Contention-Free Random Access (CFRA)-based communication, wherein the A-IoT reader is configured to determine the requirement by: determining a unique ID that is different from scheduling IDs assigned to other A-IoT devices; andwherein the A-IoT reader is configured to provide the scheduling ID by: assigning the unique ID as the scheduling ID of the A-IoT device; and providing, to the A-IoT device and during a first transmission between the A-IoT reader and the A-IoT device, information associated with the scheduling ID.

6. The system according to claim 1, wherein the A-IoT device comprises a plurality of A-IoT devices, wherein the A-IoT reader is configured to determine the requirement by: determining a plurality of unique IDs each of which is different from one another; and wherein the A-IoT reader is configured to provide the scheduling ID by: assigning, to each of the plurality of A-IoT devices, one of the plurality of unique IDs as the respective scheduling ID; and providing, to each of the plurality of A-IoT devices and during a first transmission between the A-IoT reader and each of the plurality of the A-IoT devices, information associated with the respective scheduling ID.

7. The system according to claim 1, wherein the scheduling ID is valid for a session and expires when the session ends, and wherein the session comprises one or more communications between the A-IoT reader and the A-IoT device.

8. 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.

9. A method comprising: determining, by an Ambient Internet of Things (A-IoT) reader, a requirement to perform a scheduling for establishing a communication with an A-IoT device; and providing, by the A-IoT reader based on the determined requirement and to the A- loT device, a scheduling identifier (ID).

10. The method according to claim 9, wherein the communication is a Contention-Based Random Access (CBRA)-based communication, and wherein the determining the requirement comprises: determining whether a random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device; and based on determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device, determining a new ID different from the random ID received from the A-IoT device.

11. The method according to claim 10, wherein the determining whether the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device comprises:determining whether a risk of collision is below a predefined threshold, wherein the risk of collision indicates a probability that the random ID received from the A-IoT device is identical to another ID associated with another A-IoT device; based on determining that the risk of collision is below the predefined threshold, determining that the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device; and based on determining that the risk of collision is equal to or exceeds the predefined threshold, determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device.

12. The method according to claim 10, wherein the providing the scheduling ID comprises: based on determining that the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device, reusing the random ID received from the A-IoT device as the scheduling ID of the A-IoT device; based on determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device, assigning the new ID as the scheduling ID of the A-IoT device; and providing, to the A-IoT device, information associated with the scheduling ID.

13. The method according to claim 9, wherein the communication is a Contention-Free Random Access (CFRA)-based communication, wherein the determining the requirement comprises:determining a unique ID that is different from scheduling IDs assigned to other A-IoT devices; and wherein the providing the scheduling ID comprises: assigning the unique ID as the scheduling ID of the A-IoT device; and providing, to the A-IoT device and during a first transmission between the A-IoT reader and the A-IoT device, information associated with the scheduling ID.

14. The method according to claim 9, wherein the A-IoT device comprises a plurality of A-IoT devices, wherein the determining the requirement comprises: determining a plurality of unique IDs each of which is different from one another; and wherein the providing the scheduling ID comprises: assigning, to each of the plurality of A-IoT devices, one of the plurality of unique IDs as the respective scheduling ID; and providing, to each of the plurality of A-IoT devices and during a first transmission between the A-loT reader and each of the plurality of the A-loT devices, information associated with the respective scheduling ID.

15. The method according to claim 9, wherein the scheduling ID is valid for a session and expires when the session ends, and wherein the session comprises one or more communications between the A-IoT reader and the A-IoT device.

16. The method according to claim 9, 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.

17. 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- loT reader to perform a method comprising: determining a requirement to perform a scheduling for establishing a communication with an A-IoT device; and providing, based on the determined requirement and to the A-IoT device, a scheduling identifier (ID).

18. The non-transitory computer-readable recording medium according to claim 17, wherein the communication is a Contention-Based Random Access (CBRA)-based communication, and wherein the determining the requirement comprises: determining whether a random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device; and based on determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device, determining a new ID different from the random ID received from the A-IoT device.

19. The non-transitory computer-readable recording medium according to claim 18, wherein the determining whether the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device comprises: determining whether a risk of collision is below a predefined threshold, wherein the risk of collision indicates a probability that the random ID received from the A-IoT device is identical to another ID associated with another A-IoT device; based on determining that the risk of collision is below the predefined threshold, determining that the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device; and based on determining that the risk of collision is equal to or exceeds the predefined threshold, determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device.

20. The non-transitory computer-readable recording medium according to claim 18, wherein the providing the scheduling ID comprises: based on determining that the random ID received from the A-IoT device can be reused as the scheduling ID of the A-IoT device, reusing the random ID received from the A-IoT device as the scheduling ID of the A-IoT device; based on determining that the random ID received from the A-IoT device cannot be reused as the scheduling ID of the A-IoT device, assigning the new ID as the scheduling ID of the A-IoT device; and providing, to the A-IoT device, information associated with the scheduling ID.

Images