Resource allocation and scheduling method for a-IOT communication and related apparatus

Abstract

A resource allocation and scheduling method for Ambient-Internet of Things (A-IoT) communication performed by a base station includes transmitting a request trigger, a system-level and / or a resource allocation (RA) information intended for one or more A-IoT devices through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling, and receiving one or more A-IoT responses from the one or more A-IoT devices.

Description

RESOURCE ALLOCATION AND SCHEDULING METHOD FOR A-IOT COMMUNICATION AND RELATED APPARATUSBACKGROUND OF DISCLOSURE1. Field of the Disclosure

[0001] The present disclosure relates to the field of communication systems, and more particularly, to a resource allocation and scheduling method for Ambient-Internet of Things (A-IoT) communication, a base station, an A-IoT device, and a related apparatus, which can provide a good communication performance and / or provide high reliability.2. Description of the Related Art

[0002] In the past two decades, wireless communication for interconnecting millions or even billions of small and low power consumption devices or things with reduced capability to create “Internet of Things” (IoT) has attracted much attention in communication standard forums and deployment across various industries. When many of these IoT devices are interconnected to a network, which could be a local area private network for inventory in a warehouse or a wide area public network for transportation within / across cities, it can greatly improve productivity efficiency in an organization and increase comforts of life at home. Today a very commonly used IoT technology is Radio Frequency IDentification (RFID) , which typical consists of a reader and tags attached to objects. RFID tags are used in many areas, such as tracking production progress through the assembly line, identifying objects / containers in warehouses and logistics, charging road tolls from vehicles using eTags, authenticating passengers using ePassport in airports, etc.

[0003] However, the technology of RFID is primarily used for identification of objects, assets, people or animals from emitting a tag ID, the reading range is limited to just a few meters and it requires handheld scanning which leads to labor intensive and time-consuming operations or costly deployments of RFID portals / gates. Other IoT technologies include NarrowBand-IoT (NB-IoT) and massive Machine Type Communication (mMTC) developed by 3rd generation partnership project (3GPP) , which can provide much higher data rates and communication range / coverage, but at a cost of higher power consumption and implementation complexity. In turn, this translates into a higher device price and requires a battery to operate that needs to be replaced or recharged manually, which leads to high maintenance cost, serious environmental issues, and even safety hazards for some use cases.

[0004] Therefore, there is a need for a resource allocation and scheduling method for Ambient-Internet of Things (A-IoT) communication, a base station, an A-IoT device, and a related apparatus, which can solve issues in the prior art and other issues.SUMMARY

[0005] In a first aspect of the present disclosure, a resource allocation and scheduling method for Ambient-Internet of Things (A-IoT) communication performed by a base station, includes transmitting a request trigger, a system-level and / or a resource allocation (RA) information intended for one or more A-IoT devices through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling, and receiving one or more A-IoT responses from the one or more A-IoT devices.

[0006] In a second aspect of the present disclosure, a resource allocation and scheduling method for Ambient-Internet of Things (A-IoT) communication performed by an A-IoT device includes receiving a request trigger, a system-level and / or a resource allocation (RA) information from a base station through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling; and transmitting one or more A-IoT responses intended for the base station.

[0007] In a third aspect of the present disclosure, a base station includes a transmitter and a receiver. The transmitter is configured to transmit a request trigger, a system-level and / or a resource allocation (RA) information intended for one or more A-IoT devices through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling. The receiver is configured to receive one or more Ambient-Internet of Things (A-IoT) responses from the one or more A-IoT devices.

[0008] In a fourth aspect of the present disclosure, an Ambient-Internet of Things (A-IoT) device includes a receiver and a transmitter. The receiver is configured to receive a request trigger, a system-level and / or a resource allocation (RA) information from a base station through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling. The transmitter is configured to transmit one or more A-IoT responses intended for the base station.

[0009] In a fifth aspect of the present disclosure, a base station includes a memory, a transceiver, and a processor coupled to the memory and the transceiver. The IoT reader is configured to perform the above method.

[0010] In a sixth aspect of the present disclosure, an Internet of Things (IoT) device includes a memory, a transceiver, and a processor coupled to the memory and the transceiver. The IoT device is configured to perform the above method.

[0011] In a seventh aspect of the present disclosure, an Ambient-Internet of Things (A-IoT) device includes a memory, a transceiver, and a processor coupled to the memory and the transceiver. The IoT device is configured to perform the above method.

[0012] In an eighth aspect of the present disclosure, a non-transitory machine-readable storage medium has stored thereon instructions that, when executed by a computer, cause the computer to perform the above method.

[0013] In a ninth aspect of the present disclosure, a chip includes a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the above method.

[0014] In a tenth aspect of the present disclosure, a computer readable storage medium, in which a computer program is stored, causes a computer to execute the above method.

[0015] In an eleventh aspect of the present disclosure, a computer program product includes a computer program, and the computer program causes a computer to execute the above method.

[0016] In a twelfth aspect of the present disclosure, a computer program causes a computer to execute the above method.BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to illustrate the embodiments of the present disclosure or related art more clearly, the following figures may be described in the embodiments are briefly introduced. It is obvious that the drawings are merely some embodiments of the present disclosure, a person having ordinary skill in this field can obtain other figures according to these figures without paying the premise.

[0018] FIG. 1 is a schematic diagram illustrating a first Ambient-IoT (A-IoT) communication topology according to an embodiment of the present disclosure.

[0019] FIG. 2 is a schematic diagram illustrating a second A-IoT communication topology according to an embodiment of the present disclosure.

[0020] FIG. 3 is a block diagram of a base station, an A-IoT device, and a carrier wave node (CWN) of communication in a communication network system according to an embodiment of the present disclosure.

[0021] FIG. 4 is a flowchart illustrating a resource allocation and scheduling method for Ambient-Internet of Things (A-IoT) communication performed by a base station according to an embodiment of the present disclosure.

[0022] FIG. 5 is a flowchart illustrating a resource allocation and scheduling method for Ambient-Internet of Things (A-IoT) communication performed by an A-IoT device according to an embodiment of the present disclosure.

[0023] FIG. 6 is a schematic diagram illustrating an exemplary illustration of proposed process flow of delivering system and resource allocation information to A-IoT device in A-IoT Topology 1 according to an embodiment of the present disclosure.

[0024] FIG. 7 is a schematic diagram illustrating an exemplary illustration of proposed process flow of delivering system and resource allocation information to A-IoT device in A-IoT Topology 2 according to an embodiment of the present disclosure.

[0025] FIG. 8 is a schematic diagram illustrating an exemplary illustration of proposed process flow of resource allocation and scheduling for communication between BS and A-IoT device in A-IoT Topology 1 according to an embodiment of the present disclosure.

[0026] FIG. 9 is a schematic diagram illustrating an exemplary illustration of proposed process flow of resource allocation and scheduling for communication between BS and A-IoT device in A-IoT Topology 2 according to an embodiment of the present disclosure.

[0027] FIG. 10 is a block diagram of a base station for wireless communication according to an embodiment of the present disclosure.

[0028] FIG. 11 is a block diagram of an A-IoT device for wireless communication according to an embodiment of the present disclosure.

[0029] FIG. 12 is a block diagram of an example of a computing device according to an embodiment of the present disclosure.

[0030] FIG. 13 is a block diagram of a system for wireless communication according to an embodiment of the present disclosure.DETAILED DESCRIPTION OF EMBODIMENTS

[0031] Embodiments of the present disclosure are described in detail with the technical matters, structural features, achieved objects, and effects with reference to the accompanying drawings as follows. Specifically, the terminologies in the embodiments of the present disclosure are merely for describing the purpose of the certain embodiment, but not to limit the disclosure.

[0032] There is a need for a new form / type of IoT devices, the new form / type of IoT devices can be densely deployed (e.g., 150 devices per 100m2) and still manageable by a network communication node. The new form / type of IoT devices supports a communication range of 10-50 m, a maximum data rate of 5 kpbs to convey tag ID, user, sensor and / or location / positioning information, a latency target between 1-10 seconds, infrequent transmissions (once in an hour / day / week) , and a positioning accuracy of 1-3 meters for indoor and several tends of meters for outdoor.

[0033] Additionally, the new form / type of IoT devices, once deployed, may be able to operate for a very long period of time without the need of a battery (e.g., for years) , such that the maintenance and operation costs are minimized, the form factor of a device can be small for easy application (e.g., sticker type of tags) and the device is safe to operate everywhere. As such, this gives rise to ambient powered IoT devices, where the device without any battery is powered purely by radio energy transmitted by a data communication triggering node (e.g., base station (BS) , user equipment (UE) ) or an external carrier wave node. But an Ambient-IoT (A-IoT) device may be equipped with a storage for energy harvested from radio waves for data processing and radio transmission at a later time.

