Transport block size indication for an ambient IoT device
By negotiating and adjusting transport block sizes based on device capabilities and radio conditions, ambient IoT systems achieve efficient and reliable data transfer, addressing the challenge of varying supportable block sizes.
Patent Information
- Application Number
- PCT/CN2024/108552
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-07-30
- Publication Date
- 2026-02-05
AI Technical Summary
In ambient IoT systems, the supportable size of transport blocks for data transmission is affected by radio conditions and device capabilities, necessitating a negotiation between devices and readers to determine a suitable block size for effective communication.
Methods for negotiating and indicating the size of a transport block include devices and readers exchanging information about their maximum data block size capabilities and radio resources, allowing for dynamic adjustments and segmentation to ensure successful data transfer.
This approach enables efficient and reliable data transfer by ensuring that the transport block sizes are aligned with the device's capabilities, reducing the likelihood of retransmissions and maintaining compliance with specified data sizes.
Smart Images

Figure CN2024108552_05022026_PF_FP_ABST
Abstract
Description
TRANSPORT BLOCK SIZE INDICATION FOR AN AMBIENT IOT DEVICEFIELD
[0001] This disclosure relates to wireless communications, and specifically to negotiation of communication parameters by a device and a reader in an ambient internet of things (AIoT) system.BACKGROUND
[0002] In an AIoT system, a “device” that may be extremely low-cost and low-power communicates on an AIoT interface with a “reader” . The reader may collect data from and / or issue commands to the device. The device may be thought of as a simple Internet of Things (IoT) object, such as a sensor or tag, but in principle it may have any function that does not require a large power supply or extensive over-the-air communication. The AIoT interface may be realized by a protocol stack comprising, for example, a physical (PHY) layer and a medium access control (MAC) layer, with the interface between the two layers being defined in terms of transport blocks (TBs) that carry upper-layer data. A TB may be seen as a protocol data unit (PDU) of the MAC layer and / or a service data unit (SDU) of the PHY layer.
[0003] Data exchange between the reader and the device may take place in either the device-to-reader (D2R) or reader-to-device (R2D) directions. However, in some versions of an AIoT system, data may be exchanged only when triggered by the reader, either in a device-terminated (DT) mode (data sent in the R2D direction, initiated by the reader sending the data to the device) or a device-originated / device-terminated-triggered (DO-DTT) mode (data sent in the D2R direction, initiated by the reader retrieving the data from the device) . The data may be formatted into transport blocks, meaning units of data delivered from a layer 2 sublayer to a physical layer in an AIoT protocol stack.
[0004] The supportable size of a transport block may be affected by radio conditions and device conditions. For example, in the R2D direction, the reader transmits to the device at a certain power level, and the ability of the device to decode the transmission depends on such factors as the device’s radio capabilities, the radio conditions and their effect on a received signal-to-interference-plus-noise ratio (SINR) at the device, the length of time for which the device’s energy reserves will support data reception, and so on. Similarly, in the D2R direction, the device transmits to the reader at a certain power level, and the ability of the reader to decode the transmission depends on such factors as the reader’s radio capabilities, the radio conditions and their effect on a received SINR at the reader, the length of time for which the device’s energy reserves will support data transmission, and so on. Because of these and other effects, a maximum transport block size may not always be usable for communication on the AIoT interface, and it may be necessary for the reader and the device to negotiate a transport block size that can be used for a particular transmission.
[0005] This disclosure is directed to methods of negotiating and indicating a size of a transport block for transmission on an AIoT interface, between a device and a reader.SUMMARY
[0006] The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.
[0007] In an aspect of the disclosure, a method of transferring data from a device to a reader is provided. The device indicates, to the reader, a maximum physical-layer data block size that the device can support receiving under a set of criteria. The device receives, from the reader, at least one physical-layer data block.
[0008] In another aspect of the disclosure, a method of transferring data from a reader to a device is provided. The reader sends, to the device, a paging message. The reader receives, from the device, a maximum physical-layer data block size. The reader transmits, to the device, at least one physical-layer data block of size less than or equal to the maximum size.
[0009] In another aspect of the disclosure, a method of transferring data from a device to a reader is provided. The device sends, to the reader, a maximum size of a physical-layer data block that the device can support transmitting under a set of criteria. The device receives, from the reader, an indication of radio resources. The device transmits, to the reader, at least one physical-layer data block, wherein the at least one physical-layer data block occupies at least a subset of the indicated radio resources, and wherein the size of the physical-layer data block is less than or equal to the maximum size.
[0010] In another aspect of the disclosure, a method of transferring data from a device to a reader is provided. The reader sends, to the device, a paging message. The reader receives, from the device, a maximum size of a physical-layer data block. The reader transmits, to the device, an indication of radio resources. The reader receives, from the device, at least one physical-layer data block, wherein the at least one physical-layer data block has a size less than or equal to the maximum size, and wherein the at least one physical-layer data block occupies at least a subset of the indicated radio resources.
[0011] In a further aspect of the disclosure, a method operable in a reader of negotiating a physical-layer data block size for transmission to a device is provided. The reader sends, to the device, a paging message and a request for data block size negotiation. The reader receives, from the device, an indication of a maximum data block size. The reader transmits, to the device, a physical-layer data block, wherein the size of the physical-layer data block is less than or equal to the maximum size.
[0012] In yet a further aspect of the disclosure, a method operable in a device of negotiating a physical-layer data block size for transmission from a reader is provided. The device receives, from the reader, a request for data block size negotiation. The device determines a maximum data block size. The device transmits, to the reader, an indication of the maximum size. The device receives, from the reader, a physical-layer data block, wherein the size of the data block is less than or equal to the maximum size.
[0013] In yet another aspect of the disclosure, a method operable in a reader of negotiating a physical-layer data block size for transmission from a device is provided. The reader sends, to the device, a paging message and a request for data block size negotiation. The reader receives, from the device, an indication of a maximum data block size. The reader transmits, to the device, an indication of radio resources. The reader receives, from the device, a physical-layer data block, wherein the size of the data block is less than or equal to the maximum size.
[0014] In an additional aspect of the disclosure, a method operable in a device of negotiating a physical-layer data block size for transmission to a reader is provided. The device receives, from the reader, a request for data block size negotiation. The device determines a maximum data block size. The device transmits, to the reader, an indication of the maximum size. The device receives, from the reader, an indication of radio resources. The device transmits, to the reader, a physical-layer data block, wherein the size of the data block is less than or equal to the maximum size, and wherein the data block occupies at least a subset of the indicated radio resources.
[0015] In another aspect of the disclosure, a method of segmentation adaptation operable at a reader is provided. The reader transmits, to a device, a paging message. The reader receives, from the device, an indication of a maximum physical-layer data block size. The reader indicates, to an upper-layer entity, the maximum size. The reader receives, from the upper-layer entity, an SDU of a MAC layer. The reader transmits, to the device, a physical-layer data block, wherein the application data in the physical-layer data block comprises the application data in the MAC SDU.
[0016] In another aspect of the disclosure, a method of upper-layer segmentation adaptation operable in a device is provided. The device sends, to a reader, an indication of a maximum physical-layer data block size. The device receives, from the reader, an indication of radio resources. The device indicates, to an upper layer of the device, a request for data segmented to fit the maximum size. The device transmits, to the reader, a physical-layer data block, wherein the size of the physical-layer data block is less than or equal to the maximum size, and wherein the physical-layer data block occupies at least a subset of the indicated radio resources.
[0017] To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.BRIEF DESCRIPTION OF THE DRAWINGS
[0018] FIG. 1 is a diagram illustrating a portion of an exemplary AIoT system.
[0019] FIG. 2 is a diagram illustrating an exemplary set of protocol stacks for the interfaces of an AIoT system.
[0020] FIG. 3 is a flow diagram illustrating an exemplary procedure on the AIoT interface for device-terminated data transfer with a long random access procedure.
[0021] FIG. 4 is a flow diagram illustrating an exemplary procedure on the AIoT interface for device-terminated data transfer with a short random access procedure.
[0022] FIG. 5 is a flow diagram illustrating an exemplary procedure on the AIoT interface for device-originated / device-terminated-triggered data transfer with a long random access procedure.
[0023] FIG. 6 is a flow diagram illustrating an exemplary procedure on the AIoT interface for device-originated / device-terminated-triggered data transfer with a short random access procedure.
[0024] FIG. 7 is a flow diagram illustrating an exemplary procedure on the AIoT interface for device-terminated data transfer with a long random access procedure and transport block size information.
[0025] FIG. 8 is a flow diagram illustrating an exemplary procedure on the AIoT interface for device-terminated data transfer with a short random access procedure and transport block size information.
[0026] FIG. 9 is a flow diagram illustrating an exemplary procedure on the AIoT interface for device-originated / device-terminated-triggered data transfer with a long random access procedure and transport block size information.
[0027] FIG. 10 is a flow diagram illustrating an exemplary procedure on the AIoT interface for device-originated / device-terminated-triggered data transfer with a short random access procedure and transport block size information.
[0028] FIG. 11 shows dynamic TB size negotiation on the AIoT interface, including paging, negotiation request, assessment, final indication, and data transfer.
[0029] FIG. 12 shows upper layer segmentation adaptation on the AIoT interface, including paging, segmentation request, data segmentation, and data transfer.DETAILED DESCRIPTION
[0030] The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.
[0031] Several aspects of telecommunication systems will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.
[0032] Figure 1 shows a portion of an exemplary AIoT system. The system as shown comprises two devices, which are intended to be low-cost and low-power or even batteryless (for example, powering themselves via energy harvesting) ; a UE-type reader, which communicates over an AIoT interface with the first device and which is embodied in a user equipment (UE) ; a base station (BS) such as a gNode B (gNB) that serves the UE-type reader over a Uu interface; a BS-type reader, which communicates over an AIoT interface with the second device and which is embodied in a BS; a controller, which communicates via an application protocol with the readers over a logical A-RC interface and which may, for example, be embodied at a node of a 5G core network (CN) ; and an application function (AF) , which communicates via an application programming interface (API) with the controller over a logical A-CA interface to exchange application data with the devices and which may be embodied at a node of a 5G CN (5GC) . As shown in the figure, the A-RC interface may traverse various other interfaces; in particular, for the UE-type reader, the A-RC interface must traverse the Uu interface as well as any network interfaces connecting the serving BS to the node that hosts the controller.
[0033] Figure 2 shows an exemplary set of protocol stacks for the interfaces of an AIoT system similar to that shown in figure 1. The device and the reader communicate on an AIoT interface via an AIoT physical (PHY) layer and an AIoT medium access control (MAC) layer. The reader and the controller communicate via a reader application protocol (R-AP) on a logical A-RC interface, supported by network and / or Uu interfaces (indicated in the figure as “NW / Uu” ) , whose details are outside the scope of this disclosure. The logical A-RC interface may traverse various network nodes and interfaces, and in the case of a UE-type reader, the A-RC interface may also traverse a Uu interface between a serving base station and the UE hosting the reader. The controller and the AF communicate via an AIoT API over a logical A-CA interface, supported by a service-based interface (SBI) protocol stack whose details are outside the scope of this disclosure. Finally, the device and the AF communicate end-to-end via an AIoT protocol, which may, for example, comprise such operations as read and write commands with associated blocks of application data. It should be appreciated that other protocol stack designs are possible, but for purposes of this disclosure, the important aspects are that the AIoT MAC and PHY layers connect the device and the reader, and that the MAC layer carries data blocks of an upper layer between the AF and the device.
[0034] Figure 3 is a flow diagram showing an exemplary procedure on the AIoT interface for device-terminated (DT) data transfer, meaning delivery of data from the reader to the device, with a long random access procedure (sometimes called a “4-step” random access procedure for historical reasons) . In step 1, prompted by a need to transfer data to the device (e.g., due to the arrival of data from upper layers or the generation of a signalling message) , the reader sends an AIoT paging message to the device. Steps 2, 3, and 4 constitute an AIoT random access procedure. In step 2, the device sends a so-called “Msg1” transmission, comprising a randomly selected identifier for the device. In step 3, the reader sends a so-called “Msg2” transmission, echoing back to the device the randomly selected identifier from step 2. In step 4, the device sends a so-called “Msg3” transmission, conveying an identifier of the device (which may, for instance, be a persistent unique identifier) and completing the random access procedure. In step 5, the reader sends data in the reader-to-device (R2D) direction, completing the transfer of data to the device.
[0035] Figure 4 is a flow diagram showing an exemplary procedure on the AIoT interface for DT data transfer with a short random access procedure (sometimes called a “2-step” random access procedure for historical reasons) . In step 1, prompted by a need to transfer data to the device (e.g., due to the arrival of data from upper layers or the generation of a signalling message) , the reader sends an AIoT paging message to the device. Step 2 constitutes an AIoT random access procedure. In step 2, the device sends a so-called “Msg1” transmission, comprising a device identifier (which may, for instance, be a persistent unique identifier) and completing the random access procedure. In step 3, the reader sends data in the R2D direction, completing the transfer of data to the device.
[0036] Figure 5 is a flow diagram showing an exemplary procedure on the AIoT interface for device-originated / device-terminated-triggered (DO-DTT) data transfer with a long ( “4-step” ) random access procedure, with data transfer during the random access procedure. In step 1, prompted by a trigger to retrieve data from the device, the reader sends an AIoT paging message to the device. Steps 2, 3, and 4 constitute an AIoT random access procedure. In step 2, the device sends a Msg1 transmission to the reader, comprising a randomly selected identifier for the device. In step 3, the reader sends a Msg2 transmission, echoing back to the device the randomly selected identifier from step 2. In step 4, the device sends a Msg3 transmission, conveying an identifier of the device (which may, for instance, be a persistent unique identifier) and a block of device-to-reader (D2R) data, and completing the random access procedure. In step 5, the reader may acknowledge the D2R data transmission from step 4. Subsequent transfer of additional D2R and / or R2D data may be possible with further steps not shown in the figure. In some alternative versions of this procedure, the D2R data may not be included in step 4, and instead Msg3 may include only the device ID (and potentially other information related to operations on the AIoT interface) . In such a case, step 5 comprises a transmission from the reader to the device requesting D2R data transmission, and a following sixth step comprises a transmission of the requested D2R data from the device to the reader. A further following seventh step may comprise an acknowledgement of the D2R data, sent from the reader to the device.
[0037] Figure 6 is a flow diagram showing an exemplary procedure on the AIoT interface for DO-DTT data transfer with a short ( “2-step” ) random access procedure, with data transfer during the random access procedure. In step 1, prompted by a trigger to retrieve data from the device, the reader sends an AIoT paging message to the device. Step 2 constitutes an AIoT random access procedure. In step 2, the device sends a Msg1 transmission to the reader, comprising a device identifier (which may, for instance, be a persistent unique identifier) and a block of D2R data, and completing the random access procedure. In step 3, the reader may acknowledge the D2R data transmission from step 2. Subsequent transfer of additional D2R and / or R2D data may be possible with further steps not shown in the figure. In some alternative versions of this procedure, the D2R data may not be included in step 2, and instead Msg1 may include only the device ID (and potentially other information related to operations on the AIoT interface) . In such a case, step 3 comprises a transmission from the reader to the device requesting D2R data transmission, and a following fourth step comprises a transmission of the requested D2R data from the device to the reader. A further following fifth step may comprise an acknowledgement of the D2R data, sent from the reader to the device.
[0038] Figure 7 is a flow diagram showing an exemplary procedure on the AIoT interface for DT data transfer with a 4-step random access procedure including transport block size information in Msg3, in accordance with an embodiment of this invention. Steps 1-3 are as in figure 3 (paging / Msg1 / Msg2) . In step 4 (Msg3) , in addition to the device identifier, the device includes transport block (TB) size information, comprising an indication of a maximum size of a physical-layer data block that the device can support receiving. A transport block may also be referred to as a protocol data unit (PDU) of the MAC layer of the AIoT interface protocol stack. As one example, the TB size information in Msg3 may comprise an explicit indication of a maximum size, such as an individual value or a selection from an enumerated set of candidate values. As another example, the TB size information in Msg3 may comprise a flag with two or more values, representing agreed-upon concepts of a “small” or “large” TB, a “small” / “medium” / “large” TB, and so on. As a third example, the TB size information in Msg3 may comprise an indication of a maximum reception time that the device can support (based, for example, on the device’s current energy reserves) . These values may be set by the device based on radio conditions, power conditions of the device, available radio resources, the device’s supportable data rate, or other conditions that affect the ability of the device to receive TBs of different sizes. In step 5, the reader sends R2D data to the device, formatting the data using TB sizes compatible with the TB size information received in step 4, allowing the device to receive the data successfully (with an acceptably high probability) according to the constraints affecting the supportable TB size.
[0039] As one example of conditions affecting the supportable TB size, suppose that TB sizes of 40 bits, 100 bits, and 400 bits are available, with potentially supportable data rates of 1 Kbps and 5 Kbps. (It should be appreciated that these numbers are chosen for the sake of a concrete example, and that substantially any other values of the TB sizes and the data rates could be applicable. ) Suppose further that the device’s current coverage conditions (as determined, for example, by the device measuring the reception performance of a transmission from the reader, such as the paging message and / or Msg2) will support a maximum data rate of 1 Kbps with the reader, meaning that each data bit requires 1 ms to transmit / receive over the AIoT interface. (Here “support” may refer, for instance, to the anticipated ability to close the link with an acceptable error rate. ) Finally, suppose that the device currently has enough reserve power to stay awake and receive data for a maximum of 150 ms. It follows that the device can receive up to 150 bits of data at the supportable data rate. Accordingly, the device may indicate in Msg3 (or any D2R transmission that carries TB size information) a maximum TB size of 100 bits, since it cannot support the larger 400-bit size. The reader may receive this size indication and infer that it cannot transmit more to this device than a 100-bit TB. (Alternatively, the device may give an indication that it can support up to 150 bits of data, although the value 150 is not a supported TB size; this indication may allow the reader to transmit a 100-bit TB and a 40-bit TB in succession, achieving 140 bits of data transfer, for example. )
[0040] In some embodiments, the available TB sizes in the D2R and R2D directions may be different. As one example, the configuration of the AIoT interface may be such that a 400-bit TB size is assumed to be always available for transmission in the R2D direction, but smaller TB sizes may be needed in the D2R direction (for example, to account for the possibility that the device does not have enough energy reserves to transmit a 400-bit TB) . In such a case, the reader may always assume that the largest TB size is available for R2D transmission, while engaging in TB size negotiations of the sort described in this disclosure for D2R transmission.
[0041] Figure 8 is a flow diagram showing an exemplary procedure on the AIoT interface for DT data transfer with a 2-step random access procedure including TB size information in Msg1, in accordance with an embodiment of this invention. Step 1 is as in figure 4 (paging) . In step 2 (Msg1) , in addition to the device identifier, the device includes TB size information, comprising an indication of a maximum size of a physical-layer data block that the device can support receiving. The various formats and semantics that the TB size information may take are similar to those described above under figure 7. In addition, in some embodiments, the TB size information may be carried implicitly by Msg1, for example, through the selection of physical-layer parameters controlling the transmission. As one example, if Msg1 is formatted as a “preamble” sequence (similar to Msg1 of the random access procedure on a Uu interface in a 5G NR cellular system, for instance) , certain selections of the preamble sequence may imply particular values of the supportable TB size. As another example, the radio resources used for Msg1 transmission may be selected with a maximum TB size in mind, such that, for instance, a first set of radio resources is used for Msg1 when the device can support a first maximum TB size and a second set of radio resources when the device can support a second maximum TB size. In step 3, the reader sends R2D data to the device, formatting the data using TB sizes compatible with the TB size information received in step 2, allowing the device to receive the data successfully (with an acceptably high probability) according to the constraints affecting the supportable TB size.
[0042] Figure 9 is a flow diagram showing an exemplary procedure on the AIoT interface for DO-DTT data transfer with a 4-step random access procedure including TB size information in Msg1, in accordance with an embodiment of this invention. Step 1 is as in figure 5 (paging) . In step 2 (Msg1) , in addition to the randomly selected identifier, the device includes TB size information, comprising an indication of a maximum size of a physical-layer data block that the device can support transmitting. The various formats and semantics that the TB size information may take are similar to those described above under figure 7. In step 3 (Msg2) , the reader sends a Msg2 transmission, echoing back to the device the randomly selected identifier from step 2, and potentially also providing a configuration for the transmission of Msg3 in the upcoming step 4. For example, the configuration may comprise a transport block size to be used, an allocation of radio resources to be used, and so on. The configuration may be conveyed by MAC layer signalling, PHY layer signalling, or a combination of MAC and PHY layer signalling. In step 4 (Msg3) , the device sends a Msg3 transmission, conveying an identifier of the device (which may, for instance, be a persistent unique identifier) and a block of D2R data, and completing the random access procedure. In step 5, the reader may acknowledge the D2R data from step 4. In some alternative versions of this procedure, the D2R data may not be included in step 4, and instead Msg3 may include only the device ID (and potentially other information related to operations on the AIoT interface) . In such a case, step 5 comprises a transmission from the reader to the device requesting D2R data transmission, and a following sixth step comprises a transmission of the requested D2R data from the device to the reader. A further following seventh step may comprise an acknowledgement of the D2R data, sent from the reader to the device. In such an alternative version of the procedure, the TB size information may be included in Msg3 rather than Msg1, and the above-described configuration for the transmission of D2R data (which in the above example applies to step 4 / Msg3, but here applies to step 6 / D2R data transmission) may be included in the transmission of step 5.
[0043] Figure 10 is a flow diagram showing an exemplary procedure on the AIoT interface for DO-DTT data transfer with a 2-step random access procedure including TB size information in Msg1, in accordance with an embodiment of this invention. Step 1 is as in figure 6 (paging) . In step 2 (Msg1) , in addition to the device identifier, the device includes TB size information, comprising an indication of a maximum size of a physical-layer data block that the device can support transmitting. The various formats and semantics that the TB size information may take are similar to those described above under figure 7. In step 3, the reader sends a configuration for D2R data transmission, to be used for the upcoming data transmission in step 4. For example, the configuration may comprise a transport block size to be used, an allocation of radio resources to be used, and so on. The configuration may be conveyed by MAC layer signalling, PHY layer signalling, or a combination of MAC and PHY layer signalling. In step 4, the device transmits to the reader a block of D2R data, using the configuration provided in step 3. In step 5, the reader may acknowledge the D2R data from step 4.
[0044] In some embodiments, the 2-step AIoT random access procedure for DO-DTT data transfer may support forms including data directly in Msg1 (figure 6) and including TB size information without data in Msg1 (figure 7) . In such cases, the device may determine whether to include D2R data in Msg1 based on the available radio resources for Msg1; for example, there may be a maximum size of data that Msg1 can contain, and the device may include data in Msg1 if the device’s queue of data to transmit fits within that maximum size, while otherwise, the device may include TB size information in Msg1. As one example, if Msg1 can contain 40 bits of data and the device has 80 bits of data to transmit, but the device has sufficient coverage and power reserves to transmit the full 80 bits, the device may opt to send Msg1 comprising TB size information, expecting to receive a configuration for subsequent D2R transmission (as in step 3 of figure 10) that supports carriage of the full 80-bit data block.
[0045] In some embodiments, the transmission of R2D or D2R data may include a “more data” flag, e.g., a flag indicating that the sender has more data queued that needs to be transmitted in a subsequent transfer. Thus, for instance, in the example above, the device might include the first 40 bits of data in Msg1, along with a “more data” indicator, expecting that the reader will respond with a configuration allowing the device to transmit the rest of its D2R data. The “more data” indicator may be a single-bit flag indicating whether more data exist, or it may indicate an amount of queued data, a required TB size to contain the remaining data, and so on. Such an indicator may be useful in case a negotiated TB size cannot contain all the data that are queued for transmission. In the example given above where Msg1 can contain 40 bits of application data and the device has 80 bits of data to transmit, the device may include, in Msg1, the first 40 bits of data along with a “more data” indicator; subsequently, the reader may transmit to the device a configuration or grant allowing the transmission of further data in a subsequent TB. If Msg1 contains all of application data, a “more data” indicator, and an indication of a supportable TB size, the reader may align its configuration or grant with the supportable TB size, so that the device can transmit as much of its application data as possible within the configured radio resources.
[0046] Figure 11 is a flow diagram showing an exemplary procedure on the AIoT interface for dynamic TB size negotiation for R2D data transmission, in accordance with an embodiment of this invention. Steps 1-2 are as in figure 3 (paging / Msg1 / Msg2) . In step 3, the reader sends a request for dynamic TB size negotiation. In step 4, the device assesses current radio conditions and power status. In step 5, the device sends a final TB size indication to the reader. In step 6, the reader sends R2D data formatted according to the negotiated TB size, allowing the device to receive the data successfully according to the constraints affecting the supportable TB size.
[0047] This embodiment introduces a new signaling mechanism where the reader can request dynamic TB size negotiation. The device assesses current radio conditions and power status to provide a final TB size indication. This ensures that the TB size is dynamically adjusted to the optimal value, reducing the likelihood of retransmissions with different TB sizes. The padding is placed at the end of the MAC PDU if present, and the presence and length of padding are implicit (e.g., may be inferred by the receiving node, in this case the device) based on TB size and the size of MAC PDU (s) and / or subPDU (s) . This dynamic negotiation mechanism ensures that the padding is correctly handled based on the dynamically negotiated TB size.
[0048] In some embodiments, a similar mechanism for dynamic TB size negotiation may be used for D2R data transmission. The initial steps of such a procedure are similar to figure 11, but in step 6, the reader may send to the device an indication of radio resources to use for a D2R data transmission, concordant with the final TB size indicated in step 5. In step 7, the device may use the indicated radio resources from step 6 to transmit D2R data to the reader. As with the R2D embodiment described above, the TB may be filled out with padding bits.
[0049] Figure 12 is a flow diagram showing an exemplary procedure on the AIoT interface for upper layer segmentation adaptation for R2D data transmission, in accordance with an embodiment of this invention. Steps 1-2 are as in figure 4 (paging / Msg1) . In step 3, the reader's upper layer requests upper layer segmentation based on the initial TB size. In step 4, the reader requests, from a controller or application function, data segmented to fit within the indicated TB size. In step 5, the reader sends segmented data and potentially TB size information to the device, allowing the device to receive the data successfully according to the constraints affecting the supportable TB size. The UE reports the TB size in Msg1 (step 2) , and the reader can send TB size information in step 5 if the TB size is not the same as the UE's report. If the reader does not send the TB size information, it implies that the TB size is the same as the reported value.
[0050] This embodiment introduces a new mechanism where the reader requests upper layer segmentation based on the initial TB size. The reader's upper layer segments data to fit within the indicated TB size, ensuring compliance with the specification that a maximum of one MAC PDU can be transmitted per TB per MAC entity. Additionally, padding is placed at the end of the MAC PDU if present, and the presence and length of padding are implicit based on TB size and the size of MAC PDU (s) and / or subPDU (s) . This embodiment ensures that the segmented data fits within the TB size, and the padding is correctly handled. Furthermore, the MAC PDU structure may be maintained, where the last MAC subPDU for MAC SDU is placed before the MAC subPDU with padding. The size of padding in the MAC subPDU with padding can be zero, and the length of padding is implicit based on TB size and the size of MAC PDU (s) and / or subPDU (s) . This embodiment ensures that the multiplexing of MAC SDUs onto transport blocks (TB) to be delivered to the physical layer on transport channels is correctly handled.
[0051] In some embodiments, a similar mechanism for upper-layer segmentation adaptation may be applied for D2R data transmission. The initial steps of such a procedure are similar to figure 12, but steps 3 and 4 of figure 12 (internal processes to the reader) may not occur. In (the equivalent of) step 5, the reader may send a communication (for example, Msg2) to the device, containing an indication of radio resources to be used for transmission of D2R data, the size of the radio resources being conformant with the supportable TB size indicated in step 2. In a following step, the device may request its upper layers to segment data according to the size of the indicated radio resources, followed by transmitting a segment of D2R data in the indicated radio resources.
[0052] It is understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
[0053] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more. ” The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” include any combination of A, B, and / or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module, ” “mechanism, ” “element, ” “device, ” and the like may not be a substitute for the word “means. ” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for.”
Claims
1.A method of transferring data operable at a device of an ambient IoT (AIoT) system, comprising:indicating, to a reader of the AIoT system, a maximum size of a physical-layer data block that the device can support receiving under a set of criteria; andreceiving, from the reader, at least one physical-layer data block.2.The method of claim 1, wherein the set of criteria comprises one or more of a minimum decoding probability, a minimum anticipated signal-to-noise ratio, a maximum data rate, a maximum reception time, a maximum probability of symbol error, and a maximum probability of block error.3.The method of claim 1, wherein the indicating comprises sending the maximum size in a Msg3 transmission of a random access procedure.4.The method of claim 1, wherein the indicating comprises sending the maximum size in a Msg1 transmission of a random access procedure.5.The method of claim 1, wherein the maximum size is selected from a set of possible data block sizes.6.The method of claim 1, wherein the maximum size is indicated as an explicit number of bits or octets.7.The method of claim 1, wherein the maximum size is indicated as a maximum reception time.8.A method of transferring data operable at a reader of an ambient IoT (AIoT) system, comprising:sending, to a device of the AIoT system, a paging message;receiving, from the device, a maximum size of a physical-layer data block; andtransmitting, to the device, at least one physical-layer data block of size less than or equal to the maximum size.9.The method of claim 8, wherein the receiving comprises receiving the maximum size in a Msg3 transmission of a random access procedure.10.The method of claim 8, wherein the receiving comprises receiving the maximum size in a Msg1 transmission of a random access procedure.11.The method of claim 8, wherein the maximum size is selected from a set of possible data block sizes.12.The method of claim 8, wherein the maximum size is indicated as an explicit number of bits or octets.13.The method of claim 8, wherein the maximum size is indicated as a maximum reception time.14.The method of claim 8, wherein the data block comprises a set of application data bits and zero or more padding bits.15.A method of transferring data operable at a device of an ambient IoT (AIoT) system, comprising:transmitting, to a reader of the AIoT system, a maximum size of a physical-layer data block that the device can support transmitting under a set of criteria;receiving, from the reader, an indication of radio resources; andtransmitting, to the reader, at least one physical-layer data block,wherein the at least one physical-layer data block occupies at least a subset of the indicated radio resources, andwherein the size of the physical-layer data block is less than or equal to the maximum size.16.The method of claim 15, wherein the set of criteria comprises one or more of a minimum decoding probability, a minimum anticipated signal-to-noise ratio, a maximum data rate, a maximum transmission time, a maximum probability of symbol error, and a maximum probability of block error.17.The method of claim 15, wherein the indicating comprises sending the maximum size in a Msg3 transmission of a random access procedure.18.The method of claim 15, wherein the indicating comprises sending the maximum size in a Msg1 transmission of a random access procedure.19.The method of claim 15, wherein the maximum size is selected from a set of possible data block sizes.20.The method of claim 15, wherein the maximum size is indicated as an explicit number of bits or octets.21.The method of claim 15, wherein the maximum size is indicated as a maximum reception time.22.A method of transferring data operable at a reader of an ambient IoT (AIoT) system, comprising:sending, to a device of the AIoT system, a paging message;receiving, from the device, a maximum size of a physical-layer data block;transmitting, to the device, an indication of radio resources; andreceiving, from the device, at least one physical-layer data block,wherein the at least one physical-layer data block has a size less than or equal to the maximum size, andwherein the at least one physical-layer data block occupies at least a subset of the indicated radio resources.23.The method of claim 22, wherein the receiving comprises receiving the maximum size in a Msg3 transmission of a random access procedure.24.The method of claim 22, wherein the receiving comprises receiving the maximum size in a Msg1 transmission of a random access procedure.25.The method of claim 22, wherein the maximum size is selected from a set of possible data block sizes.26.The method of claim 22, wherein the maximum size is indicated as an explicit number of bits or octets.27.The method of claim 22, wherein the maximum size is indicated as a maximum reception time.28.A method operable in a reader of an AIoT system for negotiating a physical-layer data block size for transmission to a device of the AIoT system, comprising:sending, to the device, a paging message and a request for data block size negotiation;receiving, from the device, an indication of a maximum data block size; andtransmitting, to the device, a physical-layer data block,wherein the size of the data block is less than or equal to the maximum size.29.The method of claim 28, wherein the sending the request for data block size negotiation comprises sending the request in a paging message.30.The method of claim 28, wherein the sending the request for data block size negotiation comprises sending the request in Msg2 of a random access procedure.31.The method of claim 28, wherein the data block comprises a set of application data bits and zero or more padding bits.32.A method operable in a device of an AIoT system for negotiating a physical-layer data block size for transmission from a reader of the AIoT system, comprising:receiving, from the reader, a request for data block size negotiation;determining a maximum data block size;transmitting, to the reader, an indication of the maximum size; andreceiving, from the reader, a physical-layer data block,wherein the size of the data block is less than or equal to the maximum size.33.The method of claim 32, wherein the receiving the request for data block size negotiation comprises receiving the request in a paging message.34.The method of claim 32, wherein the receiving the request for data block size negotiation comprises receiving the request in Msg2 of a random access procedure.35.The method of claim 32, wherein the data block comprises a set of application data bits and zero or more padding bits.36.A method operable in a reader of an AIoT system for negotiating a physical-layer data block size for transmission from a device of the AIoT system, comprising:sending, to the device, a paging message and a request for data block size negotiation;receiving, from the device, an indication of a maximum data block size;transmitting, to the device, an indication of radio resources; andreceiving, from the device, a physical-layer data block,wherein the size of the data block is less than or equal to the maximum size.37.The method of claim 36, wherein the sending the request for data block size negotiation comprises sending the request in a paging message.38.The method of claim 36, wherein the sending the request for data block size negotiation comprises sending the request in Msg2 of a random access procedure.39.The method of claim 36, wherein the data block comprises a set of application data bits and zero or more padding bits.40.A method operable in a device of an AIoT system for negotiating a physical-layer data block size for transmission to a reader of the AIoT system, comprising:receiving, from the reader, a request for data block size negotiation;determining a maximum data block size;transmitting, to the reader, an indication of the maximum size;receiving, from the reader, an indication of radio resources; andtransmitting, to the reader, a physical-layer data block,wherein the size of the data block is less than or equal to the maximum size, andwherein the data block occupies at least a subset of the indicated radio resources.41.The method of claim 40, wherein the receiving the request for data block size negotiation comprises receiving the request in a paging message.42.The method of claim 40, wherein the receiving the request for data block size negotiation comprises receiving the request in Msg2 of a random access procedure.43.The method of claim 40, wherein the data block comprises a set of application data bits and zero or more padding bits.44.A method operable at a reader of an AIoT system, comprising:transmitting, to a device of the AIoT system, a paging message;receiving, from the device, an indication of a maximum physical-layer data block size;indicating, to an upper-layer entity, the maximum size;receiving, from the upper-layer entity, an SDU of a MAC layer; andtransmitting, to the device, a physical-layer data block,wherein the application data in the physical-layer data block comprises the application data in the MAC SDU.45.The method of claim 44, wherein the upper-layer entity is a controller of the AIoT system.46.The method of claim 44, wherein the upper-layer entity is an application function of the AIoT system.47.A method operable at a device of an AIoT system, comprising:sending, to a reader of the AIoT system, an indication of a maximum physical-layer data block size;receiving, from the reader, an indication of radio resources;indicating, to an upper layer of the device, a request for data segmented to fit the maximum size; andtransmitting, to the reader, a physical-layer data block,wherein the size of the physical-layer data block is less than or equal to the maximum size, andwherein the physical-layer data block occupies at least a subset of the indicated radio resources.
Citation Information
Patent Citations
Communication method and device
CN117528645A
Determining Maximum Transport Block Size
US20190068333A1
Data transmission method and apparatus
US20210105086A1
Random Access Identifier for Reduced Capability Device
US20240032103A1