[0034] As observed from the above operation requirements (coverage, data type and data rate, latency, transmission frequency and positioning) , which are higher than RFID, the intended use cases for A-IoT devices include: 1. Indoor inventory: automated warehousing, medical instruments inventory management and positioning, non-public network for logistics, automobile manufacturing, airport terminal / shipping port, smart homes, automated supply chain distribution, fresh food supply chain, end-to-end logistics, electronic shelf label. 2. Indoor command: online modification of medical instruments status, device activation and deactivation, elderly health care, device permanent deactivation.

[0035] Types of A-IoT devices / tags:

[0036] Considering the limited size and complexity required by practical applications for battery less A-IoT devices with no energy storage capability or A-IoT devices with limited energy storage that do not need to be replaced or recharged manually, the output power of energy storage unit is typically from a few μW to a few hundreds of μW. In general, it is expected that A-IoT devices are categorized into the following types.

[0037] 1. Lower peak power consumption A-IoT devices / tags (a few μW) are equipped with energy storage, neither downlink (DL) nor uplink (UL) amplification in the device. Device’s UL transmission is backscattered on a carrier wave provided externally.

[0038] 2. Higher peak power consumption A-IoT devices / tags (a few hundreds of μW) has energy storage, both DL and / or UL amplification in the device. The device’s UL transmission may be generated internally by the device, or be backscattered on a carrier wave provided externally.

[0039] A-IoT communication topologies:

[0040] FIG. 1 illustrates a first Ambient-IoT (A-IoT) communication topology according to an embodiment of the present disclosure. That is topology 1: Direct data and signaling communication between BS and A-IoT devices. FIG. 2 illustrates a second Ambient-IoT (A-IoT) communication topology according to an embodiment of the present disclosure. That is topology 2: Data and signaling communication between BS and A-IoT devices via an intermediate node. Different from RFID devices, where a handheld reader or an expensive RFID portal / gate is used to obtain ID information from the tags, A-IoT devices are expected to exchange data and signaling information with a base station (BS) directly or via an intermediate node acting like an information relay / transfer point as shown by the above Topology 1 and Topology 2 illustrations.

[0041] In Topology 1 (direct communication between BS and A-IoT) , A-IoT devices / tags directly communicates in both directions (DL and UL) with a BS. The communication between the BS and A-IoT devices / tags includes data information (e.g., tag IDs, sensor information, positioning, etc. ) and signaling information (paging, random access, configuration details, scheduling information, etc. ) The carrier wave node has two main functions in Topology 1; one it provides to A-IoT devices additional energy that is needed for processing DL information from the BS and performing UL transmission to the BS when the separation distance is far (i.e., pathloss is high) ; second it provides a UL carrier wave on which A-IoT devices perform backscattering transmission to resolve a full-duplex and a spectrum usage regulation issue when a Frequency Division Duplexing (FDD) spectrum band is used for A-IoT operation. Since the BS directly communicates with A-IoT devices / tags to exchange commands and data information, it is also commonly referred to as the ‘reader’ in A-IoT communication.

[0042] In Topology 2 (indirect communication between the base station (BS) and A-IoT devices via an intermediate node) , the intermediate node (which could be a user equipment (UE) or a repeater) under the BS's control relays or transfers data and signaling information between the BS and the A-IoT devices. The intermediate node UE communicates directly with the BS and relays information from the A-IoT devices to the BS over the existing cellular Uu interface for both downlink (DL) and uplink (UL) . For simplicity, this bidirectional communication between the BS and the intermediate node is referred to as “intermediate UE DL and UL” or “Uu DL and UL. ” The intermediate node UE also communicates directly with the A-IoT devices, relaying information from the BS to the A-IoT devices. For simplicity, this bidirectional communication is referred to as “A-IoT device DL and UL. ” In Topology 2, A-IoT devices harvest radio energy transmitted from the intermediate node UE to power data / signaling processing and A-IoT device UL transmissions. When an FDD spectrum band is used for A-IoT operation, both A-IoT device DL and UL transmissions are expected to occur on an uplink frequency carrier. Topology 2 is typically used in scenarios where the base station (BS) is located outdoors, and A-IoT devices are located indoors. In this setup, an intermediate UE facilitates communication between the BS and the A-IoT devices.

[0043] As seen in both Topology 1 and Topology 2, there is only one central communication node (i.e., a ‘reader’ ) that exchange commands and data information directly with A-IoT devices / tags, for simplicity, let’s refer this bidirectional communication between the reader and A-IoT devices / tags as “reader-to-device” (R2D) and “device-to-reader” (D2R) communications. And let’s further define the communication channel in the physical layer for transmitting command, control and data information in R2D communication as “physical reader device channel” (PRDCH) and the communication channel in the physical layer for transmitting response, control and data information in D2R communication as “physical device reader channel” (PDRCH) .

[0044] Downlink and uplink resource allocation and scheduling in cellular communication:

[0045] In cellular communication, when a user equipment (UE) is in the radio resource control (RRC) connected state with a serving base station (BS) , such as a 5th Generation (5G) New Radio (NR) gNB, the allocation of resource blocks (RBs) and timings (i.e., symbols and slots) for downlink (DL) transmissions (gNB transmitting and UE receiving) and uplink (UL) transmissions (UE transmitting and gNB receiving) to / from one or multiple UEs in a cell is fully managed and controlled by the serving gNB.

[0046] For resource allocation and scheduling over the Uu interface, the process is simpler in cellular DL compared to cellular UL because it does not require the UE to send a scheduling request (SR) or buffer status report (BSR) . Both cellular DL and UL support dynamic scheduling and configured scheduling modes.

[0047] In cellular DL, the dynamic scheduling mode involves the gNB scheduling time and frequency resources for each physical downlink shared channel (PDSCH) transmission to a UE. This scheduling information is conveyed via downlink control information (DCI) in the physical downlink control channel (PDCCH) . In contrast, the configured scheduling mode, also known as semi-persistent scheduling (SPS) for cellular DL, allows the gNB to pre-configure a set of time and frequency resources, as well as the parameters needed for PDSCH scheduling, through RRC signaling (e.g., RRC setup or RRC reconfiguration) . The gNB activates SPS transmissions in the DL by sending a DCI, enabling it to schedule PDSCH without requiring DCI for every transmission. This approach significantly reduces the load on the physical (PHY) and medium access control (MAC) layers.

[0048] In cellular UL, the dynamic scheduling mode operates similarly to DL. However, the UE may first send an SR and a BSR to the gNB to request resources for physical uplink shared channel (PUSCH) transmissions. The gNB then schedules each UL transmission in the PUSCH using DCI. In the configured scheduling mode, referred to as configured grant (CG) for cellular UL, two mechanisms, Type 1 and Type 2, are supported in 5G NR.

[0049] 1. Type 1 CG: gNB configures using RRC a set of time and frequency resources and parameters necessary for PUSCH transmissions, and UE is expected to transmit PUSCH without any DCI trigger / indication.

[0050] 2. Type 2 CG: gNB firstly configures using RRC a set of time and frequency resources and parameters necessary for PUSCH transmissions. When gNB schedules / grants UE to transmit PUSCH using Type 2 CG resources, it sends an activation command in DCI; otherwise, it sends a deactivation DCI to stop PUSCH transmission.

[0051] In some embodiments of the present disclosure, resource allocation and scheduling methods for A-IoT device communication in a cellular system are proposed, adopting a “request trigger and respond” strategy. The request trigger may include at least one of the following parameters to address UL resource dimensioning issues and transmission conflict / collision issues caused by an unknown and potentially large number of A-IoT devices transmitting responses simultaneously: 1. “Paging / polling” : Used to page a specific set or subset of A-IoT devices that satisfy one or more criteria to transmit their responses. 2. “Request / response type” : Indicates the type of response required from A-IoT devices. In some embodiments, additional benefits of adopting the proposed resource allocation and scheduling methods for A-IoT device communication in a cellular system may include: 1. Achieving a unified / common request trigger signaling design for both deployment topologies: when an A-IoT device communicates directly with a BS, and when an A-IoT device communicates indirectly with a BS via an intermediate node UE. 2. This ensures that the processing and implementation complexity for A-IoT devices is kept to a minimum.

[0052] FIG. 3 illustrates that, in some embodiments, a base station 10 (such as an A-IoT reader) , an A-IoT device 20, and a carrier wave node (CWN) 30 of communication in a communication network system 40 according to an embodiment of the present disclosure are provided. The communication network system 40 includes the base station 10, the A-IoT device 20, and the CWN 30. The base station 10 may include a memory 12, a transceiver 13, and a processor 11 coupled to the memory 12 and the transceiver 13. The A-IoT device 20 may include a memory 22, a transceiver 23, and a processor 21 coupled to the memory 22 and the transceiver 23. The CWN 30 may include a memory 32, a transceiver 33, and a processor 31 coupled to the memory 32 and the transceiver 33. The processor 11, 21, or 31 may be configured to implement proposed functions, procedures and / or methods described in this description. Layers of radio interface protocol may be implemented in the processor 11, 21, or 31. The memory 12, 22, or 32 is operatively coupled with the processor 11, 21, or 31 and stores a variety of information to operate the processor 11, 21, or 31. The transceiver 13, 23, or 33 is operatively coupled with the processor 11, 21, or 31 and transmits and / or receives a radio signal.

[0053] The processor 11, 21, or 31 may include application-specific integrated circuit (ASIC) , other chipset, logic circuit and / or data processing device. The memory 12, 22, or 32 may include read-only memory (ROM) , random access memory (RAM) , flash memory, memory card, storage medium and / or other storage device. The transceiver 13, 23, or 33 may include baseband circuitry to process radio frequency signals. When the embodiments are implemented in software, the techniques described herein can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The modules can be stored in the memory 12, 22, or 32 and executed by the processor 11, 21, or 31. The memory 12, 22, or 32 can be implemented within the processor 11, 21, or 31 or external to the processor 11, 21, or 31 in which case those can be communicatively coupled to the processor 11, 21, or 31 via various means as is known in the art.

[0054] In some embodiments, the transceiver 13 is configured to transmit a request trigger, a system-level and / or a resource allocation (RA) information intended for one or more A-IoT devices 20 through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling, and the transceiver 13 is configured to receive one or more A-IoT responses from the one or more A-IoT devices 20. This can solve issues in the prior art and other issues and / or improve communication performance and reliability.

[0055] In some embodiments, the transceiver 23 is configured to receive a request trigger, a system-level and / or a resource allocation (RA) information from the base station 10 through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling, and the transceiver 23 is configured to transmit one or more A-IoT responses intended for the base station 10. This can solve issues in the prior art and other issues and / or improve communication performance and reliability.

[0056] FIG. 4 illustrates a resource allocation and scheduling method 410 for Ambient-Internet of Things (A-IoT) communication performed by a base station according to an embodiment of the present disclosure. In some embodiments, the method 410 includes: an operation 412, transmitting a request trigger, a system-level and / or a resource allocation (RA) information intended for one or more A-IoT devices through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling, and an operation 414, receiving one or more A-IoT responses from the one or more A-IoT devices. This can solve issues in the prior art and other issues and / or improve communication performance and reliability.

[0057] In some embodiments, the request trigger includes one or more of following parameters: a paging or polling used to page a set or a subset of the one or more A-IoT devices that satisfy one or more criterion to transmit the one or more A-IoT responses, a request or response type used to indicate a type of response from the one or more A-IoT devices is requested, a time and frequency resource assignment used to schedule one or more PUSCH resources for one or more A-IoT response transmissions, a periodicity containing a periodicity value and used to indicate a set of periodic occurring time and frequency resources for multiple A-IoT response transmissions, a resource pool index or identifier (ID) used to indicate a set of time and frequency resources, a resource pool, or a resource region on an A-IoT uplink interface, a configuration index or ID used to identify a type 2 configured grant, an activation and deactivation used to indicate the one or more A-IoT devices to start transmitting or stop transmitting the one or more A-IoT responses using the type 2 configured grant identified by the configuration index or ID.

[0058] In some embodiments, one or more criterion includes one or more A-IoT device IDs or a range of A-IoT device IDs, a divisor value in a mathematical modulo operation, a location zone or distance range, and / or an A-IoT device type index or ID. In some embodiments, the request or response type is a device ID only, a device ID and a positioning or ranging information, or a device ID and a sensor data. In some embodiments, transmitting the request trigger, the system-level and / or the RA information intended for the one or more A-IoT devices through the signaling includes transmitting the request trigger, the system-level and / or the RA information intended for the one or more A-IoT devices using a downlink control information (DCI) in a physical downlink control channel (PDCCH) or a radio resource control (RRC) configuration signaling in a physical downlink shared channel (PDSCH) . In some embodiments, transmitting the request trigger, the system-level and / or the RA information intended for the one or more A-IoT devices through the signaling includes transmitting the request trigger, the system-level and / or the RA information intended for the one or more A-IoT devices via an intermediate node using an A-IoT control information (ACI) in a physical uplink control channel (PUCCH) or an RRC configuration signaling in a physical uplink shared channel (PUSCH) .

[0059] In some embodiments, receiving the one or more A-IoT responses from the one or more A-IoT devices includes receiving the one or more A-IoT responses from the one or more A-IoT devices via an intermediate node. In some embodiments, if no A-IoT response transmission is required from the one or more A-IoT devices, a DCI format is transmitted from the base station to the intermediate node to schedule PUCCH and / or PUSCH resources for delivering the system-level and / or the RA information from the intermediate UE to the one or more A-IoT devices. In some embodiments, if an A-IoT response transmission is required from the one or more A-IoT devices, a DCI format is transmitted from the base station to the intermediate node to schedule a PUCCH or PUSCH resource to transmit an ACI containing the request trigger, and the request trigger in the ACI is used to schedule one or more PUSCH resources to the one or more A-IoT devices to transmit the one or more A-IoT responses.

[0060] In some embodiments, the term “ / ” can be interpreted to indicate “and / or. ” The term “configured” can refer to “pre-configured” and “network configured” . The term “preset” , “pre-defined” or “pre-defined rules” in the present disclosure may be achieved by pre-storing corresponding codes, tables, or other manners for indicating relevant information in devices. The specific implementation is not limited in the present disclosure. For example, “preset” and “pre-defined” may refer to those defined in a protocol. It is also to be understood that in the disclosure, “protocol” may refer to a standard protocol in the field of communication, which may include, for example, a relevant protocol applied in the future communication system, which is not limited in the present disclosure.

[0061] FIG. 5 illustrates a resource allocation and scheduling method 510 for Ambient-Internet of Things (A-IoT) communication performed by an A-IoT device according to an embodiment of the present disclosure. In some embodiments, the method 510 includes: an operation 512, receiving a request trigger, a system-level and / or a resource allocation (RA) information from a base station through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling, and an operation 514, transmitting one or more A-IoT responses intended for the base station. This can solve issues in the prior art and other issues and / or improve communication performance and reliability.

[0062] In some embodiments, the request trigger includes one or more of following parameters: a paging or polling used to page a set or a subset of the one or more A-IoT devices that satisfy one or more criterion to transmit the one or more A-IoT responses, a request or response type used to indicate a type of response from the one or more A-IoT devices is requested, a time and frequency resource assignment used to schedule one or more PUSCH resources for one or more A-IoT response transmissions, a periodicity containing a periodicity value and used to indicate a set of periodic occurring time and frequency resources for multiple A-IoT response transmissions, a resource pool index or identifier (ID) used to indicate a set of time and frequency resources, a resource pool, or a resource region on an A-IoT uplink interface, a configuration index or ID used to identify a type 2 configured grant, an activation and deactivation used to indicate the one or more A-IoT devices to start transmitting or stop transmitting the one or more A-IoT responses using the type 2 configured grant identified by the configuration index or ID.

[0063] In some embodiments, one or more criterion includes one or more A-IoT device IDs or a range of A-IoT device IDs, a divisor value in a mathematical modulo operation, a location zone or distance range, and / or an A-IoT device type index or ID. In some embodiments, the request or response type is a device ID only, a device ID and a positioning or ranging information, or a device ID and a sensor data. In some embodiments, receiving the request trigger, the system-level and / or the RA information from the base station through the signaling includes receiving the request trigger, the system-level and / or the RA information from the base station using a downlink control information (DCI) in a physical downlink control channel (PDCCH) or a radio resource control (RRC) configuration signaling in a physical downlink shared channel (PDSCH) . In some embodiments, receiving the request trigger, the system-level and / or the RA information from the base station through the signaling includes receiving the request trigger, the system-level and / or the RA information from the base station via an intermediate node using an A-IoT control information (ACI) in a physical uplink control channel (PUCCH) or an RRC configuration signaling in a physical uplink shared channel (PUSCH) .

[0064] In some embodiments, transmitting the one or more A-IoT responses intended for the base station includes transmitting the one or more A-IoT responses intended for the base station via an intermediate node. In some embodiments, if no A-IoT response transmission is required from the one or more A-IoT devices, the base station transmits, to the intermediate node, a DCI format used to schedule PUCCH and / or PUSCH resources for delivering the system-level and / or the RA information from the intermediate UE to the one or more A-IoT devices. In some embodiments, if an A-IoT response transmission is required from the one or more A-IoT devices, the base station transmits, to the intermediate node, a DCI format used to schedule a PUCCH or PUSCH resource to transmit an ACI containing the request trigger, and the request trigger in the ACI is used to schedule one or more PUSCH resources to the one or more A-IoT devices to transmit the one or more A-IoT responses.

[0065] Examples:

[0066] In some embodiments of the present disclosure, resource allocation and scheduling methods for A-IoT device communication in a cellular system propose adopting a “request trigger and respond” strategy. The request trigger may be provided directly from the BS to A-IoT devices (using a DCI in the PDCCH or RRC configuration signaling in the PDSCH) or forwarded via an intermediate node UE (using an ACI in the PUCCH or RRC configuration signaling in the PUSCH) . The request trigger can include at least one of the following parameters: 1. “Paging / polling” : Used to page a specific set or subset of A-IoT devices that satisfy one or more criteria to transmit their responses. 2. “Request / response type” : Indicates the type of response requested from A-IoT devices. In one example, the request / response type is device / tag ID only.

[0067] In most use cases of ambient internet of things (A-IoT) such as warehouse inventory, parcel logistics, factory production lines, store shelves and even at homes, the number of active devices (e.g., A-IoT tags / labels) within the coverage area of a base station (BS) or an intermediate user equipment (UE) is likely to be unknown at any given time. In one scenario, there could be hundreds or thousands of devices on the shelves in a warehouse or store. In another scenario, new devices / tags are passing through production lines or being deployed in offices or homes, while some of existing devices / tags may leave the area. Since the cost of these devices is targeted to be much less than one US dollar (e.g., from a few cents to a few tens of cents) and the power consumption can be kept as low / minimal as possible for signal processing and transmission (i.e., battery-less and to be energized by ambient power from radio waves) , the design and implementation of these devices need to be very simple and very low complexity when they communicate with a BS or an intermediate node UE. As such, one could assume no radio resource control (RRC) connection, no device attachment to a cell or UE, no cell selection / re-selection process, and no hybrid automatic repeat request (HARQ) are expected for A-IoT communication in a cellular system. That is, without the existing process of cell searching, reading cell configuration information in master information block (MIB) and system information blocks (SIBs) , UE registration and cell camping that are traditionally required for a normal UE (e.g., smartphone) to complete its initial access to a network cell, the new process for A-IoT devices (e.g., A-IoT tags / labels) to communicate with a BS or an intermediate UE can be simplified and based on a “trigger and response” approach.

[0068] Furthermore, due to unknown and potential a large number of devices may be responding at the same time after receiving a communication request trigger or command in A-IoT downlink from a BS or an intermediate UE, it can cause two resource allocation issues in scheduling devices to transmit in A-IoT uplink as followed.

[0069] 1. Provisioning / dimensioning of UL resources for A-IoT devices’ transmissions, since the total amount of A-IoT traffic is uncertain as some devices may transmit / respond with only tag IDs while others may include also sensor data or positioning information.

[0070] 2. Transmission conflict and collision on a same or overlapping UL resources due to multiple devices sending responses simultaneously.

[0071] Proposed polling / sampling-based resource allocation and scheduling for A-IoT communication:

[0072] To support A-IoT devices operating in a cellular system, certain system-level and resource allocation (RA) information relating to DL and UL transmissions can be signaled / configured firstly to the devices in order for the A-IoT communication to function properly. The system-level and RA information may include details such as DL and UL carrier frequencies, sub-carrier spacing of the carriers, DL and UL bandwidth part (BWP) information, frequency resource blocks (RBs) allocated within the BWPs, synchronization timing information, control channel occasions, configured grant (CG) resources, possibly resource pools and etc. Depending on the signaled / configured information, it will have certain impacts to the subsequent allocation and scheduling of UL PUSCH resources to the A-IoT devices for transmitting responses back to the base station (in Topology 1) and the intermediate UE (in Topology 2) .

[0073] To resolve or minimize previously described UL resource dimensioning and transmission conflict / collision issues in A-IoT communication, in some embodiments of the present disclosure invention, it is proposed to adopt a polling / sampling-based paging and scheduling strategy to limit the number of A-IoT devices sending responses / data information together, and to adopt a query-based control of traffic type in order for the BS and intermediate UE to dimension / determine the amount of UL PUSCH resources needed for A-IoT devices to transmit response data. To get an overview picture of how resource allocation and scheduling can be performed in a A-IoT communication system, it is proposed to adopt the following example processes according to the communication Topology deployed in the A-IoT system.

[0074] Example process sequence for delivering system and resource allocation information (Topology 1) :

[0075] In order to keep processing complexity to a minimal level for a A-IoT device that operates on ambient power received in surrounding radio waves, the process sequence and number of operations in A-IoT communication to deliver (by signaling / configuration) can be kept as small as possible. For A-IoT communication Topology 1, where a BS and a A-IoT device communicate directly with each other over a “A-IoT DL interface” and a “A-IoT UL interface” , an exemplary proposal of a simple process sequence to deliver A-IoT system and RA information is illustrated by diagram 100 in FIG. 6. In some embodiments, the proposed process sequence may involve mainly two operations:

[0076] In operation 101: BS transmits a DCI (using DCI format 1_X) in PDCCH scheduling one or multiple PDSCH transmission (s) to deliver A-IoT system-level and RA information, where the scheduling mechanism used in the DCI could be: 1. A dynamic scheduling one or more time and frequency resources for PDSCH transmission (s) . A “periodicity” parameter field could be included in the DCI indicating periodic occurring time and frequency resources for multiple PDSCH transmissions, and hence, minimizing PDCCH transmissions from the BS and reducing monitoring / blind decoding of DCI by A-IoT device. 2. A configured scheduling via a semi-persistent scheduling to transmit multiple PDSCHs. In some embodiments, in either dynamic scheduling or configured scheduling, the scheduling DCI only needs to be transmitted once, even if multiple PDSCH transmissions are needed to deliver the system-level and RA information.

[0077] In operation 102, BS transmits a PDSCH (over the A-IoT DL interface) containing the system-level and RA information. If the transmitted DCI in operation 101 indicates multiple time and frequency PDSCH resources or activates a SPS transmission, the BS performs multiple PDSCH transmissions (until operation 103) to deliver the system-level and RA information (e.g., retransmissions of a same TB to improve reliability performance) .

[0078] Example process sequence for delivering system and resource allocation information (Topology 2) :

[0079] For A-IoT communication Topology 2, where a BS and a A-IoT device communicate indirectly with each other via an intermediate node UE (which is acting as a relay node for A-IoT data and signaling information) , an exemplary proposal of a simple process sequence to deliver A-IoT system-level and RA information is illustrated by diagram 200 in FIG. 7. In some embodiments, the proposed process sequence may involve mainly two stages:

[0080] 1st Stage: From BS to intermediate UE:

[0081] In the 1st stage of delivering system-level and RA information to a A-IoT device, the information is first delivered to the intermediate UE over the existing Uu DL interface before relaying to the A-IoT device.

[0082] In operation 201, since the delivery of system-level and RA information is carried out by the BS over the existing Uu DL interface, an existing DCI format is used to schedule a PDSCH transmission.

[0083] In operation 202, the BS transmits A-IoT system-level and RA information using the scheduled PDSCH.

[0084] In operation 203, the BS transmits to the intermediate UE a DCI in PDCCH (a new DCI format 0_Y) which schedules PUCCH and / or PUSCH resources on the A-IoT DL interface (let’s referred this as a A-IoT DL grant) for the purpose of delivering the system-level and RA information from the intermediate UE to A-IoT device. In one example, the intermediate UE uses a scheduled PUCCH resource to transmit a A-IoT control information (ACI) which in turn schedules one or more PUSCH resources provided by the BS to deliver the system-level and RA information over the A-IoT DL interface to A-IoT device.

[0085] 2nd Stage: From intermediate UE to A-IoT device:

[0086] In operation 204, as described in above, in one example, the intermediate UE uses the A-IoT DL grant received in operation 203 to transmit ACI in a BS scheduled PUCCH resource. The ACI in turn schedules one or more PUSCH resources according to the A-IoT DL grant from the BS. In another example, when the A-IoT DL grant provided by the BS in operation 203 contains only PUSCH resources, the intermediate UE transmits ACI in a PUSCH resource from the A-IoT DL grant to schedule one or more other PUSCH resources provided in the A-IoT DL grant.

[0087] In operation 205, the intermediate UE delivers the system-level and RA information received from the BS in operation 202 to A-IoT device using the one or more PUSCH resources (until operation 206) scheduled by ACI in operation 204.

[0088] Example process sequence for delivering resource allocation and scheduling information (Topology 1) :

[0089] As already mentioned previously, the A-IoT communication between a BS and A-IoT devices can be based on a “request trigger and response” behavior. The request trigger, which is also referred as “paging” in the present disclosure, can be indicated / provided to a A-IoT device in communication Topology 1 using two different mechanisms / containers, namely a physical layer control signaling (via a DCI in PDCCH) and a radio resource control (RRC) configuration signaling (via PDSCH) . The response from the A-IoT device is always transmitted using configured grant resources on PUSCH or using a DCI scheduled PUSCH resources on the A-IoT UL interface.

[0090] For A-IoT communication directly between a BS and a A-IoT device over a A-IoT DL and UL interface in A-IoT communication Topology 1, an exemplary proposal of a simple process sequence for the “request trigger and response” behavior is illustrated by diagram 300 in FIG. 8.

[0091] In operation 301, the BS may in one case provide a request trigger to one or more A-IoT devices at a same time using a RRC configuration signaling in PDSCH transmitted over the A-IoT DL interface. The request trigger in PDSCH contains a new or updated A-IoT RA information, which could be a RRC configuration of a Type 1 or Type 2 configured grant. In the process of A-IoT communication, A-IoT devices may enter or leave a coverage area of the BS. Therefore, any existing A-IoT RA information provided previously can be updated, or a new A-IoT RA information is required. In this case, the DCI transmitted in operation 301 is to schedule a PDSCH transmission in operation 302 for providing RRC configuration of a new / updated A-IoT RA information and a request trigger for A-IoT device UL transmission.

[0092] In another case, the BS may directly request / trigger one or more A-IoT response transmissions from A-IoT device, by sending a request triggering DCI in operation 301 to schedule one or more PUSCH resources, to indicate a resource pool or to activate Type 2 configured grant on the A-IoT UL interface. Since the DCI in operation 301 directly indicates PUSCH resources for transmitting A-IoT responses, the next operation of the process sequence in diagram 300 is for A-IoT device to transmit responses (e.g., tag ID, positioning / ranging information sensor data, etc. ) on the indicated PUSCH resources in operation 303. The request triggering DCI can contain one or more of the following parameter fields.

[0093] 1. “Time and frequency resource assignment” fields, dynamic scheduling one or more PUSCH resources for A-IoT response transmission (s) ; these fields could be provided in DCI using separate parameters.

[0094] 2. “Periodicity” field, a periodicity value (e.g., 500ms, 1000ms, 2sec, 5sec, etc. ) indicating a set of periodic occurring time and frequency resources for multiple A-IoT response transmissions, and hence, minimizing PDCCH transmissions from the BS and reducing monitoring / blind decoding of DCI by A-IoT device.

[0095] 3. “Resource pool index / ID” , indicating a common set of time and frequency resources, a resource pool or a resource region on the A-IoT UL interface (e.g., a UL carrier) , in which A-IoT devices perform transmission of A-IoT responses.

[0096] 4. “Configuration index / ID” field, identifying a Type 2 configured grant that has been previously configured as part of RA information for A-IoT response transmission.

[0097] 5. “Activation and deactivation” field, indicating to A-IoT device to start transmitting or stop transmitting A-IoT responses using a Type 2 configured grant identified by the “configuration index / ID” field.

[0098] 6. “Paging / polling” field, paging a specific set or a subset of A-IoT devices that satisfy one or more criterion to transmit A-IoT response. To avoid or minimize potential transmission conflict / collision caused by more than one A-IoT devices sending responses in a same or overlapping PUSCH resource (due to a large number of A-IoT devices in the same area) , this parameter field sets the one or more criterion to limit the number of A-IoT devices sending A-IoT responses together. Some examples of paging / polling / sampling criteria for A-IoT devices to transmit A-IoT response may include: (1) One or more A-IoT device / tag IDs or a range of A-IoT device / tag IDs (e.g., from ID xxx to ID xxx+50) . (2) Divisor value in a mathematical modulo operation (i.e., mod function) : When this criterion is provided, a A-IoT device performs mathematical modulo operation of its device / tag ID and the divisor value (i.e., “Tag ID mod divisor” ) . If the remainder of the modulo operation is value ‘0’ , the A-IoT device transmits A-IoT response in the allocated / scheduled PUSCH resource. (3) Location zone or distance range: When a A-IoT device’s position is within the indicated location zone or distance range to the A-IoT request transmitter (e.g., 2, 5, 10, 20, 30 or 50 meters to the BS) , the A-IoT device transmits A-IoT response in the allocated / scheduled PUSCH resource. (4) A-IoT device type index / ID: A-IoT devices can be categorized into different types based on the device’s processing / transmission capability (e.g., passive or active) , peak power consumption (e.g., less than or more than X μW) and use case (e.g., meat or vegetable products, cars, trucks or bikes, luggage destination or flight number such as New York, London, Paris or Tokyo, etc. ) . Since there can be a very wide range of applications where A-IoT devices / tags can be used, this A-IoT device type index / ID can be configured in advanced.

[0099] 7. “Request / response type” field, indicating the type of response from A-IoT devices is requested by the BS. In one example, the request / response type is device / tag ID only. In another example, the request / response type is device / tag ID + positioning / ranging information. In one more example, the request / response type is device / tag ID + sensor data. As the request / response type can greatly influence the A-IoT response data traffic volume and pattern (e.g., periodic or event trigger only) , the BS could use this parameter field to dimension the number of required resources and to schedule appropriate time and frequency resources. Note that, since not every A-IoT device has the positioning / ranging determination capability and / or performs sensing, this “request / response type” field could be used in conjunction with the “paging / polling” field to further limit the amount of PUSCH resources that need to be allocated for response transmissions from A-IoT devices. A ‘0’ or ‘none’ value indicates no response is needed or expected from A-IoT device. This value can be indicated when the DCI is used for scheduling PDSCH resources on the A-IoT DL interface to convey A-IoT RA information to A-IoT device.

[0100] In operation 303, depending on the triggering / requesting information indicated in DCI of operation 301 or provided in operation 302, A-IoT device responds with requested information (e.g., tag ID, positioning / ranging information, sensor data, etc. ) using the allocated resources in DCI of operation 301 or in PDSCH of operation 302, respectively. After A-IoT device’s response transmission in PUSCH, the BS may repeat operation 301 and transmit another DCI triggering more responses from A-IoT device to transmit on PUSCH of operation 303, or the BS simply provides / schedules more UL PUSCH resources for retransmission of the same TB.

[0101] In operation 304, in some cases, A-IoT device may perform multiple transmissions on the A-IoT UL interface without receiving an additional DCI scheduling more PUSCH resources for transmitting more than one TB, a retransmission of the same TB, or for periodic transmissions according to a traffic pattern.

[0102] Example process sequence for delivering resource allocation and scheduling information (Topology 2) :

[0103] Similar to the process sequence operations described for the A-IoT communication in Topology 1, the A-IoT data and signaling communication between a BS and A-IoT devices in Topology 2 is also based on a “request trigger and response” model / behavior to keep the processing complexity of A-IoT devices to a minimum level, except that the A-IoT data and signaling can be routed through an intermediate node UE.

[0104] For A-IoT communication between a BS and a A-IoT device but routed through an intermediate node UE, an exemplary proposal of a simple process sequence for the “request trigger and response” behavior is illustrated by diagram 400 in FIG. 9. In some embodiments, the proposed process sequence involves mainly two stages:

[0105] 1st Stage (A-IoT request trigger and RA) : Intermediate UE forwards request trigger and RA from BS to A-IoT devices:

[0106] For the request trigger part of the proposed “request trigger and response” model in A-IoT communication, the main objective is to deliver all necessary A-IoT request trigger information and RA information from the BS to A-IoT devices. As such, the 1st stage of the A-IoT communication in Topology 2 is to firstly provide the request trigger information and RA information from the BS to the intermediate UE, and then the intermediate UE forwards these two pieces of information to A-IoT devices.

[0107] In operation 401, in one case the BS provides a request trigger and RA information via RRC configuration signaling, where the request trigger and RA information is intended for A-IoT response transmissions from one or more A-IoT devices on the A-IoT UL interface. In order to achieve this intention, the first operation is to transmit a DCI in PDCCH by the BS to schedule a PDSCH transmission to convey the request trigger and RA information to the intermediate UE. In operation 402, the RA information for the A-IoT response transmissions contains a new or updated A-IoT RA information, which could be a RRC configuration of a Type 1 or Type 2 configured grant. In the process of A-IoT communication, A-IoT devices may enter or leave a coverage area of the BS. Therefore, any existing A-IoT RA information provided previously can be updated, or a new A-IoT RA information is required. In this case, the DCI transmitted in operation 401 is to schedule a PDSCH transmission in operation 402 for conveying RRC configuration signaling of a new / updated A-IoT RA information and a request trigger information for response transmissions by A-IoT devices. The request triggering information in the RRC configuration signaling could contain details such as:

[0108] 1. A paging / polling” information for paging a specific set or a subset of A-IoT devices that satisfy one or more criterion to transmit A-IoT response. Some examples of paging / polling / sampling criteria for A-IoT devices to transmit A-IoT response may include: (1) One or more A-IoT device / tag IDs or a range of A-IoT device / tag IDs (e.g., from ID xxx to ID xxx+50) . (2) Divisor value in a mathematical modulo operation (i.e., mod function) . (3) Location zone or distance range. (4) A-IoT device type index / ID.

[0109] 2. A “Request / response type” information for indicating the type of response from A-IoT devices is requested by the BS. In one example, the request / response type is device / tag ID only. In another example, the request / response type is device / tag ID + positioning / ranging information. In one more example, the request / response type is device / tag ID + sensor data.

[0110] In another case, the BS directly provides a request trigger and RA information in DCI and transmits in PDCCH in operation 401 to the intermediate UE using a dynamic scheduling method, where the request trigger and RA information is intended for A-IoT response transmissions from one or more A-IoT devices on the A-IoT UL interface. In order to achieve this intention of request / trigger one or more A-IoT response transmissions from A-IoT devices, the request triggering DCI can contain one or more of the following parameter fields.

[0111] 1. “Time and frequency resource assignment” fields, dynamic scheduling one or more PUSCH resources for A-IoT response transmission (s) ; these fields could be provided in DCI using separate parameters.

[0112] 2. “Periodicity” field, a periodicity value (e.g., 500ms, 1000ms, 2sec, 5sec, etc. ) indicating a set of periodic occurring time and frequency resources for multiple A-IoT response transmissions, and hence, minimizing PUCCH transmissions from the intermediate UE and reducing monitoring / blind decoding of ACI by A-IoT device.

[0113] 3. “Resource pool index / ID” , indicating a common set of time and frequency resources, a resource pool or a resource region on the A-IoT UL interface (e.g., a UL carrier) , in which A-IoT devices perform transmission of A-IoT responses.

[0114] 4. “Configuration index / ID” field, identifying a Type 2 configured grant that has been previously configured as part of RA information for A-IoT response transmission.

[0115] 5. “Activation and deactivation” field, indicating to A-IoT device to start transmitting or stop transmitting A-IoT responses using a Type 2 configured grant identified by the “configuration index / ID” field.

[0116] 6. “Paging / polling” field, paging a specific set or a subset of A-IoT devices that satisfy one or more criterion to transmit A-IoT response. To avoid or minimize potential transmission conflict / collision caused by more than one A-IoT devices sending responses in a same or overlapping PUSCH resource (due to a large number of A-IoT devices in the same area) , this parameter field sets the one or more criterion to limit the number of A-IoT devices sending responses together. Some examples of paging / polling / sampling criteria for A-IoT devices to transmit A-IoT response may include: (1) One or more A-IoT device / tag IDs or a range of A-IoT device / tag IDs (e.g., from ID xxx to ID xxx+50) . (2) Divisor value in a mathematical modulo operation (i.e., mod function) ; When this criterion is provided, a A-IoT device performs mathematical modulo operation of its device / tag ID and the divisor value (i.e., “Tag ID mod divisor” ) . If the remainder of the modulo operation is value ‘0’ , the A-IoT device transmits A-IoT response in the allocated / scheduled PUSCH resource. (3) Location zone or distance range; When a A-IoT device’s position is within the indicated location zone or distance range to the A-IoT request transmitter (e.g., 2, 5, 10, 20, 30 or 50 meters to the intermediate UE) , the A-IoT device transmits A-IoT response in the allocated / scheduled PUSCH resource. (4) A-IoT device type index / ID; A-IoT devices can be categorized into different types based on the device’s processing / transmission capability (e.g., passive or active) , peak power consumption (e.g., less than or more than X μW) and use case (e.g., meat or vegetable products, cars, trucks or bikes, luggage destination or flight number such as New York, London, Paris or Tokyo, etc. ) . Since there can be a very wide range of applications where A-IoT devices / tags can be used, this A-IoT device type index / ID can be configured in advanced.

[0117] 7. “Request / response type” field, indicating the type of response from A-IoT devices is requested by the BS. In one example, the request / response type is device / tag ID only. In another example, the request / response type is device / tag ID + positioning / ranging information. In one more example, the request / response type is device / tag ID + sensor data. As the request / response type can greatly influence the A-IoT response data traffic volume and pattern (e.g., periodic or event trigger only) , the BS UE could use this parameter field to dimension the number of required resources and to schedule appropriate time and frequency resources. Note that, since not every A-IoT device has the positioning / ranging determination capability and / or performs sensing, this “request / response type” field could be used in conjunction with the “paging / polling” field to further limit the amount of PUSCH resources that need to be allocated for response transmissions from A-IoT devices. A ‘0’ or ‘none’ value indicates no response is needed or expected from A-IoT device. This value can be indicated when the ACI is used for scheduling PDSCH resources on the A-IoT DL interface to convey A-IoT RA information to A-IoT device.

[0118] In operation 403, the BS further transmit / provide another DCI to the intermediate UE containing a A-IoT grant, scheduling a PUCCH or PUSCH transmission to transmit ACI to A-IoT devices.

[0119] For the A-IoT communication between the intermediate UE and one or more A-IoT devices, in operation 404, the intermediate UE transmits a ACI in PUCCH or PUSCH as scheduled by the BS in operation 403 to deliver / forward the same request trigger information and RA information received in operation 401 to A-IoT devices, or to schedule another PUSCH transmission for delivering the RRC configuration information containing the request trigger information and RA information received in operation 402 to A-IoT devices in operation 405. Note that, the RA provided by the intermediate UE in operation 405 could be a full set or a subset of the RA received in operation 402 from the BS. The main intention for the intermediate UE to forward only subset of the allocated resources from the BS is to avoid a potential TX conflict / collision due to large number of A-IoT devices sending responses together based on a same request / trigger ACI. As such, the ACI in operation 401 and triggering information in operation 405 can use the proposed polling / sampling-based paging mechanism.

[0120] 2nd Stage (A-IoT response transmission) : Intermediate UE receives and forwards A-IoT responses from A-IoT devices to BS:

[0121] For the response part of the proposed “request trigger and response” model in A-IoT communication, the main objective is for the intermediate UE to forward / relay A-IoT responses received from A-IoT devices to the BS.

[0122] In operation 406, after receiving all the necessary request trigger information and RA information from the intermediate UE (i.e., via a dynamic scheduling ACI in operation 404 or a configured scheduling in RRC in operation 405) , if a A-IoT device fulfills the request trigger criteria, the A-IoT device transmits A-IoT responses using the allocated / scheduled PUSCH resources on the A-IoT UL interface in operation 406 until operation 407 (if multiple A-IoT UL transmissions are needed to convey the A-IoT responses) . After A-IoT device’s response transmission in PUSCH, the intermediate UE may repeat operation 404 and transmit another ACI triggering more responses from A-IoT device to transmit on PUSCH of operation 406, or the intermediate UE simply provides / schedules more UL PUSCH resources for retransmission of the same TB.

[0123] In operation 407, in some cases, A-IoT device may perform multiple transmissions on the A-IoT UL interface without receiving an additional ACI scheduling more PUSCH resources for transmitting more than one TB, a retransmission of the same TB, or for periodic transmissions according to a traffic pattern.

[0124] In operation 408, the intermediate UE forwards / relays the A-IoT responses from the A-IoT devices to the BS using PUSCH. The forwarding operation could be a Layer 2 or a Layer 3 relay operation.

[0125] FIG. 10 illustrates a base station 1000 for wireless communication according to an embodiment of the present disclosure. The base station 1000 includes a transmitter 1001 configured to transmit a request trigger, a system-level and / or a resource allocation (RA) information intended for one or more A-IoT devices through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling, and a receiver 1002 configured to receive one or more Ambient-Internet of Things (A-IoT) responses from the one or more A-IoT devices. This can solve issues in the prior art and other issues and / or improve communication performance and reliability.

[0126] FIG. 11 illustrates an IoT device 1100 for wireless communication according to an embodiment of the present disclosure. The IoT device 1100 includes a receiver 1101 configured to receive a request trigger, a system-level and / or a resource allocation (RA) information from a base station through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling, and a transmitter 1102 configured to transmit one or more A-IoT responses intended for the base station. This can solve issues in the prior art and other issues and / or improve communication performance and reliability.

[0127] In summary, in some embodiments, in the present disclosure of resource allocation and scheduling methods for A-IoT device communication in a cellular system, a “request trigger and respond” strategy is proposed to address issues such as dimensioning transmission resources for a potentially very large number of A-IoT devices with diverse response data types and resolving UL transmission conflicts or collisions due to simultaneous A-IoT responses. The request trigger may be provided directly by the base station (BS) to A-IoT devices using a DCI in the PDCCH or RRC configuration signaling in the PDSCH, or it may be forwarded via an intermediate user equipment (UE) using an ACI in the PUCCH or RRC configuration signaling in the PUSCH. The request trigger includes parameters such as “paging / polling, ” which limits the number of responding A-IoT devices by criteria like device / tag IDs, modulo operations, location zones, or device type indexes; “request / response type, ” which specifies the type of response requested (e.g., device / tag ID, positioning data, or sensor data) and may work with “paging / polling” to minimize required PUSCH resources; “time and frequency resource assignment” for dynamically scheduling PUSCH resources; “periodicity” for recurring time and frequency resources; “resource pool index / ID” for identifying resource pools on the A-IoT UL interface; “configuration index / ID” for specifying a Type 2 configured grant; and “activation and deactivation” for controlling A-IoT response transmissions using the configured grant. When an intermediate UE is involved in forwarding request triggers, system-level information, or random access (RA) information from the BS to A-IoT devices, and relaying A-IoT responses to the BS, the intermediate UE utilizes scheduled PUCCH or PUSCH resources to transmit ACI, which either schedules PUSCH resources for delivering system-level and RA information over the A-IoT DL interface when no A-IoT response is required or allocates resources for A-IoT responses when required. The intermediate UE forwards A-IoT responses from devices to the BS over PUSCH using a Layer 2 or Layer 3 relay operation, ensuring efficient communication and resource management in the A-IoT system.

[0128] Commercial interests for some embodiments are as follows. 1. Solving issues in the prior art and other issues. 2. Improving a communication performance. 3. Some embodiments of the present disclosure are used by 5G-NR chipset vendors, V2X communication system development vendors, automakers including cars, trains, trucks, buses, bicycles, moto-bikes, helmets, and etc., drones (unmanned aerial vehicles) , smartphone makers, smart watches, wireless earbuds, wireless headphones, communication devices, remote control vehicles, and robots for public safety use, AR / VR device maker for example gaming, conference / seminar, education purposes, smart home appliances including TV, stereo, speakers, lights, door bells, locks, cameras, conferencing headsets, and etc., smart factory and warehouse equipment including IIoT devices, robots, robotic arms, and simply just between production machines. In some embodiments, commercial interest for the disclosed invention and business importance includes lowering power consumption for wireless communication means longer operating time for the device and / or better user experience and product satisfaction from longer operating time between battery charging. Some embodiments of the present disclosure are a combination of “techniques / processes” that can be adopted in 3GPP specification to create an end product. Some embodiments of the present disclosure relate to mobile cellular communication technology in 3GPP NR Releases 19, and beyond for providing IoT wireless communication services.

[0129] FIG. 12 is a block diagram of an example of a computing device according to an embodiment of the present disclosure. Any suitable computing device can be used for performing the operations described herein. For example, FIG. 12 illustrates an example of the computing device 1100 that can implement some embodiments in FIG. 1 to FIG. 11, using any suitably configured hardware and / or software. In some embodiments, the computing device 1100 can include a processor 1112 that is communicatively coupled to a memory 1114 and that executes computer-executable program code and / or accesses information stored in the memory 1114. The processor 1112 may include a microprocessor, an application-specific integrated circuit ( “ASIC” ) , a state machine, or other processing device. The processor 1112 can include any of a number of processing devices, including one. Such a processor can include or may be in communication with a computer-readable medium storing instructions that, when executed by the processor 1112, cause the processor to perform the operations described herein.

[0130] The memory 1114 can include any suitable non-transitory computer-readable medium. The computer-readable medium can include any electronic, optical, magnetic, or other storage device capable of providing a processor with computer-readable instructions or other program code. Non-limiting examples of a computer-readable medium include a magnetic disk, a memory chip, a read-only memory (ROM) , a random access memory (RAM) , an application specific integrated circuit (ASIC) , a configured processor, optical storage, magnetic tape or other magnetic storage, or any other medium from which a computer processor can read instructions. The instructions may include processor-specific instructions generated by a compiler and / or an interpreter from code written in any suitable computer-programming language, including, for example, C, C++, C#, visual basic, java, python, perl, javascript, and actionscript.

[0131] The computing device 1100 can also include a bus 1116. The bus 1116 can communicatively couple one or more components of the computing device 1100. The computing device 1100 can also include a number of external or internal devices such as input or output devices. For example, the computing device 1100 is illustrated with an input / output ( “I / O” ) interface 1118 that can receive input from one or more input devices 1120 or provide output to one or more output devices 1122. The one or more input devices 1120 and one or more output devices 1122 can be communicatively coupled to the I / O interface 1118. The communicative coupling can be implemented via any suitable manner (e.g., a connection via a printed circuit board, connection via a cable, communication via wireless transmissions, etc. ) . Non-limiting examples of input devices 1120 include a touch screen (e g., one or more cameras for imaging a touch area or pressure sensors for detecting pressure changes caused by a touch) , a mouse, a keyboard, or any other device that can be used to generate input events in response to physical actions by a user of a computing device. Non-limiting examples of output devices 1122 include a liquid crystal display (LCD) screen, an external monitor, a speaker, or any other device that can be used to display or otherwise present outputs generated by a computing device.

[0132] The computing device 1100 can execute program code that configures the processor 1112 to perform one or more of the operations described above with respect to FIG. 1 to FIG. 11. The program code may be resident in the memory 1114 or any suitable computer-readable medium and may be executed by the processor 1112 or any other suitable processor.

[0133] The computing device 1100 can also include at least one network interface device 1124. The network interface device 1124 can include any device or group of devices suitable for establishing a wired or wireless data connection to one or more data networks 1128. Non limiting examples of the network interface device 1124 include an Ethernet network adapter, a modem, and / or the like. The computing device 1100 can transmit messages as electronic or optical signals via the network interface device 1124.

[0134] FIG. 13 is a block diagram of an example system 700 for wireless communication according to an embodiment of the present disclosure. Embodiments described herein may be implemented into the system using any suitably configured hardware and / or software. FIG. 13 illustrates the system 700 including a radio frequency (RF) circuitry 710, a baseband circuitry 720, an application circuitry 730, a memory / storage 740, a display 750, a camera 760, a sensor 770, and an input / output (I / O) interface 780, coupled with each other at least as illustrated.

[0135] The application circuitry 730 may include a circuitry such as, but not limited to, one or more single-core or multi-core processors. The processors may include any combination of general-purpose processors and dedicated processors, such as graphics processors, application processors. The processors may be coupled with the memory / storage and configured to execute instructions stored in the memory / storage to enable various applications and / or operating systems running on the system.

[0136] The baseband circuitry 720 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processors may include a baseband processor. The baseband circuitry may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry. The radio control functions may include, but are not limited to, signal modulation, encoding, decoding, radio frequency shifting, etc. In some embodiments, the baseband circuitry may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry may support communication with an evolved universal terrestrial radio access network (EUTRAN) and / or other wireless metropolitan area networks (WMAN) , a wireless local area network (WLAN) , a wireless personal area network (WPAN) . Embodiments in which the baseband circuitry is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

[0137] In various embodiments, the baseband circuitry 720 may include circuitry to operate with signals that are not strictly considered as being in a baseband frequency. For example, in some embodiments, baseband circuitry may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency.

[0138] The RF circuitry 710 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network.

[0139] In various embodiments, the RF circuitry 710 may include circuitry to operate with signals that are not strictly considered as being in a radio frequency. For example, in some embodiments, RF circuitry may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency.

[0140] In various embodiments, the transmitter circuitry, control circuitry, or receiver circuitry discussed above with respect to the user equipment, eNB, or gNB may be embodied in whole or in part in one or more of the RF circuitry, the baseband circuitry, and / or the application circuitry. As used herein, “circuitry” may refer to, be part of, or include an application specific integrated circuit (ASIC) , an electronic circuit, a processor (shared, dedicated, or group) , and / or a memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and / or other suitable hardware components that provide the described functionality. In some embodiments, the electronic device circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules.

[0141] In some embodiments, some or all of the constituent components of the baseband circuitry, the application circuitry, and / or the memory / storage may be implemented together on a system on a chip (SOC) . The memory / storage 740 may be used to load and store data and / or instructions, for example, for system. The memory / storage for one embodiment may include any combination of suitable volatile memory, such as dynamic random access memory (DRAM) ) , and / or non-volatile memory, such as flash memory.

[0142] In various embodiments, the I / O interface 780 may include one or more user interfaces designed to enable user interaction with the system and / or peripheral component interfaces designed to enable peripheral component interaction with the system. User interfaces may include, but are not limited to a physical keyboard or keypad, a touchpad, a speaker, a microphone, etc. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, and a power supply interface.

[0143] In various embodiments, the sensor 770 may include one or more sensing devices to determine environmental conditions and / or location information related to the system. In some embodiments, the sensors may include, but are not limited to, a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of, or interact with, the baseband circuitry and / or RF circuitry to communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite.

[0144] In various embodiments, the display 750 may include a display, such as a liquid crystal display and a touch screen display. In various embodiments, the system 700 may be a mobile computing device such as, but not limited to, a laptop computing device, a tablet computing device, a netbook, an ultrabook, a smartphone, a AR / VR glasses, etc. In various embodiments, system may have more or less components, and / or different architectures. Where appropriate, methods described herein may be implemented as a computer program. The computer program may be stored on a storage medium, such as a non-transitory storage medium.

[0145] A person having ordinary skill in the art understands that each of the units, algorithm, and operations described and disclosed in the embodiments of the present disclosure are realized using electronic hardware or combinations of software for computers and electronic hardware. Whether the functions run in hardware or software depends on the condition of application and design requirement for a technical plan.

[0146] A person having ordinary skill in the art can use different ways to realize the function for each specific application while such realizations cannot go beyond the scope of the present disclosure. It is understood by a person having ordinary skill in the art that he / she can refer to the working processes of the system, device, and unit in the above-mentioned embodiment since the working processes of the above-mentioned system, device, and unit are basically the same. For easy description and simplicity, these working processes may not be detailed.

[0147] It is understood that the disclosed system, device, and method in the embodiments of the present disclosure can be realized with other ways. The above-mentioned embodiments are exemplary only. The division of the units is merely based on logical functions while other divisions exist in realization. It is possible that a plurality of units or components are combined or integrated in another system. It is also possible that some characteristics are omitted or skipped. On the other hand, the displayed or discussed mutual coupling, direct coupling, or communicative coupling operate through some ports, devices, or units whether indirectly or communicatively by ways of electrical, mechanical, or other kinds of forms.

[0148] The units as separating components for explanation are or are not physically separated. The units for display are or are not physical units, that is, located in one place or distributed on a plurality of network units. Some or all of the units are used according to the purposes of the embodiments. Moreover, each of the functional units in each of the embodiments can be integrated in one processing unit, physically independent, or integrated in one processing unit with two or more than two units.

[0149] If the software function unit is realized and used and sold as a product, it can be stored in a readable storage medium in a computer. Based on this understanding, the technical plan proposed by the present disclosure can be essentially or partially realized as the form of a software product. Or, one part of the technical plan beneficial to the conventional technology can be realized as the form of a software product. The software product in the computer is stored in a storage medium, including a plurality of commands for a computational device (such as a personal computer, a server, or a network device) to run all or some of the operations disclosed by the embodiments of the present disclosure. The storage medium includes a USB disk, a mobile hard disk, a read-only memory (ROM) , a random access memory (RAM) , a floppy disk, or other kinds of media capable of storing program codes.

[0150] While the present disclosure has been described in connection with what is considered the most practical and preferred embodiments, it is understood that the present disclosure is not limited to the disclosed embodiments but is intended to cover various arrangements made without departing from the scope of the broadest interpretation of the appended claims.

Claims

1.A resource allocation and scheduling method for Ambient-Internet of Things (A-IoT) communication performed by a base station, comprising:transmitting a request trigger, a system-level and / or a resource allocation (RA) information intended for one or more A-IoT devices through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling; andreceiving one or more A-IoT responses from the one or more A-IoT devices.2.The method of claim 1, wherein the request trigger comprises one or more of following parameters:a paging or polling used to page a set or a subset of the one or more A-IoT devices that satisfy one or more criterion to transmit the one or more A-IoT responses;a request or response type used to indicate a type of response from the one or more A-IoT devices is requested; a time and frequency resource assignment used to schedule one or more PUSCH resources for one or more A-IoT response transmissions;a periodicity containing a periodicity value and used to indicate a set of periodic occurring time and frequency resources for multiple A-IoT response transmissions;a resource pool index or identifier (ID) used to indicate a set of time and frequency resources, a resource pool, or a resource region on an A-IoT uplink interface;a configuration index or ID used to identify a type 2 configured grant;an activation and deactivation used to indicate the one or more A-IoT devices to start transmitting or stop transmitting the one or more A-IoT responses using the type 2 configured grant identified by the configuration index or ID.3.The method of claim 2, wherein one or more criterion comprises:one or more A-IoT device IDs or a range of A-IoT device IDs;a divisor value in a mathematical modulo operation;a location zone or distance range; and / oran A-IoT device type index or ID.4.The method of claim 2, wherein the request or response type is a device ID only, a device ID and a positioning or ranging information, or a device ID and a sensor data.5.The method of claim 1, wherein transmitting the request trigger, the system-level and / or the RA information intended for the one or more A-IoT devices through the signaling comprises:transmitting the request trigger, the system-level and / or the RA information intended for the one or more A-IoT devices using a downlink control information (DCI) in a physical downlink control channel (PDCCH) or a radio resource control (RRC) configuration signaling in a physical downlink shared channel (PDSCH) .6.The method of claim 1, wherein transmitting the request trigger, the system-level and / or the RA information intended for the one or more A-IoT devices through the signaling comprises:transmitting the request trigger, the system-level and / or the RA information intended for the one or more A-IoT devices via an intermediate node using an A-IoT control information (ACI) in a physical uplink control channel (PUCCH) or an RRC configuration signaling in a physical uplink shared channel (PUSCH) .7.The method of claim 1, wherein receiving the one or more A-IoT responses from the one or more A-IoT devices comprises:receiving the one or more A-IoT responses from the one or more A-IoT devices via an intermediate node.8.The method of claim 1, wherein if no A-IoT response transmission is required from the one or more A-IoT devices, a DCI format is transmitted from the base station to the intermediate node to schedule PUCCH and / or PUSCH resources for delivering the system-level and / or the RA information from the intermediate UE to the one or more A-IoT devices.9.The method of claim 1, wherein if an A-IoT response transmission is required from the one or more A-IoT devices, a DCI format is transmitted from the base station to the intermediate node to schedule a PUCCH or PUSCH resource to transmit an ACI containing the request trigger, and the request trigger in the ACI is used to schedule one or more PUSCH resources to the one or more A-IoT devices to transmit the one or more A-IoT responses.10.A resource allocation and scheduling method for Ambient-Internet of Things (A-IoT) communication performed by an A-IoT device, comprising:receiving a request trigger, a system-level and / or a resource allocation (RA) information from a base station through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling; and transmitting one or more A-IoT responses intended for the base station.11.The method of claim 10, wherein the request trigger comprises one or more of following parameters:a paging or polling used to page a set or a subset of the one or more A-IoT devices that satisfy one or more criterion to transmit the one or more A-IoT responses;a request or response type used to indicate a type of response from the one or more A-IoT devices is requested;a time and frequency resource assignment used to schedule one or more PUSCH resources for one or more A-IoT response transmissions;a periodicity containing a periodicity value and used to indicate a set of periodic occurring time and frequency resources for multiple A-IoT response transmissions;a resource pool index or identifier (ID) used to indicate a set of time and frequency resources, a resource pool, or a resource region on an A-IoT uplink interface;a configuration index or ID used to identify a type 2 configured grant;an activation and deactivation used to indicate the one or more A-IoT devices to start transmitting or stop transmitting the one or more A-IoT responses using the type 2 configured grant identified by the configuration index or ID.12.The method of claim 11, wherein one or more criterion comprises:one or more A-IoT device IDs or a range of A-IoT device IDs;a divisor value in a mathematical modulo operation;a location zone or distance range; and / oran A-IoT device type index or ID.13.The method of claim 11, wherein the request or response type is a device ID only, a device ID and a positioning or ranging information, or a device ID and a sensor data.14.The method of claim 10, wherein receiving the request trigger, the system-level and / or the RA information from the base station through the signaling comprises:receiving the request trigger, the system-level and / or the RA information from the base station using a downlink control information (DCI) in a physical downlink control channel (PDCCH) or a radio resource control (RRC) configuration signaling in a physical downlink shared channel (PDSCH) .15.The method of claim 10, wherein receiving the request trigger, the system-level and / or the RA information from the base station through the signaling comprises:receiving the request trigger, the system-level and / or the RA information from the base station via an intermediate node using an A-IoT control information (ACI) in a physical uplink control channel (PUCCH) or an RRC configuration signaling in a physical uplink shared channel (PUSCH) .16.The method of claim 10, wherein transmitting the one or more A-IoT responses intended for the base station comprises:transmitting the one or more A-IoT responses intended for the base station via an intermediate node.17.The method of claim 10, wherein if no A-IoT response transmission is required from the one or more A-IoT devices, the base station transmits, to the intermediate node, a DCI format used to schedule PUCCH and / or PUSCH resources for delivering the system-level and / or the RA information from the intermediate UE to the one or more A-IoT devices.18.The method of claim 10, wherein if an A-IoT response transmission is required from the one or more A-IoT devices, the base station transmits, to the intermediate node, a DCI format used to schedule a PUCCH or PUSCH resource to transmit an ACI containing the request trigger, and the request trigger in the ACI is used to schedule one or more PUSCH resources to the one or more A-IoT devices to transmit the one or more A-IoT responses.19.A base station, comprising:a transmitter configured to transmit a request trigger, a system-level and / or a resource allocation (RA) information intended for one or more A-IoT devices through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling; anda receiver configured to receive one or more Ambient-Internet of Things (A-IoT) responses from the one or more A-IoT devices.20.An Ambient-Internet of Things (A-IoT) device, comprising:a receiver configured to receive a request trigger, a system-level and / or a resource allocation (RA) information from a base station through a signaling, wherein the request trigger is used to indicate resource allocation and scheduling; anda transmitter configured to transmit one or more A-IoT responses intended for the base station.21.A base station, comprising:a memory;a transceiver; anda processor coupled to the memory and the transceiver;wherein the reader is configured to perform any one of claims 1 to 9.22.An Ambient-Internet of Things (A-IoT) device, comprising:a memory;a transceiver; anda processor coupled to the memory and the transceiver;wherein the device is configured to perform any one of claims 10 to 18.23.A non-transitory machine-readable storage medium having stored thereon instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 18.24.A chip, comprising:a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the method of any one of claims 1 to 18.25.A computer readable storage medium, in which a computer program is stored, wherein the computer program causes a computer to execute the method of any one of claims 1 to 18.26.A computer program product, including a computer program, wherein the computer program causes a computer to execute the method of any one of claims 1 to 18.27.A computer program, wherein the computer program causes a computer to execute the method of any one of claims 1 to 18.

Images